From nobody Fri Jun 2 07:11:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9712EB9E for ; Fri, 2 Jun 2017 07:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjVqQbHiXMw2 for ; Fri, 2 Jun 2017 07:11:17 -0700 (PDT) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 3618B12946D for ; Fri, 2 Jun 2017 07:11:17 -0700 (PDT) Received: by mail-wm0-f49.google.com with SMTP id d127so27952643wmf.0 for ; Fri, 02 Jun 2017 07:11:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=50DiJxZIUl0WwGUlqf+jms6gMQMe+EwQqZ6Iv+JZJSs=; b=oY4L6F4f84lbq+E8HMUvK4F5jncF9vvHspJCxHFO2g+ZFQjQDyySYc88cZm1ki+5qe GVw/UxaROKnRyg8jUovp5CfQChDZXAr9VpXuBfbJ0pCKWEnNTjIBg557e6XSXdGMKyLT vlKxUUeP4IRyDaDPwU85KUA5deUllLmQi6lpcTGGFft38V3eQyVjJxPFNhHKIgmEMX4i Rn9bcCyyCx8tn68f2ZByYa4CTKiGdCrF1AwMCD6dgpEcUs4qXkR+Ig78xGNt4vPjc7sE cuZPCVYCiP4DHwyLGv/U8ASGYfhXTSWVkiOXotKssz1Se/C9KhcJTFhzCsCl86AplWtz cbRg== X-Gm-Message-State: AODbwcBPzvwe7AerSs7fKdry0i1UEpBG1u6alylHoe/Bq6TBABVIcgGT DGhGGzE+h6ZqGe+/J0hg7Q== X-Received: by 10.80.166.33 with SMTP id d30mr6287358edc.115.1496412675259; Fri, 02 Jun 2017 07:11:15 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:cddf:8b77:9087:26d0]) by smtp.gmail.com with ESMTPSA id k33sm8828181edb.11.2017.06.02.07.11.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 07:11:14 -0700 (PDT) Date: Fri, 2 Jun 2017 16:11:12 +0200 From: Job Snijders To: ipv6@ietf.org Subject: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170602141112.x64nleqclygz7dwd@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:11:19 -0000 Hi Working Group, Please review the below. Kind regards, Job ----- Forwarded message from internet-drafts@ietf.org ----- Date: Mon, 22 May 2017 04:25:28 -0700 From: internet-drafts@ietf.org To: Job Snijders , Randy Bush , Christopher Morrow , Fernando Gont , Nick Hilliard , Geoff Huston , Brian Carpenter , Chris Morrow Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-bourbaki-6man-classless-ipv6 Revision: 00 Title: IPv6 is Classless Document date: 2017-05-22 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ Htmlized: https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 Abstract: Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. 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 ----- End forwarded message ----- From nobody Fri Jun 2 07:13:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A7112946D for ; Fri, 2 Jun 2017 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4HnSabOGzbh for ; Fri, 2 Jun 2017 07:13:01 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:67c:12f4::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9371286CA for ; Fri, 2 Jun 2017 07:13:01 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 20A00788EA for ; Fri, 2 Jun 2017 16:13:00 +0200 (CEST) Date: Fri, 2 Jun 2017 16:12:59 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170602141259.GD30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:13:03 -0000 Support On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote: :Hi Working Group, : :Please review the below. : :Kind regards, : :Job : :----- Forwarded message from internet-drafts@ietf.org ----- : :Date: Mon, 22 May 2017 04:25:28 -0700 :From: internet-drafts@ietf.org :To: Job Snijders , Randy Bush , Christopher Morrow , : Fernando Gont , Nick Hilliard , Geoff Huston : , Brian Carpenter , Chris Morrow : :Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt : : :A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt :has been successfully submitted by Randy Bush and posted to the :IETF repository. : :Name: draft-bourbaki-6man-classless-ipv6 :Revision: 00 :Title: IPv6 is Classless :Document date: 2017-05-22 :Group: Individual Submission :Pages: 7 :URL: https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt :Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ :Htmlized: https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 :Htmlized: https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 : : :Abstract: : Over the history of IPv6, various classful address models have been : proposed, none of which has withstood the test of time. The last : remnant of IPv6 classful addressing is a rigid network interface : identifier boundary at /64. This document removes the fixed position : of that boundary for interface addressing. : : : : :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 : : :----- End forwarded message ----- : :-------------------------------------------------------------------- :IETF IPv6 working group mailing list :ipv6@ietf.org :Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 :-------------------------------------------------------------------- -- If Reagan is the answer, it must have been a VERY silly question. From nobody Fri Jun 2 07:34:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0312EBA1 for ; Fri, 2 Jun 2017 07:34:06 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSskZPqgOGmR for ; Fri, 2 Jun 2017 07:34:03 -0700 (PDT) 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 21BB2129463 for ; Fri, 2 Jun 2017 07:34:03 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y190so41248766vkc.1 for ; Fri, 02 Jun 2017 07:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KK9pAF5s6cM+A9ERxX18swuKC3l7xw4VFSSn+L78n2M=; b=cjUWrOJ+zDpFC974WVg4SPOgV1fQX+C3QtaTmzXr/RWa8pkF0OfmHn0zL2FNaB8cMN 3wWVjS8Vp+vlKz08/jNGi1EBEBvC8CIkDiVT/3NxBz4l15zBGHfaewQSvTeQJwLpTSh7 Qcqfc+CDMt2EE4KoEMqs5hXxsxIALZUv97se1haT287rAk5CAEHwk5+/D42zDeVQYzk2 0Rnm2mh0WOXwIfSRfCks+0T0iPeS5+ez4BapCcYJELNSnXv5QWqg44HY6e3oWCnp7UiM IVmV0C0J/fL+VfR6fmJQU96ktr3XVJ3oeP/COv7pJMyXVt6zToNbuUXFDnFQE83DL0yO 7Nfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KK9pAF5s6cM+A9ERxX18swuKC3l7xw4VFSSn+L78n2M=; b=Qo86ySfkFhLvY+wCZaqm+yhiQy4kJtBQI6h+iNLTfc8accl3U8Ltscxw8DN8j4o5Cz W6quURK8ABtzBY4YpknSp1abfKMJw6TTEI0caSCiLl29fgs0kmqyvzbodBphsEIUdrbj M1q76ZDAOm1a5JkYiSvRhlLaypOuTxtSEUPM3QZ4P5HEEOY9jgIG8lZlHkz4efAyD7Ot +jriAGI9h8zu2HOnHiuZopYJd1fs5hLzroP5eB59hChrW39heKdlADePUPXbwbIRYRH6 3fmZabn2cD9muztBHo7DouSh0SgcuC5bRoMb7yFNYqRxEaupebE3nOkqOWf+vc3Ojujc biAw== X-Gm-Message-State: AODbwcCJfYdA6318WTpge2yXcH8q7Pzs7i4YDJWwSY378A9UN3AnM8AH iwvxQNM9pWH6A81NSQRDvbSiV2FMt7gN/RI= X-Received: by 10.31.114.135 with SMTP id n129mr968241vkc.18.1496414042078; Fri, 02 Jun 2017 07:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 07:33:41 -0700 (PDT) In-Reply-To: <20170602141259.GD30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> From: Lorenzo Colitti Date: Fri, 2 Jun 2017 23:33:41 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Peter Hessler Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c14c71c6ac0b90550fb0baa" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:34:06 -0000 --94eb2c14c71c6ac0b90550fb0baa Content-Type: text/plain; charset="UTF-8" Do not support. A few reasons: - The /64 boundary is beneficial for many reasons. See RFC 7421 and RFC 7934. - The document lists no compelling use cases of what you can do with less than 2^64 addresses per link than you can't do with a 2^64 addresses per link. - The only technical motivation in this draft seems to be "classful addressing was a bad idea in IPv4". That's not a valid argument in IPv6 because the address space is completely different. A /64 is *four billion times* bigger than the IPv4 internet. That's 10,000 times more than the difference between a grain of sand and the whole planet we live on. Such a huge scaling difference pretty much invalidates any argument that solutions that worked well in IPv4 will work well in IPv6. - Routing on any prefix length is already required by the standards - see BCP 198. Please stop trying to make IPv6 be the same as IPv4. That will take away our ability to make the Internet better once IPv4 is gone. On Fri, Jun 2, 2017 at 11:12 PM, Peter Hessler wrote: > Support > > On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote: > :Hi Working Group, > : > :Please review the below. > : > :Kind regards, > : > :Job > : > :----- Forwarded message from internet-drafts@ietf.org ----- > : > :Date: Mon, 22 May 2017 04:25:28 -0700 > :From: internet-drafts@ietf.org > :To: Job Snijders , Randy Bush , Christopher > Morrow , > : Fernando Gont , Nick Hilliard , > Geoff Huston > : , Brian Carpenter , > Chris Morrow > : > :Subject: New Version Notification for draft-bourbaki-6man-classless- > ipv6-00.txt > : > : > :A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt > :has been successfully submitted by Randy Bush and posted to the > :IETF repository. > : > :Name: draft-bourbaki-6man-classless-ipv6 > :Revision: 00 > :Title: IPv6 is Classless > :Document date: 2017-05-22 > :Group: Individual Submission > :Pages: 7 > :URL: https://www.ietf.org/internet-drafts/draft-bourbaki-6man- > classless-ipv6-00.txt > :Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man- > classless-ipv6/ > :Htmlized: https://tools.ietf.org/html/ > draft-bourbaki-6man-classless-ipv6-00 > :Htmlized: https://datatracker.ietf.org/ > doc/html/draft-bourbaki-6man-classless-ipv6-00 > : > : > :Abstract: > : Over the history of IPv6, various classful address models have been > : proposed, none of which has withstood the test of time. The last > : remnant of IPv6 classful addressing is a rigid network interface > : identifier boundary at /64. This document removes the fixed position > : of that boundary for interface addressing. > : > : > : > : > :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 > : > : > :----- End forwarded message ----- > : > :-------------------------------------------------------------------- > :IETF IPv6 working group mailing list > :ipv6@ietf.org > :Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > :-------------------------------------------------------------------- > > -- > If Reagan is the answer, it must have been a VERY silly question. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c14c71c6ac0b90550fb0baa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do not support. A few reasons:
  • The /64 boundar= y is beneficial for many reasons. See RFC 7421 and RFC 7934.
  • Th= e document lists no compelling use cases of what you can do with less than = 2^64 addresses per link than you can't do with a 2^64 addresses per lin= k.
  • The only technical motivation in this draft seems to be "cl= assful addressing was a bad idea in IPv4". That's not a valid argu= ment in IPv6 because the address space is completely different. A /64 is *f= our billion times* bigger than the IPv4 internet. That's 10,000 times m= ore than the difference between a grain of sand and the whole planet we liv= e on. Such a huge scaling difference pretty much invalidates any argument t= hat solutions that worked well in IPv4 will work well in IPv6.
  • Rout= ing on any prefix length is already required by the standards - see BCP 198= .
Please stop trying to make IPv6 be the same as IPv4. Th= at will take away our ability to make the Internet better once IPv4 is gone= .

On Fri, Jun 2, 2017 at 11:12 PM, Peter Hessler <phessler@theapt.org> wrote:
Support

On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote:
:Hi Working Group,
:
:Please review the below.
:
:Kind regards,
:
:Job
:
:----- Forwarded message from i= nternet-drafts@ietf.org -----
:
:Date: Mon, 22 May 2017 04:25:28 -0700
:From: internet-drafts@ietf.org=
:To: Job Snijders <job@ntt.net>, R= andy Bush <randy@psg.com>, Chris= topher Morrow <morrowc@google.com<= /a>>,
:=C2=A0 =C2=A0 =C2=A0 =C2=A0Fernando Gont <fgont@si6networks.com>, Nick Hilliard <nick@inex.ie>, Geoff Huston
:=C2=A0 =C2=A0 =C2=A0 =C2=A0<gih@apnic.= net>, Brian Carpenter <brian.e.carpenter@gmail.com>, Chris Morrow
:=C2=A0 =C2=A0 =C2=A0 =C2=A0<morro= wc@google.com>
:Subject: New Version Notification for draft-bourbaki-6man-classless-i= pv6-00.txt
:
:
:A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt
:has been successfully submitted by Randy Bush and posted to the
:IETF repository.
:
:Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bourbaki-6man-classless-ipv6
:Revision:=C2=A0 =C2=A0 =C2=A0 00
:Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 is Classless
:Document date: 2017-05-22
:Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
:Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07
:URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bo= urbaki-6man-classless-ipv6-00.txt
:Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bourbaki-6man-= classless-ipv6/
:Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-= 00
:Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-= classless-ipv6-00
:
:
:Abstract:
:=C2=A0 =C2=A0Over the history of IPv6, various classful address models hav= e been
:=C2=A0 =C2=A0proposed, none of which has withstood the test of time.=C2=A0= The last
:=C2=A0 =C2=A0remnant of IPv6 classful addressing is a rigid network interf= ace
:=C2=A0 =C2=A0identifier boundary at /64.=C2=A0 This document removes the f= ixed position
:=C2=A0 =C2=A0of that boundary for interface addressing.
:
:
:
:
:Please note that it may take a couple of minutes from the time of submissi= on
:until the htmlized version and diff are available at tools.ietf.org.
:
:The IETF Secretariat
:
:
:----- End forwarded message -----
:
:----------------------------------------------------------------= ----
:IETF IPv6 working group mailing list
:ipv6@ietf.org
:Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
:----------------------------------------------------------------= ----

--
If Reagan is the answer, it must have been a VERY silly question.

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

--94eb2c14c71c6ac0b90550fb0baa-- From nobody Fri Jun 2 07:36:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9EF12EBA1 for ; Fri, 2 Jun 2017 07:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFDm3hR4X63I for ; Fri, 2 Jun 2017 07:36:27 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 0231F129463 for ; Fri, 2 Jun 2017 07:36:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v52EaPoR023284 for ; Fri, 2 Jun 2017 16:36:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5D06B206E83 for ; Fri, 2 Jun 2017 16:36:25 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53976206E65 for ; Fri, 2 Jun 2017 16:36:25 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v52EaPIv025811 for ; Fri, 2 Jun 2017 16:36:25 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: Alexandre Petrescu Message-ID: Date: Fri, 2 Jun 2017 16:36:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:36:30 -0000 I support it. There is some additional matters I would like to suggest. > Thus, a correct implementation of SLAAC must in fact allow for any > prefix length, with the value being a parameter per interface. For > instance, the Interface Identifier length in the recommended (see > [RFC8064]) algorithm for selecting stable interface identifiers > [RFC7217] is a parameter, rather than a hardcoded value. As another example, the linux kernel MUST NOT complain when it receives an RA containing a prefix with plen==65 (currently it does). Alex Le 02/06/2017 à 16:11, Job Snijders a écrit : > Hi Working Group, > > Please review the below. > > Kind regards, > > Job > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Mon, 22 May 2017 04:25:28 -0700 From: internet-drafts@ietf.org > To: Job Snijders , Randy Bush , > Christopher Morrow , Fernando Gont > , Nick Hilliard , Geoff Huston > , Brian Carpenter , Chris > Morrow Subject: New Version Notification for > draft-bourbaki-6man-classless-ipv6-00.txt > > > A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt has > been successfully submitted by Randy Bush and posted to the IETF > repository. > > Name: draft-bourbaki-6man-classless-ipv6 Revision: 00 Title: IPv6 > is Classless Document date: 2017-05-22 Group: Individual Submission > Pages: 7 URL: > https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt > > Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ > Htmlized: > https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 > > > > Abstract: Over the history of IPv6, various classful address models > have been proposed, none of which has withstood the test of time. > The last remnant of IPv6 classful addressing is a rigid network > interface identifier boundary at /64. This document removes the > fixed position of that boundary for interface addressing. > > > > > 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 > > > ----- End forwarded message ----- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 2 07:57:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6FA12EBDD for ; Fri, 2 Jun 2017 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbim1iMrpTcx for ; Fri, 2 Jun 2017 07:57:00 -0700 (PDT) Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) (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 69F9F12EBE5 for ; Fri, 2 Jun 2017 07:57:00 -0700 (PDT) Received: by mail-wm0-f43.google.com with SMTP id d127so28994873wmf.0 for ; Fri, 02 Jun 2017 07:57:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=epN6QBR7l7IsoefQPKGNqBcI3Z9UJkLF5QNfV96Fz2M=; b=EX00294NwtThct9/z4jKMSiTmM7KIeYIZKTPa7NyJBTkt7kRvMNG4+zg2koArRdm7A B9LVlT2d8y/Kxjn3ONBeQwgbAzCZ1GoVmkKjd1Z4+ARHDq+t094/6+CTVqfe+iCqOeax kUGLXxv2oyJgMGLvmAHkThYh50hf9dybiOgfD57W8by+aIdViyZqS590pqLHg+kgjwsf TaKxRqXt1QaVvzwnqVTQJH2PIzHF/lgh/ceMQ2hoyIYRZUQRmyvrr1O0TYGxjU1AEiwW uiOQWFYCvPpaaHJ5rHyAx0Y94bwQg7ym4Cr4zZITfW/FJiFBqL149aO6tN6uc2GHdcA0 QIjw== X-Gm-Message-State: AODbwcDWRBbX5beByf8WkTMMK4fou/WMriGoVUzdrA8nnTMCaHS7Z0w9 Y73pidOVqwmmTO92O3vJrg== X-Received: by 10.80.179.131 with SMTP id s3mr6283423edd.57.1496415418641; Fri, 02 Jun 2017 07:56:58 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:cddf:8b77:9087:26d0]) by smtp.gmail.com with ESMTPSA id f38sm8126404edd.10.2017.06.02.07.56.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 07:56:57 -0700 (PDT) Date: Fri, 2 Jun 2017 16:56:55 +0200 From: Job Snijders To: Lorenzo Colitti , draft-bourbaki-6man-classless-ipv6@ietf.org Cc: Peter Hessler , IETF IPv6 Mailing List Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170602145655.msfjw35qhoev4sm2@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:57:02 -0000 Dear Lorenzo, On Fri, Jun 02, 2017 at 11:33:41PM +0900, Lorenzo Colitti wrote: > Do not support. A few reasons: > > - The /64 boundary is beneficial for many reasons. See RFC 7421 and RFC 7934. >From our brief hallway conversation at IETF 98 I was under the impression that you have a strong personal preference for the /64 boundary because you believe there to be '64 bits for the network' and '64 bits for the end-user' - however I do not share your (simplistic?) view of the world. Depending on the context, there may be more then 2 parties: an end-user might be a network provider themselves, and these functions can be recursive. What if someone resells a service to someone else? Without flexibility on the /64 boundary one can't cut up the assigned space in smaller pieces. It's been mentioned a couple of times before: any fixed boundary (including /64) is detrimental to permissionless expansion at the edge of the network. > - The document lists no compelling use cases of what you can do > with less than 2^64 addresses per link than you can't do with a > 2^64 addresses per link. This is not true. The security section for instance shows: "In such cases, the use of smaller subnets forces an operational limit on such data structures, thus helping mitigate some pathological behaviors (such as Neighbor Cache Exhaustion attacks)." > - The only technical motivation in this draft seems to be "classful > addressing was a bad idea in IPv4". That's not a valid argument in IPv6 > because the address space is completely different. A /64 is *four billion > times* bigger than the IPv4 internet. That's 10,000 times more than the > difference between a grain of sand and the whole planet we live on. Such a > huge scaling difference pretty much invalidates any argument that solutions > that worked well in IPv4 will work well in IPv6. Would be a shame to throw away lessons learned from IPv4. > - Routing on any prefix length is already required by the standards - > see BCP 198. Yes, RFC7608 is referenced as suggested reading. > Please stop trying to make IPv6 be the same as IPv4. That will take > away our ability to make the Internet better once IPv4 is gone. I believe there to be tangible merit in making IPv6 feel and look more like IPv4. Perhaps this becomes more apparent when one shifts the innovation focus from layer-3 to higher layers. Making IPv6 look more like IPv4 (for instance through broader adoption of DHCPv6 w/ routing options, and classlessness like in IPv4) will positively impact IPv6 deployment. Kind regards, Job From nobody Fri Jun 2 08:08:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD6A12EBE8 for ; Fri, 2 Jun 2017 08:08:09 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KjPinZUDdhg for ; Fri, 2 Jun 2017 08:08:04 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 2D136129BF7 for ; Fri, 2 Jun 2017 08:08:04 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 202so18584422ybd.0 for ; Fri, 02 Jun 2017 08:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R1M3XZr2iPliWYPHsrQ43q3rRTOeaVO5JsV4dNclOWw=; b=gHLBQcgvpGJC0ipNqLEw9nANEZrh0K5pG7djp4Z8w6VelWQNlpEUM5yWmTjkNw8cjY k2Q93AN8yjukQKcli9QK7wV+bDJ/aQxeDfubnLb6+DJwmWj8GIK1eFLSsuiVsieuQ3jD NTShAV1RWQHY7AbVTOftDcX4ysEZFAFd+L2omSLOmyxuVavOlQ6NhtFve15X9Zb/1Pfq wgQIaIInHI8n+cyMucIswhFPo/D2YMc5d6BNQQx1hOQcjnanwCtPCj+2wwpFqC4KxFP2 8wn4RXVzBNRDr9SKkyhGheXk31zdYwrBQ0YSnw2x9OixkuiL+dmZvZNr89EjylIlYmQz t6fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R1M3XZr2iPliWYPHsrQ43q3rRTOeaVO5JsV4dNclOWw=; b=n8M2M4Q8HH3KY6dH5FjuC2UidM2Z1OYTgkUM/Af6Jw66gSnELS0wpDI5vbsB8kriso GVIrH+j4XOLmNril2QjVmGW3W4vJCZNcnJzwaLfWziK1b3Tq/UGWTLAXZDx3rrxHNOaJ ogRpOPYMbDg9Ak56MYG+NVchGwv5Zw5rVSJL1o3fulVa0AC+Tg+uD0iKXoX/5NIo32o3 xyjE0zeeKy0q76Yga9p8dIMAc06tPBCwdNh5W8rRj7isBdMOQv4yWtIzFTeP1eyEKo1+ jvFmQm5V8ReE8QszHT8HowFBY/N2oX081EdUAVlvmGMhWGPAg2qkt/8r4hlpGBU9OC46 KfpQ== X-Gm-Message-State: AODbwcAfmJnG+98iRvBaCZ4G7Rsb3SN53B/3KGRUsRxSaKeI92spQjE1 Apq3+vNAuQ4J2mc6IoMTIVCuAPqQADGq X-Received: by 10.37.56.13 with SMTP id f13mr165465yba.175.1496416083086; Fri, 02 Jun 2017 08:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.212.133 with HTTP; Fri, 2 Jun 2017 08:07:42 -0700 (PDT) In-Reply-To: <20170602145655.msfjw35qhoev4sm2@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> From: Erik Kline Date: Sat, 3 Jun 2017 00:07:42 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: Lorenzo Colitti , draft-bourbaki-6man-classless-ipv6@ietf.org, IETF IPv6 Mailing List , Peter Hessler Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c091e5a19ef020550fb8585" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:08:09 -0000 --94eb2c091e5a19ef020550fb8585 Content-Type: multipart/alternative; boundary="94eb2c091e5a1223230550fb856f" --94eb2c091e5a1223230550fb856f Content-Type: text/plain; charset="UTF-8" On 2 June 2017 at 23:56, Job Snijders wrote: > Dear Lorenzo, > > On Fri, Jun 02, 2017 at 11:33:41PM +0900, Lorenzo Colitti wrote: > > Do not support. A few reasons: > > > > - The /64 boundary is beneficial for many reasons. See RFC 7421 and > RFC 7934. > > >From our brief hallway conversation at IETF 98 I was under the > impression that you have a strong personal preference for the /64 > boundary because you believe there to be '64 bits for the network' and > '64 bits for the end-user' - however I do not share your (simplistic?) > view of the world. > > Depending on the context, there may be more then 2 parties: an end-user > might be a network provider themselves, and these functions can be > recursive. What if someone resells a service to someone else? Without > flexibility on the /64 boundary one can't cut up the assigned space in > smaller pieces. > > It's been mentioned a couple of times before: any fixed boundary > (including /64) The pain one feels when you only get allocated single /64 is actually the /64 boundary working *for* you. If a provider /could/ give you less they would, and we'd be having discussions about only having a single /120 or even a single /128. > is detrimental to permissionless expansion at the edge > of the network > > - The document lists no compelling use cases of what you can do > > with less than 2^64 addresses per link than you can't do with a > > 2^64 addresses per link. > > This is not true. The security section for instance shows: "In such > cases, the use of smaller subnets forces an operational limit on such > data structures, thus helping mitigate some pathological behaviors (such > as Neighbor Cache Exhaustion attacks)." > > > - The only technical motivation in this draft seems to be "classful > > addressing was a bad idea in IPv4". That's not a valid argument in > IPv6 > > because the address space is completely different. A /64 is *four > billion > > times* bigger than the IPv4 internet. That's 10,000 times more than > the > > difference between a grain of sand and the whole planet we live on. > Such a > > huge scaling difference pretty much invalidates any argument that > solutions > > that worked well in IPv4 will work well in IPv6. > > Would be a shame to throw away lessons learned from IPv4. > > > - Routing on any prefix length is already required by the standards - > > see BCP 198. > > Yes, RFC7608 is referenced as suggested reading. > > > Please stop trying to make IPv6 be the same as IPv4. That will take > > away our ability to make the Internet better once IPv4 is gone. > > I believe there to be tangible merit in making IPv6 feel and look more > like IPv4. Perhaps this becomes more apparent when one shifts the > innovation focus from layer-3 to higher layers. > > Making IPv6 look more like IPv4 (for instance through broader adoption > of DHCPv6 w/ routing options, and classlessness like in IPv4) will > positively impact IPv6 deployment. > Absolutely not. IPv6 NAT is where is this ends, and that's so asinine in such a large space it shouldn't bear mentioning. Kind regards, > > Job > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c091e5a1223230550fb856f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 2 June 2017 at 23:56, Job Snijders <job@ntt.net> wrote:
=
Dear Lorenzo,

On Fri, Jun 02, 2017 at 11:33:41PM +0900, Lorenzo Colitti wrote:
> Do not support. A few reasons:
>
>=C2=A0 =C2=A0 - The /64 boundary is beneficial for many reasons.= See RFC 7421 and RFC 7934.

>From our brief hallway conversation at IETF 98 I was under the
impression that you have a strong personal preference for the /64
boundary because you believe there to be '64 bits for the network' = and
'64 bits for the end-user' - however I do not share your (simplisti= c?)
view of the world.

Depending on the context, there may be more then 2 parties: an end-user
might be a network provider themselves, and these functions can be
recursive. What if someone resells a service to someone else? Without
flexibility on the /64 boundary one can't cut up the assigned space in<= br> smaller pieces.

It's been mentioned a couple of times before: any fixed boundary
(including /64)

The pain one feels when you= only get allocated single /64 is actually the /64 boundary working *for* y= ou.=C2=A0 If a provider /could/ give you less they would, and we'd be h= aving discussions about only having a single /120 or even a single /128.
=C2=A0
=C2=A0
is detrimental to permissionless expansion at th= e edge
of the network
>=C2=A0 =C2=A0 - The document lists no compelling use cases of what you = can do
>=C2=A0 =C2=A0 with less than 2^64 addresses per link t= han you can't do with a
>=C2=A0 =C2=A0 2^64 addresses per link.

This is not true. The security section for instance shows: "In = such
cases, the use of smaller subnets forces an operational limit on such
data structures, thus helping mitigate some pathological behaviors (such as Neighbor Cache Exhaustion attacks)."

>=C2=A0 =C2=A0 - The only technical motivation in this draft seems to be= "classful
>=C2=A0 =C2=A0 addressing was a bad idea in IPv4".= That's not a valid argument in IPv6
>=C2=A0 =C2=A0 because the address space is completely different. A /64 = is *four billion
>=C2=A0 =C2=A0 times* bigger than the IPv4 internet. That's 10,000 t= imes more than the
>=C2=A0 =C2=A0 difference between a grain of sand and the whole planet w= e live on. Such a
>=C2=A0 =C2=A0 huge scaling difference pretty much invalidates any argum= ent that solutions
>=C2=A0 =C2=A0 that worked well in IPv4 will work well in IPv6.

Would be a shame to throw away lessons learned from IPv4.

>=C2=A0 =C2=A0 - Routing on any prefix length is already required by the= standards -
>=C2=A0 =C2=A0 see BCP 198.

Yes, RFC7608 is referenced as suggested reading.

> Please stop trying to make IPv6 be the same as IPv4. That will take > away our ability to make the Internet better once IPv4 is gone.

I believe there to be tangible merit in making IPv6 feel and look mo= re
like IPv4. Perhaps this becomes more apparent when one shifts the
innovation focus from layer-3 to higher layers.

Making IPv6 look more like IPv4 (for instance through broader adoption
of DHCPv6 w/ routing options, and classlessness like in IPv4) will
positively impact IPv6 deployment.

Abso= lutely not.=C2=A0 IPv6 NAT is where is this ends, and that's so asinine= in such a large space it shouldn't bear mentioning.

Kind regards,

Job

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

--94eb2c091e5a1223230550fb856f-- --94eb2c091e5a19ef020550fb8585 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgCcwra2pjsR7WE2M6Of35fC5cZzbNmlXV 0EfvFTbCPXkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjAy MTUwODAzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADuC4IELR3kLiQ0NxqjXjvhl80FHaECkQwuvXNiC5PDg1nplAt+h B+QdUKaFi+6hAiptMsZNyK19tn3tUmKrbMqnM/sIPxQF1yFcFDDael057B8fOemVS1G4HhyFjFtX 2xHpRHfV7PVVyXwaqX3pucp+1iI2em5N4ylxYQw69lHGt/BOdYKh/njU2w9Z+pYmzkcNQQMRvf1k XxO3zDcEecspbOeZPTCL9BgQgLVjPxzHbnfEesm6uXp0tAdOyPD2XmVCpaKHaLUgcCzC7YNRa4uG gN4vAqAUWPNBu+GlgJnMQgp3exufQ1tZe4ABadE4WTVKh3i4tBU2JVwzVO2tGTg= --94eb2c091e5a19ef020550fb8585-- From nobody Fri Jun 2 08:27:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19AC129B45 for ; Fri, 2 Jun 2017 08:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBZh_yUu24Nj for ; Fri, 2 Jun 2017 08:27:33 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 7261612714F for ; Fri, 2 Jun 2017 08:27:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v52FRU4o030076 for ; Fri, 2 Jun 2017 17:27:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 76D4D206F51 for ; Fri, 2 Jun 2017 17:27:29 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0F970206EE5 for ; Fri, 2 Jun 2017 17:27:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v52FRR5v004317 for ; Fri, 2 Jun 2017 17:27:27 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: Alexandre Petrescu Message-ID: <8a10b07f-d529-f498-df6f-a71faebecd73@gmail.com> Date: Fri, 2 Jun 2017 17:27:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:27:37 -0000 Le 02/06/2017 à 16:36, Alexandre Petrescu a écrit : > I support it. > > There is some additional matters I would like to suggest. > >> Thus, a correct implementation of SLAAC must in fact allow for any >> prefix length, with the value being a parameter per interface. For >> instance, the Interface Identifier length in the recommended (see >> [RFC8064]) algorithm for selecting stable interface identifiers >> [RFC7217] is a parameter, rather than a hardcoded value. > > As another example, the linux kernel MUST NOT complain when it receives > an RA containing a prefix with plen==65 (currently it does). Sorry, I have been just shown that the kernel does not complain when it receives a plen==65. Still, the radvd complains when indicating it should send a 65, or a 63. Alex > > Alex > > > > > Le 02/06/2017 à 16:11, Job Snijders a écrit : >> Hi Working Group, >> >> Please review the below. >> >> Kind regards, >> >> Job >> >> ----- Forwarded message from internet-drafts@ietf.org ----- >> >> Date: Mon, 22 May 2017 04:25:28 -0700 From: internet-drafts@ietf.org >> To: Job Snijders , Randy Bush , >> Christopher Morrow , Fernando Gont >> , Nick Hilliard , Geoff Huston >> , Brian Carpenter , Chris >> Morrow Subject: New Version Notification for >> draft-bourbaki-6man-classless-ipv6-00.txt >> >> >> A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt has >> been successfully submitted by Randy Bush and posted to the IETF >> repository. >> >> Name: draft-bourbaki-6man-classless-ipv6 Revision: 00 >> Title: IPv6 >> is Classless Document date: 2017-05-22 Group: Individual >> Submission >> Pages: 7 URL: >> https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt >> >> >> > Status: > https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ >> Htmlized: >> https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 >> >> >> >> >> Abstract: Over the history of IPv6, various classful address models >> have been proposed, none of which has withstood the test of time. >> The last remnant of IPv6 classful addressing is a rigid network >> interface identifier boundary at /64. This document removes the >> fixed position of that boundary for interface addressing. >> >> >> >> >> 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 >> >> >> ----- End forwarded message ----- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 2 09:00:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5A41270B4 for ; Fri, 2 Jun 2017 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I0IMAdAE2JB for ; Fri, 2 Jun 2017 09:00:22 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D41129410 for ; Fri, 2 Jun 2017 09:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52G0L7a044069; Fri, 2 Jun 2017 09:00:21 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52G0CPR043581 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 09:00:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 09:00:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 09:00:11 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Peter Hessler CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS262dsSo24MvI90arLJF3XDEOhqIRufvw Date: Fri, 2 Jun 2017 16:00:11 +0000 Message-ID: <94187941f954445897f5d6e06b3caf0a@XCH15-06-08.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_94187941f954445897f5d6e06b3caf0aXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:00:26 -0000 --_000_94187941f954445897f5d6e06b3caf0aXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoZSAvNjQgYm91bmRhcnkgaXMgYmVuZWZpY2lhbCBmb3IgbWFueSByZWFz b25zIHdoZW4gZGVsZWdhdGluZw0KYW4gSVB2NiBwcmVmaXggdG8gYSBzaXRlLiBXaGF0IHRoZSBz aXRlIGRvZXMgd2l0aCB0aGUgcHJlZml4IGludGVybmFsbHkgKGluY2x1ZGluZw0Kc3ViLWRlbGVn YXRpbmcgaW50byBsb25nZXIgcHJlZml4ZXMpIGlzIGVudGlyZWx5IHVwIHRvIHRoZSBzaXRlLg0K DQpUaGFua3MgLSBGcmVkDQoNCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IEZyaWRheSwgSnVuZSAwMiwg MjAxNyA3OjM0IEFNDQpUbzogUGV0ZXIgSGVzc2xlciA8cGhlc3NsZXJAdGhlYXB0Lm9yZz4NCkNj OiBJRVRGIElQdjYgTWFpbGluZyBMaXN0IDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogUmU6IGRy YWZ0LWJvdXJiYWtpLTZtYW4tY2xhc3NsZXNzLWlwdjYtMDANCg0KRG8gbm90IHN1cHBvcnQuIEEg ZmV3IHJlYXNvbnM6DQoNCiAgKiAgIFRoZSAvNjQgYm91bmRhcnkgaXMgYmVuZWZpY2lhbCBmb3Ig bWFueSByZWFzb25zLiBTZWUgUkZDIDc0MjEgYW5kIFJGQyA3OTM0Lg0KICAqICAgVGhlIGRvY3Vt ZW50IGxpc3RzIG5vIGNvbXBlbGxpbmcgdXNlIGNhc2VzIG9mIHdoYXQgeW91IGNhbiBkbyB3aXRo IGxlc3MgdGhhbiAyXjY0IGFkZHJlc3NlcyBwZXIgbGluayB0aGFuIHlvdSBjYW4ndCBkbyB3aXRo IGEgMl42NCBhZGRyZXNzZXMgcGVyIGxpbmsuDQogICogICBUaGUgb25seSB0ZWNobmljYWwgbW90 aXZhdGlvbiBpbiB0aGlzIGRyYWZ0IHNlZW1zIHRvIGJlICJjbGFzc2Z1bCBhZGRyZXNzaW5nIHdh cyBhIGJhZCBpZGVhIGluIElQdjQiLiBUaGF0J3Mgbm90IGEgdmFsaWQgYXJndW1lbnQgaW4gSVB2 NiBiZWNhdXNlIHRoZSBhZGRyZXNzIHNwYWNlIGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50LiBBIC82 NCBpcyAqZm91ciBiaWxsaW9uIHRpbWVzKiBiaWdnZXIgdGhhbiB0aGUgSVB2NCBpbnRlcm5ldC4g VGhhdCdzIDEwLDAwMCB0aW1lcyBtb3JlIHRoYW4gdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIGdy YWluIG9mIHNhbmQgYW5kIHRoZSB3aG9sZSBwbGFuZXQgd2UgbGl2ZSBvbi4gU3VjaCBhIGh1Z2Ug c2NhbGluZyBkaWZmZXJlbmNlIHByZXR0eSBtdWNoIGludmFsaWRhdGVzIGFueSBhcmd1bWVudCB0 aGF0IHNvbHV0aW9ucyB0aGF0IHdvcmtlZCB3ZWxsIGluIElQdjQgd2lsbCB3b3JrIHdlbGwgaW4g SVB2Ni4NCiAgKiAgIFJvdXRpbmcgb24gYW55IHByZWZpeCBsZW5ndGggaXMgYWxyZWFkeSByZXF1 aXJlZCBieSB0aGUgc3RhbmRhcmRzIC0gc2VlIEJDUCAxOTguDQpQbGVhc2Ugc3RvcCB0cnlpbmcg dG8gbWFrZSBJUHY2IGJlIHRoZSBzYW1lIGFzIElQdjQuIFRoYXQgd2lsbCB0YWtlIGF3YXkgb3Vy IGFiaWxpdHkgdG8gbWFrZSB0aGUgSW50ZXJuZXQgYmV0dGVyIG9uY2UgSVB2NCBpcyBnb25lLg0K DQpPbiBGcmksIEp1biAyLCAyMDE3IGF0IDExOjEyIFBNLCBQZXRlciBIZXNzbGVyIDxwaGVzc2xl ckB0aGVhcHQub3JnPG1haWx0bzpwaGVzc2xlckB0aGVhcHQub3JnPj4gd3JvdGU6DQpTdXBwb3J0 DQoNCk9uIDIwMTcgSnVuIDAyIChGcmkpIGF0IDE2OjExOjEyICswMjAwICgrMDIwMCksIEpvYiBT bmlqZGVycyB3cm90ZToNCjpIaSBXb3JraW5nIEdyb3VwLA0KOg0KOlBsZWFzZSByZXZpZXcgdGhl IGJlbG93Lg0KOg0KOktpbmQgcmVnYXJkcywNCjoNCjpKb2INCjoNCjotLS0tLSBGb3J3YXJkZWQg bWVzc2FnZSBmcm9tIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPiAtLS0tLQ0KOg0KOkRhdGU6IE1vbiwgMjIgTWF5IDIwMTcgMDQ6MjU6Mjgg LTA3MDANCjpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4NCjpUbzogSm9iIFNuaWpkZXJzIDxqb2JAbnR0Lm5ldDxtYWlsdG86am9i QG50dC5uZXQ+PiwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNvbTxtYWlsdG86cmFuZHlAcHNnLmNv bT4+LCBDaHJpc3RvcGhlciBNb3Jyb3cgPG1vcnJvd2NAZ29vZ2xlLmNvbTxtYWlsdG86bW9ycm93 Y0Bnb29nbGUuY29tPj4sDQo6ICAgICAgIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtz LmNvbTxtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tPj4sIE5pY2sgSGlsbGlhcmQgPG5pY2tA aW5leC5pZTxtYWlsdG86bmlja0BpbmV4LmllPj4sIEdlb2ZmIEh1c3Rvbg0KOiAgICAgICA8Z2lo QGFwbmljLm5ldDxtYWlsdG86Z2loQGFwbmljLm5ldD4+LCBCcmlhbiBDYXJwZW50ZXIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29t Pj4sIENocmlzIE1vcnJvdw0KOiAgICAgICA8bW9ycm93Y0Bnb29nbGUuY29tPG1haWx0bzptb3Jy b3djQGdvb2dsZS5jb20+Pg0KOlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYm91cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMC50eHQNCjoNCjoNCjpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm91cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMC50eHQN CjpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhbmR5IEJ1c2ggYW5kIHBvc3Rl ZCB0byB0aGUNCjpJRVRGIHJlcG9zaXRvcnkuDQo6DQo6TmFtZTogICAgICAgICAgZHJhZnQtYm91 cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ng0KOlJldmlzaW9uOiAgICAgIDAwDQo6VGl0bGU6ICAg ICAgICAgSVB2NiBpcyBDbGFzc2xlc3MNCjpEb2N1bWVudCBkYXRlOiAyMDE3LTA1LTIyDQo6R3Jv dXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo6UGFnZXM6ICAgICAgICAgNw0KOlVS TDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt Ym91cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMC50eHQNCjpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91cmJha2ktNm1hbi1jbGFzc2xl c3MtaXB2Ni8NCjpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJvdXJiYWtpLTZtYW4tY2xhc3NsZXNzLWlwdjYtMDANCjpIdG1saXplZDogICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VyYmFraS02bWFuLWNs YXNzbGVzcy1pcHY2LTAwDQo6DQo6DQo6QWJzdHJhY3Q6DQo6ICAgT3ZlciB0aGUgaGlzdG9yeSBv ZiBJUHY2LCB2YXJpb3VzIGNsYXNzZnVsIGFkZHJlc3MgbW9kZWxzIGhhdmUgYmVlbg0KOiAgIHBy b3Bvc2VkLCBub25lIG9mIHdoaWNoIGhhcyB3aXRoc3Rvb2QgdGhlIHRlc3Qgb2YgdGltZS4gIFRo ZSBsYXN0DQo6ICAgcmVtbmFudCBvZiBJUHY2IGNsYXNzZnVsIGFkZHJlc3NpbmcgaXMgYSByaWdp ZCBuZXR3b3JrIGludGVyZmFjZQ0KOiAgIGlkZW50aWZpZXIgYm91bmRhcnkgYXQgLzY0LiAgVGhp cyBkb2N1bWVudCByZW1vdmVzIHRoZSBmaXhlZCBwb3NpdGlvbg0KOiAgIG9mIHRoYXQgYm91bmRh cnkgZm9yIGludGVyZmFjZSBhZGRyZXNzaW5nLg0KOg0KOg0KOg0KOg0KOlBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCjp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo6DQo6VGhlIElFVEYg U2VjcmV0YXJpYXQNCjoNCjoNCjotLS0tLSBFbmQgZm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0NCjoN CjotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KOklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KOmlw djZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQo6QWRtaW5pc3RyYXRpdmUgUmVxdWVz dHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KOi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQotLQ0KSWYgUmVhZ2FuIGlzIHRoZSBhbnN3ZXIsIGl0IG11c3QgaGF2ZSBiZWVuIGEgVkVS WSBzaWxseSBxdWVzdGlvbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWlu aXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== --_000_94187941f954445897f5d6e06b3caf0aXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzcwMTU4 MjE5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTI4MDY5OTYwO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGUgLzY0IGJvdW5kYXJ5 IGlzIGJlbmVmaWNpYWwgZm9yIG1hbnkgcmVhc29ucyB3aGVuIGRlbGVnYXRpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+YW4gSVB2NiBwcmVmaXggdG8gYSBzaXRlLiBXaGF0IHRoZSBzaXRlIGRvZXMgd2l0 aCB0aGUgcHJlZml4IGludGVybmFsbHkgKGluY2x1ZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zdWIt ZGVsZWdhdGluZyBpbnRvIGxvbmdlciBwcmVmaXhlcykgaXMgZW50aXJlbHkgdXAgdG8gdGhlIHNp dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBG cmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg SnVuZSAwMiwgMjAxNyA3OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBQZXRlciBIZXNzbGVyICZsdDtw aGVzc2xlckB0aGVhcHQub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBJUHY2IE1haWxpbmcg TGlzdCAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0 LWJvdXJiYWtpLTZtYW4tY2xhc3NsZXNzLWlwdjYtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gbm90IHN1cHBvcnQuIEEgZmV3IHJlYXNv bnM6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUgLzY0IGJvdW5kYXJ5IGlz IGJlbmVmaWNpYWwgZm9yIG1hbnkgcmVhc29ucy4gU2VlIFJGQyA3NDIxIGFuZCBSRkMgNzkzNC48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQpUaGUgZG9jdW1lbnQgbGlzdHMgbm8gY29tcGVsbGluZyB1c2UgY2FzZXMgb2Ygd2hh dCB5b3UgY2FuIGRvIHdpdGggbGVzcyB0aGFuIDJeNjQgYWRkcmVzc2VzIHBlciBsaW5rIHRoYW4g eW91IGNhbid0IGRvIHdpdGggYSAyXjY0IGFkZHJlc3NlcyBwZXIgbGluay48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUg b25seSB0ZWNobmljYWwgbW90aXZhdGlvbiBpbiB0aGlzIGRyYWZ0IHNlZW1zIHRvIGJlICZxdW90 O2NsYXNzZnVsIGFkZHJlc3Npbmcgd2FzIGEgYmFkIGlkZWEgaW4gSVB2NCZxdW90Oy4gVGhhdCdz IG5vdCBhIHZhbGlkIGFyZ3VtZW50IGluIElQdjYgYmVjYXVzZSB0aGUgYWRkcmVzcyBzcGFjZSBp cyBjb21wbGV0ZWx5IGRpZmZlcmVudC4gQSAvNjQgaXMgKmZvdXIgYmlsbGlvbiB0aW1lcyogYmln Z2VyIHRoYW4gdGhlIElQdjQgaW50ZXJuZXQuIFRoYXQncw0KIDEwLDAwMCB0aW1lcyBtb3JlIHRo YW4gdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIGdyYWluIG9mIHNhbmQgYW5kIHRoZSB3aG9sZSBw bGFuZXQgd2UgbGl2ZSBvbi4gU3VjaCBhIGh1Z2Ugc2NhbGluZyBkaWZmZXJlbmNlIHByZXR0eSBt dWNoIGludmFsaWRhdGVzIGFueSBhcmd1bWVudCB0aGF0IHNvbHV0aW9ucyB0aGF0IHdvcmtlZCB3 ZWxsIGluIElQdjQgd2lsbCB3b3JrIHdlbGwgaW4gSVB2Ni48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpSb3V0aW5nIG9uIGFu eSBwcmVmaXggbGVuZ3RoIGlzIGFscmVhZHkgcmVxdWlyZWQgYnkgdGhlIHN0YW5kYXJkcyAtIHNl ZSBCQ1AgMTk4LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBsZWFzZSBzdG9wIHRyeWluZyB0byBtYWtlIElQdjYgYmUgdGhlIHNhbWUgYXMgSVB2NC4g VGhhdCB3aWxsIHRha2UgYXdheSBvdXIgYWJpbGl0eSB0byBtYWtlIHRoZSBJbnRlcm5ldCBiZXR0 ZXIgb25jZSBJUHY0IGlzIGdvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4gMiwgMjAxNyBhdCAxMToxMiBQ TSwgUGV0ZXIgSGVzc2xlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoZXNzbGVyQHRoZWFwdC5vcmci IHRhcmdldD0iX2JsYW5rIj5waGVzc2xlckB0aGVhcHQub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VwcG9ydDxicj4N Cjxicj4NCk9uIDIwMTcgSnVuIDAyIChGcmkpIGF0IDE2OjExOjEyICYjNDM7MDIwMCAoJiM0Mzsw MjAwKSwgSm9iIFNuaWpkZXJzIHdyb3RlOjxicj4NCjpIaSBXb3JraW5nIEdyb3VwLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjo8YnI+DQo6UGxlYXNlIHJldmlldyB0aGUgYmVsb3cuPGJyPg0KOjxi cj4NCjpLaW5kIHJlZ2FyZHMsPGJyPg0KOjxicj4NCjpKb2I8YnI+DQo6PGJyPg0KOi0tLS0tIEZv cndhcmRlZCBtZXNzYWdlIGZyb20gPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiAtLS0tLTxicj4NCjo8YnI+DQo6RGF0 ZTogTW9uLCAyMiBNYXkgMjAxNyAwNDoyNToyOCAtMDcwMDxicj4NCjpGcm9tOiA8YSBocmVmPSJt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 L2E+PGJyPg0KOlRvOiBKb2IgU25pamRlcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2JAbnR0Lm5l dCI+am9iQG50dC5uZXQ8L2E+Jmd0OywgUmFuZHkgQnVzaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJh bmR5QHBzZy5jb20iPnJhbmR5QHBzZy5jb208L2E+Jmd0OywgQ2hyaXN0b3BoZXIgTW9ycm93ICZs dDs8YSBocmVmPSJtYWlsdG86bW9ycm93Y0Bnb29nbGUuY29tIj5tb3Jyb3djQGdvb2dsZS5jb208 L2E+Jmd0Oyw8YnI+DQo6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmVybmFuZG8gR29udCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbSI+ZmdvbnRAc2k2bmV0d29y a3MuY29tPC9hPiZndDssIE5pY2sgSGlsbGlhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrQGlu ZXguaWUiPm5pY2tAaW5leC5pZTwvYT4mZ3Q7LCBHZW9mZiBIdXN0b248YnI+DQo6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpnaWhAYXBuaWMubmV0Ij5naWhA YXBuaWMubmV0PC9hPiZndDssIEJyaWFuIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSI+YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPC9h PiZndDssIENocmlzIE1vcnJvdzxicj4NCjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1vcnJvd2NAZ29vZ2xlLmNvbSI+bW9ycm93Y0Bnb29nbGUuY29tPC9h PiZndDs8YnI+DQo6U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1i b3VyYmFraS02bWFuLWNsYXNzbGVzcy1pcHY2LTAwLnR4dDxicj4NCjo8YnI+DQo6PGJyPg0KOkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib3VyYmFraS02bWFuLWNsYXNzbGVzcy1pcHY2LTAw LnR4dDxicj4NCjpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhbmR5IEJ1c2gg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQo6SUVURiByZXBvc2l0b3J5Ljxicj4NCjo8YnI+DQo6TmFt ZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWJvdXJiYWtpLTZtYW4t Y2xhc3NsZXNzLWlwdjY8YnI+DQo6UmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMDA8YnI+ DQo6VGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lQdjYgaXMgQ2xhc3Ns ZXNzPGJyPg0KOkRvY3VtZW50IGRhdGU6IDIwMTctMDUtMjI8YnI+DQo6R3JvdXA6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCjpQYWdl czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Nzxicj4NCjpVUkw6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJvdXJiYWtpLTZtYW4tY2xhc3NsZXNzLWlwdjYt MDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYm91cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMC50eHQ8L2E+PGJyPg0K OlN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91cmJha2ktNm1hbi1jbGFzc2xlc3Mt aXB2Ni8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ib3VyYmFraS02bWFuLWNsYXNzbGVzcy1pcHY2LzwvYT48YnI+DQo6SHRtbGl6ZWQ6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvdXJiYWtpLTZtYW4tY2xhc3NsZXNzLWlwdjYtMDAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91cmJha2ktNm1hbi1jbGFzc2xl c3MtaXB2Ni0wMDwvYT48YnI+DQo6SHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3Vy YmFraS02bWFuLWNsYXNzbGVzcy1pcHY2LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VyYmFraS02bWFuLWNsYXNzbGVzcy1p cHY2LTAwPC9hPjxicj4NCjo8YnI+DQo6PGJyPg0KOkFic3RyYWN0Ojxicj4NCjombmJzcDsgJm5i c3A7T3ZlciB0aGUgaGlzdG9yeSBvZiBJUHY2LCB2YXJpb3VzIGNsYXNzZnVsIGFkZHJlc3MgbW9k ZWxzIGhhdmUgYmVlbjxicj4NCjombmJzcDsgJm5ic3A7cHJvcG9zZWQsIG5vbmUgb2Ygd2hpY2gg aGFzIHdpdGhzdG9vZCB0aGUgdGVzdCBvZiB0aW1lLiZuYnNwOyBUaGUgbGFzdDxicj4NCjombmJz cDsgJm5ic3A7cmVtbmFudCBvZiBJUHY2IGNsYXNzZnVsIGFkZHJlc3NpbmcgaXMgYSByaWdpZCBu ZXR3b3JrIGludGVyZmFjZTxicj4NCjombmJzcDsgJm5ic3A7aWRlbnRpZmllciBib3VuZGFyeSBh dCAvNjQuJm5ic3A7IFRoaXMgZG9jdW1lbnQgcmVtb3ZlcyB0aGUgZml4ZWQgcG9zaXRpb248YnI+ DQo6Jm5ic3A7ICZuYnNwO29mIHRoYXQgYm91bmRhcnkgZm9yIGludGVyZmFjZSBhZGRyZXNzaW5n Ljxicj4NCjo8YnI+DQo6PGJyPg0KOjxicj4NCjo8YnI+DQo6UGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxi cj4NCjp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMu aWV0Zi5vcmc8L2E+Ljxicj4NCjo8YnI+DQo6VGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo6PGJy Pg0KOjxicj4NCjotLS0tLSBFbmQgZm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS08YnI+DQo6PGJyPg0K Oi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KOklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxi cj4NCjo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48YnI+ DQo6QWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCjotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLTwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPklmIFJl YWdhbiBpcyB0aGUgYW5zd2VyLCBpdCBtdXN0IGhhdmUgYmVlbiBhIFZFUlkgc2lsbHkgcXVlc3Rp b24uPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYgd29ya2luZyBncm91 cCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBp ZXRmLm9yZzwvYT48YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_94187941f954445897f5d6e06b3caf0aXCH150608nwnosboeingcom_-- From nobody Fri Jun 2 09:08:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3B1270B4 for ; Fri, 2 Jun 2017 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbQnwf8ujr4W for ; Fri, 2 Jun 2017 09:08:34 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932431243FE for ; Fri, 2 Jun 2017 09:08:34 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id w1so42461298vkd.2 for ; Fri, 02 Jun 2017 09:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T4z9pQFfL1mToQ46McSiTDE93hV3m5ak9cxDqeNTbH4=; b=eaD3DQuxq94OYsBOW1rzVc+Pas9nCxoGfwxvNKZ8synkMFCnO7sbcDR2w1EhH3u3a9 d76cjc0XyCCcvGsDmC9BNuwNDIcOjisjWQOHYFuFN2jnHVD9Xnot1wIHroj9US6BRHSn /yvUFeIs8yRbWksencGN90NThu6jpSHcSP+dArf+haYqD+TxQcumlzgXlzEAP3e+5Lrf 1pfPwzU1j5C5Z72cvOsODbchFvH21/UNjl7v6P+s7cVjuMHduXie3HxPBuySx2EMV7ru Pq0RSDJpZLQPhNhJjetPO4h+MC7cIXJzeZaaHSDPEjvaqoLVLhl/WtEH4yLr4nEooYFm PF4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T4z9pQFfL1mToQ46McSiTDE93hV3m5ak9cxDqeNTbH4=; b=GjNPPlbPtXYgN/mGg6dwJUMtNhOOQyVSIGzeF+GL/iKzElO2jwSEJpeQWELZhcYwWD p7Q2rRe3j0C626uoLGQXqDkCCjnS+XRp6oHZGbfioZjS3v0+8bLCnP6AG0h8C3BxbHCk F3rIECiA02O3dg9g0SidFyDj1Ww/WQnsUSBJ52784CaZONuDbwDzUfEBtU4GR20WACu0 q1sVv/nrCuZNJaWTSgulgkj8DCSrp6gzLEp6jextDuMnR3A+fYJI6lhxr0OldHzNzeyc 64cVJx8GEl8Le9QVbGqzRo1CGPY5VRj4S+rAeD2Stqqidrrp1MrnfTgKGRPh1uuIjh72 Wr3Q== X-Gm-Message-State: AODbwcBmQtqOvTJ2sHDdqWXiFLDqApON54kzVQGcxS9FatkcWEiFfpnP zX6WJj4DbEz2lwAyD4zEGBV9WKrrrsyt X-Received: by 10.31.33.3 with SMTP id h3mr3829615vkh.29.1496419713430; Fri, 02 Jun 2017 09:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 09:08:12 -0700 (PDT) In-Reply-To: <20170602145655.msfjw35qhoev4sm2@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> From: Lorenzo Colitti Date: Sat, 3 Jun 2017 01:08:12 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: draft-bourbaki-6man-classless-ipv6@ietf.org, Peter Hessler , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a11c0087e749b510550fc5dd7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:08:36 -0000 --001a11c0087e749b510550fc5dd7 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 11:56 PM, Job Snijders wrote: > > - The document lists no compelling use cases of what you can do > > with less than 2^64 addresses per link than you can't do with a > > 2^64 addresses per link. > > This is not true. The security section for instance shows: "In such > cases, the use of smaller subnets forces an operational limit on such > data structures, thus helping mitigate some pathological behaviors (such > as Neighbor Cache Exhaustion attacks)." > I said "compelling". Those attacks have relatively simple operational countermeasures. They were discovered several years ago, and we're coping just fine. > > > - The only technical motivation in this draft seems to be "classful > > addressing was a bad idea in IPv4". That's not a valid argument in > IPv6 > > because the address space is completely different. A /64 is *four > billion > > times* bigger than the IPv4 internet. That's 10,000 times more than > the > > difference between a grain of sand and the whole planet we live on. > Such a > > huge scaling difference pretty much invalidates any argument that > solutions > > that worked well in IPv4 will work well in IPv6. > > Would be a shame to throw away lessons learned from IPv4. > I think that's exactly the fallacy here. It is not useful to apply something you learned about IPv4 addressing to IPv6, because the number of addresses is incomparably bigger. Rule of thumb in software engineering is that a solution usually scales by one or two orders of magnitude. Here we have something like 34 orders of magnitude. Even a single /64 is 9 orders of magnitude larger than the IPv4 Internet. It really doesn't make sense to assign addresses the same way. > Making IPv6 look more like IPv4 (for instance through broader adoption > of DHCPv6 w/ routing options, and classlessness like in IPv4) will > positively impact IPv6 deployment. > But the deployment we get will be dumbed down to the level of functionality that we can support (and suffer from) in IPv4. It's not worth it. Example: I don't want us to have to deal with NAT any more, ever. If you think we can use DHCPv6 without ending up with NAT, then please read RFC7934 in a loop until you understand why we can't. :-) --001a11c0087e749b510550fc5dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 2, 2017 at 11:56 PM, Job Snijders <job@ntt.net> wrote:
=
>=C2=A0 =C2=A0 - The document lists no co= mpelling use cases of what you can do
>=C2=A0 =C2=A0 with less than 2^64 addresses per link t= han you can't do with a
>=C2=A0 =C2=A0 2^64 addresses per link.

This is not true. The security section for instance shows: "In = such
cases, the use of smaller subnets forces an operational limit on such
data structures, thus helping mitigate some pathological behaviors (such as Neighbor Cache Exhaustion attacks)."

I said "compelling". Those attacks have relatively simple o= perational countermeasures. They were discovered several years ago, and we&= #39;re coping just fine.
=C2=A0

>=C2=A0 =C2=A0 - The only technical motivation in this draft seems to be= "classful
>=C2=A0 =C2=A0 addressing was a bad idea in IPv4".= That's not a valid argument in IPv6
>=C2=A0 =C2=A0 because the address space is completely different. A /64 = is *four billion
>=C2=A0 =C2=A0 times* bigger than the IPv4 internet. That's 10,000 t= imes more than the
>=C2=A0 =C2=A0 difference between a grain of sand and the whole planet w= e live on. Such a
>=C2=A0 =C2=A0 huge scaling difference pretty much invalidates any argum= ent that solutions
>=C2=A0 =C2=A0 that worked well in IPv4 will work well in IPv6.

Would be a shame to throw away lessons learned from IPv4.

I think that's exactly the fallacy here. It i= s not useful to apply something you learned about IPv4 addressing to IPv6, = because the number of addresses is incomparably bigger. Rule of thumb in so= ftware engineering is that a solution usually scales by one or two orders o= f magnitude. Here we have something like 34 orders of magnitude. Even a sin= gle /64 is 9 orders of magnitude larger than the IPv4 Internet. It really d= oesn't make sense to assign addresses the same way.
=C2=A0
Making IPv6 look more like IPv4 (for inst= ance through broader adoption
of DHCPv6 w/ routing options, and classlessness like in IPv4) will
positively impact IPv6 deployment.

But = the deployment we get will be dumbed down to the level of functionality tha= t we can support (and suffer from) in IPv4. It's not worth it.

Example: I don't want us to have to deal with NAT any = more, ever. If you think we can use DHCPv6 without ending up with NAT, then= please read RFC7934 in a loop until you understand why we can't. :-)
--001a11c0087e749b510550fc5dd7-- From nobody Fri Jun 2 09:16:22 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C58261294DB; Fri, 2 Jun 2017 09:16:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'Path MTU Discovery for IP version 6' to Internet Standard (draft-ietf-6man-rfc1981bis-08.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ipv6@ietf.org, Ole Troan , otroan@employees.org, draft-ietf-6man-rfc1981bis@ietf.org, suresh.krishnan@gmail.com, rfc-editor@rfc-editor.org, 6man-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <149642017480.31788.16582937937569528863.idtracker@ietfa.amsl.com> Date: Fri, 02 Jun 2017 09:16:14 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:16:15 -0000 The IESG has approved the following document: - 'Path MTU Discovery for IP version 6' (draft-ietf-6man-rfc1981bis-08.txt) as Internet Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ Technical Summary This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. Working Group Summary The 6MAN working started working on advancing the IPv6 core specifications to Internet Standard at IETF93 July 2015. See: https://www.ietf.org/proceedings/93/slides/slides-93-6man-3.pdf The working group identified three RFCs to update (RFC2460, RFC4291, and RFC1981) by incorporating updates from other RFCs and Errata, and three to advance in place RFC4443, RFC3596, and RFC4941. After further analysis, the w.g. decided to not reclassify RFC4941 at this time. The working followed the requirements in RFC6410 for advancing a Draft Standard to Internet Standard. While RFC6410 describes how to handle Errata, it doesn't say anything about Updated-By RFCs. The working group, with the advice of our AD, incorporated the changes from the the Updated-By RFC and verified there was interoperability of the updates. All of the Updated-By and errata were brought into the new draft in small steps to allow thorough review of all of the changes. A summary and link to diff from the previous version was sent to the mailing list. All of the changes to each draft were also discussed in detail at IETF94, IETF95, IETF96, and IETF97. All of the changes from RFC1981 are summarized in Appendix B and are ordered by the Internet Draft that brought the change in. This document is an update to RFC1981 that was published prior to RFC2119 being published. Consequently while it does use "should/must" style language in upper and lower case, the document does not cite the RFC2119 definitions. Since the changes in this update were very limited, the w.g. concluded to not change any of this language. A working group last call for moving this and the other two documents to Internet Standard was started on 30 May 2016. Reviews were also requested. Issues found during the last call and reviews were entered into the 6MAN ticket system. These are now closed. Document Quality IPv6 is implemented on most platforms (hosts, routers, servers, etc.), including proprietary and open source. A list of products that have received the IPV6 Ready logo can be found at: https://www.ipv6ready.org/db/index.php/public/?o=4 Most major ISP now support IPv6, as well as many mobile operators. Google’s IPv6 stats at https://www.google.com/intl/en/ipv6/statistics.html show they are seeing now about 15% of their overall user traffic is IPv6. Country adoption is 29% in the US, Germany 27%, Finland 12%, Japan 14%, Brazil 11%. IPv6 users per AS can be found at http://stats.labs.apnic.net/aspop The University of New Hampshire InterOperability Laboratory (UNH) analyzed the incorporated updates to insure they were implemented and interoperable. No problems were found. Their report can be found at: https://www.ietf.org/proceedings/95/slides/slides-95-6man-2.pdf No MIB, Media, or other expert reviews are required. Personnel Document Shepherd: Ole Trøan Responsible AD: Suresh Krishnan IETF Last Call Summary The document received lots of comments during IETF last call. The two main classes of issues that were brought up were transport layer related issues and security related issues. These issues have been fixed in the latest version of the document. There was also some concern raised about the effects of ICMPv6 filtering on the Internet on the PMTUD protocol. To address this, text was added to the introduction to describe the effects of ICMPv6 filtering. RFC Editor Note OLD: Alternatively, the retransmission could be done in immediate response to a notification that the Path MTU was decreased, but only for the specific connection specified by the Packet Too Big message, but only based on the message and connection. NEW: Alternatively, the retransmission could be done in immediate response to a notification that the Path MTU was decreased, but only for the specific connection specified by the Packet Too Big message. From nobody Fri Jun 2 10:15:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C12126557 for ; Fri, 2 Jun 2017 10:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qzfrmZBdYgM for ; Fri, 2 Jun 2017 10:15:05 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AED1205F0 for ; Fri, 2 Jun 2017 10:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52HF3qG043040; Fri, 2 Jun 2017 10:15:04 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52HEuxM042830 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 10:14:56 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 10:14:55 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 10:14:55 -0700 From: "Manfredi, Albert E" To: Lorenzo Colitti CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfA= Date: Fri, 2 Jun 2017 17:14:55 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 17:15:06 -0000 Pj4gV291bGQgYmUgYSBzaGFtZSB0byB0aHJvdyBhd2F5IGxlc3NvbnMgbGVhcm5lZCBmcm9tIElQ djQuDQo+DQo+IEkgdGhpbmsgdGhhdCdzIGV4YWN0bHkgdGhlIGZhbGxhY3kgaGVyZS4gSXQgaXMg bm90IHVzZWZ1bCB0byBhcHBseSBzb21ldGhpbmcNCj4geW91IGxlYXJuZWQgYWJvdXQgSVB2NCBh ZGRyZXNzaW5nIHRvIElQdjYsIGJlY2F1c2UgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMNCj4gaXMg aW5jb21wYXJhYmx5IGJpZ2dlci4gUnVsZSBvZiB0aHVtYiBpbiBzb2Z0d2FyZSBlbmdpbmVlcmlu ZyBpcyB0aGF0IGENCj4gc29sdXRpb24gdXN1YWxseSBzY2FsZXMgYnkgb25lIG9yIHR3byBvcmRl cnMgb2YgbWFnbml0dWRlLiBIZXJlIHdlIGhhdmUNCj4gc29tZXRoaW5nIGxpa2UgMzQgb3JkZXJz IG9mIG1hZ25pdHVkZS4gRXZlbiBhIHNpbmdsZSAvNjQgaXMgOSBvcmRlcnMgb2YNCj4gbWFnbml0 dWRlIGxhcmdlciB0aGFuIHRoZSBJUHY0IEludGVybmV0Lg0KDQpZZWFoLCB0aGlzIGh5cGUgbmVl ZHMgdG8gZW5kLiBBIC82NCBoYXJkIGJvdW5kYXJ5IG1lcmVseSBkb3VibGVzIHRoZSB3aWR0aCBv ZiBJUHY0IGFkZHJlc3NlcywgYW5kIGVncmVnaW91c2x5IHdhc3RlcyB0aGUgbWFqb3JpdHkgb2Yg dGhlIHJlbWFpbmluZyA2NCBiaXRzLiAgQW5kIHdpdGggaW5ub3ZhdGlvbnMgc3VjaCBhcyBJb1Qs IHN1ZGRlbmx5IGFsbCB0aGF0IHZhc3QgZXh0cmEgc3BhY2UgY2FuIGJlIHN3YWxsb3dlZCB1cC4g QmFjayBpbiAxOTgwLCBJUHY0IGFkZHJlc3Mgc3BhY2Ugc2VlbWVkIHByZXR0eSBodWdlIHRvby4g VGhlIGRlcGxveW1lbnQgYXNzdW1wdGlvbnMgbWFkZSBhcmUga2V5LCB3aGVuIHBlb3BsZSBtYWtl IGFzc2VydGlvbnMgYWJvdXQgdGhlIHZhc3RuZXNzIG9mIHRoZSBhZGRyZXNzIHNwYWNlLg0KDQo+ IEV4YW1wbGU6IEkgZG9uJ3Qgd2FudCB1cyB0byBoYXZlIHRvIGRlYWwgd2l0aCBOQVQgYW55IG1v cmUsIGV2ZXIuDQoNCkkndmUgc2VlbiB0aGlzIGNvbW1lbnQgbWFkZSBiZWZvcmUsIGFuZCB5ZXQg dGhlIC82NCBoYXJkIGJvdW5kYXJ5IHByYWN0aWNhbGx5IGd1YXJhbnRlZXMgdGhhdCBOQVQgd2ls bCBnZXQgdXNlZCB3aXRoIElQdjYuIEl0J3MgZXhhY3RseSB0aGUgc2FtZSBzb2x1dGlvbiwgZm9y IGV4YWN0bHkgdGhlIHNhbWUgcHJvYmxlbS4gSW5hYmlsaXR5IHRvIGV4cGFuZCBhdCB0aGUgZWRn ZXMuDQoNCkJlcnQNCg0K From nobody Fri Jun 2 10:40:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787DC127180 for ; Fri, 2 Jun 2017 10:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5a8VKIQUGci for ; Fri, 2 Jun 2017 10:40:03 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF0E126CE8 for ; Fri, 2 Jun 2017 10:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52He2Tb020039; Fri, 2 Jun 2017 10:40:03 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52Hdvaq019799 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 10:39:58 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 10:39:57 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 10:39:56 -0700 From: "Templin, Fred L" To: "Manfredi, Albert E" , Lorenzo Colitti CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olsSo24MvI90arLJF3XDEOhqISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAAYWAA== Date: Fri, 2 Jun 2017 17:39:56 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 17:40:05 -0000 Hi Bert, When you say "IoT", I think about my cellphone and all of its associated de= vices. Or, my home router and all of the addressable devices in my home. Giving ea= ch of them a /64 then allowing them to portion their /64s internally as they s= ee fit (e.g., subnetting to longer prefixes) would not lead to NAT AFAICT. And, th= e address space may be used internally for multi-addressing purposes (e.g., privacy addresses, random interface identifiers, etc.) which is one of the advantages of IPv6. Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E > Sent: Friday, June 02, 2017 10:15 AM > To: Lorenzo Colitti > Cc: IETF IPv6 Mailing List > Subject: RE: draft-bourbaki-6man-classless-ipv6-00 >=20 > >> Would be a shame to throw away lessons learned from IPv4. > > > > I think that's exactly the fallacy here. It is not useful to apply some= thing > > you learned about IPv4 addressing to IPv6, because the number of addres= ses > > is incomparably bigger. Rule of thumb in software engineering is that a > > solution usually scales by one or two orders of magnitude. Here we have > > something like 34 orders of magnitude. Even a single /64 is 9 orders of > > magnitude larger than the IPv4 Internet. >=20 > Yeah, this hype needs to end. A /64 hard boundary merely doubles the widt= h of IPv4 addresses, and egregiously wastes the majority > of the remaining 64 bits. And with innovations such as IoT, suddenly all= that vast extra space can be swallowed up. Back in 1980, IPv4 > address space seemed pretty huge too. The deployment assumptions made are= key, when people make assertions about the > vastness of the address space. >=20 > > Example: I don't want us to have to deal with NAT any more, ever. >=20 > I've seen this comment made before, and yet the /64 hard boundary practic= ally guarantees that NAT will get used with IPv6. It's > exactly the same solution, for exactly the same problem. Inability to exp= and at the edges. >=20 > Bert >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jun 2 12:17:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2297129C09 for ; Fri, 2 Jun 2017 12:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOEJmLqcMwMg for ; Fri, 2 Jun 2017 12:17:18 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E38129C03 for ; Fri, 2 Jun 2017 12:17:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52JHHTa037182; Fri, 2 Jun 2017 12:17:18 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52JHEl5037145 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Jun 2017 12:17:15 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 12:17:14 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 12:17:14 -0700 From: "Manfredi, Albert E" To: "Templin, Fred L" CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAH/0AP//opYA Date: Fri, 2 Jun 2017 19:17:14 +0000 Message-ID: <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:17:20 -0000 -----Original Message----- From: Templin, Fred L=20 > When you say "IoT", I think about my cellphone and all of its > associated devices. Or, my home router and all of the addressable > devices in my home. Giving each of them a /64 then allowing them > to portion their /64s internally as they see fit (e.g., subnetting > to longer prefixes) would not lead to NAT AFAICT. True, Fred, but you have posited "giving each of them a /64," presumably by= your ISP. I'm saying instead, you create a mobile hotspot with your smartp= hone, and your smartphone is only provided with a single /64. Now you need = to provide routes to each device behind the smartphone, which can be aggreg= ated from the smartphone's /64. Or similarly, any number of IoT devices, ea= ch provided with a /64, but each of them needing to create multiple subnets= . No matter what type of privacy or temporary addresses you use, a hard /64 b= oundary, without a NAT option, will prevent you from be able to aggregate r= outes. Any expansion at the edges would create a flat address space. Ultimately, this increasing flat address space will become limiting, IPv6 o= r not. Bert From nobody Fri Jun 2 12:17:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D9012896F for ; Fri, 2 Jun 2017 12:17:41 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zeRl7wwyAC7 for ; Fri, 2 Jun 2017 12:17:40 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BC1129BEC for ; Fri, 2 Jun 2017 12:17:40 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 9so55614754pfj.1 for ; Fri, 02 Jun 2017 12:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rs3crKX1nMai8YGzECpGf4VOqWLxK6rp0SdIFw9Jkn0=; b=RCT5XiaWjwF1bJVxfF3mZNjndXXaDnDNjgv4rm+eWxyIPK+l248hFe84kUABn4vKlu uedqCDc7AIqhj9hYnoioZlQSD+Qz3/Wmewti/F1akQkt0EPhWGCg6o3cb/ZPLfJy7yUq w9uWAGtXs5YieypzOsqX0d//EFVWoBNCAxGXgzPo3yGur3u3svBSl5V1MHP6bGUbJcEe Qh62ywSruYFOYtFA3l9sZhTL0Bd4LjjYIJqPQ8g+KH9rVBNtixZE3cAwcu6T27KpZbcM y3Q+SCMWgPCEvur+1ye0/uLlxXUUVfWo4s7ECvvzN1vn8KLbSJzBIflzaZwcCsGliUNB dgFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rs3crKX1nMai8YGzECpGf4VOqWLxK6rp0SdIFw9Jkn0=; b=CFjXH/UAcgGz2vuqPMb55x1oPjm2viiyEbkbzhE0EdH+O23S4A1ShCDEPWy5HZ5ULP +NiavU3g9QTrKZKgLVdRi0zADsCuveL3gMBd+h5uDcWF+SH4svT0qMPuSzD6VksCOmnC IBKmcww0HGxWbVxvuyktJmbBVocmpTTsSX5m3YqLZhiR0SG98Z2W7omPdYt8+NZcPaK/ erMAKh7yRCaeP99tuwjJ9l1qelVMdpFf/+IiotrolPjTRTnvFTSwzsr0gpAiuCeWeRdd YOtxFH1CgP5cRlC9zPgxGe//JabEa1v5fDzPnWmF9Cg+lEViASs/HsAIouvrheyGjE2p M7Ug== X-Gm-Message-State: AODbwcBQV+DN7FWtOErAytMLqRz5PMtSQ/DiNa7T4cubxtfzp4ClrNPU xS2A/JpDz2/wVoDrR9yefA== X-Received: by 10.99.103.7 with SMTP id b7mr8752990pgc.2.1496431059202; Fri, 02 Jun 2017 12:17:39 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:1:e9b4:4fd1:22cb? ([2620:0:10e7:10:1:e9b4:4fd1:22cb]) by smtp.gmail.com with ESMTPSA id v9sm41583702pfa.43.2017.06.02.12.17.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 12:17:38 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_998B7677-3437-48CA-AAAE-B28705380936" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Fri, 2 Jun 2017 12:17:45 -0700 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> To: IETF IPv6 Mailing List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:17:42 -0000 --Apple-Mail=_998B7677-3437-48CA-AAAE-B28705380936 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 2, 2017, at 10:14, Manfredi, Albert E = wrote: > On Jun 2, 2017, at 09:08, Lorenzo Colitti wrote: >>=20 >> Example: I don't want us to have to deal with NAT any more, ever. >=20 > I've seen this comment made before, and yet the /64 hard boundary = practically guarantees that NAT will get used with IPv6. It's exactly = the same solution, for exactly the same problem. Inability to expand at = the edges. I have reluctantly come to believe that service providers MUST have the = ability to force their economy class subscribers into artificially small = allocations, so they can charge premium prices for larger ones drawn = from the same functionally limitless supply at equivalent cost. We have = to expect that only business and luxury class subscribers will have = sufficiently large allocations that IPv6/NAT will add more costs than it = saves them. I once believed IPv4/NAT was about preserving scarce number resources. I = now think that was wrong. It was always about optimizing rents across = differing classes of subscribers even when the extracted resource on = which the rents are derived is practically unlimited. In this one = respect, IPv6 is no different than IPv4. As a purely technical matter, = the rent MUST flow. Accordingly, I say we should stop arguing that IPv6 does not require = NAT. For certain classes of subscriber, NAT is essential for making IPv6 = service available at an affordable price. Indeed, any internet layer = that uses fixed size global scope addresses requires NAT at the = provider/subscriber boundary. --james woodyatt > --Apple-Mail=_998B7677-3437-48CA-AAAE-B28705380936 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 2, 2017, at 10:14, Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote:
On Jun 2, 2017, at = 09:08, Lorenzo Colitti <lorenzo@google.com> wrote:

Example: I don't want us to have to deal with = NAT any more, ever.

I've seen = this comment made before, and yet the /64 hard boundary practically = guarantees that NAT will get used with IPv6. It's exactly the same = solution, for exactly the same problem. Inability to expand at the = edges.

I = have reluctantly come to believe that service providers MUST have the = ability to force their economy class subscribers into artificially small = allocations, so they can charge premium prices for larger ones drawn = from the same functionally limitless supply at equivalent cost. We have = to expect that only business and luxury class subscribers will have = sufficiently large allocations that IPv6/NAT will add more costs than it = saves them.

I = once believed IPv4/NAT was about preserving scarce number resources. I = now think that was wrong. It was always about optimizing rents across = differing classes of subscribers even when the extracted resource on = which the rents are derived is practically unlimited. In this one = respect, IPv6 is no different than IPv4. As a purely technical matter, = the rent MUST flow.

Accordingly, I say we should stop arguing that IPv6 does not = require NAT. For certain classes of subscriber, NAT is essential for = making IPv6 service available at an affordable price. Indeed, any = internet layer that uses fixed size global scope addresses requires NAT = at the provider/subscriber boundary.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_998B7677-3437-48CA-AAAE-B28705380936-- From nobody Fri Jun 2 12:30:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2312896F for ; Fri, 2 Jun 2017 12:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swLM4LJDU7bE for ; Fri, 2 Jun 2017 12:30:52 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA06126C26 for ; Fri, 2 Jun 2017 12:30:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52JUpwJ058237; Fri, 2 Jun 2017 12:30:52 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52JUiC5058172 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 12:30:44 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 12:30:42 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 12:30:43 -0700 From: "Manfredi, Albert E" To: james woodyatt , IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAJtJgP//i6kg Date: Fri, 2 Jun 2017 19:30:43 +0000 Message-ID: <2c496b044bc941bda1abd8f5662c5224@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:30:54 -0000 From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of james woodyatt > I have reluctantly come to believe that service providers MUST have > the ability to force their economy class subscribers into artificially > small allocations, so they can charge premium prices for larger ones > drawn from the same functionally limitless supply at equivalent cost. Interesting way to put it, somewhat negative, but in essence I agree. Anoth= er less negative way to put it is that your cheap subscribers, those only r= equesting a single /64, can provide low cost service to many, many other de= vices. This responds also to Fred's point, of being "given" many /64 addresses fro= m the ISP. It would be far cheaper and far more convenient to *not* have to= go to the trouble of requesting dozens or more other /64s, from your ISP. > I once believed IPv4/NAT was about preserving scarce number resources. > I now think that was wrong. It was always about optimizing rents across > differing classes of subscribers even when the extracted resource on > which the rents are derived is practically unlimited. In this one > respect, IPv6 is no different than IPv4. Complete agreement. It's democratization. Users can do their own thing. Jus= t like they do with IPv4 NAT. This need doesn't go away with IPv6, unless w= e create a police force that guarantees everyone a /48, which would then fu= rther put to the lie the idea of this super vast IPv6 address space. Bert From nobody Fri Jun 2 12:35:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D46129BB8 for ; Fri, 2 Jun 2017 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC2ll4v_2Y5k for ; Fri, 2 Jun 2017 12:35:51 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EAC11293E1 for ; Fri, 2 Jun 2017 12:35:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52JZodl012539; Fri, 2 Jun 2017 12:35:50 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52JZkbF012520 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Jun 2017 12:35:46 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 12:35:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 12:35:45 -0700 From: "Templin, Fred L" To: "Manfredi, Albert E" CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olsSo24MvI90arLJF3XDEOhqISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAAYWAIAAlQ4A//+MbiA= Date: Fri, 2 Jun 2017 19:35:45 +0000 Message-ID: <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:35:53 -0000 HI Bert, > -----Original Message----- > From: Manfredi, Albert E > Sent: Friday, June 02, 2017 12:17 PM > To: Templin, Fred L > Cc: IETF IPv6 Mailing List > Subject: RE: draft-bourbaki-6man-classless-ipv6-00 >=20 > -----Original Message----- > From: Templin, Fred L >=20 > > When you say "IoT", I think about my cellphone and all of its > > associated devices. Or, my home router and all of the addressable > > devices in my home. Giving each of them a /64 then allowing them > > to portion their /64s internally as they see fit (e.g., subnetting > > to longer prefixes) would not lead to NAT AFAICT. >=20 > True, Fred, but you have posited "giving each of them a /64," My meaning was for the ISP to give the cell phone or home gateway a /64, then let the cell phone/ home gateway subnet the /64 to the IoT devices within the subnetwork it provides as it sees fit. (Where I am using the term "subnetwork" to refer to mobile hotspots, home networks, etc.) One /64 goes in the ISP's routing system, but countless billions of addresses/prefixes could be assigned within the subnetwork. There is no NAT in that picture. Thanks - Fred > presumably by your ISP. I'm saying instead, you create a mobile hotspot > with your smartphone, and your smartphone is only provided with a single = /64. Now you need to provide routes to each device > behind the smartphone, which can be aggregated from the smartphone's /64.= Or similarly, any number of IoT devices, each provided > with a /64, but each of them needing to create multiple subnets. >=20 > No matter what type of privacy or temporary addresses you use, a hard /64= boundary, without a NAT option, will prevent you from be > able to aggregate routes. Any expansion at the edges would create a flat = address space. >=20 > Ultimately, this increasing flat address space will become limiting, IPv6= or not. >=20 > Bert From nobody Fri Jun 2 13:01:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF62127337 for ; Fri, 2 Jun 2017 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeqMRLH-cgXh for ; Fri, 2 Jun 2017 13:01:53 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2930127B57 for ; Fri, 2 Jun 2017 13:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52K1p9u053683; Fri, 2 Jun 2017 13:01:51 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52K1iXB053561 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Jun 2017 13:01:44 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 13:01:43 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 13:01:43 -0700 From: "Manfredi, Albert E" To: "Templin, Fred L" CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAH/0AP//opYAgAB9xoD//492sA== Date: Fri, 2 Jun 2017 20:01:43 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:01:54 -0000 -----Original Message----- From: Templin, Fred L=20 > My meaning was for the ISP to give the cell phone or home gateway > a /64, then let the cell phone/ home gateway subnet the /64 to > the IoT devices within the subnetwork it provides as it sees fit. Presumably, using some sort of internal address format, also /64, such as p= rivacy addresses? Yes, true, but ... I'd only make two observations. If the internal address scheme is globally = routable, then you can't escape that fact that your ISP is going to have to= list potentially many, many routes, reachable through that smartphone's (o= r home gateway, or internal IoT device gateway) /64. This state of affairs = is not desirable. If the internal address structure is not routable, the obvious example bein= g ULAs, then we're back to requiring a NAT. So a hard /64 boundary limits expansion at the edges, unless we use a NAT. = Without resorting to a NAT, your ISP will have something to say about what = you do, it seems to me. And of course, "ISP" is only to put the problem in = terms a home user will understand. The same general issue arises with any n= etwork. Bert From nobody Fri Jun 2 13:03:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1261243F6 for ; Fri, 2 Jun 2017 13:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQqkU8JOyDP5 for ; Fri, 2 Jun 2017 13:03:36 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14C8127241 for ; Fri, 2 Jun 2017 13:03:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52K3ZMQ056552; Fri, 2 Jun 2017 13:03:35 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52K3Uoq056498 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Jun 2017 13:03:31 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 13:03:30 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 13:03:30 -0700 From: "Manfredi, Albert E" To: "Templin, Fred L" CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAH/0AP//opYAgAB9xoD//492sAAAViDQ Date: Fri, 2 Jun 2017 20:03:30 +0000 Message-ID: <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:03:38 -0000 -----Original Message----- From: Templin, Fred L=20 > My meaning was for the ISP to give the cell phone or home gateway > a /64, then let the cell phone/ home gateway subnet the /64 to > the IoT devices within the subnetwork it provides as it sees fit. Sorry, I have to make an important correction: Presumably, using some sort of internal address format, also /64, such as p= rivacy addresses? Yes, true, but ... I'd only make two observations. If the internal address scheme is globally = routable, then you can't escape that fact that your ISP is going to have to= list potentially many, many routes, reachable through that smartphone's (o= r home gateway, or internal IoT device gateway) /64. This state of affairs = is not desirable. If the internal address structure is not *globally* routable, the obvious e= xample being ULAs, then we're back to requiring a NAT. So a hard /64 boundary limits expansion at the edges, unless we use a NAT. = Without resorting to a NAT, your ISP will have something to say about what = you do, it seems to me. And of course, "ISP" is only to put the problem in = terms a home user will understand. The same general issue arises with any n= etwork. Bert From nobody Fri Jun 2 13:13:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BB8124BE8 for ; Fri, 2 Jun 2017 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flPkTwowg9PD for ; Fri, 2 Jun 2017 13:13:39 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95B61201FA for ; Fri, 2 Jun 2017 13:13:39 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8C19D880E7 for ; Fri, 2 Jun 2017 13:13:39 -0700 (PDT) Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5A7943280AE4 for ; Fri, 2 Jun 2017 13:13:39 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> From: Brian Haberman Message-ID: Date: Fri, 2 Jun 2017 16:13:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mx4F1cxRGW5uFNFXs2UBw9sqbK1HELw4L" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:13:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mx4F1cxRGW5uFNFXs2UBw9sqbK1HELw4L Content-Type: multipart/mixed; boundary="lJJh6HHpnJJRxfWgj8W1a8Oc5DugpweBg"; protected-headers="v1" From: Brian Haberman To: ipv6@ietf.org Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> --lJJh6HHpnJJRxfWgj8W1a8Oc5DugpweBg Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Bert, On 6/2/17 4:03 PM, Manfredi, Albert E wrote: > -----Original Message----- > From: Templin, Fred L=20 >=20 >> My meaning was for the ISP to give the cell phone or home gateway >> a /64, then let the cell phone/ home gateway subnet the /64 to >> the IoT devices within the subnetwork it provides as it sees fit. >=20 > Sorry, I have to make an important correction: >=20 > Presumably, using some sort of internal address format, also /64, such = as privacy addresses? Yes, true, but ... I interpreted Fred's proposal as: 1. ISP gives the phone a /64 2. The phone delegates longer prefixes to the devices behind it from the = /64 3. The ISP router has a single /64 route that points to the phone Regards, Brian --lJJh6HHpnJJRxfWgj8W1a8Oc5DugpweBg-- --mx4F1cxRGW5uFNFXs2UBw9sqbK1HELw4L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZMcbwAAoJEBOZRqCi7goqexwIANI0GIvxbvqKNkOBAL6Z1IRo wCsTzWjfbdttyYfHgyNukomTNHUBKWx9uQ5BS0bhTws8pr1PYYM2xcBJyTmlVk20 8OhSd7cEsOzbiEM1Pn+X+QZ5EJf26YZyjrELZ2rTOnL4L0heiL4IWbjHhGBdRrn+ HroJJS8wwk4nZ967iH+jVgxA8Vg5II5zQFZGFN1P+64o3czK/2k2Fd047GwDj5jr +IHJKlb5oy7m3cWUuyD1m9Y1gh/Swbg3LyDJMb4mpUBpVo3Ei02Th/nt3rc8z7mh NfBW2Wp4VtIjiEbovU69fMbabJWYqXbz2fngKXxLlJXS+ccWd3mUmH3SwmUlqpw= =BVDP -----END PGP SIGNATURE----- --mx4F1cxRGW5uFNFXs2UBw9sqbK1HELw4L-- From nobody Fri Jun 2 13:14:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD971279E5 for ; Fri, 2 Jun 2017 13:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g89BWb8Eyadv for ; Fri, 2 Jun 2017 13:14:22 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA071124BE8 for ; Fri, 2 Jun 2017 13:14:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52KEL22008515; Fri, 2 Jun 2017 13:14:21 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52KEDUe008354 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 2 Jun 2017 13:14:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 13:14:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 13:14:11 -0700 From: "Templin, Fred L" To: "Manfredi, Albert E" CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olsSo24MvI90arLJF3XDEOhqISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAH/0AP//opYAgAB9xoD//492sAAAViDQAAAxDtA= Date: Fri, 2 Jun 2017 20:14:11 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:14:23 -0000 Bert, I think you are either not reading or not understanding what I am wri= ting. It must be the former, because what I am writing is not complicated. Another question that we would have to ask is what is the longest prefix th= at we should expect an ISP (or a core Internet router, for that matter) to car= ry in its routing tables? A /80? A /96? Thanks - Fred > -----Original Message----- > From: Manfredi, Albert E > Sent: Friday, June 02, 2017 1:04 PM > To: Templin, Fred L > Cc: IETF IPv6 Mailing List > Subject: RE: draft-bourbaki-6man-classless-ipv6-00 >=20 > -----Original Message----- > From: Templin, Fred L >=20 > > My meaning was for the ISP to give the cell phone or home gateway > > a /64, then let the cell phone/ home gateway subnet the /64 to > > the IoT devices within the subnetwork it provides as it sees fit. >=20 > Sorry, I have to make an important correction: >=20 > Presumably, using some sort of internal address format, also /64, such as= privacy addresses? Yes, true, but ... >=20 > I'd only make two observations. If the internal address scheme is globall= y routable, then you can't escape that fact that your ISP is > going to have to list potentially many, many routes, reachable through th= at smartphone's (or home gateway, or internal IoT device > gateway) /64. This state of affairs is not desirable. >=20 > If the internal address structure is not *globally* routable, the obvious= example being ULAs, then we're back to requiring a NAT. >=20 > So a hard /64 boundary limits expansion at the edges, unless we use a NAT= . Without resorting to a NAT, your ISP will have something > to say about what you do, it seems to me. And of course, "ISP" is only to= put the problem in terms a home user will understand. The > same general issue arises with any network. >=20 > Bert From nobody Fri Jun 2 13:19:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01344127735 for ; Fri, 2 Jun 2017 13:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W29srWkkNBrr for ; Fri, 2 Jun 2017 13:19:52 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 26CF9127241 for ; Fri, 2 Jun 2017 13:19:51 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id g76so12120376wrd.1 for ; Fri, 02 Jun 2017 13:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tYmIL4OtPUDuAYo+rkJoKY4H46KVR7q7GsR4XR15qIk=; b=PSTrMpZQbBBpiRGH8uIjUdK330kqkYGG3GA4F7yOdaPahjB73AoGNLq4Fvkj5zjxXl fknjAid9UQBzSGI6kk5FLDJ9ar+r8opYZsWndwjiX3ie2wiAeBvuIyHMRbw6ukL9PRD9 x+k/+A0ZPyjjHDWm9z9FRCH2JLPsU4mLgTcJr/ddXnnFjIVE03FnZ7ZvWcUQCDDgTcSu tS/Gs/Rw1OLWgvTWPp1vOVF0M4Z/N1C+rBV6BQYTuQUkpmBw2my6EaaHkKwf0e5/kvv9 avy/TGw3OHt2HIuDvkfxO/6+5x0yU7EICeUqRGSWo5QgrB9uPmM9lUHw/4VvymhkguPJ AjDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tYmIL4OtPUDuAYo+rkJoKY4H46KVR7q7GsR4XR15qIk=; b=ezxgRLxqN9qYNiX4byVMFF/hIeHW9gKwa+4gGZqt+xt439R/Lp7tweKO8nVv+r7UFO mosUNe4CRteQMxTPW+6Ib7Qf/g1GG3WdpzfvDOVNBMoLY9cvOKdLAx66jT2IqfUY2ZUi SaNfgdWakTvAjffaJGJ/5q5bhq8NDFvZ8cBuieG+AzSZ/+IF9Z2Py5b3kKyv8GQicGZe PpT1hoCaLp1iLoIiwfdiPMlOjxjxKG3D4kJCQiHeyWm40WhlpUD7g0EKaSzw/kf+qD9p DZm7kRo7PAXGbPSVMEtKMZJ6DuTBOxbYc4kUdnR+fjOBJSJO11hqtooI4uxaRsikz1Dx qoMA== X-Gm-Message-State: AODbwcCCG1pIhFruhRR6Yppf/NGt+0JJMqc8u7xTMy8UFh3jlfNq5SVV WuBGBDXVFMX0HD0FMmt24UGe5UsO0xTN X-Received: by 10.223.131.33 with SMTP id 30mr3583650wrd.37.1496434790464; Fri, 02 Jun 2017 13:19:50 -0700 (PDT) MIME-Version: 1.0 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: From: Job Snijders Date: Fri, 02 Jun 2017 20:19:39 +0000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" , "Templin, Fred L" Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c0d0d221dc4d40550ffe0d8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:19:54 -0000 --94eb2c0d0d221dc4d40550ffe0d8 Content-Type: text/plain; charset="UTF-8" On Fri, 2 Jun 2017 at 22:14, Templin, Fred L wrote: > Bert, I think you are either not reading or not understanding what I am > writing. > It must be the former, because what I am writing is not complicated. > > Another question that we would have to ask is what is the longest prefix > that > we should expect an ISP (or a core Internet router, for that matter) to > carry > in its routing tables? A /80? A /96? Generally speaking most ISPs accept up to /48 from EBGP peers. Some exceptions apply, for instance if a valid route6: object exists or the two parties agreed beforehand to accept longer prefixes. Perhaps this number changes over time. We'll see. Kind regards, Job --94eb2c0d0d221dc4d40550ffe0d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, 2 Jun 2017 at 22:14, Templ= in, Fred L <Fred.L.Templin@= boeing.com> wrote:
Bert, I = think you are either not reading or not understanding what I am writing. It must be the former, because what I am writing is not complicated.

Another question that we would have to ask is what is the longest prefix th= at
we should expect an ISP (or a core Internet router, for that matter) to car= ry
in its routing tables? A /80? A /96?


Generally speaking most ISPs accept up to /48 from EBGP peers. Som= e exceptions apply, for instance if a valid route6: object exists or the tw= o parties agreed beforehand to accept longer prefixes.=C2=A0

=
Perhaps this number changes over time. We'll see.=C2=A0

Kind regards,

Job
=
--94eb2c0d0d221dc4d40550ffe0d8-- From nobody Fri Jun 2 13:21:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601EA127B5A for ; Fri, 2 Jun 2017 13:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swh9HnBPhOQw for ; Fri, 2 Jun 2017 13:21:11 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A8D1279E5 for ; Fri, 2 Jun 2017 13:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52KL90a005767; Fri, 2 Jun 2017 13:21:10 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52KL8J4005757 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 13:21:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 13:21:08 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 13:21:08 -0700 From: "Manfredi, Albert E" To: Brian Haberman , "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAH/0AP//opYAgAB9xoD//492sAAAViDQAA8M3IAADpZlQA== Date: Fri, 2 Jun 2017 20:21:08 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:21:12 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBIYWJlcm1hbg0KDQo+IEkgaW50ZXJwcmV0 ZWQgRnJlZCdzIHByb3Bvc2FsIGFzOg0KPg0KPiAxLiBJU1AgZ2l2ZXMgdGhlIHBob25lIGEgLzY0 DQo+DQo+IDIuIFRoZSBwaG9uZSBkZWxlZ2F0ZXMgbG9uZ2VyIHByZWZpeGVzIHRvIHRoZSBkZXZp Y2VzIGJlaGluZCBpdCBmcm9tIHRoZSAvNjQNCj4NCj4gMy4gVGhlIElTUCByb3V0ZXIgaGFzIGEg c2luZ2xlIC82NCByb3V0ZSB0aGF0IHBvaW50cyB0byB0aGUgcGhvbmUNCg0KT29vcHBzLCBzb3Jy eSBndXlzLCBJIHJlcmVhZC4gWWVzLCBidXQgdGhlbiB3ZSBoYXZlIG5vIGFyZ3VtZW50LCByaWdo dD8gV2UncmUgc2F5aW5nIGV4YWN0bHkgdGhlIHNhbWUgdGhpbmcuIFdlIGFyZSBzYXlpbmcgdGhh dCBhIGhhcmQgLzY0IGJvdW5kYXJ5IGluIElQdjYgYWRkcmVzc2VzIGhhcyBkcmF3YmFja3MsIGUu Zy4gZXhwYW5zaW9uIGF0IHRoZSBlZGdlcywgc28gaXQgc2hvdWxkIG5vdCBiZWNvbWUgYSBmaXh0 dXJlLg0KDQpBbmQgeWVzLCBub3cgb25lIG1pZ2h0IHdvbmRlciBob3cgbG9uZyBwcmVmaXhlcyBj YW4gYmVjb21lLiBJZiBJU1BzIHN0YXJ0IGhhbmRpbmcgb3V0IC8xMjhzLCB3ZSdyZSBiYWNrIHRv IHJlcXVyaXJuZyBOQVRzLg0KDQpCZXJ0DQoNCg== From nobody Fri Jun 2 13:30:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ECF128B8D for ; Fri, 2 Jun 2017 13:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yet6sJIXqqsx for ; Fri, 2 Jun 2017 13:30:05 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 9F0091279E5 for ; Fri, 2 Jun 2017 13:30:05 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so24696098ywr.0 for ; Fri, 02 Jun 2017 13:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7RytlZwO8wkxc+VaWSLjJSdVccbeAtdiRSoPFInamJc=; b=QCLc7E6fqBJncgQ4Fmd7lKE2quy8G+Ls6RXrwGmcWICzzIevqfcaOCBGwICCQitT+i voA/bv9cDX38+U/PxE9pqIK5gUd9BN8IutGNlsf3CmUu4zXcdB/ICr1wBaNb2VETPZ+F IhmpMj+PJBbcMxztxVaOJvzS4dzedDQ5YEIRLngw/awcd4FIQRC+r6VoNNVGJTnW3HOt u7fabeeCeEFpDD+6iQC5P9HK/YGRzgk+e5TGLJlk3zfJbfezMpMB0rkDIba+268M6/GY 7OzN7A9M6A6aiHbzuGle/CodB831rWOddWe1xUPFkwU8n8K2n/eoCKypsArVxzoY8bLT SMzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7RytlZwO8wkxc+VaWSLjJSdVccbeAtdiRSoPFInamJc=; b=MBYPZHPnSuPQWOLZX0lJOGoL+cwldqTakPkVh2s918s9YtL7FLV494u4L5DXfoXVn+ 7JzaGBFDaXFCpUnwe8jLNVHX25wqwwCjyPmabM7jtW8lIgkAuyS4XFLEvNGw65zomrOz Pb/C7dIvdEpVMq0MRgr+fQ6IUQ3fvAArVz83vD4TsEZXQ/x9rcBYzMzHq7RmBxSmJ++I aJGwEWcOV10l2/on9qR8BjWyFzcct8pOF+hf/XotTLt/8EMwVi6yz/X6NVFINwq8C1lH LUVZtCPHHEukwg7bs4Z/QAdXAYxPzISBwBSxoVccVOnMl0IHhnPwOGFXv5hI2Gp76OYw GdwQ== X-Gm-Message-State: AODbwcDgod8sYWzv6Fqqh95yNNTJmGhd8+A2hXIRuF3Ys8KjLYAk+z3W wiczACGURdVWxdzexuDwPjJXqt8Kyg== X-Received: by 10.129.62.14 with SMTP id l14mr7153884ywa.322.1496435404753; Fri, 02 Jun 2017 13:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.153.208 with HTTP; Fri, 2 Jun 2017 13:30:04 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> From: Ca By Date: Fri, 2 Jun 2017 13:30:04 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: james woodyatt Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403045f35c2bae7e80551000479" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:30:08 -0000 --f403045f35c2bae7e80551000479 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 12:17 PM, james woodyatt wrote: > On Jun 2, 2017, at 10:14, Manfredi, Albert E > wrote: > > On Jun 2, 2017, at 09:08, Lorenzo Colitti wrote: > > > Example: I don't want us to have to deal with NAT any more, ever. > > > I've seen this comment made before, and yet the /64 hard boundary > practically guarantees that NAT will get used with IPv6. It's exactly the > same solution, for exactly the same problem. Inability to expand at the > edges. > > > I have reluctantly come to believe that service providers MUST have the > ability to force their economy class subscribers into artificially small > allocations, so they can charge premium prices for larger ones drawn from > the same functionally limitless supply at equivalent cost. We have to > expect that only business and luxury class subscribers will have > sufficiently large allocations that IPv6/NAT will add more costs than it > saves them. > > I once believed IPv4/NAT was about preserving scarce number resources. I > now think that was wrong. It was always about optimizing rents across > differing classes of subscribers even when the extracted resource on which > the rents are derived is practically unlimited. In this one respect, IPv6 > is no different than IPv4. As a purely technical matter, the rent MUST flow. > > Accordingly, I say we should stop arguing that IPv6 does not require NAT. > For certain classes of subscriber, NAT is essential for making IPv6 service > available at an affordable price. Indeed, any internet layer that uses > fixed size global scope addresses requires NAT at the provider/subscriber > boundary. > > James, have you seen this situation in IPv6? I personally have not seen scenarios where there is class of service that requires IPv6 NAT or less than a /64 is given. I have also not seen in the IPv6 marketplace a scenario where cost is tied to address space size. Please share where this scenario is real. Regards, CB > > --james woodyatt > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --f403045f35c2bae7e80551000479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 12:17 PM, james woodyatt <<= a href=3D"mailto:jhw@google.com" target=3D"_blank">jhw@google.com> wrote:
On Jun 2, 2017, at 10:14, Manfredi, Albert E <albert.e.manfredi@boeing.co= m> wrote:
On Jun = 2, 2017, at 09:08, Lorenzo Colitti <lorenzo@google.com> wrote:

Example: I don't want us to have to deal with NAT = any more, ever.

I've seen this comment made before,= and yet the /64 hard boundary practically guarantees that NAT will get use= d with IPv6. It's exactly the same solution, for exactly the same probl= em. Inability to expand at the edges.

I have reluctantly come to believe that service providers MUST= have the ability to force their economy class subscribers into artificiall= y small allocations, so they can charge premium prices for larger ones draw= n from the same functionally limitless supply at equivalent cost. We have t= o expect that only business and luxury class subscribers will have sufficie= ntly large allocations that IPv6/NAT will add more costs than it saves them= .

I once believed IPv4/NAT was about preserving sc= arce number resources. I now think that was wrong. It was always about opti= mizing rents across differing classes of subscribers even when the extracte= d resource on which the rents are derived is practically unlimited. In this= one respect, IPv6 is no different than IPv4. As a purely technical matter,= the rent MUST flow.

Accordingly, I say we should = stop arguing that IPv6 does not require NAT. For certain classes of subscri= ber, NAT is essential for making IPv6 service available at an affordable pr= ice. Indeed, any internet layer that uses fixed size global scope addresses= requires NAT at the provider/subscriber boundary.


James, have you seen this situation in I= Pv6?=C2=A0 I personally have not seen scenarios where there is class of ser= vice that requires IPv6 NAT or less than a /64 is given.

I have also not seen in the IPv6 marketplace a scenario where cost i= s tied to address space size.

Please share where t= his scenario is real.

Regards,
CB=C2=A0<= /div>

--james woodyatt <jhw@google.com>




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


--f403045f35c2bae7e80551000479-- From nobody Fri Jun 2 14:19:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30881124217 for ; Fri, 2 Jun 2017 14:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgBSCykt8cnu for ; Fri, 2 Jun 2017 14:19:44 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 917371201FA for ; Fri, 2 Jun 2017 14:19:44 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id C6DDEC74 for ; Fri, 2 Jun 2017 21:19:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtciL4Jty43F for ; Fri, 2 Jun 2017 16:19:43 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 67ECCBC1 for ; Fri, 2 Jun 2017 16:19:43 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id 23so18873591uaj.5 for ; Fri, 02 Jun 2017 14:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gp4r9VuQzfM3uz4F6IMdsjppDp8xNHPqwXGL4DukYRU=; b=jdXy8hbF18K1/JDSmXz4ixFuDOpMFH5ecY4P8E29ItBqAdJnjudXsxJUrZKoHyXX+g TwWqZhWgZ49xzxsN4WF2TiYUPFi9qmAJ5zLOgVmUred/8uDNje90OWkXL3ZA1dGFlzXH 59n9gqMBs9BvJHHrcfZarokbYxE1U+1GjJBHuWte4l9nkJ+8wyLOxwuN/yOG7OUNDGe+ FA4Q2npLwxXVQSez2aRA8P3C1buOiEvoca8itLAQztMIDegxuJE5aZoLWIQRdHaxqYY2 UI4f7W3LBmezGOvoNXcNjGpEiWNzIEA3c4Qs3dSLP1fAjZPswtquqopUNPXe1zDZWMxh XAHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gp4r9VuQzfM3uz4F6IMdsjppDp8xNHPqwXGL4DukYRU=; b=i+DLKeLtLouLGIeyuZfG+ODdTUHPtQ9DsMoiZCUKbf9QvAvgFq94LeZj4saMF3KFD0 QWlEs9QdbnD9Y5KSDdi2NfbZCBv3ZUHVmqeZRNh7tRorJEWRiJdwBIL4vQx0b2wfYw7O 4peMYjgLA8JCY/CZBFd4TkUuuRjKYAcKQStcGs2KH3ZRuuRkzdCTiZC+QD5kmvLuSfyr aN/OszFUPPUq5RHtm0qcmroOtBMMPH7jH5tKsgdgtDFNDusY3qid6fMrwn6H743UmrUh GGkeaPG0/PsCixXj3BiiwKZpYMHpkfY6jj7HQQmBiKxK/IgtZBfMcnQy4KF+B8mxG8cz KJFA== X-Gm-Message-State: AODbwcBLOT0gTwFago3XpFgZuq+tgIsGtonPciIBSNxZvGY4Yy7L+XQd lxYRBkkITmM3enKXpK5d83lzvJkuwhH3TfsV5/4Ue4aAQvJSoxVq4TTeUVSbGSzraJUS3goNF+y gVdhsrAkFtruXcHI= X-Received: by 10.176.23.201 with SMTP id p9mr4090108uaf.24.1496438382424; Fri, 02 Jun 2017 14:19:42 -0700 (PDT) X-Received: by 10.176.23.201 with SMTP id p9mr4090097uaf.24.1496438382147; Fri, 02 Jun 2017 14:19:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.137 with HTTP; Fri, 2 Jun 2017 14:19:41 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> From: David Farmer Date: Fri, 2 Jun 2017 16:19:41 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Peter Hessler , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="089e08200124326664055100b6b7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 21:19:47 -0000 --089e08200124326664055100b6b7 Content-Type: text/plain; charset="UTF-8" Can everyone tone it down a little bit PLEASE! The actual distance between the positions here is rather small, I believe we are basically standing nose to nose on different sides of the same line, which is /64. I think we all agree that /64 is the normal subnet size in most situations, in other words the default, especially for subnets with general purpose hosts, and most notably for subnet with hosts using SLACC. I would like to see the Draft reinforce that /64 is the norm expected in many situations, including references to RFC 7421 and RFC 7934. Also, I would like to see this stated normatively in the draft using RFC 2119 "RECOMMENDED", that is "/64 is the RECOMMENDED subnet size." Furthermore, no one disputes that there are exceptions to /64. There are at least two formal exceptions already, RFC 6164 and addresses that begin with binary 000. Where we seem to diverge is the number and nature of the exceptions that should be allowed to /64. One side seems to want only formally recognized and approved exceptions, where as the draft is arguing that there is much operational deployment of any number of subnet sizes like 127, 126, 124, 120, ... beyond the current formally approved exceptions. The actual difference between MUST with stated exceptions and RECOMMENDED is kind of nuanced anyway. So here is an anecdote of the operational issues here; In the last month I established a Direct Internet Access (DIA) connection with the large Cable Co. in our region to get their IP based video service for our on-campus residential students and for various offices around the University, with the added benefit of providing more direct access to campus resources for commuter students, staff, and facility when at home. The Cable Co provided the addressing for the link to do BGP over; They provided a /30 for IPv4, our internal practice these days is to use a /31, but there is really nothing wrong with a /30. Since they provided a /30 for IPv4 they quite logically provided a /126 for IPv6, and use the same last digits between the IPv4 and IPv6 addresses, again our practice is to use a /127. However, in totality this seems quite operationally reasonable and logical, but it violates the IPv6 specifications, should I have told them we can't do that? No, in this case I believe its the specification that is wrong, not the Cable Co's operational practice. So, should we rewrite RFC6164 to also formally allow the use of a /126 as well? Or, should we simply recognize that /64 is a RECOMMENDATION (and /127 for that matter is too), and let operators use other prefix lengths that seem appropriate to the situation? Thanks. On Fri, Jun 2, 2017 at 9:33 AM, Lorenzo Colitti wrote: > Do not support. A few reasons: > > - The /64 boundary is beneficial for many reasons. See RFC 7421 and > RFC 7934. > - The document lists no compelling use cases of what you can do with > less than 2^64 addresses per link than you can't do with a 2^64 addresses > per link. > - The only technical motivation in this draft seems to be "classful > addressing was a bad idea in IPv4". That's not a valid argument in IPv6 > because the address space is completely different. A /64 is *four billion > times* bigger than the IPv4 internet. That's 10,000 times more than the > difference between a grain of sand and the whole planet we live on. Such a > huge scaling difference pretty much invalidates any argument that solutions > that worked well in IPv4 will work well in IPv6. > - Routing on any prefix length is already required by the standards - > see BCP 198. > > Please stop trying to make IPv6 be the same as IPv4. That will take away > our ability to make the Internet better once IPv4 is gone. > > On Fri, Jun 2, 2017 at 11:12 PM, Peter Hessler > wrote: > >> Support >> >> On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote: >> :Hi Working Group, >> : >> :Please review the below. >> : >> :Kind regards, >> : >> :Job >> : >> :----- Forwarded message from internet-drafts@ietf.org ----- >> : >> :Date: Mon, 22 May 2017 04:25:28 -0700 >> :From: internet-drafts@ietf.org >> :To: Job Snijders , Randy Bush , Christopher >> Morrow , >> : Fernando Gont , Nick Hilliard < >> nick@inex.ie>, Geoff Huston >> : , Brian Carpenter , >> Chris Morrow >> : >> :Subject: New Version Notification for draft-bourbaki-6man-classless- >> ipv6-00.txt >> : >> : >> :A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt >> :has been successfully submitted by Randy Bush and posted to the >> :IETF repository. >> : >> :Name: draft-bourbaki-6man-classless-ipv6 >> :Revision: 00 >> :Title: IPv6 is Classless >> :Document date: 2017-05-22 >> :Group: Individual Submission >> :Pages: 7 >> :URL: https://www.ietf.org/internet- >> drafts/draft-bourbaki-6man-classless-ipv6-00.txt >> :Status: https://datatracker.ietf.org/ >> doc/draft-bourbaki-6man-classless-ipv6/ >> :Htmlized: https://tools.ietf.org/html/d >> raft-bourbaki-6man-classless-ipv6-00 >> :Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-bourbaki-6man-classless-ipv6-00 >> : >> : >> :Abstract: >> : Over the history of IPv6, various classful address models have been >> : proposed, none of which has withstood the test of time. The last >> : remnant of IPv6 classful addressing is a rigid network interface >> : identifier boundary at /64. This document removes the fixed position >> : of that boundary for interface addressing. >> : >> : >> : >> : >> :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 >> : >> : >> :----- End forwarded message ----- >> : >> :-------------------------------------------------------------------- >> :IETF IPv6 working group mailing list >> :ipv6@ietf.org >> :Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> :-------------------------------------------------------------------- >> >> -- >> If Reagan is the answer, it must have been a VERY silly question. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --089e08200124326664055100b6b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can everyone tone it down a little bit PLEASE!

The actual distance between the positions here is rather small, I b= elieve we are basically standing nose to nose on different sides of the sam= e line, which is /64.

I think we all agree that /6= 4 is the normal subnet size in most situations, in other words the default,= especially for subnets with general purpose hosts, and most notably for su= bnet with hosts using SLACC. I would like to see the Draft reinforce that /= 64 is the norm expected in many situations, including references to RFC 742= 1 and RFC 7934. Also, I would like to see this stated normatively in the dr= aft using RFC 2119 "RECOMMENDED", that is "/64 is the RECOMM= ENDED subnet size." =C2=A0=C2=A0

Furthermore,= no one disputes that there are exceptions to /64. There are at least two f= ormal exceptions already, RFC 6164 and addresses that begin with binary 000= . Where we seem to diverge is the number and nature of the exceptions that = should be allowed to /64. One side seems to want only formally recognized a= nd approved exceptions, where as the draft is arguing that there is much op= erational deployment of any number of subnet sizes like 127, 126, 124, 120,= ... beyond the current formally approved exceptions.
=C2=A0=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
The actual difference between MUST with stated exceptions = and RECOMMENDED is kind of nuanced anyway.

So here= is an anecdote of the operational issues here; =C2=A0In the last month I e= stablished a Direct Internet Access (DIA) connection with the large Cable C= o. in our region to get their IP based video service for our on-campus resi= dential students and for various offices around the University, with the ad= ded benefit of providing more direct access to campus resources for commute= r students, staff, and facility when at home.=C2=A0 The Cable Co provided t= he addressing for the link to do BGP over; They provided a /30 for IPv4, ou= r internal practice these days is to use a /31, but there is really nothing= wrong with a /30. Since they provided a /30 for IPv4 they quite logically = provided a /126 for IPv6, and use the same last digits between the IPv4 and= IPv6 addresses, again our practice is to use a /127. However, in totality = this seems quite operationally reasonable and logical, but it violates the = IPv6 specifications, should I have told them we can't do that?=C2=A0 No= , in this case I believe its the specification that is wrong, not the Cable= Co's operational practice.=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=
So, should we rewrite RFC6164 to also form= ally allow the use of a /126 as well?=C2=A0 Or, should we simply recognize = that /64 is a RECOMMENDATION (and /127 for that matter is too), and let ope= rators use other prefix lengths that seem appropriate to the situation?

Thanks.
=C2=A0
On Fri,= Jun 2, 2017 at 9:33 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
Do not support. A few reasons:
  • The /64 boundary is benefic= ial for many reasons. See RFC 7421 and RFC 7934.
  • The document l= ists no compelling use cases of what you can do with less than 2^64 address= es per link than you can't do with a 2^64 addresses per link.
  • T= he only technical motivation in this draft seems to be "classful addre= ssing was a bad idea in IPv4". That's not a valid argument in IPv6= because the address space is completely different. A /64 is *four billion = times* bigger than the IPv4 internet. That's 10,000 times more than the= difference between a grain of sand and the whole planet we live on. Such a= huge scaling difference pretty much invalidates any argument that solution= s that worked well in IPv4 will work well in IPv6.
  • Routing on any p= refix length is already required by the standards - see BCP 198.
    • Please stop trying to make IPv6 be the same as IPv4. That will take= away our ability to make the Internet better once IPv4 is gone.

On Fri, Ju= n 2, 2017 at 11:12 PM, Peter Hessler <phessler@theapt.org>= wrote:
Support

On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote:
:Hi Working Group,
:
:Please review the below.
:
:Kind regards,
:
:Job
:
:----- Forwarded message from internet-drafts@ietf.org -----
:
:Date: Mon, 22 May 2017 04:25:28 -0700
:From: intern= et-drafts@ietf.org
:To: Job Snijders <job@= ntt.net>, Randy Bush <randy@psg.com>, Christopher Morrow <morrowc@google.com>,
:=C2=A0 =C2=A0 =C2=A0 =C2=A0Fernando Gont <fgont@si6networks.com>, Nick Hilliard = <nick@inex.ie>,= Geoff Huston
:=C2=A0 =C2=A0 =C2=A0 =C2=A0<gih@apnic.net>, Brian Carpenter <brian.e.carpenter@gmail.com>= ;, Chris Morrow
:=C2=A0 =C2=A0 =C2=A0 =C2=A0<morrowc@google.com>
:Subject: New Version Notification for draft-bourbaki-6man-classless-i= pv6-00.txt
:
:
:A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt
:has been successfully submitted by Randy Bush and posted to the
:IETF repository.
:
:Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bourbaki-6man-classless-ipv6
:Revision:=C2=A0 =C2=A0 =C2=A0 00
:Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 is Classless
:Document date: 2017-05-22
:Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
:Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07
:URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bo= urbaki-6man-classless-ipv6-00.txt
:Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bourbaki-6man-class= less-ipv6/
:Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-= 00
:Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-= classless-ipv6-00
:
:
:Abstract:
:=C2=A0 =C2=A0Over the history of IPv6, various classful address models hav= e been
:=C2=A0 =C2=A0proposed, none of which has withstood the test of time.=C2=A0= The last
:=C2=A0 =C2=A0remnant of IPv6 classful addressing is a rigid network interf= ace
:=C2=A0 =C2=A0identifier boundary at /64.=C2=A0 This document removes the f= ixed position
:=C2=A0 =C2=A0of that boundary for interface addressing.
:
:
:
:
:Please note that it may take a couple of minutes from the time of submissi= on
:until the htmlized version and diff are available at tools.ietf.org.
:
:The IETF Secretariat
:
:
:----- End forwarded message -----
:
:----------------------------------------------------------------= ----
:IETF IPv6 working group mailing list
:ipv6@ietf.org
:Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
:----------------------------------------------------------------= ----

= --
If Reagan is the answer, it must have been a VERY silly question.
-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---


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




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecom= munication Services
Office of Information Technology
University of Mi= nnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 P= hone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-81= 2-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--089e08200124326664055100b6b7-- From nobody Fri Jun 2 14:34:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3D612751F for ; Fri, 2 Jun 2017 14:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-LP_fcXxvKn for ; Fri, 2 Jun 2017 14:34:50 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95111126D73 for ; Fri, 2 Jun 2017 14:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52LYnYL047252; Fri, 2 Jun 2017 14:34:49 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52LYfhX047211 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 14:34:41 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 14:34:39 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 14:34:40 -0700 From: "Manfredi, Albert E" To: David Farmer CC: IETF IPv6 Mailing List Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAHFvgP//jAag Date: Fri, 2 Jun 2017 21:34:40 +0000 Message-ID: <16298890ffe643e4b2e35bcfe31c2e84@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 21:34:52 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERh dmlkIEZhcm1lcg0KDQo+IFRoZSBhY3R1YWwgZGlzdGFuY2UgYmV0d2VlbiB0aGUgcG9zaXRpb25z IGhlcmUgaXMgcmF0aGVyIHNtYWxsLCBJDQo+IGJlbGlldmUgd2UgYXJlIGJhc2ljYWxseSBzdGFu ZGluZyBub3NlIHRvIG5vc2Ugb24gZGlmZmVyZW50IHNpZGVzDQo+IG9mIHRoZSBzYW1lIGxpbmUs IHdoaWNoIGlzIC82NC4NCg0KV2VsbCAuLi4uIHNvcnQgb2YuDQoNCj4gSSB0aGluayB3ZSBhbGwg YWdyZWUgdGhhdCAvNjQgaXMgdGhlIG5vcm1hbCBzdWJuZXQgc2l6ZSBpbiBtb3N0DQo+IHNpdHVh dGlvbnMsIGluIG90aGVyIHdvcmRzIHRoZSBkZWZhdWx0LCBlc3BlY2lhbGx5IGZvciBzdWJuZXRz IHdpdGgNCj4gZ2VuZXJhbCBwdXJwb3NlIGhvc3RzLA0KDQpFeGNlcHQgdGhhdCB0aGUgY29uc2Vx dWVuY2VzIG9mIGFsbCB0aGF0IGUtbWFpbCAobXkgcmVzcG9uc2UgdG8gTG9yZW56bywgZWNob2Vk IGJ5IEZyZWQpLCB3b3VsZCBiZSB0aGF0IGV2ZW4gYSBTTEFBQywgd2l0aG91dCBhIGhhcmQgLzY0 IGJvdW5kYXJ5LCB3b3VsZCBiZSB2ZXJ5IG5pY2UuIEEgc3ViamVjdCBmb3IgYW5vdGhlciBkYXku DQoNCkhvbWUgZ2F0ZXdheXMgYXNzaWduZWQgYSAvNjQsIHNtYXJ0cGhvbmUtcHJvdmlkZWQgbW9i aWxlIGhvdHNwb3RzLCBJJ20gbm90IHN1cmUgc3VjaCBleGFtcGxlcyBjYW4gYmUgZm9yZXZlciBy ZWxlZ2F0ZWQgdG8gdGhlIGNhdGVnb3J5IG9mIGNvcm5lciBjYXNlcz8NCg0KQmVydA0KDQo= From nobody Fri Jun 2 15:10:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9270E12940B for ; Fri, 2 Jun 2017 15:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xOUhK3_w8Yf for ; Fri, 2 Jun 2017 15:10:38 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 E5B4D1243FE for ; Fri, 2 Jun 2017 15:10:37 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 7CC56A08 for ; Fri, 2 Jun 2017 22:10:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhoCFUDvorQ1 for ; Fri, 2 Jun 2017 17:10:37 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 4A55FC57 for ; Fri, 2 Jun 2017 17:10:37 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id q15so10444499uaa.10 for ; Fri, 02 Jun 2017 15:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kAnn8vgsGMAKahndu3NIorwq0cZTkPIxEJDnpiulR8k=; b=hFi+tTytYBojBLoN2K20JVnPBNEdDqLVwTN7eLXYK7VvU/uQySWIluklGaVdPMCQ4N j0z5bAzA8hg5UGo2hjkP4A+GDOm0Gi7ZQ3Mm+11/Sl1+W/UytFpCHw2LJCU4tw1olDi1 7APIs+cFYoMOypFG3h+P9HKDoQcllT1Rw1yGTaAc/M8p1H6iJA00/zunw20VGBBMLEdn U2zFQXd9YqVAdlI27ymQD36mqp3OXWN0hXWP6fWcCRMIAbR/Gup5sZvKKtFsf4yJa508 mMnHouPuikJy+1pOl4ekLfaAY1SmuFSb90BJJozGUmZcPiubEvd24GVI2Njb5Cx3LRu9 v7lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kAnn8vgsGMAKahndu3NIorwq0cZTkPIxEJDnpiulR8k=; b=BPpBdVWJlSCjQavWamtSyMEsKRRgDzP6nBh1UZr/pCK12Rhalghkm/ZI/58n6a77rT hZGzxhbIRkWNd1zxi49R5Oml3Z2qoULP0B/EkNTupk+XdK/YEcLntwpnmEC8/S84ZHLz Wb8YkcwyLdhOzDjM3MuzzGJrwtetCVs+ymzeoWKSjxMAP9C/Dy4dABW6OMMSz7urqAhf 2z25xa1EgMYHh4zOVci/G64993VNLYhht0SmUM8ipxOMXeM+5wLS9DnuFiQXD+V69sc9 hbl4qSeeIALnUvHQtdXiGZ8KATtgdi3DgWcH/hcJrHOyU1errcIonK2us+RpFHxHroDA 27tQ== X-Gm-Message-State: AODbwcCeJ53xZdONP6AnHXZCP1JlPynqXCKICueUpbd+vEYEBcuc78Kp nZ2agARC/pl8ECOiO+aqmXt2vGDQrQ4HT0egQcDGC66exGTxNgFMuYT71p3Vd77ZbPl0KiI1v7Y A12mn+PI/SFEwc6s= X-Received: by 10.31.99.67 with SMTP id x64mr4568447vkb.24.1496441436524; Fri, 02 Jun 2017 15:10:36 -0700 (PDT) X-Received: by 10.31.99.67 with SMTP id x64mr4568434vkb.24.1496441436315; Fri, 02 Jun 2017 15:10:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.137 with HTTP; Fri, 2 Jun 2017 15:10:35 -0700 (PDT) In-Reply-To: <16298890ffe643e4b2e35bcfe31c2e84@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <16298890ffe643e4b2e35bcfe31c2e84@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Fri, 2 Jun 2017 17:10:35 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c07b1183d3b570551016c51" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 22:10:40 -0000 --94eb2c07b1183d3b570551016c51 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 4:34 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer > > > The actual distance between the positions here is rather small, I > > believe we are basically standing nose to nose on different sides > > of the same line, which is /64. > > Well .... sort of. > > > I think we all agree that /64 is the normal subnet size in most > > situations, in other words the default, especially for subnets with > > general purpose hosts, > > Except that the consequences of all that e-mail (my response to Lorenzo, > echoed by Fred), would be that even a SLAAC, without a hard /64 boundary, > would be very nice. A subject for another day. > > Home gateways assigned a /64, smartphone-provided mobile hotspots, I'm not > sure such examples can be forever relegated to the category of corner cases? > Personally, I'd support doing that too. But, that is a real change to a bunch of code, and while I seed the need for doing it, it needs to be done very carefully. More importantly, I wouldn't want doing that to get in the way of the more philosophical change(correction) proposed in this draft. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c07b1183d3b570551016c51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 4:34 PM, Manfredi, Albert E &l= t;albert.= e.manfredi@boeing.com> wrote:
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer

> The actual distance between the positions here is rather small, I
> believe we are basically standing nose to nose on different sides
> of the same line, which is /64.

Well .... sort of.

> I think we all agree that /64 is the normal subnet size in most
> situations, in other words the default, especially for subnets with > general purpose hosts,

Except that the consequences of all that e-mail (my response to Lorenzo, ec= hoed by Fred), would be that even a SLAAC, without a hard /64 boundary, wou= ld be very nice. A subject for another day.

Home gateways assigned a /64, smartphone-provided mobile hotspots, I'm = not sure such examples can be forever relegated to the category of corner c= ases?

Personally, I'd support doing= that too.=C2=A0 But, that is a real change to a bunch of code, and while I= seed the need for doing it, it needs to be done very carefully.=C2=A0 More= importantly, I wouldn't want doing that to get in the way of the more = philosophical change(correction) proposed in this draft.=C2=A0
= =C2=A0=C2=A0
Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c07b1183d3b570551016c51-- From nobody Fri Jun 2 16:39:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC31294C4 for ; Fri, 2 Jun 2017 16:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlgKjx20y76W for ; Fri, 2 Jun 2017 16:39:17 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 7352D129442 for ; Fri, 2 Jun 2017 16:39:17 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id u10so52888534uaf.1 for ; Fri, 02 Jun 2017 16:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JmJyzGtrsPTgZrD0qIzwQAuAEvzRLaWxzko2e9jtITM=; b=TGaw3oThtUc9V08pIZX7fiK1wFV2P1tdXcSm1FdRW/c5vq0ua6Q5FllilYt65/mUmV SATRlxy6mM45V9ANIG03eEUSAl2c+SGoRrTXhoiwpidUTIAjpz/cbOslJvGm8ub9FCsf +WiulajZmrXViyrrTUVfV7+rzVVCZHcv2SPrSQHWaG6hhWy/zDtdqbHxAw2TJSXOFxvW V/SKV/3JcPeKGYMG7sbAudef0n2FGdsrx8s+1eXJWuLB3KYK6Rb26t1IsYug3TA3Pmjq P5ryBfByI7jk1Q+/G68y9pfdoUQULAdMS6NDV4Jq5OOCBPFYxCVxOZm6X+Pdob2OMgPn ELxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JmJyzGtrsPTgZrD0qIzwQAuAEvzRLaWxzko2e9jtITM=; b=U8a3aZSlOqjSpUUCFuKEkkuNRJDAW2JKdaTXVbhyF+YPjD646NWLJijhe7owz2jekX 790YbOkW7h09Ilr4ApnXeGxEvKqw38M5ii39uQKS70iWHWkI/jCLtSZTgvjV+hIQy84l E1ZfRgw0YvzKiB3DL6PRy50jFMAJJOnCnn0Kq6nYTkplfeC3IVu4XWtKTOT9HlPTJZaB j/HdJdQ3GnPDFM2TRvOQlXM9jlAneJ5gQezQpbhNyQmUARUEG5kEarVlMvUbM2zjHaEJ lkQCkzL4DlgiQOk7ozhOz4Cr54w6kHbtfMODsbRbMsrJ1MLF05EOBRbS07KtMvriyACb pO/Q== X-Gm-Message-State: AODbwcDzCVgEfcIfTNIS3qgDSOfwOWzHmoPs+zH7d+sdRLNeIKE8HQNP QRWiRMY7tb6B7EQfHuCpiKGuH6Ty9A== X-Received: by 10.176.27.84 with SMTP id n20mr5368314uai.125.1496446756583; Fri, 02 Jun 2017 16:39:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.201 with HTTP; Fri, 2 Jun 2017 16:39:15 -0700 (PDT) Received: by 10.176.64.201 with HTTP; Fri, 2 Jun 2017 16:39:15 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> From: Mark Smith Date: Sat, 3 Jun 2017 09:39:15 +1000 Message-ID: Subject: RE: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: Lorenzo Colitti , 6man WG Content-Type: multipart/alternative; boundary="f403045e5b8459fd4a055102a92f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 23:39:19 -0000 --f403045e5b8459fd4a055102a92f Content-Type: text/plain; charset="UTF-8" On 3 Jun. 2017 03:15, "Manfredi, Albert E" wrote: >> Would be a shame to throw away lessons learned from IPv4. > > I think that's exactly the fallacy here. It is not useful to apply something > you learned about IPv4 addressing to IPv6, because the number of addresses > is incomparably bigger. Rule of thumb in software engineering is that a > solution usually scales by one or two orders of magnitude. Here we have > something like 34 orders of magnitude. Even a single /64 is 9 orders of > magnitude larger than the IPv4 Internet. Yeah, this hype needs to end. A /64 hard boundary merely doubles the width of IPv4 addresses, and egregiously wastes the majority of the remaining 64 bits. And with innovations such as IoT, suddenly all that vast extra space can be swallowed up. Back in 1980, IPv4 address space seemed pretty huge too. The deployment assumptions made are key, when people make assertions about the vastness of the address space. > Example: I don't want us to have to deal with NAT any more, ever. I've seen this comment made before, and yet the /64 hard boundary practically guarantees that NAT will get used with IPv6. How does that guarantee it? Classless IPv4 didn't prevent NAT being deployed. In my experience, cost of public address space, the size of the private address space and it being free, the perception that NAT didn't cause any issues and the perceived level of security isolation private addressing provided were the reasons NAT continued to be deployed after classless IPv4 commonly became available. Regards, Mark. It's exactly the same solution, for exactly the same problem. Inability to expand at the edges. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f403045e5b8459fd4a055102a92f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 3 Jun. 2017 03:15, "Manfredi, Albert E" <albert.e.manfredi@boeing.com&g= t; wrote:
>> Would be a shame to throw away lessons learned from IPv= 4.
>
> I think that's exactly the fallacy here. It is not useful to apply= something
> you learned about IPv4 addressing to IPv6, because the number of addre= sses
> is incomparably bigger. Rule of thumb in software engineering is that = a
> solution usually scales by one or two orders of magnitude. Here we hav= e
> something like 34 orders of magnitude. Even a single /64 is 9 orders o= f
> magnitude larger than the IPv4 Internet.

Yeah, this hype needs to end. A /64 hard boundary merely doubles the = width of IPv4 addresses, and egregiously wastes the majority of the remaini= ng 64 bits.=C2=A0 And with innovations such as IoT, suddenly all that vast = extra space can be swallowed up. Back in 1980, IPv4 address space seemed pr= etty huge too. The deployment assumptions made are key, when people make as= sertions about the vastness of the address space.

> Example: I don't want us to have to deal with NAT any more, ever.<= br>
I've seen this comment made before, and yet the /64 hard boundary= practically guarantees that NAT will get used with IPv6.

How does that gu= arantee it? Classless IPv4 didn't prevent NAT being deployed.

In my experience, cost of public = address space, the size of the private address space and it being free, the= perception that NAT didn't cause any issues and the perceived level of= security isolation private addressing provided were the reasons NAT contin= ued to be deployed after classless IPv4 commonly became available.

Regards,
= Mark.


It's
exactly the same solution, f= or exactly the same problem. Inability to expand at the edges.

Bert

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

--f403045e5b8459fd4a055102a92f-- From nobody Fri Jun 2 17:37:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBB712EAF4 for ; Fri, 2 Jun 2017 17:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.491 X-Spam-Level: X-Spam-Status: No, score=-5.491 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9CRm4vw3Flu for ; Fri, 2 Jun 2017 17:37:16 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 88F3212EAEA for ; Fri, 2 Jun 2017 17:37:16 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 69C8624AE0D; Sat, 3 Jun 2017 00:35:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A979416003D; Sat, 3 Jun 2017 00:35:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8BF07160086; Sat, 3 Jun 2017 00:35:56 +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 o8lL6VmrCCfY; Sat, 3 Jun 2017 00:35:56 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2634516003D; Sat, 3 Jun 2017 00:35:56 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7A0327ADD848; Sat, 3 Jun 2017 10:35:52 +1000 (AEST) To: Brian Haberman Cc: ipv6@ietf.org From: Mark Andrews References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 In-reply-to: Your message of "Fri, 02 Jun 2017 16:13:31 -0400." Date: Sat, 03 Jun 2017 10:35:52 +1000 Message-Id: <20170603003552.7A0327ADD848@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 00:37:18 -0000 In message , Brian Hab erman writes: > Hi Bert, > > On 6/2/17 4:03 PM, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Templin, Fred L > > > >> My meaning was for the ISP to give the cell phone or home gateway > >> a /64, then let the cell phone/ home gateway subnet the /64 to > >> the IoT devices within the subnetwork it provides as it sees fit. > > > > Sorry, I have to make an important correction: > > > > Presumably, using some sort of internal address format, also /64, such > as privacy addresses? Yes, true, but ... > > I interpreted Fred's proposal as: > > 1. ISP gives the phone a /64 The ISP could give each phone a /48. There is NOTHING stopping the ISP giving a /48 today. IPv6 is sized to allow this. When you stop trying to hand out the minimum and start handing out reasonable quantities of subnets the so called problems go away. > 2. The phone delegates longer prefixes to the devices behind it > from the /64 The phone then hands out /64's to devices behind it on demand. > 3. The ISP router has a single /64 route that points to the phone The ISP's router has a single /48 that points to the phone. > Regards, > Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 2 18:42:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA787129AF4 for ; Fri, 2 Jun 2017 18:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeiMw8Ea0GXE for ; Fri, 2 Jun 2017 18:42:08 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FF31243F6 for ; Fri, 2 Jun 2017 18:42:08 -0700 (PDT) Received: from [192.168.0.54] (unknown [196.207.188.130]) (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 36CB482768; Sat, 3 Jun 2017 03:42:24 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Mark Andrews , Brian Haberman Cc: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> From: Fernando Gont Message-ID: <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> Date: Sat, 3 Jun 2017 04:40:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170603003552.7A0327ADD848@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 01:42:11 -0000 Hi, Mark, On 06/03/2017 03:35 AM, Mark Andrews wrote: > > In message , Brian Hab > erman writes: >> Hi Bert, >> >> On 6/2/17 4:03 PM, Manfredi, Albert E wrote: >>> -----Original Message----- >>> From: Templin, Fred L >>> >>>> My meaning was for the ISP to give the cell phone or home gateway >>>> a /64, then let the cell phone/ home gateway subnet the /64 to >>>> the IoT devices within the subnetwork it provides as it sees fit. >>> >>> Sorry, I have to make an important correction: >>> >>> Presumably, using some sort of internal address format, also /64, such >> as privacy addresses? Yes, true, but ... >> >> I interpreted Fred's proposal as: >> >> 1. ISP gives the phone a /64 > > The ISP could give each phone a /48. There is NOTHING stopping the > ISP giving a /48 today. IPv6 is sized to allow this. When you > stop trying to hand out the minimum and start handing out reasonable > quantities of subnets the so called problems go away. > >> 2. The phone delegates longer prefixes to the devices behind it >> from the /64 > > The phone then hands out /64's to devices behind it on demand. And such devices, if they feel like sharing, hand a...? >> 3. The ISP router has a single /64 route that points to the phone > > The ISP's router has a single /48 that points to the phone. At which point we probably should start thinking about ipng-bis :-). That's 16-bits away from IPv4, which has (or used to) /32 pointing to hosts. 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 Jun 2 20:03:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AA612EBA2 for ; Fri, 2 Jun 2017 20:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLVR5zS7A6ok for ; Fri, 2 Jun 2017 20:03:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 6D67F12EB7F for ; Fri, 2 Jun 2017 20:03:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id D498624AE0D; Sat, 3 Jun 2017 03:03:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DF38716003D; Sat, 3 Jun 2017 03:03:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 73D1E160086; Sat, 3 Jun 2017 03:03:17 +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 L73azsidpkqd; Sat, 3 Jun 2017 03:03:17 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1088916003D; Sat, 3 Jun 2017 03:03:17 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7BC6B7ADDD68; Sat, 3 Jun 2017 13:03:14 +1000 (AEST) To: Fernando Gont Cc: Brian Haberman , ipv6@ietf.org From: Mark Andrews References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 In-reply-to: Your message of "Sat, 03 Jun 2017 04:40:27 +0300." <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> Date: Sat, 03 Jun 2017 13:03:14 +1000 Message-Id: <20170603030314.7BC6B7ADDD68@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 03:03:25 -0000 In message <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com>, Fernando Gon t writes: > Hi, Mark, > > On 06/03/2017 03:35 AM, Mark Andrews wrote: > > > > In message , Brian > Hab > > erman writes: > >> Hi Bert, > >> > >> On 6/2/17 4:03 PM, Manfredi, Albert E wrote: > >>> -----Original Message----- > >>> From: Templin, Fred L > >>> > >>>> My meaning was for the ISP to give the cell phone or home gateway > >>>> a /64, then let the cell phone/ home gateway subnet the /64 to > >>>> the IoT devices within the subnetwork it provides as it sees fit. > >>> > >>> Sorry, I have to make an important correction: > >>> > >>> Presumably, using some sort of internal address format, also /64, such > >> as privacy addresses? Yes, true, but ... > >> > >> I interpreted Fred's proposal as: > >> > >> 1. ISP gives the phone a /64 > > > > The ISP could give each phone a /48. There is NOTHING stopping the > > ISP giving a /48 today. IPv6 is sized to allow this. When you > > stop trying to hand out the minimum and start handing out reasonable > > quantities of subnets the so called problems go away. > > > >> 2. The phone delegates longer prefixes to the devices behind it > >> from the /64 > > > > The phone then hands out /64's to devices behind it on demand. > > And such devices, if they feel like sharing, hand a...? /64's on demand using PD. This isn't rocket science. ISP's handout /48's. Internally you handout /64's on demand and route each of them individually. DHCP-PD is designed to allow you to do this. A /48 allow you to hand out 65000 /64's. > >> 3. The ISP router has a single /64 route that points to the phone > > > > The ISP's router has a single /48 that points to the phone. > > At which point we probably should start thinking about ipng-bis :-). > That's 16-bits away from IPv4, which has (or used to) /32 pointing to hosts. > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 2 20:23:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA30129C0E; Fri, 2 Jun 2017 20:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uZxwzgIIz9f; Fri, 2 Jun 2017 20:23:39 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 20D371242F5; Fri, 2 Jun 2017 20:23:39 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id y4so54064020uay.2; Fri, 02 Jun 2017 20:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=YOPQmLrF6cemCbFwfoFuM04uMSPfBMtHUmlEkOjQyJs=; b=Kgqxe3WWVVuucyJzgYp/wnfTZCfuElXqiSmcvtCkALktSYMNVS7wtgd0eB1EVoCQ/O 5ca9bl9Fgx5+qqcXREW+eGU25SEv/n+bAsf3qgW6lB05HMi6KuaVL2Ot+RvSMsXYO71L PbIubkmYVpRknBeykK79s2Q5wBrwQ73FNJiMH/SwFp1DM1RYpM/x51X/pSkE7VvQ7+XG vjPOSS/K/EYrLN5vbuZftVX2ndZZXPcp93qVEcSPojIdGXxxQcRwDHb3lX1T2x0+shUo osxJ0E2BnuRxFsYkwLAAQU1xc8DIvNx/5yzXrh3i81GrQltyFAOcuakwBdgd+DnWgI6w vMzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=YOPQmLrF6cemCbFwfoFuM04uMSPfBMtHUmlEkOjQyJs=; b=WAkMbmknHw1u72Ql7gdlPR6pWZXPyLDh+afADc2l3OqFQ04nLt6uRy4d5SDJjp8AaH dMUdjWbx5IzPCoty8v0OO/6fWmDu69vAjD7CHtLrAnfi1NXEgvug2K00EK4spfyHU4wO 9Ir8Myx0MF9LUSlJoMFMEFxEPokXHF6X9YhwzEkwQTXhHqJnbiKVGkHN5LzAeTwKaXQw S7vLMfzlZF6/mbPAxbQIac/Nde5RHAgGYAVcEneGVCfWO8YJ9dCeHYQ94Bm3GucOAzma d4sen2sOlZhwfhj7nqrRv3rfotD5rtINfzGVVyU9sJ6YDbDhAWc6A0IVAYwdPur73mcN XbvA== X-Gm-Message-State: AODbwcAmbV6sRUdjQIijW6IObQjztYOgLFgR02vew/ulcrgH59pr78N/ as757M0tgJh0xBfrnTC8QbDXC7MFTg== X-Received: by 10.176.27.84 with SMTP id n20mr5722502uai.125.1496460218102; Fri, 02 Jun 2017 20:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.201 with HTTP; Fri, 2 Jun 2017 20:23:07 -0700 (PDT) From: Mark Smith Date: Sat, 3 Jun 2017 13:23:07 +1000 Message-ID: Subject: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Job Snijders Cc: Lorenzo Colitti , draft-bourbaki-6man-classless-ipv6@ietf.org, IETF IPv6 Mailing List , Peter Hessler Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 03:23:40 -0000 On 3 June 2017 at 00:56, Job Snijders wrote: > Dear Lorenzo, > > >> Please stop trying to make IPv6 be the same as IPv4. That will take >> away our ability to make the Internet better once IPv4 is gone. > > I believe there to be tangible merit in making IPv6 feel and look more > like IPv4. Perhaps this becomes more apparent when one shifts the > innovation focus from layer-3 to higher layers. > > Making IPv6 look more like IPv4 (for instance through broader adoption > of DHCPv6 w/ routing options, and classlessness like in IPv4) will > positively impact IPv6 deployment. > I think that's the fundamental agenda here, although perhaps not realised. It is to devolve IPv6's capabilities and features to the point where IPv6 isn't really much more than IPv4 with a different packet format, and so the IPv4 operational practices people are comfortable with can be directly applied to IPv6 without change. This is because of the common human trait of intolerance of or resistance to change. If this proposal is accepted, then I think /120s will become the defacto subnet size, despite what the draft says about /64s being the recommended default. Here's the clue for why - RFC1918 addressed networks I've seen, where IPv4 address space doesn't need to be conserved (i.e., unlike public IPv4 address space), always use /24s as the defacto subnet size. "Same-same" is easier for us humans than "Same-different." Why do I have a different perspective? My first networking protocol was a more modern one than IPv4, Novell's IPX, derived from Xerox's XNS. Learning and operating IPv4 networks after operating IPX networks was a backwards step. The only major advantage that IPv4 provided over protocols designed in the 1980s and 1990s, such as IPX, Appletalk and CLNS, was that it provided organisations with Internet connectivity. On many other criteria, IPv4 was far inferior - entirely understandable, because it was fundamentally designed in the 1970s, and then adapted over time to cope with being used to build a global Internet work. It was never intended to be used to build a global internetwork connecting billions of devices - https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html IPv6 is actually the first true protocol designed to suit the global "Internet" problem. I have a few horrible stories of seeing IPv4 routers with 4 x /24s or 25 x /26s on the same interface because renumbering and changing subnet masks of hosts into a single large enough subnet was more far expensive than sub-optimal forwarding across the same link. An impossible problem to have when the default subnet address space size far exceeds the practical link-layer node attachment limits (and in some cases impractical link-layer limits because of link layer "excessive" addressing - does an Ethernet really need 48 bit MAC addresses? Who's going to go close to attaching 2^46 nodes to one of them? The ND cache resource exhaustion type of problem also exists at layer 2 with switch tables ...) I don't want to experience or see people experience those sorts of IPv4 "right-sizing subnet" types of problems in IPv6. Regards, Mark. From nobody Fri Jun 2 20:48:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC70126C2F for ; Fri, 2 Jun 2017 20:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIP6rb0JgAoI for ; Fri, 2 Jun 2017 20:48:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194BE1294B9 for ; Fri, 2 Jun 2017 20:48:22 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id 63so26823584ywr.0 for ; Fri, 02 Jun 2017 20:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3IuVpMn0ZKYk7hPaEzPooU77murbmX6MzboyD004ytw=; b=Lu+daMVZ9adhar2uODF5xokWWKZLmyfE+WxFpQlBRZTE67V8/ozQTxQ8Q7lsDlMkwZ Z3Avu8JtlzRZdwsqMOFazDeh6rMzC2aj+/xo8oasg7jS3X6yAJ7HwBuZVV0oMciSAs6f aJXftncs9tdqRLW4qPyCJyyTX0LAyX59VEyqx5o+HT/I4IhJLHVGw/bmnAUHbWnXMLme BgnuOV1al/4X6hjot70NrLVeIwTil9W7pmggqERTmSTqlrPvPMBUziX6bvgAx2MKHE0x RDU6KW6pm6JwJStccbLOfntrMrOXp5Nr2+UAczgCTatU9HUAG96VZ0M8ilETAqgqLDZV nigw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3IuVpMn0ZKYk7hPaEzPooU77murbmX6MzboyD004ytw=; b=kyNrwfl0sJ90uiN0I3eXokgkNEcvhWlDgAk+GqdFo3gH2L6wEuAOgsf47Hw2uF9k+m WY4GbfRoMAg5wArl+xVNLissJCDOOSIae4lgGudgiZeMR7blqy5Jv9tqXDka+CWBqG7F EKkCy7ZXUKxHWH0LM6oLH1lsQtANRvAPrMkKb+tNxsB5i7i+WKm+Qyn98/byY3Wy64py Xit06VVjhbZIqgimQ1AUQPNm8wV8GjAHOoHwLIJikUrEocM2asd7V8es77T0/Ev4VaYX sl2Wrzza5QqedvSIO7vZ3VUggvPn3TROnRZbHvROLNOySmLNxzjvY20WnTUNms8b8ir1 XMtw== X-Gm-Message-State: AODbwcDkC1Qot7//yGhN1ykEjSYdIRttloixJTQ/I9cvm9z6/GoL8xlH pu/3p84CmwDgZ1wWLoqdqurQVmD/EB1j X-Received: by 10.129.173.74 with SMTP id l10mr7849736ywk.114.1496461701035; Fri, 02 Jun 2017 20:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.37.202 with HTTP; Fri, 2 Jun 2017 20:48:20 -0700 (PDT) In-Reply-To: References: From: Chris Morrow Date: Fri, 2 Jun 2017 23:48:20 -0400 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Job Snijders , Lorenzo Colitti , draft-bourbaki-6man-classless-ipv6@ietf.org, IETF IPv6 Mailing List , Peter Hessler Content-Type: multipart/alternative; boundary="f403045ea6f61d4b7e055106240f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 03:48:25 -0000 --f403045ea6f61d4b7e055106240f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable please read david farmer's message.=E2=80=8B really I think he's on point h= ere. --f403045ea6f61d4b7e055106240f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
please read david farmer's message.=E2=80=8B really I = think he's on point here.
--f403045ea6f61d4b7e055106240f-- From nobody Fri Jun 2 21:14:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EA129C31 for ; Fri, 2 Jun 2017 21:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7E_zyCa_J0z for ; Fri, 2 Jun 2017 21:14:29 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 0909512426E for ; Fri, 2 Jun 2017 21:14:28 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id x47so54394175uab.0 for ; Fri, 02 Jun 2017 21:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pa5saqYQl8CpwkOaW7T8I67jAl8ceaKoXEGVz+uPZNI=; b=AYikxPTGLoAlVlsC4hL09wYAZUbtrnjVrxR62D9PkvDOx/+DjgpcsRW+9Z6fZ2qn1a I5RCyxW3/bBBXo5jouGATbm5+ZOkdaNRI/mSnhcmSVLAunE1tCMNO27NKLEIEeBlX/jc HqfW1aR+a/alTbDHz/ygzNR39xpW5RzVCX5md6TvS+X2VChrMVe51aS9kgAkP/rf9D47 YbDTlcgI6+4CucMahBTtsZq2JuqU5CIPGRGuw4V7s7SlYIrX3p4mgy6OBYcbZUzVt3Kq XME7wPNmIbig8htcHvBDaDzmUo24H3Z1vqUEuhbt2E60nVlFv01IRLmHFcRN9Vsvjp0q cdiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pa5saqYQl8CpwkOaW7T8I67jAl8ceaKoXEGVz+uPZNI=; b=aAMDEDNc+2pJijQLwdDGoHHUZhJjQalGIa2VHZt5/PX0uKd9kYk2vD/k8PJ6mECnC1 OLNmxdvtFLvlGm2McCbvS7YAzMddAl7s5ux+Sscc/SvJFD0BEi8XUxSWsL7LBRtwBBHk OJuRTcT63Ppry1dzzPS/odrSOGF20pNQIhGOB3ruyMBOytjZBk8XVVJ9DzOz7q7UHOoJ /BPjMG9/+o73hgDknltHhRg0iVCku2WNLe/9LWEo7p2qVuHx9gWmepVIcdWMOkQ9IErw dNRhN9zKhXlisyLHTyfMGsr4paF1AmHyVfLC2loD/le6Krl32Gyb5ZcDz64EDa5KX175 UbNg== X-Gm-Message-State: AODbwcBmHYnoJCckwMlteUzP28MmJdTEqGnD3lUFOGyHrDe0UHwAnmZq bsBcNwP+iI3sZie8FTMCYS5ltwgacqGa X-Received: by 10.159.40.136 with SMTP id d8mr5875505uad.48.1496463268006; Fri, 02 Jun 2017 21:14:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:14:26 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:14:26 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Sat, 3 Jun 2017 13:14:26 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: IETF IPv6 Mailing List , Job Snijders , draft-bourbaki-6man-classless-ipv6@ietf.org, Peter Hessler Content-Type: multipart/alternative; boundary="94eb2c124714829be3055106812d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 04:14:32 -0000 --94eb2c124714829be3055106812d Content-Type: text/plain; charset="UTF-8" What he said. On Jun 3, 2017 12:23, "Mark Smith" wrote: > On 3 June 2017 at 00:56, Job Snijders wrote: > > Dear Lorenzo, > > > > > > >> Please stop trying to make IPv6 be the same as IPv4. That will take > >> away our ability to make the Internet better once IPv4 is gone. > > > > I believe there to be tangible merit in making IPv6 feel and look more > > like IPv4. Perhaps this becomes more apparent when one shifts the > > innovation focus from layer-3 to higher layers. > > > > Making IPv6 look more like IPv4 (for instance through broader adoption > > of DHCPv6 w/ routing options, and classlessness like in IPv4) will > > positively impact IPv6 deployment. > > > > I think that's the fundamental agenda here, although perhaps not > realised. It is to devolve IPv6's capabilities and features to the > point where IPv6 isn't really much more than IPv4 with a different > packet format, and so the IPv4 operational practices people are > comfortable with can be directly applied to IPv6 without change. This > is because of the common human trait of intolerance of or resistance > to change. > > If this proposal is accepted, then I think /120s will become the > defacto subnet size, despite what the draft says about /64s being the > recommended default. Here's the clue for why - RFC1918 addressed > networks I've seen, where IPv4 address space doesn't need to be > conserved (i.e., unlike public IPv4 address space), always use /24s as > the defacto subnet size. "Same-same" is easier for us humans than > "Same-different." > > Why do I have a different perspective? My first networking protocol > was a more modern one than IPv4, Novell's IPX, derived from Xerox's > XNS. Learning and operating IPv4 networks after operating IPX networks > was a backwards step. The only major advantage that IPv4 provided over > protocols designed in the 1980s and 1990s, such as IPX, Appletalk and > CLNS, was that it provided organisations with Internet connectivity. > On many other criteria, IPv4 was far inferior - entirely > understandable, because it was fundamentally designed in the 1970s, > and then adapted over time to cope with being used to build a global > Internet work. It was never intended to be used to build a global > internetwork connecting billions of devices - > > https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html > > IPv6 is actually the first true protocol designed to suit the global > "Internet" problem. > > I have a few horrible stories of seeing IPv4 routers with 4 x /24s or > 25 x /26s on the same interface because renumbering and changing > subnet masks of hosts into a single large enough subnet was more far > expensive than sub-optimal forwarding across the same link. An > impossible problem to have when the default subnet address space size > far exceeds the practical link-layer node attachment limits (and in > some cases impractical link-layer limits because of link layer > "excessive" addressing - does an Ethernet really need 48 bit MAC > addresses? Who's going to go close to attaching 2^46 nodes to one of > them? The ND cache resource exhaustion type of problem also exists at > layer 2 with switch tables ...) > > I don't want to experience or see people experience those sorts of > IPv4 "right-sizing subnet" types of problems in IPv6. > > Regards, > Mark. > --94eb2c124714829be3055106812d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What he said.

On Jun 3, 2017 12:23, "Mark Smith" <markzzzsmith@gmail.com> wrote:
On 3 June 2017 at 00:= 56, Job Snijders <job@ntt.net> wro= te:
> Dear Lorenzo,
>
<snip>
>
>> Please stop trying to make IPv6 be the same as IPv4. That will tak= e
>> away our ability to make the Internet better once IPv4 is gone. >
> I believe there to be tangible merit in making IPv6 feel and look more=
> like IPv4. Perhaps this becomes more apparent when one shifts the
> innovation focus from layer-3 to higher layers.
>
> Making IPv6 look more like IPv4 (for instance through broader adoption=
> of DHCPv6 w/ routing options, and classlessness like in IPv4) will
> positively impact IPv6 deployment.
>

I think that's the fundamental agenda here, although perhaps not
realised. It is to devolve IPv6's capabilities and features to the
point where IPv6 isn't really much more than IPv4 with a different
packet format, and so the IPv4 operational practices people are
comfortable with can be directly applied to IPv6 without change. This
is because of the common human trait of intolerance of or resistance
to change.

If this proposal is accepted, then I think /120s will become the
defacto subnet size, despite what the draft says about /64s being the
recommended default. Here's the clue for why - RFC1918 addressed
networks I've seen, where IPv4 address space doesn't need to be
conserved (i.e., unlike public IPv4 address space), always use /24s as
the defacto subnet size. "Same-same" is easier for us humans than=
"Same-different."

Why do I have a different perspective? My first networking protocol
was a more modern one than IPv4, Novell's IPX, derived from Xerox's=
XNS. Learning and operating IPv4 networks after operating IPX networks
was a backwards step. The only major advantage that IPv4 provided over
protocols designed in the 1980s and 1990s, such as IPX, Appletalk and
CLNS, was that it provided organisations with Internet connectivity.
On many other criteria, IPv4 was far inferior - entirely
understandable, because it was fundamentally designed in the 1970s,
and then adapted over time to cope with being used to build a global
Internet work. It was never intended to be used to build a global
internetwork connecting billions of devices -

https://mailman.nanog.org/piper= mail/nanog/2010-April/020488.html

IPv6 is actually the first true protocol designed to suit the global
"Internet" problem.

I have a few horrible stories of seeing IPv4 routers with 4 x /24s or
25 x /26s on the same interface because renumbering and changing
subnet masks of hosts into a single large enough subnet was more far
expensive than sub-optimal forwarding across the same link. An
impossible problem to have when the default subnet address space size
far exceeds the practical link-layer node attachment limits (and in
some cases impractical link-layer limits because of link layer
"excessive" addressing - does an Ethernet really need 48 bit MAC<= br> addresses? Who's going to go close to attaching 2^46 nodes to one of them? The ND cache resource exhaustion type of problem also exists at
layer 2 with switch tables ...)

I don't want to experience or see people experience those sorts of
IPv4 "right-sizing subnet" types of problems in IPv6.

Regards,
Mark.
--94eb2c124714829be3055106812d-- From nobody Fri Jun 2 21:21:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10F7129BB3 for ; Fri, 2 Jun 2017 21:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8siH1HcKrEZ for ; Fri, 2 Jun 2017 21:21:39 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 80D721294BF for ; Fri, 2 Jun 2017 21:21:39 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id j17so54351284uag.3 for ; Fri, 02 Jun 2017 21:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TIIuZEtimxfuVIlK8iAOnxfeivfGV6vH4VEH8tkpXOg=; b=YPAnW58ROPlKbK6vMQT/dwFM1LpOUX0WdJccO+VvQEA5nVx+gSAv+VKJ6GexBQXzHC /RQwyeob/huk6hnLo1E530ORSeau6SBy2LgVyEh+TbDBfYi9me8if0/AolL7OWMc/Q53 aFFQkvXo26erzeEFQX3UJpyLYJ8YUphcFOCu+W+uiueELevD6jnf++k3/s9YN1jiruiH AAacMDS93BICPvV5xZwySc9YKIkLNP7bn5HM97kZTSNoTqzR2PTrQFmoHWqT750ppddx 7dArJXNbDvCR0C/D36i15//uoD54xHpgc1Fdra0SyEa4Ntrbmdub0i1GVdGVG8116ZiK +YzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TIIuZEtimxfuVIlK8iAOnxfeivfGV6vH4VEH8tkpXOg=; b=asFuZ/Y5qvGBy4Qm7QzOVn+mtUKIaZJtbfqdCko22ckCFfztpH7heO4iMhHs4U3BpN cU6Hw3CCtPz/yFHn/Pdy8HR7dIYPE+PapjK8hffmYcMnwCiFjtyYF92I7P3EYrAYyuOk EY/fmC9U51geWfYcb0YFvCjhNwBjVy4rpFqoVl78HTbAHD945bA+yi8rdFk4WhwLK3a8 5/30GlmW+ArIfSG6/1+rYk0a/g07kcAfOJ7oANwbEYw7u1JTxNW8IOTTr/XIzWxthII6 SiO6VjdIsuTx0F3xpNp/BK17Ytys7ocn4rPpmu96X7ajwPGhF2sXDcyW58lx00uDcLzZ TJxA== X-Gm-Message-State: AODbwcD+t4lKLwaahc1kTNp/bV+nwQnM+Y2TXMY4XK2S3O+F4ubbfjO9 5IxMKRKoTpFhZINm8tE/BAKr6aoG36Z2VHI= X-Received: by 10.159.52.214 with SMTP id b22mr5543411uac.93.1496463698375; Fri, 02 Jun 2017 21:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:21:37 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:21:37 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Lorenzo Colitti Date: Sat, 3 Jun 2017 13:21:37 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont Cc: Mark Andrews , IETF IPv6 Mailing List , Brian Haberman Content-Type: multipart/alternative; boundary="f403045e7976298ec30551069b93" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 04:21:41 -0000 --f403045e7976298ec30551069b93 Content-Type: text/plain; charset="UTF-8" On Jun 3, 2017 10:42, "Fernando Gont" wrote: > The phone then hands out /64's to devices behind it on demand. And such devices, if they feel like sharing, hand a...? This should read: "The phone enables bridging. All the devices behind it share the /64." This works today. Stop trying to solve a problem we don't have? --f403045e7976298ec30551069b93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 3, 2017 10:42, "Fernando Gont" <fgont@si6networks.com> wrote:
> The phone then hands out /64's to devices behind it on demand.

And such devices, if they feel like sharing, hand a...?
<= /div>

This should = read: "The phone enables bridging. All the devices behind it share the= /64."

This works t= oday. Stop trying to solve a problem we don't have?
--f403045e7976298ec30551069b93-- From nobody Fri Jun 2 21:29:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF51294F5 for ; Fri, 2 Jun 2017 21:29:39 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5Ss825TTlUi for ; Fri, 2 Jun 2017 21:29:38 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 32183126CBF for ; Fri, 2 Jun 2017 21:29:38 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id y4so54386686uay.2 for ; Fri, 02 Jun 2017 21:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ayZ0YpfrD1g5t34sH8/oy479354fJvx1nlwDfBNJe+g=; b=gpc9t1woGvaiXmeMdPfli5utzSOIyXmkRHJC+luJHH+EeIgfgZFprFegqGTG7fCMRA kBCR7PuJg2u/q2kEwZgmJpSsltwqqkSmzXzMF741Zx2tnCaKmcjYq2mTmXlcQgPhNOdu AxHre6NznZM1j10syiRqgA3SdRHz8P05ounHVnHTx3FOo7361aKWYizLAPog2lTpugkV mCjEgEWoGLPy3g4SaYIuMjWQPNxeZceITr1fsoGjBsUP49XqQ0PalTUl2ac6EsnqLRsf Mmp5SbcbIbfCZ7HXkQQlTnvaAeaPxKtwk+1rY1XPiHmr6ZFPMepNKvVuWkrpDh4dLbLu HmzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ayZ0YpfrD1g5t34sH8/oy479354fJvx1nlwDfBNJe+g=; b=KTDAuDJZio/10c6U+edG7yWIKPbmjsF6WgmV+t0GoYjEmggwm8BTAaZiKdFEXyYz1b 5gsIcJkq/hatJbmX0L30kQw8aywZTwrk2R/dEO8Csoso3KuKfix6RXD+zNW879UWgJ+Y mmqPQMDa706AMftvGWJN30cxu9HOa2V8xcBwn0iBcfZVOI3Tw1n9o0WWDmPe2jJ/NKMb McJa1IoazNqH9BuXQLB9IUB+TT6dnQymGNrLKJSqPD8XSErs956OvV+4ttyvVDL3LKS6 gzrSia4F9I6rPFO4lxVI/6EaKkrUitgNlkYpy1eZMhS8B4ygbd80qehSfN3iImWeFw9C ciLg== X-Gm-Message-State: AODbwcB3UCB7CUC3qFvP1s0NazapqM0WMXSwxZ6smp8Wpchbl8xblhJx wcxck1cqE/ATLZSCDP/3WUM8//pho0CfN+4= X-Received: by 10.176.17.228 with SMTP id q36mr3885288uac.20.1496464177235; Fri, 02 Jun 2017 21:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:29:36 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:29:36 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> From: Lorenzo Colitti Date: Sat, 3 Jun 2017 13:29:36 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: James Woodyatt Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403045e75fcb46061055106b7d2" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 04:29:40 -0000 --f403045e75fcb46061055106b7d2 Content-Type: text/plain; charset="UTF-8" On Jun 3, 2017 04:17, "james woodyatt" wrote: I once believed IPv4/NAT was about preserving scarce number resources. I now think that was wrong. It was always about optimizing rents across differing classes of subscribers even when the extracted resource on which the rents are derived is practically unlimited. In this one respect, IPv6 is no different than IPv4. As a purely technical matter, the rent MUST flow. That doesn't actually work. When all the applications have built NAT traversal mechanisms, anything more than one IP address per location becomes worth nothing. At that point the extra rent is gone, and everybody loses because the system is less capable, less robust, and harder to configure than it would have been without NAT. And in fact, that's what happens in IPv4 today. Putting an entire corporate campus with tens of thousands of users behind one public IPv4 address is standard practice. --f403045e75fcb46061055106b7d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 3, 2017 04:17, "james woodyatt" <jhw@google.com> wrote:
I once believed IPv4/NAT w= as about preserving scarce number resources. I now think that was wrong. It= was always about optimizing rents across differing classes of subscribers = even when the extracted resource on which the rents are derived is practica= lly unlimited. In this one respect, IPv6 is no different than IPv4. As a pu= rely technical matter, the rent MUST flow.

That doesn't ac= tually work. When all the applications have built NAT traversal mechanisms,= anything more than one IP address per location becomes worth nothing. At t= hat point the extra rent is gone, and everybody loses because the system is= less capable, less robust, and harder to configure than it would have been= without NAT.

And in fac= t, that's what happens in IPv4 today. Putting an entire corporate campu= s with tens of thousands of users behind one public IPv4 address is standar= d practice.
--f403045e75fcb46061055106b7d2-- From nobody Fri Jun 2 21:35:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8931270FC for ; Fri, 2 Jun 2017 21:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ0DgKbIdndu for ; Fri, 2 Jun 2017 21:35:01 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 6F37A129C37 for ; Fri, 2 Jun 2017 21:35:01 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id j17so54417194uag.3 for ; Fri, 02 Jun 2017 21:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PTZG4eJdO/FW1ciAcncD8qog4Ruz0daqd4Y8/PQFr4A=; b=P1S+R6yTyn9IIJtuIRQmxI5k4j5Q8zK4TI8o3QAH4NQmi+vbidpUpOY5rw5Tmjeq5y +R84fZ8uCENoMO4Rdc/x98Nl2oF7SKj1IQcNrwTMnlzlWqCjIWh0wR2iVbEcRpkW9Ghl BQe49ATG7nYIsPJ25tR45OzHoiS2vC1K8uwo7eTaMIcCya82BrLRIm7eZtw1lslOIE4l SXyHlGFFmn4VvfdIxr9cwzm4xu9LcgfCy6GbkPzl7o7QX49+3K7NFiivugDi0vF2BpHK SESoGou3Y3+P4jWk6j4QA/RrSNDR1QLJQUnRf2iPv4nhd9ypGerHfq1Xi2/6rmrf5PrM LBXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PTZG4eJdO/FW1ciAcncD8qog4Ruz0daqd4Y8/PQFr4A=; b=UG/V6q2WLsr+6aqducZHBfN8t0R5AALm4QUmvhFwD/JaoJnfRX08U7amg8vA3n4FOT KtMc3BsYNlYjtyyvqEjWfe3Dnu3zS/Hr9zsy0bV87LXvPAVoHnl4y2ZNbMpjuh7I/7Ep 1ceVRREcpuzL6FbN32GoNHnGlbcfFZrgbwIoDtyTvfWqwHVTDlk3nH2563A4VNFU5sbE TYPHNrdkESz8RhT35yXJTJvhzkkLu4Vxs+cy3rG4IYodHcMmQl01zXV4LeBBhKAcE20X z+71q0X66yWsS9Fb/3ioBOm+SXAayP84y3kATsbToIueVlJ7RoRSfRo2dxTa1sBzWDQ0 YizA== X-Gm-Message-State: AODbwcBT7sb1EGh9+yKquDN7V8Gw0mj/i9El3b2FxLLUNyYuFLWZHjj+ 3wEZ8XArBOwGrLucVe89Bw9FeDUa+jSd X-Received: by 10.176.83.16 with SMTP id x16mr5969162uax.11.1496464500549; Fri, 02 Jun 2017 21:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:34:59 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 21:34:59 -0700 (PDT) In-Reply-To: <2c496b044bc941bda1abd8f5662c5224@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <2c496b044bc941bda1abd8f5662c5224@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Sat, 3 Jun 2017 13:34:59 +0900 Message-ID: Subject: RE: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: IETF IPv6 Mailing List , James Woodyatt Content-Type: multipart/alternative; boundary="94eb2c18f1acf9b5c5055106caa4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 04:35:03 -0000 --94eb2c18f1acf9b5c5055106caa4 Content-Type: text/plain; charset="UTF-8" On Jun 3, 2017 04:31, "Manfredi, Albert E" wrote: Complete agreement. It's democratization. Users can do their own thing. Actually they can't. NAT doesn't extend the network, it just provides a crippled, stripped-down version of it. guarantees everyone a /48, which would then further put to the lie the idea of this super vast IPv6 address space. You seem not to know that there is in fact plenty of space to do that. See the calculations in RFC 3177. --94eb2c18f1acf9b5c5055106caa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 3, 2017 04:31, "Manfredi, Albert E" <albert.e.manfredi@boeing.com> wrote:=
Complete agreement. It's democratization. User= s can do their own thing.
<= br>
Actually they can't. NAT doesn't extend = the network, it just provides a crippled, stripped-down version of it.

= guarantees everyone a /48, which would then further put to the lie the idea= of this super vast IPv6 address space.

You seem not to know that there is= in fact plenty of space to do that. See the calculations in RFC 3177.
--94eb2c18f1acf9b5c5055106caa4-- From nobody Fri Jun 2 21:51:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ECF129B42 for ; Fri, 2 Jun 2017 21:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4mkTQHC1GXu for ; Fri, 2 Jun 2017 21:51:11 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 B8E27129B38 for ; Fri, 2 Jun 2017 21:51:10 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id v104so15221094wrb.0 for ; Fri, 02 Jun 2017 21:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aJwh/uaFVoy2KptrexOOK0QpXJBJTaI0Qub97CwNu4Y=; b=jg3CeAAUdWyPwY5EJEl65Okwlmb8kt4MIvZ0NUf9e/nWvvFXjConGiyDR11M2Fw19X 5Sq200kWIJPLjY+pJknEmdygpboxClqEL9QvtpnuVHR66Co/3MhRA4F7jd7aubx8rATd jd92iUdqDWDv7rLG1qsWo6USZDDKjGm7eP5eC8gwj1U0EdI+AnKDSTQio/zjT0Sgev3B Og5qf3OZhlkQak+sccZIs6G7ZQXvr1OfTYBngbxHXcqKzDuhGLbtUe/Qf4kDlAfkw9So jWljAn2AR6d3k+0R8KTsCAUAhJlxwlMfTPgvJo2oMy3fFkCUXZGuZfzPy1DPP5SNvorc aYcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aJwh/uaFVoy2KptrexOOK0QpXJBJTaI0Qub97CwNu4Y=; b=SMSxa7dOPcTURn1cmo05oNbap+6ckSF8J0yWmxEPd4zPFa5uq4P75Z7fZoJCuauYu1 uTBVL67PFD7F+msfPkXloJrC0L0D/Ci0S1AfZhX+FJb2FxHz3V4sXLxd3p3QSXWslYxM hcP8qLBY6KAi2pMNiB0s/7NNu3FAt7IIzuBdleag3wK53DEVVdjn2etUULLFWjpYpNpS uN/Kf3KgBBHuCpEO+kHPKMbctzcjgiIyiU3Qi9d3rfxWHh2rd/YgROvKJZjLo37O69H/ HcdR/f5yxUoNnlrIRTaarYmn3Rp+T9qk82OgCirguPrVRDa8YUP6UHxnZnvXVjy87bCY T4XQ== X-Gm-Message-State: AODbwcBYtOB/+vwQ4MvpHyH2MiEF27Qsy6iv8EeLmB0RHVUHoTCXycOv p44Yl+85L/nZvPhJArd7EXdpCizbQrbt X-Received: by 10.223.166.196 with SMTP id t62mr6629059wrc.52.1496465469270; Fri, 02 Jun 2017 21:51:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Fri, 2 Jun 2017 21:51:08 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Tom Herbert Date: Fri, 2 Jun 2017 21:51:08 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Fernando Gont , Brian Haberman , IETF IPv6 Mailing List , Mark Andrews Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 04:51:12 -0000 On Fri, Jun 2, 2017 at 9:21 PM, Lorenzo Colitti wrote: > On Jun 3, 2017 10:42, "Fernando Gont" wrote: > >> The phone then hands out /64's to devices behind it on demand. > > And such devices, if they feel like sharing, hand a...? > > > This should read: "The phone enables bridging. All the devices behind it > share the /64." Which allows the phone to bridge 2^64 devices! I don't understand why my phone needs a /64. This is an impediment to being about to use Identifier Locator Address (ILA) meaningfully in carrier networks. Tom > This works today. Stop trying to solve a problem we don't have? > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 2 22:17:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F921267BB for ; Fri, 2 Jun 2017 22:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40MkEveQxlCD for ; Fri, 2 Jun 2017 22:17:05 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 46678124D85 for ; Fri, 2 Jun 2017 22:17:05 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id y4so54631986uay.2 for ; Fri, 02 Jun 2017 22:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oHuWkhHVTm0992TRwSfAW1/EoQLZx9kPZjXWx/hUlYc=; b=ATZ+i7I746CORbx4yUT59GxznmPV8KNzNYFcpim0RkOGgFvgpWAA8cXT6fzKjkspzs eHGs+WdXbPo/Dy944jiAdGLza1CxC4pW1qtb7zfPw4YghgyLWvbPl9MSkvBWeGC8tgEZ bLcZx+NviDZav1w7QOUWZkYILbcOkYyDtvTTfkzuJnChpIg6qvB8Gu/07WKI53oCfmOV QrFB/2GP96aYFBjzryFagtwaR2rJ/9U2MM3GnxO1oJ+Oox4HGuLO+OQfoJ579xBCLrf9 fvOZxbZwMfAlA1JA+oLP15GKe2vAiQFk3XqEu0TvYFC9TvanctvQz4JQ63ufrr3kJaGt qFOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oHuWkhHVTm0992TRwSfAW1/EoQLZx9kPZjXWx/hUlYc=; b=fFunc2+JI/tJv74eAqGUvmmFEkT7kS7j6WlPMwK2mjDUckhLI9Ln5/NxgdGVYXR7r5 wHd/PRr4njj+BsLq7RtVOzqjQrNzhiEZGydY5dPLPL2BdUDiE3JIFo5HdazrLvp5bif+ C+L6CYhKOQk/SoGkFOWjRiqNIv7tH3V56tjxSZBVWpC7/9CiPDAUuxfesi00Ow8Vjo+E Y1s7gjGNX3qh497nL1cmfVrmYLw24eey1uD+l5aQB6zkTssTp3z7XFSTp0ui8UTMRmzj Uap7F+7o6iZZwmnBPe/lDwgrSrVdJO0FFTjWPACkEpdgLiUVjlULRzgbhEL0KMCiFmt3 oNmA== X-Gm-Message-State: AODbwcCvPBO0v4nyneA1gGhfTvXD8MioWKjHDcuqeWLZ+XgG/tlDNwo7 CUJdLPz4nv3QqpFkLy+Dt2QbXfRUGEht X-Received: by 10.176.6.197 with SMTP id g63mr5682656uag.52.1496467024277; Fri, 02 Jun 2017 22:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 22:17:03 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 22:17:03 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Lorenzo Colitti Date: Sat, 3 Jun 2017 14:17:03 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Tom Herbert Cc: Mark Andrews , IETF IPv6 Mailing List , Brian Haberman , Fernando Gont Content-Type: multipart/alternative; boundary="94eb2c122e6466d2ec055107617c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 05:17:07 -0000 --94eb2c122e6466d2ec055107617c Content-Type: text/plain; charset="UTF-8" On Jun 3, 2017 13:51, "Tom Herbert" wrote: Which allows the phone to bridge 2^64 devices! I don't understand why my phone needs a /64. The answers are in RFC 7934 and RFC7421. --94eb2c122e6466d2ec055107617c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 3, 2017 13:51, "Tom Herbert" <tom@herbertland.com> wrote:
= Which allows the phone to bridge 2^64 devices! I don't understand why my phone needs a /64.

<= /div>
The answers are in RFC 7934 and RFC7421.
--94eb2c122e6466d2ec055107617c-- From nobody Fri Jun 2 22:51:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAAF124217 for ; Fri, 2 Jun 2017 22:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Evb1mMyAkcKk for ; Fri, 2 Jun 2017 22:51:24 -0700 (PDT) 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 175F9127419 for ; Fri, 2 Jun 2017 22:51:24 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id p62so13908030vkp.0 for ; Fri, 02 Jun 2017 22:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1RZQnfWCsztIL1XiCH8ixGpFY3eZL1KR5eu2cWK5Tco=; b=QU77Zsc5zSSY2WlKplP0UotawMX7YzUwjCSMbnH769ZpvHMptpOMK4QE+PaMaJ5syC SlpMb4KEwPchmtn9X1Xj9gQSoPG1tm/EpI9ax4xmekoBQrJdPoSJgaeTqfpLKS/D6Dh8 4F908WEGyTyVRwmN8BLFx+yawMYDQo71+qyo3nvfrZc/lKbqp0NwWElnj8xAviw54Ko8 LhgqxSw/EKFdemZzYy2Yjw+jZupx1RUa073p1msSV9prKMQ7uBE8rG2zRJIeRERBrM5G 8Y65AQ8qyMjKz3bnING3xRtnOiRaZH10fMFPBbwZEUbjczWgY4Jay/Y9dEZYDydzWI+T /35w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1RZQnfWCsztIL1XiCH8ixGpFY3eZL1KR5eu2cWK5Tco=; b=GjYjOiLtlNO4mteV7vXNOYRDoXwnezo5bzs1yrDwVxS0qFN9+pOgK10dKr05A5K/6I QjcJv/wvpOKQtUUuMwfMYyKQ+K/goPX9kiSEH+uH8NXUVEjkQAgAfVbsiZzqDd2Ki1fr sh3C+NfzWqVGPh8Et6N34VN5lW63mgfcoQZkTyfvw5PSehJXV54nHV6AAW1IbzpVNESJ akNlrJjfZmCiJrADLUrvi1CGThMAPzR/FlRDPuvK/ofOnaHjhErd8A91kz/DZ+57FDuL h5FK/6ZUzMP9jNn6N+O5ZUKzw8zP6d0zB987kYmXFp4bIqEJYRNmIze36U1DlOSQGjlQ qVhA== X-Gm-Message-State: AODbwcBt41iS9Pea5JQk1/6pqZ2R2+0MLWjv15var7wlQXC1AHy5IhSW 6E+c6BEaWExjgcGF1oCYN1WuuylFzMjG X-Received: by 10.31.210.1 with SMTP id j1mr5108245vkg.144.1496469083045; Fri, 02 Jun 2017 22:51:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 22:51:22 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 22:51:22 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Lorenzo Colitti Date: Sat, 3 Jun 2017 14:51:22 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Tom Herbert Cc: Mark Andrews , IETF IPv6 Mailing List , Brian Haberman , Fernando Gont Content-Type: multipart/alternative; boundary="001a114bc9e21d3c82055107dc4a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 05:51:27 -0000 --001a114bc9e21d3c82055107dc4a Content-Type: text/plain; charset="UTF-8" On Jun 3, 2017 13:51, "Tom Herbert" wrote: > This should read: "The phone enables bridging. All the devices behind it > share the /64." Which allows the phone to bridge 2^64 devices! I don't understand why my phone needs a /64. This is an impediment to being about to use Identifier Locator Address (ILA) meaningfully in carrier networks. ILA provides mobility by forcing mobile entities to be numbered within 64 bits instead of 128. That makes sense in a datacenter where the numbers of locators is limited and multiple identifiers often share a given locator, but it's extremely inefficient in a network where everything is point-to-point like today's subscriber and mobile networks. When everything is point-to-point, identifiers can never share a locator and ILA effectively reduces the size of the address space from 128 bits to 64, reducing the number of addressable devices by 2e19. That's a spectacularly bad deal compared to the alternative, which is a few bytes of encap overhead. --001a114bc9e21d3c82055107dc4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 3, 2017 13:51, "Tom Herbert" <tom@herbertland.com> wrote:
=
> This should read: "The phone enables bridging. All the devices be= hind it
> share the /64."

Which allows the phone to bridge 2^64 devices! I don't understand= why
my phone needs a /64. This is an impediment to being about to use
Identifier Locator Address (ILA) meaningfully in carrier networks.

ILA= provides mobility by forcing mobile entities to be numbered within 64 bits= instead of 128.

That ma= kes sense in a datacenter where the numbers of locators is limited and mult= iple identifiers often share a given locator, but it's extremely ineffi= cient in a network where everything is point-to-point like today's subs= criber and mobile networks.

When everything is point-to-point, identifiers can never share a locato= r and ILA effectively reduces the size of the address space from 128 bits t= o 64, reducing the number of addressable devices by 2e19. That's a spec= tacularly bad deal compared to the alternative, which is a few bytes of enc= ap overhead.
--001a114bc9e21d3c82055107dc4a-- From nobody Fri Jun 2 23:38:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D66126CF9 for ; Fri, 2 Jun 2017 23:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yca6_BnigjKk for ; Fri, 2 Jun 2017 23:38:32 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 11102126C0F for ; Fri, 2 Jun 2017 23:38:32 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id b84so39291718wmh.0 for ; Fri, 02 Jun 2017 23:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=zHDoewOo3V48shLV7YD8dZAv/TPntYTM2kSxi2OgY/4=; b=akOgUYFEBFMi+gdGiABcN6NvzxLR9+BlVBFXagzDP9ZRxCFgSoTMYs/zHfOGp9MCIr k5JBFj2porNcI6HeoOCibOrrCC/5mpxyh++l93yohVw7057tku4o5s9tzMa/y6MAr/L9 vrm9iZDxVHj85/GFEARDUcjNn96yeRVIcYS4Brju96oU1i9XFy5t0hrbZFhUDE7gz9zJ BU7Zgsuehf5ZhwjMlzRa29tPwNPd8Zyxyo4YRmWP9EDpiYMeZQ7WEJ2C3KrYvCqq62e/ TPeCVh3UDr6Xv93d2fzylR6vHahp0DQMGtyYHWNLoAEkDxaDmJALyOZMx3y+kblzwWqH 3p/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=zHDoewOo3V48shLV7YD8dZAv/TPntYTM2kSxi2OgY/4=; b=Gjg3QATb1wFpHJi5KRWH1lgcALXw/aA/GXaMzz6pOYQszl/oEuK4qnmU4bSD0zxdw9 hKtEf77Ai3AllT6EPfOSq096NSRPQZdnm0bThy27uBWBZ+3dxUiw6B2UlbZZRfRqRRE3 ic0G593/RcDnURGKd3NcNM3ieLVOMUncS561LmThwNyfZ7uUn3PltKYHx1D4gmBlLWXR Bhm9x5g4S+qgyrHY1Q/UPDufl513VQEyqsSeGx9XllfxRf0Psl+1DcCs+dJduIIBU6XL uDqLL1PAjDH+j4MejF9HSpjHILz8TDuVQ4Ndms03+wfG2+u1uPcTuq1roasgK4BAOH9V Ogbg== X-Gm-Message-State: AODbwcCmEQe2kDWjR/cJColXdqt3LkB3ohAyxnQni408MkT+LQiKA+9D H546rLbBrUndn9Zn X-Received: by 10.28.92.135 with SMTP id q129mr1709328wmb.109.1496471910574; Fri, 02 Jun 2017 23:38:30 -0700 (PDT) Received: from [192.168.32.152] ([197.232.21.8]) by smtp.gmail.com with ESMTPSA id o97sm25771688wrc.48.2017.06.02.23.38.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 23:38:29 -0700 (PDT) Date: Sat, 3 Jun 2017 09:29:38 +0300 From: David Conrad To: Job Snijders , Mark Smith Cc: draft-bourbaki-6man-classless-ipv6@ietf.org, IETF IPv6 Mailing List , Peter Hessler Message-ID: In-Reply-To: References: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) X-Readdle-Message-ID: b7924f10-2ba3-4a82-ae70-8ed02cd0e03c@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5932595a_74b0dc51_13f01" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 06:38:34 -0000 --5932595a_74b0dc51_13f01 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jun 3, 2017, 6:23 AM +0300, Mark Smith , wrote: > I think that's the fundamental agenda here, although perhaps not > realised. It is to devolve IPv6's capabilities and features to the > point where IPv6 isn't really much more than IPv4 with a different > packet format, and so the IPv4 operational practices people are > comfortable with can be directly applied to IPv6 without change. This > is because of the common human trait of intolerance of or resistance > to change. In most large scale environments, change of "operational practices" implies cost. In this context, I believe there is a perception that the additional cost is for minimal benefit -- customers don't care (and are unwilling to pay a differential) if their cat pictures come over IPv4 or IPv6. As such, the resistance here is more about not wanting to spend more money than it is some sort of psychological roadblock associated with a common human trait. Regards, -drc --5932595a_74b0dc51_13f01 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Jun 3, 2017, = 6:23 AM +0300, Mark Smith <markzzzsmith=40gmail.com>, wrote:

I think that's the fundamental= agenda here, although perhaps not
realised. It is to devolve IPv6's capabilities and features to the
point where IPv6 isn't really much more than IPv4 with a different
packet format, and so the IPv4 operational practices people are
comfortable with can be directly applied to IPv6 without change. This
is because of the common human trait of intolerance of or resistance
to change.&=23160;

In most large scale environments, change of =22operational practices= =22 implies cost. In this context, I believe there is a perception that t= he additional cost is for minimal benefit -- customers don't care (and ar= e unwilling to pay a differential) if their cat pictures come over IPv4 o= r IPv6. As such, the resistance here is more about not wanting to spend m= ore money than it is some sort of psychological roadblock associated with= a common human trait.&=23160;

Regards,
-drc

--5932595a_74b0dc51_13f01-- From nobody Sat Jun 3 02:40:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FB8120227 for ; Sat, 3 Jun 2017 02:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTqH3AJ1LkST for ; Sat, 3 Jun 2017 02:40:06 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 6AD811200B9 for ; Sat, 3 Jun 2017 02:40:06 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id g76so17010890wrd.1 for ; Sat, 03 Jun 2017 02:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ccx/I2QVKIN+PH8Fprw7QRoBMM32ZwqPs+LWhrt25GM=; b=awlSIZQqT4bXpnedb+JlWA7zdNYNLMLxAg9q2hoW34scSFohK259Z9jyb51iDltCXH JQ9ncKhqRw9ZW0jTj/4n3plQRLViQJHW32lXbEXi1de8CdT++IYL2jOT4bURwnFjaqzX 2oh9TijovpyyK5LY52i33c3eu8AxBVvFFsvcvQ6kONHOS360DE46FDP9JABQasbi7m5W JFNinxnH/+3YntGSpEVEX/jKERh1LplANehcaaQYQQo25VGEk4YexqUXb91acUZPJ+2w Au/IxtkVGpUS3fOltSK/S1aEraCgTSkin3ELZbzDsz/YpbdpWFJ5DbaratJkit404BBP /6Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ccx/I2QVKIN+PH8Fprw7QRoBMM32ZwqPs+LWhrt25GM=; b=SbEHPngUAS3oy0u9IRSASZU2nD9xsQ2sXYqXO4fD91GWb+b8tyjoPZ3KNqH9sdqJsK 8ekwn1wJdEKCrRlNfHGzcEORBsfmpK5cQCviPX23+Pwjk0bcWuzLWG9O60CnHTi6XZGF 8W/QTi3Lku8zVJcKg3I2sLUnmJEnumwSi5CxrNjj2YThfbcoYFNiTzhEo0VIZEW+pqm0 KaJ3NquXyvjFH+C6MLPcG0+jP51mg3mwhHF1gPKCTgeNrtsuyvY9EuaecqrFruw6aS9+ 8yRrIs2zdEEY+LmOjXPCNzTcF/Dn8CIUB48MwhzG0SKCbEGASGZanPtfjr4V+glEJGmo vX3Q== X-Gm-Message-State: AODbwcAhJ6auu1krja2igwhXJ1zpdsyps2pUMUP8kfDafG4XWN3uoAbR Eb8uu2iTRqLXfmf2qD5b+xcElYLGpg== X-Received: by 10.223.128.208 with SMTP id 74mr7544751wrl.2.1496482804960; Sat, 03 Jun 2017 02:40:04 -0700 (PDT) MIME-Version: 1.0 Sender: mpetach@gmail.com Received: by 10.28.164.134 with HTTP; Sat, 3 Jun 2017 02:40:04 -0700 (PDT) In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: Matthew Petach Date: Sat, 3 Jun 2017 02:40:04 -0700 X-Google-Sender-Auth: eFZUFNYhOlp-hl6fHej0VhHZ3L0 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: ipv6@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 09:40:08 -0000 I support this draft. Matt On Fri, Jun 2, 2017 at 7:11 AM, Job Snijders wrote: > Hi Working Group, > > Please review the below. > > Kind regards, > > Job > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Mon, 22 May 2017 04:25:28 -0700 > From: internet-drafts@ietf.org > To: Job Snijders , Randy Bush , Christopher Morrow , > Fernando Gont , Nick Hilliard , Geoff Huston > , Brian Carpenter , Chris Morrow > > Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt > > > A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt > has been successfully submitted by Randy Bush and posted to the > IETF repository. > > Name: draft-bourbaki-6man-classless-ipv6 > Revision: 00 > Title: IPv6 is Classless > Document date: 2017-05-22 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt > Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ > Htmlized: https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 > > > Abstract: > Over the history of IPv6, various classful address models have been > proposed, none of which has withstood the test of time. The last > remnant of IPv6 classful addressing is a rigid network interface > identifier boundary at /64. This document removes the fixed position > of that boundary for interface addressing. > > > > > 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 > > > ----- End forwarded message ----- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Jun 3 03:15:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02638127136 for ; Sat, 3 Jun 2017 03:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.678 X-Spam-Level: * X-Spam-Status: No, score=1.678 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc7-at4bOxPf for ; Sat, 3 Jun 2017 03:15:43 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (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 4943B1279EB for ; Sat, 3 Jun 2017 03:15:42 -0700 (PDT) Received: from [192.168.0.26] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id 385F319F4F3 for ; Sat, 3 Jun 2017 12:15:35 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <5f7b9da2-98e1-dc7d-9441-928fcc3e8075@gmail.com> Date: Sat, 3 Jun 2017 12:15:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170603003552.7A0327ADD848@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:15:44 -0000 Le 03/06/2017 à 02:35, Mark Andrews a écrit : > > In message , > Brian Hab erman writes: >> Hi Bert, >> >> On 6/2/17 4:03 PM, Manfredi, Albert E wrote: >>> -----Original Message----- From: Templin, Fred L >>> >>>> My meaning was for the ISP to give the cell phone or home >>>> gateway a /64, then let the cell phone/ home gateway subnet the >>>> /64 to the IoT devices within the subnetwork it provides as it >>>> sees fit. >>> >>> Sorry, I have to make an important correction: >>> >>> Presumably, using some sort of internal address format, also /64, >>> such >> as privacy addresses? Yes, true, but ... >> >> I interpreted Fred's proposal as: >> >> 1. ISP gives the phone a /64 > > The ISP could give each phone a /48. Ask an operator, he'd say /56 instead of /48, if at all. And it would be a non-operational specific purpose trial. Ask another operator, he'd say '64share' everywhere, despite IETF saying it's INFORMATIONAL. Ask an end-user, he'd say operators are difficult, better do NAT. Alex > There is NOTHING stopping the ISP giving a /48 today. IPv6 is sized > to allow this. When you stop trying to hand out the minimum and > start handing out reasonable quantities of subnets the so called > problems go away. > >> 2. The phone delegates longer prefixes to the devices behind it >> from the /64 > > The phone then hands out /64's to devices behind it on demand. > >> 3. The ISP router has a single /64 route that points to the phone > > The ISP's router has a single /48 that points to the phone. > >> Regards, Brian > From nobody Sat Jun 3 03:16:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65835128616 for ; Sat, 3 Jun 2017 03:16:10 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-CbNxHw-4Bq for ; Sat, 3 Jun 2017 03:16:08 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F891279EB for ; Sat, 3 Jun 2017 03:16:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 88F441BC37 for ; Sat, 3 Jun 2017 10:15:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Simon Hobson In-Reply-To: Date: Sat, 3 Jun 2017 11:15:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <723E4B25-B932-412D-8369-448703DAA21A@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:16:10 -0000 Lorenzo Colitti wrote: > When all the applications have built NAT traversal mechanisms, = anything more than one IP address per location becomes worth nothing. At = that point the extra rent is gone, and everybody loses because the = system is less capable, less robust, and harder to configure than it = would have been without NAT. >=20 > And in fact, that's what happens in IPv4 today. Agreed - but that is typically out of necessity as there just aren't the = IP addresses to go round. Having had the luxury of managing a network with a whole /24 to play = with, and looked at the underlying problems making SIP phones work = through NAT, I fully agree that NAT is to be avoided due to the amount = of brokenness* it creates. Trying to persuade those who see things "just = work" (because of all the wasted effort put in to make things work - = would have been much better spent getting IPv6 adopted sooner) is a = different matter. BUT, I cannot see the logic behind your earlier comment that DHCP makes = NAT inevitable for IPv6. * PS - I have a special place in hell for the ******** ******** at Zyxel = who think that randomising port translations on every connection, and = "no you can't turn that off, we don't care if it breaks things, it adds = security" (yes, that's the response I got from them !) is a good idea. From nobody Sat Jun 3 03:17:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F091279EB for ; Sat, 3 Jun 2017 03:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUwHLKusbRFN for ; Sat, 3 Jun 2017 03:17:41 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (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 BEDC1127136 for ; Sat, 3 Jun 2017 03:17:41 -0700 (PDT) Received: from [192.168.0.26] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id E44FB19F59E for ; Sat, 3 Jun 2017 12:17:29 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Alexandre Petrescu Message-ID: <702089d2-48fe-1bc4-c1a6-eb89b9ef205f@gmail.com> Date: Sat, 3 Jun 2017 12:17:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:17:43 -0000 Le 03/06/2017 à 03:40, Fernando Gont a écrit : > Hi, Mark, > > On 06/03/2017 03:35 AM, Mark Andrews wrote: >> >> In message , Brian Hab >> erman writes: >>> Hi Bert, >>> >>> On 6/2/17 4:03 PM, Manfredi, Albert E wrote: >>>> -----Original Message----- >>>> From: Templin, Fred L >>>> >>>>> My meaning was for the ISP to give the cell phone or home gateway >>>>> a /64, then let the cell phone/ home gateway subnet the /64 to >>>>> the IoT devices within the subnetwork it provides as it sees fit. >>>> >>>> Sorry, I have to make an important correction: >>>> >>>> Presumably, using some sort of internal address format, also /64, such >>> as privacy addresses? Yes, true, but ... >>> >>> I interpreted Fred's proposal as: >>> >>> 1. ISP gives the phone a /64 >> >> The ISP could give each phone a /48. There is NOTHING stopping the >> ISP giving a /48 today. IPv6 is sized to allow this. When you >> stop trying to hand out the minimum and start handing out reasonable >> quantities of subnets the so called problems go away. >> >>> 2. The phone delegates longer prefixes to the devices behind it >>> from the /64 >> >> The phone then hands out /64's to devices behind it on demand. > > And such devices, if they feel like sharing, hand a...? '64share' is INFORMATIONAL, should not be used on a large scale. Alex >>> 3. The ISP router has a single /64 route that points to the phone >> >> The ISP's router has a single /48 that points to the phone. > > At which point we probably should start thinking about ipng-bis :-). > That's 16-bits away from IPv4, which has (or used to) /32 pointing to hosts. > > Cheers, > From nobody Sat Jun 3 03:21:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8864B127136 for ; Sat, 3 Jun 2017 03:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.867 X-Spam-Level: X-Spam-Status: No, score=0.867 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa6wvlwe892Z for ; Sat, 3 Jun 2017 03:21:55 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (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 5EFED126D74 for ; Sat, 3 Jun 2017 03:21:55 -0700 (PDT) Received: from [192.168.0.26] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id 26CFA19F5BE for ; Sat, 3 Jun 2017 12:21:52 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Alexandre Petrescu Message-ID: <52afa37a-3571-bb8b-ece7-63da5405bba6@gmail.com> Date: Sat, 3 Jun 2017 12:21:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:21:56 -0000 Le 03/06/2017 à 06:21, Lorenzo Colitti a écrit : > On Jun 3, 2017 10:42, "Fernando Gont" > wrote: > > > The phone then hands out /64's to devices behind it on demand. > > And such devices, if they feel like sharing, hand a...? > > > This should read: "The phone enables bridging. All the devices behind it > share the /64." > > This works today. Stop trying to solve a problem we don't have? '64share' does not scale, and is INFORMATIONAL. Solutions? Alex > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Jun 3 03:45:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD01287A5; Sat, 3 Jun 2017 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L_3x-TrAmpO; Sat, 3 Jun 2017 03:45:22 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4B01287A0; Sat, 3 Jun 2017 03:45:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 63C711BC37; Sat, 3 Jun 2017 10:45:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: Date: Sat, 3 Jun 2017 11:45:13 +0100 Cc: draft-bourbaki-6man-classless-ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <74616764-EF03-4AD3-BC59-B579B9FD2001@thehobsons.co.uk> References: To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:45:24 -0000 Mark Smith wrote: > I think that's the fundamental agenda here, although perhaps not > realised. It is to devolve IPv6's capabilities and features to the > point where IPv6 isn't really much more than IPv4 with a different > packet format, and so the IPv4 operational practices people are > comfortable with can be directly applied to IPv6 without change. This > is because of the common human trait of intolerance of or resistance > to change. I think that's over stating it a bit. Part of "the problem" with IPv6 is (as David Conrad says) that it's "too = different" and that means a lot of unlearning and relearning - and that = implies cost. In an environment where the majority still see no problem = because "it's OK, NAT works" then cost is a difficult thing to get = people to buy into. I see the point in fixing stuff that people don't realise is broken - = but the risk is that people see that "it's too complicated" and "they're = changing stuff for the sake of change" - and resist adopting it". I've = heard both these criticisms. > If this proposal is accepted, then I think /120s will become the > defacto subnet size, despite what the draft says about /64s being the > recommended default. Here's the clue for why - RFC1918 addressed > networks I've seen, where IPv4 address space doesn't need to be > conserved (i.e., unlike public IPv4 address space), always use /24s as > the defacto subnet size. "Same-same" is easier for us humans than > "Same-different." I've worked with different sized subnets. But I do see your point, I've come across lots of situations where = "nothing exists other than a /24" seems to have been the mindset. In one = case, I recall a Netgear router refusing to allow a valid IP4 address in = one GUI page because of an assumption of "/24 everywhere" that made it a = network address. And another model of router that did not support any = subnet size greater than /24. and ... And at my previous employer, I recall being involved in a project to = link all the businesses together with one global WAN (we were one of a = couple of dozen companies in the group). It was soon clear to me that I = was working with "professional IT people" who could not grasp the = concept that 172.16.1.1/23 was not in the range of ".1 to .10 reserved = for routers" in their addressing plan - and nor could they see that = ".1-.10, .11-.30, and so on" wasn't an easy addressing plan to work with = in terms of filtering traffic for diagnostic purposes ! That was dealing with people who did IT at a sufficiently high level = that they should not have had any excuse. In the general case, once you = get outside of large corporates, the level of skill is much much lower - = to the extent that I have to wonder just how on earth some of these = people can call themselves IT professionals. Down to the level of = knowledge where it comes down to "if the plug physically fits in the = socket then it should just work, right ?" ISPs colour code the sockets and cables with their routers for a reason. = They NEED to be able to say "use the YELLOW cable, and plug it into the = YELLOW socket ..." or customers simply won't be able to connect stuff = properly. I've had people plug a phone (RJ11) plug into a network port = (RJ45) and express surprise that it doesn't do anything ! > Why do I have a different perspective? My first networking protocol > was a more modern one than IPv4, Novell's IPX, derived from Xerox's > XNS. Learning and operating IPv4 networks after operating IPX networks > was a backwards step. The only major advantage that IPv4 provided over > protocols designed in the 1980s and 1990s, such as IPX, Appletalk and > CLNS, was that it provided organisations with Internet connectivity. > On many other criteria, IPv4 was far inferior - entirely > understandable, because it was fundamentally designed in the 1970s, > and then adapted over time to cope with being used to build a global > Internet work. I cut my first networking teeth with AppleTalk. I can still just about = remember how easy it was - and how darned complicated that IP stuff was = back then. > I have a few horrible stories of seeing IPv4 routers with 4 x /24s or > 25 x /26s on the same interface because renumbering and changing > subnet masks of hosts into a single large enough subnet was more far > expensive than sub-optimal forwarding across the same link. You've explained that in one - the cost of renumbering. At work I want = to renumber our office LAN, since being 192.168.1.0/24 it clashes with = so many customer LANs which causes issues when using VPNs (and ditto for = a couple of the clients as well who have the same issue). It's not = happened because of the cost involved - all those IP addresses (often = uneditable) embedded in systems - not least, the IP Port printers = configured on Windows desktops. > does an Ethernet really need 48 bit MAC addresses? Who's going to go = close to attaching 2^46 nodes to one of > them? I suspect you already know the answer to that already. No, no-one is = going to connect more than a few thousand nodes to one network, but if = you don't have globally unique MAC addresses, how can you guarantee = local uniqueness while still providing a stable interface identifier ? I assume you have never had to diagnose a problem with duplicate MAC = addresses ? I haven't personally, but I've heard first hand from a = friend who has ! He was managing a university site, and they bought a = batch of new desktops for a refresh. Turns out that Dell had a = provisioning system bug while meant that there were MAC address = duplicates - every 256 block of addresses got allocated to 257 machines = (ie one address got duplicated). Normally, this is unlikely to be a problem - not many customers buy more = than 256 machines in one batch, and few of those will put them on one = segment. But this university did, and they found the bug - eventually ! David Conrad wrote: > In most large scale environments, change of "operational practices" = implies cost. In this context, I believe there is a perception that the = additional cost is for minimal benefit -- customers don't care (and are = unwilling to pay a differential) if their cat pictures come over IPv4 or = IPv6. As such, the resistance here is more about not wanting to spend = more money than it is some sort of psychological roadblock associated = with a common human trait.=20 Indeed. From nobody Sat Jun 3 06:15:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFE712E03C for ; Sat, 3 Jun 2017 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKHY0IDDHMpf for ; Sat, 3 Jun 2017 06:15:57 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A3F3012957F for ; Sat, 3 Jun 2017 06:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v53DFrQk003123 for ; Sat, 3 Jun 2017 15:15:53 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wg1mT1dr1zDJfJ; Sat, 3 Jun 2017 15:15:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Carsten Bormann In-Reply-To: <74616764-EF03-4AD3-BC59-B579B9FD2001@thehobsons.co.uk> Date: Sat, 3 Jun 2017 15:15:52 +0200 X-Mao-Original-Outgoing-Id: 518188552.523926-e3a978233af8af625f383898f9b4e86d Content-Transfer-Encoding: quoted-printable Message-Id: References: <74616764-EF03-4AD3-BC59-B579B9FD2001@thehobsons.co.uk> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 13:15:58 -0000 On Jun 3, 2017, at 12:45, Simon Hobson wrote: >=20 > unlearning and relearning Reminds me of the story where a kid learns how to roast a duck and the = mother explains that to roast a duck, you have to cut off a bit at the = ends before roasting. Kid asked ma why, and she didn=E2=80=99t know; = her grandma had always told her so. Long story compressed, it turned = out grand-grandma had an oven that was too short for a whole duck, and = the cutting routine survived through the family even though today=E2=80=99= s ovens are larger. But the whole discussion here is backwards, because we stopped cutting = our ducks a long time ago. Changing the established IPv6 operational practices so they look more = like duck-cutting for IPv4 doesn=E2=80=99t make sense. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jun 3 07:39:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC512E044 for ; Sat, 3 Jun 2017 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LXrjIse-Cgp for ; Sat, 3 Jun 2017 07:39:18 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 86A17127369 for ; Sat, 3 Jun 2017 07:39:18 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id v111so12457914wrc.3 for ; Sat, 03 Jun 2017 07:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vJ0ThW/aX9UnOMPNM+Ge6LXKRs1HZK7qa4+KELY7ZGc=; b=tvVIbjM+k+nYjops4tBWsTPpOjhtfaieB1JrDXl3GZ2vvMXqPtJKZCBsSfar214pyu I0WEN54px1VbGVydpavnUkj246z6zxS8++SMS0ZpvHyFT1ExYim8hbbKXDvlmEtWkp7r BLMqlg/UidobS+rdvQHfsG1854PvS2rG9VnQ7qRONoqo8pe72HaJLX/9JJMp0D1Ep6h2 PhK0X7sPpu2oBKUwVmg3t8msqIggYJlZix40r7C9tet6d6/wd8GJdIcKGwsRDpvarvb7 cr714tcqq7Ziv0slBHxgZ83u6FTks4BPpMkEfdHAXAQ2/pw7K4CD9XVbW6t1o0zf9MiY m/Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vJ0ThW/aX9UnOMPNM+Ge6LXKRs1HZK7qa4+KELY7ZGc=; b=uIXVRCMTtJJoLw9YIEfRQ7oXuHSeIrIIEAB62ukbQTpSvNS2sfJGE4SnbF1zUmW8QC w6kfkSLhQ4d/8JHY7KSo5mDusdrr8UltRaHV018fuwDFJF5q+0nZKpclU96R+Dl/x3bO vjcZHbGlJlat6ni2+sAP2PylKa1iZQ4NgkeX0PuhtrVUNkL9CG1fXh4YFXlcAaNOziQp uOyzFlD5ts6z1vrxDum1bv6KGhEvzJ8SM4TKIhOM4lqr/AfSnxGFunD9GS58WsYeFRyW 8kq+hT8xHE/zigYPcxlJ1yFj/pZCdvY5uHIDHATo6Ba4HFyMv/vPs1aRz42SAhtkqJr9 obOQ== X-Gm-Message-State: AODbwcAoC1gL+1VgbSzuf7amTO9+4+nlhm5/cT6d8mgHOZBq26wSv1HY rEy1jm2B2G2xSne2O/vqv//zVUtXujkB X-Received: by 10.223.128.80 with SMTP id 74mr10200971wrk.30.1496500756963; Sat, 03 Jun 2017 07:39:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 07:39:16 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Tom Herbert Date: Sat, 3 Jun 2017 07:39:16 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Mark Andrews , IETF IPv6 Mailing List , Brian Haberman , Fernando Gont Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:39:20 -0000 On Fri, Jun 2, 2017 at 10:51 PM, Lorenzo Colitti wrote: > On Jun 3, 2017 13:51, "Tom Herbert" wrote: > >> This should read: "The phone enables bridging. All the devices behind it >> share the /64." > > Which allows the phone to bridge 2^64 devices! I don't understand why > my phone needs a /64. This is an impediment to being about to use > Identifier Locator Address (ILA) meaningfully in carrier networks. > > > ILA provides mobility by forcing mobile entities to be numbered within 64 > bits instead of 128. > I would point out that RFC7421 includes ILNP as a motivation for a /64, but this argument is not a valid rationale for assigning /64 to mobile devices. Mobile devices need to be assigned identifiers not locators. > That makes sense in a datacenter where the numbers of locators is limited > and multiple identifiers often share a given locator, but it's extremely > inefficient in a network where everything is point-to-point like today's > subscriber and mobile networks. > I disagree. In a datacenter we have VMs that are mobile entities and locators that are physical hosts. In a mobile network its the devices themselves that are the mobile entities and the point of attachment, e.g. base stations, that are the locators. The two cases are isomorphic. So in order for identifier/locator split to work it should be the base stations that have a /64 and the mobile devices that would be an identifier. The impediment here is giving each low end device a /64. If they were given a /96 or a /104 we could do a productive identifier/locator split for mobility. > When everything is point-to-point, identifiers can never share a locator and > ILA effectively reduces the size of the address space from 128 bits to 64, > reducing the number of addressable devices by 2e19. That's a spectacularly > bad deal compared to the alternative, which is a few bytes of encap > overhead. How much of the /64 space that is being assigned to end devices is being used? Unless it's more than some 0.00000...% that seems like the spectacularly bad deal to me and the thing that is reducing that Internet address space down to sixty-four bits. Forcing this assignment precludes us from taking advantage of the incredibly large address space with techniques like identifier/locator split. The only recourse that we have is to use encapsulation which means another forty bytes of header, another header to process, and makes this solution no different than what we can do in IPv4. The irony of the last point is not lost, /64 is forcing us to implement mobility just like we'd do in IPV4. Tom From nobody Sat Jun 3 08:04:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB56129423 for ; Sat, 3 Jun 2017 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcxMWJ8SFLy8 for ; Sat, 3 Jun 2017 08:04:25 -0700 (PDT) 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 CECD4120727 for ; Sat, 3 Jun 2017 08:04:24 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id b84so44460050wmh.0 for ; Sat, 03 Jun 2017 08:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ENEMZdlEWYzeRzvgqpk8JHzeXxjlFBxFnzjhqE7rssU=; b=A0WSK6z2LUaJO8PIGm5fUjU8nkOxJZQ5F+xnU5HPGSIe7cpszzVBRYp76MPyRrRiBw azZeTCJliGIlaPT3AH938WquYh20lUBn1fOXUQSxkD0C86NsjJ7uoiyjFJUIc2Lxkpk1 qVomyp3LEkP3Nm2qQ8K8wm/+5CqIZUnKRaVSMk3jMBacx6cNdqhx7XVtpcYsKqmPMxzD cPG5W3hnqMwJ7jNb9sQ4mrDQpQX+PKf147eMm4pH9EAlpgq+fMDe8UBIll5u74ov0SUc 4ZDj2LmOFqYZxxJdZb4fD3EsTi801r1jiDPi2xlgPZPeQpY9nbi5mVOxmG+1EPU1BjEC +mPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ENEMZdlEWYzeRzvgqpk8JHzeXxjlFBxFnzjhqE7rssU=; b=FCx8qumovPsCaTzTu9laQ8u5eFQ4rIBbC1vlWGHBg8Za41U0A5GdovY3Z7mRHgTtEP aBoQMT1aKiuDlIsfuNm7xU2evbrXKDX3PriAkj0w03DwF7k4goUhS5yx/lHIiGhVGULz i6Oh5T6jZP/cKILUjcMiHTEqFUzdCyycRuhSrZkngWI4Xi6y8jnUjM5h56WBrliHBhKK dFAyGyvCVf2OTGhDXBHScoDnY9tf0Fm2BZYwNICVyKrGAm1rwH/BEczdi85o6giiVOCD VPqRD4hZkKrqG8Kyc8WE8WwKvKhiHgQAMmse/TTgKrXoFb1ksQY5/8L0mfjpQ6Lx3FiH Zp8w== X-Gm-Message-State: AODbwcDHlD6seUkP2oKZRCHgh6AEkVPR2Nya7jPVo9aISZ4sAZ12F4NL RTU6nrpKfy33Je39PXpnrR7T1f/00RG5 X-Received: by 10.28.56.198 with SMTP id f189mr2554103wma.111.1496502263340; Sat, 03 Jun 2017 08:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 08:04:22 -0700 (PDT) In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: Tom Herbert Date: Sat, 3 Jun 2017 08:04:22 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 15:04:27 -0000 On Fri, Jun 2, 2017 at 7:11 AM, Job Snijders wrote: > Hi Working Group, > > Please review the below. > > Kind regards, > > Job > Job, Thanks for the draft. I think the case will be bolstered with some real examples as to how fixed /64 interface addressing has proven to be problematic. Using identifier/locator split in addresses as I mentioned is one example. I suspect there are more that could be documented. Tom > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Mon, 22 May 2017 04:25:28 -0700 > From: internet-drafts@ietf.org > To: Job Snijders , Randy Bush , Christopher Morrow , > Fernando Gont , Nick Hilliard , Geoff Huston > , Brian Carpenter , Chris Morrow > > Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt > > > A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt > has been successfully submitted by Randy Bush and posted to the > IETF repository. > > Name: draft-bourbaki-6man-classless-ipv6 > Revision: 00 > Title: IPv6 is Classless > Document date: 2017-05-22 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt > Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ > Htmlized: https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 > > > Abstract: > Over the history of IPv6, various classful address models have been > proposed, none of which has withstood the test of time. The last > remnant of IPv6 classful addressing is a rigid network interface > identifier boundary at /64. This document removes the fixed position > of that boundary for interface addressing. > > > > > 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 > > > ----- End forwarded message ----- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jun 3 08:25:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3F129411 for ; Sat, 3 Jun 2017 08:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12soaMOFs1qd for ; Sat, 3 Jun 2017 08:25:05 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 8DE14128B37 for ; Sat, 3 Jun 2017 08:25:05 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id d127so46402140wmf.0 for ; Sat, 03 Jun 2017 08:25:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=mHEqnOE0SUPJUgsyk39GxghWBCdz0bj/+5uSNAtgtxQ=; b=lJkPmLXaMswTgOnuUXZjQwJhHS2HEJUUzWtuhBZ7rJPADSTFdKoHALQl/PK6D/du7F axoaPYHqA5d6ISrTF1Z4DtoojqcZihaavlWojM6kQ0nyYAi4EZAmyJohsJbDqeTTSuqi GKvP0WFQraHxPdRwOHM9FQr8nl9FaTWpKDQgk9o0R4lVzT9ZA7Dg1GB1OOk/pzGGw5Qr aYkNOtBNEhotgoY2mwKhwrfcbsIelHRLgV/iYPKKZsMPbqwtnYvJeGsVDk5xwHcIixAG 3EaCF56q7eMeSlJgm3310a5Miu0fhDtbnO45XSIGtFQNeKDKjbs+NPlaPAxY/J/VYTre y63Q== X-Gm-Message-State: AODbwcD3/59P+xXNRbGCSlc006LmOXEwi1YnTWiooqHUV27x0YnOwpwr he073TulPyaNgdfQqCIbJA== X-Received: by 10.80.164.241 with SMTP id x46mr10069891edb.114.1496503503657; Sat, 03 Jun 2017 08:25:03 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:1d16:b1a5:1626:a6a1]) by smtp.gmail.com with ESMTPSA id h46sm9268586ede.56.2017.06.03.08.25.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 08:25:00 -0700 (PDT) Date: Sat, 3 Jun 2017 17:25:00 +0200 From: Job Snijders To: ipv6@ietf.org Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Message-ID: <20170603152500.ajhb5t3yzdrrvb5u@hanna.meerval.net> References: <74616764-EF03-4AD3-BC59-B579B9FD2001@thehobsons.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170428 (1.8.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 15:25:07 -0000 On Sat, Jun 03, 2017 at 03:15:52PM +0200, Carsten Bormann wrote: > On Jun 3, 2017, at 12:45, Simon Hobson wrote: > > unlearning and relearning > > Reminds me of the story where a kid learns how to roast a duck and the > mother explains that to roast a duck, you have to cut off a bit at the > ends before roasting. Kid asked ma why, and she didn’t know; her > grandma had always told her so. Long story compressed, it turned out > grand-grandma had an oven that was too short for a whole duck, and the > cutting routine survived through the family even though today’s ovens > are larger. > > But the whole discussion here is backwards, because we stopped cutting > our ducks a long time ago. Changing the established IPv6 operational > practices so they look more like duck-cutting for IPv4 doesn’t make > sense. I too have a story: Snow White and the Seven Dwarfs. The fairy tale's lesson is that it's OK to make mistakes; just make sure you learn from them. When the wicked step-mother offered Snow White the silver IP protocol for her corset, Snow White quickly realised it was a mistake when it magically tightened at the /64 boundary, restricting her breathing. Luckily Grumpy [draft-bourbaki-6man-classless-ipv6] got scissors and was able to cut the laces. The color quickly came back to Snow White's face. However, it should be noted that Snow White still bought the poison apple the following day! So let's not be like Snow White. Back to the topic: Nobody is talking about deprecation of IPv6, it is insincere to pretend we are. We're improving an aspect of the specification to further the adoption and deployment of IPv6. Kind regards, Job From nobody Sat Jun 3 08:47:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB697129BBF for ; Sat, 3 Jun 2017 08:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMRhSzj3fzWy for ; Sat, 3 Jun 2017 08:47:43 -0700 (PDT) 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 3CEA8129535 for ; Sat, 3 Jun 2017 08:47:41 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v53FlZY5064936 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jun 2017 16:47:36 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <5932DA16.9040008@foobar.org> Date: Sat, 03 Jun 2017 16:47:34 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.14 (Macintosh/20170515) MIME-Version: 1.0 To: Tom Herbert CC: Job Snijders , "ipv6@ietf.org" Subject: Re: draft-bourbaki-6man-classless-ipv6-00 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 15:47:45 -0000 Tom Herbert wrote: > Thanks for the draft. I think the case will be bolstered with some > real examples as to how fixed /64 interface addressing has proven to > be problematic. Using identifier/locator split in addresses as I > mentioned is one example. I suspect there are more that could be > documented. Tom, let's say your device is assigned a /64, e.g. either on a mobile network or via PD. Your device sits between upstream and downstream devices and passes traffic between upstream and downstream. Forcing /64 means that your device is limited to bridging mode, because downstream devices would not be permitted to assign a netmask of longer than /64. This could seriously adversely impact on network connectivity options for downstream devices. E.g. multiple networks sitting on some homenet. Would this fall into the category of examples that you're talking about here? Nick From nobody Sat Jun 3 08:50:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317F0129535 for ; Sat, 3 Jun 2017 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKXQ6fzUrB9B for ; Sat, 3 Jun 2017 08:50:01 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 A6D22129504 for ; Sat, 3 Jun 2017 08:50:00 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n195so46757524wmg.1 for ; Sat, 03 Jun 2017 08:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C///FMPXf/m8bIGh3SPum/8dijp5c0CPzGQ0pd9X9h4=; b=QK64+dCEN6z8PI9nmR5QDBeh6jspFWIi+7baqW8Yys9Yl7GsNj1NNFIPROOrdy5GiI e2Iigws7OGgACV0h07q8DeHms8Htq318bvzuIwq0UuUMThyKT9Mkv4LHHVVGy9KIi5FM 2MwEErrBcYiRGY1eQE9HIum3aoxzt4jO6Xa7H9eocTyNggsBihwfF+18j6TS5gIgYnll OvW21Unx/CVMNY2FIM6rmeRZSxEMDkB+s4xj7t9vYlLPoJPfF4uJlFbB3aSro8bNyW3m fVuDLq6/nPi4SXPLu95aOoXwQni2wF/O13cpAvQYntGuWwo7aNO2w+9Tw/FNG0cc03+N +BSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C///FMPXf/m8bIGh3SPum/8dijp5c0CPzGQ0pd9X9h4=; b=VeLEje94uQ6dEwWFuG+s5EfT9VU+7LzPB1VU3Wy1XrKUUn0COY8c3fpA/tWcr8l5EA TRh62D8DiWd766INQSkzKCH7u2TFHGmK4hLGoRMJhN+eqLrmVVM6KwV94NSoOzF5nTwz qnyivBVryGXr5o7ZkRnnksvpDDbPN3tYlFAar1LXZFNYJ6rhSeK0g/zrxW432EpD0URk j04fpqjx6tIgmDHNZaD0zzeJNpg2/czVOVIIaGEmL8Mh4bI2M+LST6VnI0NA3x+LiAW+ fs24xEM9HXk3P+fL9FNBf4lVbV7+6eSorc72L/SUSlguzNNDf1L6gm2SDAnBVJ/qJJzq fffQ== X-Gm-Message-State: AODbwcDpOV178rST1KrEZJEYDXlLrLxjv1hXkCYLBTfOahpHt6rfpXtU YhaOnycfvnEyu4F1wwYGBOGTSgnVKClW X-Received: by 10.28.56.198 with SMTP id f189mr2648258wma.111.1496504999217; Sat, 03 Jun 2017 08:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 08:49:58 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Tom Herbert Date: Sat, 3 Jun 2017 08:49:58 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Mark Andrews , IETF IPv6 Mailing List , Brian Haberman , Fernando Gont Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 15:50:02 -0000 On Fri, Jun 2, 2017 at 10:17 PM, Lorenzo Colitti wrote: > On Jun 3, 2017 13:51, "Tom Herbert" wrote: > > Which allows the phone to bridge 2^64 devices! I don't understand why > my phone needs a /64. > > > The answers are in RFC 7934 and RFC7421. Lorenzo, RFC7934 presents the arguments why hosts need multiple addresses, not why hosts need 2^64 addresses. For RFC7421 the arguments seem to be around operational simplicity. These don't answer my specific question: Why does a low end device, like a phone, _need_ the equivalent of four billion IPv4 address spaces assigned to it? What is a specific application that a phone runs that justifies giving the device such an enormous space? I don't believe it can be ILA, ILNP, NAT, or renumbering-- these are justifications for given datacenter servers /64s. Tom From nobody Sat Jun 3 09:03:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD0D129BF5 for ; Sat, 3 Jun 2017 09:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxFh1T9LOH_7 for ; Sat, 3 Jun 2017 09:03:33 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD7E1242EA for ; Sat, 3 Jun 2017 09:03:33 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b84so45056907wmh.0 for ; Sat, 03 Jun 2017 09:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fcyXyBHsQG22SFJAUC7/zR6iRblw/KjH9SjrR+r4H1w=; b=Sl2ujH16YqMt1PFMB4RCh0/oQakAPzbVG1BmJQoRdu87Ys3sbv3rNdBIeUYTdNdWC0 iqaPv+uGhhJW5VLoXMJEeMepI2prQuf9173BirjQFUPqFV27rqaEVsHh6B/kaKvyPGmL Qa9pjZR6slIaEfTuSOlwKdGRboWaCt+nGbqX9NuPa/b5dxLV8qyJFsiZT6V3TblEEv+V KrB8B/43LCRgizx9EKBPhT25uvp9Zsom43o+fHSOqtBrHDh3fstgDpPWy9xhBHJ2x4+J ecbi9jAHfxkx+8kothY6rPvdX2yXRxtmf4C/qAjJhkfHBqbkS42j0Hq9fS+ST7t0esr2 61zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fcyXyBHsQG22SFJAUC7/zR6iRblw/KjH9SjrR+r4H1w=; b=H79cByFdVSotcnFG+x4X5TakLVADNDq4Wf/854SrIWCLhwNwg+cCJR6l7C9C2TNvVS oZGgor5Qij9ImZU92cn2n17LY7QgIrD+lCBhUtK6ZfhbWo8Gw/ahpTlC4edz1LBkiz5R udbSJzBoglWlJU4QF3ziahkRMmukvuTrS1rmQocxQ4IFLgLw0f8o1XhbUhFJ+BYw/pfS X+rmu384a1uleitIKZsviFDvxhMT+TDj1WZpId0VhR29PeNSZwjHr+qasd6NKtFkzhlX IL1H8kGIMQGjPOW/fBon0XWHhssCUh3ByymEn1lH8ThazUHQE5ZfJ0GzIXTdbwCC7wDn BPfQ== X-Gm-Message-State: AODbwcANf3A4iyA7QoFOF6eJU0sJtxJ53SkhOeuB58f04pTlLOSfCrHq TOUDwR2tjbOggG6wcaESUxI22iI7e/rj X-Received: by 10.28.54.154 with SMTP id y26mr2247352wmh.53.1496505811754; Sat, 03 Jun 2017 09:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 09:03:30 -0700 (PDT) In-Reply-To: <5932DA16.9040008@foobar.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> From: Tom Herbert Date: Sat, 3 Jun 2017 09:03:30 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Nick Hilliard Cc: Job Snijders , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 16:03:35 -0000 On Sat, Jun 3, 2017 at 8:47 AM, Nick Hilliard wrote: > Tom Herbert wrote: >> Thanks for the draft. I think the case will be bolstered with some >> real examples as to how fixed /64 interface addressing has proven to >> be problematic. Using identifier/locator split in addresses as I >> mentioned is one example. I suspect there are more that could be >> documented. > > Tom, > > let's say your device is assigned a /64, e.g. either on a mobile network > or via PD. Your device sits between upstream and downstream devices and > passes traffic between upstream and downstream. > > Forcing /64 means that your device is limited to bridging mode, because > downstream devices would not be permitted to assign a netmask of longer > than /64. This could seriously adversely impact on network connectivity > options for downstream devices. E.g. multiple networks sitting on some > homenet. > > Would this fall into the category of examples that you're talking about > here? > I think this is too much a generalization trying to make it a "one size fits all" problem. I'm not going to use my phone as a router into my enterprise network, I don't see any reason to have it delegate some complex network hierarchy. We need the ability to tether a small number of devices, anything more than we are talking about a different type of device. Tom > Nick From nobody Sat Jun 3 10:04:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EDE129BF5 for ; Sat, 3 Jun 2017 10:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_4jBYRyf_qc for ; Sat, 3 Jun 2017 10:04:17 -0700 (PDT) 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 F06E612741D for ; Sat, 3 Jun 2017 10:04:16 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v53H45Z4073857 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jun 2017 18:04:05 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <5932EC04.7010505@foobar.org> Date: Sat, 03 Jun 2017 18:04:04 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.14 (Macintosh/20170515) MIME-Version: 1.0 To: Tom Herbert CC: "ipv6@ietf.org" Subject: Re: draft-bourbaki-6man-classless-ipv6-00 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 17:04:19 -0000 Tom Herbert wrote: > I think this is too much a generalization trying to make it a "one > size fits all" problem. I'm not going to use my phone as a router into > my enterprise network, I don't see any reason to have it delegate some > complex network hierarchy. we're talking about any network structure of any form rather than a complex network hierarchy. The problem as it stands is that there are situations where the fixed /64 rules out entire categories of options. One of these, as you point out, would be complex hierarchies. Another would be the entire category of small networks that are being discussed in the homenet wg. > We need the ability to tether a small > number of devices, anything more than we are talking about a different > type of device. The number of devices isn't the issue here; it's whether the protocol can facilitate a single downstream network or more than one. Right now, we're limited to one in the usual case where the device is assigned a /64. Nick From nobody Sat Jun 3 10:14:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B746C12EB1C for ; Sat, 3 Jun 2017 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4V6NA_IfHlm for ; Sat, 3 Jun 2017 10:14:26 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FE4129C12 for ; Sat, 3 Jun 2017 10:14:25 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id d127so47507191wmf.0 for ; Sat, 03 Jun 2017 10:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vFnYLTeae5vmqzgpxLTIwjoxPFrUJcAdEHGl9lnd4o=; b=ahwFcM3jJhSUXsTAi/Tgetrx97FEK0pSUoq4sHzzrLp7PNzvXMBD2RVbk5IyBwww8+ y+1AtHAvoScnXngqykGBK/0Lmx/vkRkJLOTAmqZs9qcEIpd317N6sJbGKS2UvRRimHfF qgiO+sAOYWxK9nMB6nPng9VnO4v8WbKdWfQP/SwgZjfwBbbLkQowYug7+59yQ6TQIHR6 IxCEASz7V+XdQoXA91476lb8O+1SATKOLFvQQD0zwb5lyfZ643RfWgwiAW5s+Lwjz683 qVxvVb+pc62gIlPbiUgmQ9ZlXPXEEE3RyshCdm8EbT3SIpFiRBVqUkenYa61PsbEJMJy OZqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vFnYLTeae5vmqzgpxLTIwjoxPFrUJcAdEHGl9lnd4o=; b=AoAMuKTNn6wK4ckEOQvDdrRq8Zv6kUcHshKmdtwLx5iSXj/TVfosS4UAO87x9+i8Y8 nAJTKD1KwhMC53FYworaU3qbE+0bAZmlCC6mCjRXmcViljahpJmTo4RZYHSVn7HRe0de RBGz60Y78tQlXlgfph1gJWVXjuDtlxf345aZ+ThHBn2UOOrXf7aq+r09qjE0a2ctoyG6 3olKRdjiB4vQ8FOXL58OLmxjnMZed26PeqEmH24zgUBP24xY+89pFbKODmPqSHr37cmP 7YNq/+Rpghu+f+TSWPJ6pId8El1HumhRO86ryYlge6wxk6g1PNzrxi8vMShAZsHzGR/S E1lA== X-Gm-Message-State: AODbwcBxOaI6JOn7jY2AivKz7/UTaO4hXw6ajrh5kc3CMbGt4w/npHdP As84zrQaw04gmwY+4k9iQi4aDSlfn2hj X-Received: by 10.28.139.69 with SMTP id n66mr2782728wmd.60.1496510064532; Sat, 03 Jun 2017 10:14:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 10:14:23 -0700 (PDT) Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 10:14:23 -0700 (PDT) In-Reply-To: <5932EC04.7010505@foobar.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <5932EC04.7010505@foobar.org> From: Tom Herbert Date: Sat, 3 Jun 2017 10:14:23 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Nick Hilliard Cc: ipv6@ietf.org Content-Type: multipart/alternative; boundary="001a11442996ccc3350551116671" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 17:14:28 -0000 --001a11442996ccc3350551116671 Content-Type: text/plain; charset="UTF-8" On Jun 3, 2017 1:04 PM, "Nick Hilliard" wrote: Tom Herbert wrote: > I think this is too much a generalization trying to make it a "one > size fits all" problem. I'm not going to use my phone as a router into > my enterprise network, I don't see any reason to have it delegate some > complex network hierarchy. we're talking about any network structure of any form rather than a complex network hierarchy. The problem as it stands is that there are situations where the fixed /64 rules out entire categories of options. I would agree with that. I think that these categories of options that are being disallowed should be described to support the draft. Tom One of these, as you point out, would be complex hierarchies. Another would be the entire category of small networks that are being discussed in the homenet wg. > We need the ability to tether a small > number of devices, anything more than we are talking about a different > type of device. The number of devices isn't the issue here; it's whether the protocol can facilitate a single downstream network or more than one. Right now, we're limited to one in the usual case where the device is assigned a /64. Nick --001a11442996ccc3350551116671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jun 3, 2017 1:04 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Tom Herbert wrote:<= br> > I think this is too much a generalization trying to make it a "on= e
> size fits all" problem. I'm not going to use my phone as a ro= uter into
> my enterprise network, I don't see any reason to have it delegate = some
> complex network hierarchy.

we're talking about any network structure of any form rather than= a
complex network hierarchy.=C2=A0 The problem as it stands is that there are=
situations where the fixed /64 rules out entire categories of options.
<= /blockquote>

I would agree with that. I think that these categories of options that are= being disallowed should be described to support the draft.

Tom

=
One of these, as you point out, would be complex hierarchies.=C2=A0 Another=
would be the entire category of small networks that are being discussed
in the homenet wg.

> We need the ability to tether a small
> number of devices, anything more than we are talking about a different=
> type of device.

The number of devices isn't the issue here; it's whether the = protocol
can facilitate a single downstream network or more than one.=C2=A0 Right no= w,
we're limited to one in the usual case where the device is assigned a /= 64.

Nick


--001a11442996ccc3350551116671-- From nobody Sat Jun 3 10:32:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B33A12EB36 for ; Sat, 3 Jun 2017 10:32:50 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qo7rRGIeqGs for ; Sat, 3 Jun 2017 10:32:49 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA0A12EB35 for ; Sat, 3 Jun 2017 10:32:48 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id 132so24812247ybq.1 for ; Sat, 03 Jun 2017 10:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xAAeIRfIrmKl3R6o5SfHLFG89uEe+z7RfVHh0EvnLRM=; b=JN+G33npwCnkQFeZ5K9HhnyEeXosX9u2hjbEEpP6REl6ee6oXiyotHTss19ZtS/jF0 AHcT1Ix7RyyZ1DN1xWnOJ2/6qshELc5OHqGbB/Z8sa3IQMxjZOTWbYV9q89wJ2VzOFgU zG4Ht8teGy29uP8w7EYh030XInQV6Rx0g374XAbYbEImuvwi1Cel0S6VwuIiIYsiVTEI 9NYr7kEKZzC5Yo6WIVBbwBG9HHvwdqwZ3rzjCDlkeuTP+FD39PVKeh7tWgJnQCCuzAS8 VY4v8YQ0TkfdnXJ55GVCHvSTQA9RdtQZt3jNLPF+urqhVf6N9rmY3nWQZLxB3Vxf09xL SocQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xAAeIRfIrmKl3R6o5SfHLFG89uEe+z7RfVHh0EvnLRM=; b=tabYsZFePPNSPB0Y5hp208kpvCL52NSS9Ica7hqSqUAXW3oe2nyWu2dpG3W/w7+OZv 4VOlx5u39xzMwEicgnFAFNPM/U2pTIK9qo/k2/oqNVnQaqc148rxMNBmtf6W3Fy9cBXg 3fdtxDH9zX4LA3PgniE8W9tNOQQZue0tk/4+q9CBMweGRK8lFCfdwnxCuZ0quDHMlQn1 FIr9vjlxfyqdIwCDxLMBtXAd0rbyEUKotcKHkrUpMVPLKde31g65ZRotvV7SOabw8Hrl AXoHVVLWGkMz6hApOXqZ+aCvgiowkJRi9/+q350CbtlaCE9BRPRs22jKEyYtwZ+TzLj1 wxCw== X-Gm-Message-State: AODbwcBIwa2jmZyTm8BwrwGmeqb2aTtxr9Yq4Kc8srLfo/yKRqWSqmQi pntATPDbyk0+2+HFSdBfbOjB7Sylih1v X-Received: by 10.37.49.67 with SMTP id x64mr4099805ybx.217.1496511168153; Sat, 03 Jun 2017 10:32:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Sat, 3 Jun 2017 10:32:47 -0700 (PDT) In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Sat, 3 Jun 2017 19:32:47 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders , 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 17:32:50 -0000 On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders wrote: > Abstract: > Over the history of IPv6, various classful address models have been > proposed, none of which has withstood the test of time. The last > remnant of IPv6 classful addressing is a rigid network interface > identifier boundary at /64. This document removes the fixed position > of that boundary for interface addressing. what I find odd is that we over and over again are morphing IPv6 into IPv4 with just more IP adresses... can't we just rename it to IPv4+ and be done with it? Things like this ONLY hurt IPv6, yet again IETF can't agree on IPv6 so why should we bother using it? But I guess the none technical side are a lost case for most IETF'ers. Not to mention that we remove one of the thing so many I've spoken to over the years think is great - the standard LAN size. No more discussion on that. either way, not support from me but doesn't really matter when all the rest think it's a great idea. Think I'll use my time outside to fix the garden rather than fighting this losing IPv6 cause. -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Sat Jun 3 10:34:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D60A12EB36 for ; Sat, 3 Jun 2017 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seG4t3WmJQRZ for ; Sat, 3 Jun 2017 10:34:15 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 0D0CE126E64 for ; Sat, 3 Jun 2017 10:34:15 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so30003340ywr.0 for ; Sat, 03 Jun 2017 10:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qGFYWtX89XFc7TMKgGKet+jbpxBPDCA8raVoiLub6Wo=; b=vOT1ZQ0VrNUbpIPvN4rHcWR6g9pfhvoGV8eiUZncsPXe2cRX2GszZ20B8eit5jXsm+ YnwqDQwCi1SAdDfTdkv4YakPuPKV1I14B3BXXbXH1THjmR9IhZvC00NonSVd7QaF+WoU QSQpUGlZ0oTqjcMhbgTMtE6PeoyQM0/MK0PPds8AzxrWWjjT1+v8zqx1vatKcphqgwVI SueHEGPDBQKLmmmN26m0j9a4cvuvk9i85DdIMWGmVdWuBPrGP6lv0btkg6QzKyTv5cuu pW7t/Ec+EaIm4Pk+3aOrh0dc0K75Sotli2Kf2IS1wOcK/o3zlqyJ7GIsHae2vx4ixgDp xqVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qGFYWtX89XFc7TMKgGKet+jbpxBPDCA8raVoiLub6Wo=; b=rffDPVcCofoXKFmOMaZCGtP4p2BIN5QkuYMXfril4cc3EygIoNvyToi7W3AR1KvIZy SzxZmhiJxZQFBxWt8LIXyJ1avGwA1kyZI63SQ3BpEJ/Qu7wkfmSc2k85z2E5W8Qysk5v yoEETzNk82c/f/Nvh8KPGTc2w+gW++jPrum3MoGA7YOojzLFIvxSCgQSoROv8LNofabS aUzTryfaCf60RgGWbXZI0Qi7v5ONSlOqiBj8r+rRuaSB1gm7GmYvGp2xYdbfmkPLkQL7 LPTBGxY6gtC6uEeI9IPgqE7sJU9o6Qyz7NecI6875znXtVuHTUfOsNgFK04zR1LBWCBj L3ag== X-Gm-Message-State: AODbwcDR1GneE2W94Qfm3xB/SYd3MeAtL9x7Bw9GJTohunlbxCKCG9De ITN5gaSHPm0S7sQKdU0zMfqfCo18wxpw X-Received: by 10.129.196.75 with SMTP id s11mr9561264ywj.320.1496511254362; Sat, 03 Jun 2017 10:34:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Sat, 3 Jun 2017 10:34:13 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Sat, 3 Jun 2017 19:34:13 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 17:34:16 -0000 On Fri, Jun 2, 2017 at 4:33 PM, Lorenzo Colitti wrote: > Please stop trying to make IPv6 be the same as IPv4. That will take away our > ability to make the Internet better once IPv4 is gone. oh totaly agree, but it's already lost, the "operators" don't want to move/change. -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Sat Jun 3 10:34:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070D6126E64 for ; Sat, 3 Jun 2017 10:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxCVt22BKJWX for ; Sat, 3 Jun 2017 10:34:33 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id D819712EB3E for ; Sat, 3 Jun 2017 10:34:29 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 439B1E6065; Sat, 3 Jun 2017 19:34:28 +0200 (CEST) Date: Sat, 03 Jun 2017 19:34:28 +0200 (CEST) Message-Id: <20170603.193428.74670442.sthaug@nethelp.no> To: job@ntt.net Cc: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: sthaug@nethelp.no In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 17:34:36 -0000 > Please review the below. Support. Steinar Haug, AS2116 > > Kind regards, > > Job > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Mon, 22 May 2017 04:25:28 -0700 > From: internet-drafts@ietf.org > To: Job Snijders , Randy Bush , Christopher Morrow , > Fernando Gont , Nick Hilliard , Geoff Huston > , Brian Carpenter , Chris Morrow > > Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt > > > A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt > has been successfully submitted by Randy Bush and posted to the > IETF repository. > > Name: draft-bourbaki-6man-classless-ipv6 > Revision: 00 > Title: IPv6 is Classless > Document date: 2017-05-22 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt > Status: https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ > Htmlized: https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 > > > Abstract: > Over the history of IPv6, various classful address models have been > proposed, none of which has withstood the test of time. The last > remnant of IPv6 classful addressing is a rigid network interface > identifier boundary at /64. This document removes the fixed position > of that boundary for interface addressing. > > > > > 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 > > > ----- End forwarded message ----- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jun 3 10:54:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97411286AB for ; Sat, 3 Jun 2017 10:54:34 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRuyfGX4FJDF for ; Sat, 3 Jun 2017 10:54:33 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002: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 D8EA2128D40 for ; Sat, 3 Jun 2017 10:54:32 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 132so24871196ybq.1 for ; Sat, 03 Jun 2017 10:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DmRdQiXN0lPE1as+EJjCBSekP5VJ/fgiTyT299V6fJg=; b=tKJ9fWa6zDbWyB3yDB4MneaGOlbMPEcBzRbyDtSrW9Cz223varRla0AiEcwWBVwUBq 0cczXvFifmZMnNj5kWRksLhwkHcLJwu4zXfejlhOl8BjdyouS329pf8uzFuA5Y3kVSJz StNy3Z87NKPlm5P3kRWo0KjsgfZxAzMY9yJ9c4RHC5lvH3GiuYa/QK9i9t/nzcJpR3mh aKAlTN6L/pnH61r3Tl6ih7I2tKECSpzdbODEcQKQP08qZQ0HwZxeRSaT/JPggnHXXAqW Zdcx6a4rtNosZKQhK+KOOPVViIYCMOUTfARsq1wgIRYV6IsETeOxrwQu3513GZZPlnCb QN+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DmRdQiXN0lPE1as+EJjCBSekP5VJ/fgiTyT299V6fJg=; b=f+LLjpdeRdy9AEflnqH5fsE0524nfnTSVxbG0WoYIhtqZGOmqV0V7ZAllyhOMD7KRx xrH7aSkmErRZBI2QLndTYZ4p7E5JdGta1KSI3gUlWTu/hekAZrLeh5uV1xLFfPyq+H39 zSDttKqZBilR2NutbeiqNYHkEQlz7g/uasZt5aXP4lCsUNL0kGTETeCpgX33jbwYTF8Q 9xZPwlgAWCyd6hTKDLbg0Q6tHkwSf0RNHghJ5DAHCwlBloFUcOFNVP20RiS5eB5/7kUD 60kx4hZ+Zy8JbRkuhHoiqeKiQvDw3ZUZTd0HwieBojfidCvFtob9kXgY9wTH66xpmAjM 3kGg== X-Gm-Message-State: AODbwcCzflQHUudVd9IBBvVZ+fiS1hEMs/L/lGLuDJ53Qik9ft4fF154 pXy2nmPW6UID/UPKb1UDr7iK/sVwB8Yd X-Received: by 10.37.98.18 with SMTP id w18mr4106401ybb.23.1496512472140; Sat, 03 Jun 2017 10:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Sat, 3 Jun 2017 10:54:31 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Sat, 3 Jun 2017 19:54:31 +0200 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 17:54:35 -0000 totaly agree - but look at the world today, all the proposals over the years, operators don't care, they have their well known IPv4 world, all they lack is more address and IPv6 provide that. --- Roger J --- On Sat, Jun 3, 2017 at 5:23 AM, Mark Smith wrote: > On 3 June 2017 at 00:56, Job Snijders wrote: >> Dear Lorenzo, >> > >> >>> Please stop trying to make IPv6 be the same as IPv4. That will take >>> away our ability to make the Internet better once IPv4 is gone. >> >> I believe there to be tangible merit in making IPv6 feel and look more >> like IPv4. Perhaps this becomes more apparent when one shifts the >> innovation focus from layer-3 to higher layers. >> >> Making IPv6 look more like IPv4 (for instance through broader adoption >> of DHCPv6 w/ routing options, and classlessness like in IPv4) will >> positively impact IPv6 deployment. >> > > I think that's the fundamental agenda here, although perhaps not > realised. It is to devolve IPv6's capabilities and features to the > point where IPv6 isn't really much more than IPv4 with a different > packet format, and so the IPv4 operational practices people are > comfortable with can be directly applied to IPv6 without change. This > is because of the common human trait of intolerance of or resistance > to change. > > If this proposal is accepted, then I think /120s will become the > defacto subnet size, despite what the draft says about /64s being the > recommended default. Here's the clue for why - RFC1918 addressed > networks I've seen, where IPv4 address space doesn't need to be > conserved (i.e., unlike public IPv4 address space), always use /24s as > the defacto subnet size. "Same-same" is easier for us humans than > "Same-different." > > Why do I have a different perspective? My first networking protocol > was a more modern one than IPv4, Novell's IPX, derived from Xerox's > XNS. Learning and operating IPv4 networks after operating IPX networks > was a backwards step. The only major advantage that IPv4 provided over > protocols designed in the 1980s and 1990s, such as IPX, Appletalk and > CLNS, was that it provided organisations with Internet connectivity. > On many other criteria, IPv4 was far inferior - entirely > understandable, because it was fundamentally designed in the 1970s, > and then adapted over time to cope with being used to build a global > Internet work. It was never intended to be used to build a global > internetwork connecting billions of devices - > > https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html > > IPv6 is actually the first true protocol designed to suit the global > "Internet" problem. > > I have a few horrible stories of seeing IPv4 routers with 4 x /24s or > 25 x /26s on the same interface because renumbering and changing > subnet masks of hosts into a single large enough subnet was more far > expensive than sub-optimal forwarding across the same link. An > impossible problem to have when the default subnet address space size > far exceeds the practical link-layer node attachment limits (and in > some cases impractical link-layer limits because of link layer > "excessive" addressing - does an Ethernet really need 48 bit MAC > addresses? Who's going to go close to attaching 2^46 nodes to one of > them? The ND cache resource exhaustion type of problem also exists at > layer 2 with switch tables ...) > > I don't want to experience or see people experience those sorts of > IPv4 "right-sizing subnet" types of problems in IPv6. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Sat Jun 3 11:16:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3A12EB71 for ; Sat, 3 Jun 2017 11:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgD01VzSDM0E for ; Sat, 3 Jun 2017 11:16:25 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1B212EB6D for ; Sat, 3 Jun 2017 11:16:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id D1B3E1BC37 for ; Sat, 3 Jun 2017 18:13:34 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Simon Hobson In-Reply-To: Date: Sat, 3 Jun 2017 19:13:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <715E81C1-6A48-4507-8C50-C94D1D68B842@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 18:16:28 -0000 Tom Herbert wrote: > I'm not going to use my phone as a router into > my enterprise network, I don't see any reason to have it delegate some > complex network hierarchy. We need the ability to tether a small > number of devices, anything more than we are talking about a different > type of device. OK, what about a situation where something that looks like a phone to = the network, but happens to not have much by way of telephony bits built = into it, is being used ? It really doesn't change the discussion that = the box is black, has no display, and is called a router - it's still = doing exactly the same thing as a phone doing tethering for downstream = devices. And at work, we have customers doing just that - connecting an entire = network (OK, not complex network) to the internet either as a temporary = measure until their proper connection gets installed, or in some cases = as a permanent measure as it's not worth getting a fibre circuit = installed for a temporary site (where temporary is typically in the = order of 2-4 years for a civil engineering project). Roger J=F8rgensen wrote: > But I guess the none technical side are a lost case for most IETF'ers. In reality the world is run by non-technical people - often derogatorily = referred to as bean counters. While not applicable here, I firmly = believe that one of the reasons for the slow adoption of IPv6 is it's = perceived complexity (and hence cost) on the part of the bean counters = who ultimately must sign off on any project in a business. > Not to mention that we remove one of the thing so many I've spoken to = over the years think is great - the standard LAN size. I'm inclined to agree there. At first I had to admit that I just couldn't bring myself to think = positively about what seems to be profligate wastage of address space - = having "cut my teeth" with IPv4 addressing. Now I'm getting my head = around it though it's taking some effort to adjust in many ways. As a thought, will there be discussions at some point in the future when = it turns out that some vendors have decided that nothing other than a = /64 exists and so their kit doesn't support (say) a /56 ? From nobody Sat Jun 3 11:41:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07412EB9A for ; Sat, 3 Jun 2017 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCmRfx6ekaTt for ; Sat, 3 Jun 2017 11:41:18 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651A712EB97 for ; Sat, 3 Jun 2017 11:41:18 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id d127so48320365wmf.0 for ; Sat, 03 Jun 2017 11:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kQ8wIEjoFC+nXwV6RfEdUxMLMW3bHqPONQWxg465zOo=; b=bzf4eP3gBh0sB+so0c7Qhv3DbDWTqk32h/n09y2/vCf/3i63U/Yl1W0eE4+Rs/7rno Bp/zGNc+L+rj8IV7XfyodFa5RUZB8l5EQsoj2fZSc1U58vNstTCHKL9EXpAwudfGjOhM BPuVhDirPI4neZ8vUAqGdgkDBcZFlfBIy0Do1DLR7kvWStcR25AT+ra++WWRo8S/e6Bj tAzCMHPAwqAq2pdcNVrtXpKejxqHbKqoRFCqrVzwYz3+rrIjWEp63WjdKG47z4yvLdEN skpAzQgaUjeh7KoU1s1w+P72OVkPNG29KJpJo1jVZ1EYYdnbqTnwvyJzHLaR/ZO4Yk3J e0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kQ8wIEjoFC+nXwV6RfEdUxMLMW3bHqPONQWxg465zOo=; b=pPibyQ9wR6V57/pg5Q+6GHKTlg7E04koZ8YpV39IJg18VaF9MopGz42o/xuCxv2LuP IIj7aj+81VmGPFX65FE6BkqSQYucAFcbKMxcUbXJbYuEzw2iD+4SJpNqknx2xhK6CqXB IeWsNPcoc9fQbVxfZxkJMKVO9lgoABa4ZeKWjd94DgakTS0FTCBpzOAFi1fpPuGjAkQd 3SabcCx9+quf0N14lNUxjoRyxmRq7KbRMk90RVGFJpx3M5po1J28ChfIHurGA/rhZjU4 dtiSuIvDry7mWjIy/Rhlfs4keqarPymmbtQlmGmZdenpbcgQ3n3tVf/0mqFZQaNSO5Bf rZCw== X-Gm-Message-State: AODbwcBGIo96tyBPiYgGsyS75iTZfrs7u9PseUkDXgQM2ALmYsnDCBSb FNUIJMYPprDyrXvn+yqKW1HZEOxcja6k X-Received: by 10.28.229.144 with SMTP id c138mr2876742wmh.60.1496515276776; Sat, 03 Jun 2017 11:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 11:41:15 -0700 (PDT) Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 11:41:15 -0700 (PDT) In-Reply-To: <715E81C1-6A48-4507-8C50-C94D1D68B842@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <715E81C1-6A48-4507-8C50-C94D1D68B842@thehobsons.co.uk> From: Tom Herbert Date: Sat, 3 Jun 2017 11:41:15 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Simon Hobson Cc: ipv6@ietf.org Content-Type: multipart/alternative; boundary="001a11471eb279437a0551129d1f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 18:41:21 -0000 --001a11471eb279437a0551129d1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Jun 3, 2017 2:16 PM, "Simon Hobson" wrote: Tom Herbert wrote: > I'm not going to use my phone as a router into > my enterprise network, I don't see any reason to have it delegate some > complex network hierarchy. We need the ability to tether a small > number of devices, anything more than we are talking about a different > type of device. OK, what about a situation where something that looks like a phone to the network, but happens to not have much by way of telephony bits built into it, is being used ? It really doesn't change the discussion that the box is black, has no display, and is called a router - it's still doing exactly the same thing as a phone doing tethering for downstream devices. But that does change the discussion significantly. Those are different devices, not smart phone I'm using to type this message. This does not need a /64 assignment, I will never use it for any more than tethering a few devices. What I do need is seamless mobility for my applications which is a problem IPv6 should be able to help solve. And at work, we have customers doing just that - connecting an entire network (OK, not complex network) to the internet either as a temporary measure until their proper connection gets installed, or in some cases as a permanent measure as it's not worth getting a fibre circuit installed for a temporary site (where temporary is typically in the order of 2-4 years for a civil engineering project). That's anecdotal. For every case like that, how many user devices are out there that don't even turn tethering ever and are only using one address, much less need 2**64 of them? Thanks, Tom Roger J=C3=B8rgensen wrote: > But I guess the none technical side are a lost case for most IETF'ers. In reality the world is run by non-technical people - often derogatorily referred to as bean counters. While not applicable here, I firmly believe that one of the reasons for the slow adoption of IPv6 is it's perceived complexity (and hence cost) on the part of the bean counters who ultimately must sign off on any project in a business. > Not to mention that we remove one of the thing so many I've spoken to over the years think is great - the standard LAN size. I'm inclined to agree there. At first I had to admit that I just couldn't bring myself to think positively about what seems to be profligate wastage of address space - having "cut my teeth" with IPv4 addressing. Now I'm getting my head around it though it's taking some effort to adjust in many ways. As a thought, will there be discussions at some point in the future when it turns out that some vendors have decided that nothing other than a /64 exists and so their kit doesn't support (say) a /56 ? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a11471eb279437a0551129d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jun 3, 2017 2:16 PM, "Simon Hobson" <linux@thehobsons.co.uk> wrote:
Tom He= rbert <tom@herbertland.com>= ; wrote:

> I'm not going to use my phone as a router into
> my enterprise network, I don't see any reason to have it delegate = some
> complex network hierarchy. We need the ability to tether a small
> number of devices, anything more than we are talking about a different=
> type of device.


OK, what about a situation where something that looks like a phone to= the network, but happens to not have much by way of telephony bits built i= nto it, is being used ? It really doesn't change the discussion that th= e box is black, has no display, and is called a router - it's still doi= ng exactly the same thing as a phone doing tethering for downstream devices= .

But that does change the discussion significantly. Those are differe= nt devices, not smart phone I'm using to type this message. This does n= ot need a /64 assignment, I will never use it for any more than tethering a= few devices. What I do need is seamless mobility for my applications which= is a problem IPv6 should be able to help solve.
And at work, we have customers doing just that - connecting an entire netwo= rk (OK, not complex network) to the internet either as a temporary measure = until their proper connection gets installed, or in some cases as a permane= nt measure as it's not worth getting a fibre circuit installed for a te= mporary site (where temporary is typically in the order of 2-4 years for a = civil engineering project).

That's anecdotal. For every case lik= e that, how many user devices are out there that don't even turn tether= ing ever and are only using one address, much less need 2**64 of them?

Thanks,
Tom




Roger J=C3=B8rgensen <rogerj@gmail.c= om> wrote:

> But I guess the none technical side are a lost case for most IETF'= ers.

In reality the world is run by non-technical people - often derogator= ily referred to as bean counters. While not applicable here, I firmly belie= ve that one of the reasons for the slow adoption of IPv6 is it's percei= ved complexity (and hence cost) on the part of the bean counters who ultima= tely must sign off on any project in a business.

> Not to mention that we remove one of the thing so many I've spoken= to over the years think is great - the standard LAN size.

I'm inclined to agree there.
At first I had to admit that I just couldn't bring myself to think posi= tively about what seems to be profligate wastage of address space - having = "cut my teeth" with IPv4 addressing. Now I'm getting my head = around it though it's taking some effort to adjust in many ways.
As a thought, will there be discussions at some point in the future when it= turns out that some vendors have decided that nothing other than a /64 exi= sts and so their kit doesn't support (say) a /56 ?

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

--001a11471eb279437a0551129d1f-- From nobody Sat Jun 3 13:43:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA65129B5E; Sat, 3 Jun 2017 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R5wPl4uTS6z; Sat, 3 Jun 2017 13:43:38 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965891286B1; Sat, 3 Jun 2017 13:43:38 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n23so66040185pfb.2; Sat, 03 Jun 2017 13:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6H1/Loyvz3nSfE/NFr5x492Qngzeurt/c3IjhNAyHrQ=; b=ed+R1nAeyg1Z/d7zcnv9bQIxqFEZ/lpwUPWXrI6v36afJ634R4/WiQMpuDZkpbV6Zn 2X/Pw323o4Kc0iKe4IONhrkm0m2zQr7fldY2H31Ve5vDuksH1BmVi/N3Oa0AjapcGEXP RGs32OyqV97FboKQRcV3pPqwwu2TkUR2sONnzqBdX2sSjJmwFJX6vzZF89OAQkv5n/VU A1t0Kv564EiK9Dht03uvZEHGfiEGhwYsZm3Jw0U2wtX3z4BaSpJTi6Uj/wwItX9kNF0P tQkqh6fl/vciBamS9QreQRvjx4dDEkfKoraFzMU9HCIsZuSjXSEcZO+xcTmmGCRAOJi2 uMvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6H1/Loyvz3nSfE/NFr5x492Qngzeurt/c3IjhNAyHrQ=; b=V4Wz8m7ZW1uAHMagYqiUeg+iAl2ao9sjv2s1EsSRvnKzbViDzm1neGqqHAZbYEtMC/ utJriUkiYaFQqytEXvSa5IZRE1p1eXBUPwkScj8TN/1960m7tpxEVbcxGBNhYqDs8oC+ XCysSGdwbuBwJDZ2SySTIa2HHAApRm8BylYS4hvjbbQjxhvTQpWEEYBrOYw7Hpik8u7e pqVZYOPbvoQA3DJTQnjqRagEaX4nb/meFmFD0IIvB40EGnUc6XT2zGY07yWSlIMEux1S hvWx9mDfKD5e+MrGBdnGwbxBEsHXluxi1Y/my6FlTlzBd8zjxqk89Zr4fjjeDGBOfaaE Aqdg== X-Gm-Message-State: AODbwcDSAkZaKQWhNf4fl/MOO3lN6rfSEjOqoVPTE07yOAjJkPpHOzNk 9TMUbTOIGoVvlCzm X-Received: by 10.99.7.138 with SMTP id 132mr13466497pgh.171.1496522617966; Sat, 03 Jun 2017 13:43:37 -0700 (PDT) Received: from [192.168.178.21] (96.23.255.123.dynamic.snap.net.nz. [123.255.23.96]) by smtp.gmail.com with ESMTPSA id v3sm17922492pgn.56.2017.06.03.13.43.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 13:43:36 -0700 (PDT) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: 6man Cc: draft-bourbaki-6man-classless-ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> Date: Sun, 4 Jun 2017 08:43:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 20:43:40 -0000 On 03/06/2017 15:23, Mark Smith wrote: ... > If this proposal is accepted, then I think /120s will become the > defacto subnet size, despite what the draft says about /64s being the > recommended default. Predicting the future of complex systems is hard, but I think this prediction is wrong. There are some very strong arguments against prefixes that long, and it is the IPv6-over-foo specs that prevent such long prefixes being used. The IPv6 routing architecture has always been CIDRised. Please remember that "ID" in CIDR stands for "inter-domain". So there is nothing new there; even BCP198 was nothing new. IMNSHO we made a basic mistake by including the value of n in the addressing architecture. That's the n in > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ All this draft really does is observe that n is a parameter. It could be said in many fewer words, I suppose. If we'd been able to agree on simply removing n=64 from 4291bis, I wouldn't have put my name on this draft. Brian From nobody Sat Jun 3 13:51:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096291286B1 for ; Sat, 3 Jun 2017 13:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJqNEvmg00qL for ; Sat, 3 Jun 2017 13:50:57 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B829129B5E for ; Sat, 3 Jun 2017 13:50:57 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id n23so66075588pfb.2 for ; Sat, 03 Jun 2017 13:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OeFQ1RUtCUQ3iD4LnSirV5QxQ2KReQSMqr+nrJBrY6o=; b=fwzJs+HO9QrU/bn2/THWLxgCA2o+ngNxtpJZ5YunKFUvm5OuYlbpYq46QqxyOE16K5 CArd73cYF1xV3fLuKMdJnyx+cDxX5CBlrTbXS/l2tk50lwidTnVL+nn1cq1YjuVQFfQI cVn8jdFFZIioHFm0uiGJHjAwDbQpxYHZ7ycTEy0PSDhpXPS2Gm+O4SYxy6PFZ4IPDYtA HAyp54xTKTUzKHZIHRIksOhJ85rBwpDMWunTdyElqXMZO3zQ/RD/u11Gf/h7SW7BwGQ8 9v+v3d97364CX2piGBeKiUmZAqMRezaNq7cgXzmIzuw03eDi4pQWlThgiG8PI6bPcio7 WkRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OeFQ1RUtCUQ3iD4LnSirV5QxQ2KReQSMqr+nrJBrY6o=; b=tJFpTcZD8KR7M2z7vzvf9JdabG1nNEQhMfDvHDB0if4Npmwu/cO70e78QxF+xWNp53 NYfUBsiUrtShqha8adLaFCM5wq8zMn9bZunqNUapsK9llBDXMDrlHXbQXARTqOqIaO+f Ky0NhqZHxH1oXThqhQvYd5YiPB+vwXdG98GiT21jtjWh4Mnukig31iRQDGGzx8r40l5X RsyyHV/TE/hJfNqTW63ruwnsUHKE5WYXDJw6ALcCmBPViiw/ZyxDPq49depsHbrLrfEy H/ab4KnjJwpsTGp5yS4gbm6xBqrgKQfkhmGZYFSr4VS4clRYfxJFIomlb0Sn8s1S2B9c Y4KA== X-Gm-Message-State: AODbwcCPP7xvcWW5IgwgT+9B8MCBfr0+miGuVnZ5y//ckse7q564NLDN n2wmPZ2JCNfRO4JM X-Received: by 10.84.217.134 with SMTP id p6mr6675143pli.192.1496523056735; Sat, 03 Jun 2017 13:50:56 -0700 (PDT) Received: from [192.168.178.21] (96.23.255.123.dynamic.snap.net.nz. [123.255.23.96]) by smtp.gmail.com with ESMTPSA id g13sm10363297pgu.54.2017.06.03.13.50.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 13:50:56 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <715E81C1-6A48-4507-8C50-C94D1D68B842@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1fe72c25-1d82-db19-d95a-66265f5614fd@gmail.com> Date: Sun, 4 Jun 2017 08:50:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 20:50:59 -0000 On 04/06/2017 06:41, Tom Herbert wrote: ... > > That's anecdotal. For every case like that, how many user devices are out > there that don't even turn tethering ever and are only using one address, > much less need 2**64 of them? So that's an argument about delegating prefixes vs assigning addresses. I don't see how it affects the question of whether the routing architecture includes a magic barrier at /64. What the draft says is that there is no magic barrier in the routing system. It isn't even news. Brian From nobody Sat Jun 3 13:56:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE32129B5E for ; Sat, 3 Jun 2017 13:56:09 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmcfTHYqTrwP for ; Sat, 3 Jun 2017 13:56:08 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 05F971286B1 for ; Sat, 3 Jun 2017 13:56:08 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 8so20270101pgc.2 for ; Sat, 03 Jun 2017 13:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OxUin8VLduHDgU/5HCEPEzjK0LCN/vZ6em49HYr0mWU=; b=nZDS+bJBAMdaU9Tl7yPs+nYwOVs04AXYHqC6m647J9GpxBf6X1xglNXRRO+DKgHx6S HoFDRWM+6hLwqIx9olFAayTHoXVC+laxKKP5G9Ik7HnyDYZuQVaFoLc9ySDiKbVrdBLZ NcZnqVO9VojP84peGnYd7+byBlv0kFwtEydhZ6vdsT1wI7Ww99F2W2G/hjgdtlUZAYX0 LYFKM5aRNab23qpGeuBT5FueBO7tuHDQPJpK9OUy503KdsH2cldX923CmGuuCKFiYlrH Jh1ss7hbEWDeUCY2ud5vGDLcZRNiMtOn+tQLALnOx64RdgncLEDbcMuq/2H9fdTSpI1u HmlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OxUin8VLduHDgU/5HCEPEzjK0LCN/vZ6em49HYr0mWU=; b=J3gPLHAKgJv93n6S54VrC4MOWQNYdWkye7pdlJD8lGzETmnCREZxTVM4plelKtEkA1 swMegPaXIsYTgbrxK5xhhG8ONHd/WuCJ8RMjZpKQpzEZ3EB5KqoHxYXwqqvdbT5abB1D 4dmxuQcUmVFovfNWdMmNZwrz7AJjrRIOLVAQYkLE7YU2NOBXf9Q0yg2FMXe0LM2UPtSl jIPLzFTBLF+T9rYCbPKYxaHlOUmpgpkLYQG699H3HjZznsmo3DddvNvJmvJu8cBT2U6D UqUa3FMYxhPHRLCXBc4zv+nHiFdq0RZmQAQHfOfoKaqg3Fo/9Cgsu/MBdUXa78TzpZKy AHOw== X-Gm-Message-State: AODbwcAxeoeNSO1Bxs4GQa9eDrLn51VvjcwbYaVe+8ohNQwGcLhst8wo C2yohuwfoiqHQPG2 X-Received: by 10.84.231.1 with SMTP id f1mr6569593plk.258.1496523367450; Sat, 03 Jun 2017 13:56:07 -0700 (PDT) Received: from [192.168.178.21] (96.23.255.123.dynamic.snap.net.nz. [123.255.23.96]) by smtp.gmail.com with ESMTPSA id g10sm40986551pgr.18.2017.06.03.13.56.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 13:56:06 -0700 (PDT) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <74616764-EF03-4AD3-BC59-B579B9FD2001@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 4 Jun 2017 08:56:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 20:56:10 -0000 On 04/06/2017 01:15, Carsten Bormann wrote: > On Jun 3, 2017, at 12:45, Simon Hobson wrote: >> >> unlearning and relearning >=20 > Reminds me of the story where a kid learns how to roast a duck and the = mother explains that to roast a duck, you have to cut off a bit at the en= ds before roasting. Kid asked ma why, and she didn=E2=80=99t know; her g= randma had always told her so. Long story compressed, it turned out gran= d-grandma had an oven that was too short for a whole duck, and the cuttin= g routine survived through the family even though today=E2=80=99s ovens a= re larger. >=20 > But the whole discussion here is backwards, because we stopped cutting = our ducks a long time ago. > Changing the established IPv6 operational practices so they look more l= ike duck-cutting for IPv4 doesn=E2=80=99t make sense. Indeed not. But we might well want to change IPv6 operational practices t= o meet future requirements, and having a magic boundary prevents that. Ha= ving a parameter n that can be modified at some point in the future gives= us a more flexible duck. BTW exactly the same story was in the NZ Herald newspaper a few days ago,= but the victim was a leg of lamb. Brian From nobody Sat Jun 3 14:13:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F727127BA3 for ; Sat, 3 Jun 2017 14:13:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hltJoLE8pju for ; Sat, 3 Jun 2017 14:13:00 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E374E127775 for ; Sat, 3 Jun 2017 14:12:59 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 9so66149201pfj.1 for ; Sat, 03 Jun 2017 14:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+qDbFiHj71bkkcpHV9t0scGi26lTaGyfsGsSQ0FCo4Y=; b=uOrk4HM4xdcVsEm3wf0e51d1qLAS96U0szWKm1r1XyfQRjCc1x2rAwkz1Yniy40kE/ u/nK0lGLwrwr6gUcIQCKLYljJNgc+Za28/uKHPDL5c+46x1+bSPzNnfDTjlbvr7Wcdg4 3Wj/kvVWk34EYE4qwSLEb6lVfROewWmZ0jaXvysNdk1Jg1oakWBg+Kh6SCMN5lKdw0PT mAGkJNQNHbWNNm75oN1uubCyjFPEn6N24lHGgwIp1ZwY/j2QRwxOnt2lqTAhVWDFSMli TLcc+iV+2PFYf+9VqyTpT/FXbZTnDsnNwtIMY2GNK2GhT79wV1EAhW2YUOfnI/cX2uSD jv/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+qDbFiHj71bkkcpHV9t0scGi26lTaGyfsGsSQ0FCo4Y=; b=rwztyb7oyhgL0G3sJcaEsAY58NwjM+go+QTTfNRjkPDFMmuS2MzhDXcmOsZZg/t6j1 fMaDY/JXJhbYu/xzuicrQNJTf6U5C8BXhcm41zcMzSH80dmOJvtru1xNJbOrNLV1taX0 z//9RKbjaxI/MeLeTI9NzKZGf9t6Ga3n1Wqx4aqbl9ttkYdp8brEsz7XHGefPI7dDPGX zNdpn2/iNy4pHeQvUTlhDb5fT8YL/3AjX/YE+mJE7vwm+wL4BUEkNlCIwmmGfKQxItLv Pt0gud/lNAJ01/bqjvdhE2eLTG3PgHvlJpdreOlid/wTwztomqYB3iPtSMmL9CDC4QxK mvqA== X-Gm-Message-State: AODbwcAkPEmdQRn7Q3WoZXOXqR/FA/rdq84oR4HRwsdzYvHeh75+KN/N JFrV7qDftrDVPQv1 X-Received: by 10.98.218.25 with SMTP id c25mr5957461pfh.118.1496524379369; Sat, 03 Jun 2017 14:12:59 -0700 (PDT) Received: from [192.168.178.21] (96.23.255.123.dynamic.snap.net.nz. [123.255.23.96]) by smtp.gmail.com with ESMTPSA id q135sm62012563pgq.41.2017.06.03.14.12.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 14:12:58 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?Q?Roger_J=c3=b8rgensen?= , 6man References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: Brian E Carpenter Organization: University of Auckland Message-ID: <68b68b48-dcdd-baef-53b0-c68bf0965ce7@gmail.com> Date: Sun, 4 Jun 2017 09:12:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 21:13:01 -0000 On 04/06/2017 05:32, Roger J=C3=B8rgensen wrote: > On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders wrote: > >> Abstract: >> Over the history of IPv6, various classful address models have been= >> proposed, none of which has withstood the test of time. The last >> remnant of IPv6 classful addressing is a rigid network interface >> identifier boundary at /64. This document removes the fixed positi= on >> of that boundary for interface addressing. >=20 > what I find odd is that we over and over again are morphing IPv6 into I= Pv4 > with just more IP adresses...=20 That simply isn't true. The draft doesn't abolish the concept of 'interfa= ce identifier', which doesn't exist in IPv4. It doesn't attack SLAAC. It doesn't attack ILNP or draft-herbert-nvo3-ila. It doesn't attack the choi= ce of /64 for all IPv6-over-foos to date. It does say two things. 1. BCP198 2. n in the addressing architecture is a parameter. Brian From nobody Sat Jun 3 14:55:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8F0127869 for ; Sat, 3 Jun 2017 14:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk94Z3JJy6fh for ; Sat, 3 Jun 2017 14:55:22 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 E9565127BA3 for ; Sat, 3 Jun 2017 14:55:21 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 7D5966C0 for ; Sat, 3 Jun 2017 21:55:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzzy8OX77Dxb for ; Sat, 3 Jun 2017 16:55:21 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 47D45668 for ; Sat, 3 Jun 2017 16:55:21 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id i62so443920vke.4 for ; Sat, 03 Jun 2017 14:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ji/9i4iLjNqFUSpQzAZ2hvcbXpC2Kt7OBZ4ra1Kt9hA=; b=J1EwQHgqYI3WzEvgjcqzbtZFH9PBplA2kUyvsGNCfqSUkNrEu3z6lfFogNTLGjthe+ vv5aork88de2NF9sDGRS5zNbP4jiQ4u3qGdm/c1dYW3eYPi47zfLtC4cYJEBGB9HEhxQ llNR3OUGs0GIe41qQ3pc66Mth5ecON2VRr5/P8lbIAAQk9XCSycWyLf2JAmDoHV84ebr FktbQnC+0fdX01tsdxia0b09dqnpv6kBA6MLJENEV1KvwPGsv86pYvcRIZ2pn3qYEUim qb8ynfauPFlUr0lxWOZqWSqYK4flntAYwuxSNiOqUj2a4MJx5XDYxyUHhJV0Td2wW95l E4cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ji/9i4iLjNqFUSpQzAZ2hvcbXpC2Kt7OBZ4ra1Kt9hA=; b=RIeUxIPaKN1MReOZDhR6vFk8vCrLKOG4pebkUTk2foR1/BYx5xswyvOChJayRK78Sh yZ1tOhImrYnAr23GMKw9DujFlzRac/iVgoONFh/BX8A8Kd8qJ9YZnKDihnX1ULE4BgHx +IL35ARCPZ2kJAsShk7YYRvGAHiZMyV4IhZXU0slmwpHMR+MlywsgQtZXlaAJ1BmP7PU fpVVY3xa5GWc+90ZNSaXJ2V9xxibcNi6G5ytBsrxjPb/+YpPQK2Jt6SfoSs2WuSr5u2h +dBWBCiSF/9UoxJcR8spK+qR9Zql3hSp0tdgL1JTbNEUCRPhE+3madIcUYYpG+UDybxq 9uXQ== X-Gm-Message-State: AODbwcAtYII/COOJhwjhY1gby1xzP0fj72N4wiAgyKvDAzXxNBwlxoNr hwREH8StbTgCDDE45RqwxCcl1v0gjCtMlg7yhk9DRpMWuTYWWH5NvrK5nJmUvyM3kkJfNV08rdQ AyyjpZMZiIMy5LyE= X-Received: by 10.31.99.67 with SMTP id x64mr6543647vkb.24.1496526920244; Sat, 03 Jun 2017 14:55:20 -0700 (PDT) X-Received: by 10.31.99.67 with SMTP id x64mr6543643vkb.24.1496526920060; Sat, 03 Jun 2017 14:55:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.137 with HTTP; Sat, 3 Jun 2017 14:55:19 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: David Farmer Date: Sat, 3 Jun 2017 16:55:19 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Cc: Job Snijders , 6man Content-Type: multipart/alternative; boundary="94eb2c07b11877a17e05511553fd" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 21:55:24 -0000 --94eb2c07b11877a17e05511553fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 3, 2017 at 12:32 PM, Roger J=C3=B8rgensen wr= ote: > > > Things like this ONLY hurt IPv6, yet again IETF can't agree on IPv6 so wh= y > should we bother using it? But I guess the none technical side are a lost > case for most IETF'ers. Not to mention that we remove one of the thing > so many I've spoken to over the years think is great - the standard LAN > size. No more discussion on that. > Personally, I'm fine with a standard LAN subnet size, but that's not what RFC4291 says, it says /64 is magic and all subnets are /64 regardless. However, not every network in the world is a LAN. Just because we use ethernet framing everywhere doesn't make every network a LAN either. We have added /127 with RFC6164 for point-to-point, but if you use a /30 for IPv4 point-to-points, then a /126 makes more sense for your IPv6 point-to-points. Anyway, changing to "/64 is the RECOMMENDED subnet size" is still provides a standardized LAN size. It just recognizes that not everything is a LAN. More generally, I understand the desire to break with the old conventions from IPv4, and eventually we have to. However, right now we are in a transition state where we have to support both IPv4 and IPv6, and to much divergence in the operational models between IPv4 and IPv6 just creates issues. Yes this costs money and the bean counters don't like that, but even more importantly it reduces reliability and lowers the quality of the user experience. This is what you call a lose-lose situation. And talk about hurting IPv6, if deploying it reduces reliability and and lowers the quality of the user experience for a network, that's what will hurt IPv6. Finally, saying all LANs are /64 only works if providers had out prefixes to customers that are larger than /64. In my experience that's not happening, if you know how to fix that please speak up! Otherwise, we better figure out have to split a /64 across multiple local subnets, because its very difficult for lay people to understand why 18 quintillion addresses isn't enough for their house, no matter how many networks they have in their house. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --94eb2c07b11877a17e05511553fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 3, 2017 at 12:32 PM, Roger J=C3=B8rgensen <rogerj@gmail.com= > wrote:

Things like this ONLY hurt IPv6, yet again IETF can't agree on IPv6 so = why
should we bother using it? But I guess the none technical side are a lost case for most IETF'ers. Not to mention that we remove one of the thing<= br> so many I've spoken to over the years think is great - the standard LAN=
size. No more discussion on that.

Perso= nally, I'm fine with a standard LAN subnet size, but that's not wha= t RFC4291 says, it says /64 is magic and all subnets are /64 regardless. Ho= wever, not every network in the world is a LAN. Just because we use etherne= t framing everywhere doesn't make every network a LAN either. We have a= dded /127 with RFC6164 for point-to-point, but if you use a /30 for IPv4 po= int-to-points, then a /126 makes more sense for your IPv6 point-to-points.= =C2=A0

Anyway, changing to "/64 is the RECOMM= ENDED subnet size" is still provides a standardized LAN size. It just = recognizes that not everything is a LAN.=C2=A0

Mor= e generally, I understand the desire to break with the old conventions from= IPv4, and eventually we have to. However, right now we are in a transition= state where we have to support both IPv4 and IPv6, and to much divergence = in the operational models between IPv4 and IPv6 just creates issues.=C2=A0 = Yes this costs money and the bean counters don't like that, but even mo= re importantly it reduces reliability and lowers the quality of the user ex= perience.=C2=A0 This is what you call a lose-lose situation.
=
And talk about hurting IPv6, if deploying it reduces reliabi= lity and and lowers the quality of the user experience for a network, that&= #39;s what will hurt IPv6.=C2=A0

Finally, saying a= ll LANs are /64 only works if providers had out prefixes to customers that = are larger than /64. In my experience that's not happening, if you know= how to fix that please speak up!=C2=A0 Otherwise, we better figure out hav= e to split a /64 across multiple local subnets, because its very difficult = for lay people to understand why 18 quintillion=C2=A0addresses isn't en= ough for their house, no matter how many networks they have in their house.=

Thanks.
=C2=A0

=

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Email:fa= rmer@umn.edu
Networking & Telecommunication Services
Office o= f Information Technology
University of Minnesota=C2=A0=C2=A0
2218 Un= iversity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c07b11877a17e05511553fd-- From nobody Sat Jun 3 17:05:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6B129B8C for ; Sat, 3 Jun 2017 17:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytmYbZraNmJU for ; Sat, 3 Jun 2017 17:05:03 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D263129AC7 for ; Sat, 3 Jun 2017 17:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v54052N7016294; Sat, 3 Jun 2017 17:05:02 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v54050vI016174 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 3 Jun 2017 17:05:01 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 3 Jun 2017 17:04:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sat, 3 Jun 2017 17:04:59 -0700 From: "Manfredi, Albert E" To: Fernando Gont , Mark Andrews , "Brian Haberman" CC: "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfCAAH/0AP//opYAgAB9xoD//492sAAAViDQAA8M3ID//9RyhoAAhuaA//7/rUA= Date: Sun, 4 Jun 2017 00:04:59 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> In-Reply-To: <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 00:05:04 -0000 From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont >> The ISP's router has a single /48 that points to the phone. > > At which point we probably should start thinking about ipng-bis :-). > That's 16-bits away from IPv4, which has (or used to) /32 pointing > to hosts. Exactly. Assuming the IETF can even cause ISPs to hand out /48s, which it cannot, th= e other side of that coin is that now the address space increase becomes ra= ther ho-hum. An extra 16 bits, effectively, is only an increase of 4 1/2 or= ders of magnitude. Which, considering how far we have already gotten beyond= un-NATed IPv4, and considering the number of addition gizmos are to connec= t to the Internet in the not so distant future, is just nothing to write ho= me about. Bert From nobody Sat Jun 3 18:21:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5910C129483 for ; Sat, 3 Jun 2017 18:21:24 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er2lbnBClDrY for ; Sat, 3 Jun 2017 18:21:23 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 4B51E127F0E for ; Sat, 3 Jun 2017 18:21:23 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id x47so61447178uab.0 for ; Sat, 03 Jun 2017 18:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mgtSFeh06PAORQPh5Uut1ALSmgieuJQnbi/qtVpEkVk=; b=V7kKpExhA38noe4IBGuMXQY7eQYXuQc6LMsLRgmSBE9bzOCp43aznksWcVTWtfa5sd 2+7Gw4v077uyfIeYAzuil3G4e57H0uSDFnKF6BxVIqtZ1De98xTEabgQTex0FgRKDXi/ oYUTJLalsmaRFMjIAxZdo7RzlIqXPxoep4psOr8eQ7YB+IYVljY4y7NvyyPA4wlkPtud pe9XEfINX7YqtgKi+FlfVjvJbJ3JOhrPp9nXvs7kc0RsoNW5IZwc65/vzbaycfWHLNCk 1s5ItTE0aQh4cuqYR2/0eOhmJiyWJ0xmkBSaO+TpDgoxAdF60mLZAPjM0zEJAflLyYp8 iHNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mgtSFeh06PAORQPh5Uut1ALSmgieuJQnbi/qtVpEkVk=; b=A0eRcVXMijVfKO3VV3twAREbndxYL3j5HH+4hRrfxZRE6tugkIr/9fdJc5EY/A2LcC W9qbAxb3aGT2lCfh+t7fXqn+KDwi8eGBa18gmJQ+L5uILAmeucEUPROPZ+PWYuZF8U8r iZoea8VIZrbqnWKsbpSi85RMcxn2eyUguKEdXC0y9NColwTjO/kgYLd+hcDjpYw/5Gqp UNRDpIRRWNRE+80wc5I/UtmBWAQ9x/DU4Zcby+3gNXUVZ9sGk/xGN4xYHxwv8SpK79+b l2M3Rv6Dl5bN1jAzgu8W1EY0u7Z+5oh4qSknTEmXCyYBOFhSQPDlkMNZjRW/Sx0yvk2X C9Bg== X-Gm-Message-State: AODbwcAipzm6j+g16W/z5RCFRDq5n/LdwtWpXlMEVF8xPMABgnKT7ToF d1PR+KwmR5zp2IjCxiJwf+qgwN5d+DdpxyY= X-Received: by 10.159.52.214 with SMTP id b22mr7489859uac.93.1496539282290; Sat, 03 Jun 2017 18:21:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sat, 3 Jun 2017 18:21:00 -0700 (PDT) In-Reply-To: <723E4B25-B932-412D-8369-448703DAA21A@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <723E4B25-B932-412D-8369-448703DAA21A@thehobsons.co.uk> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 10:21:00 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Simon Hobson Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403045e79765099630551183452" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 01:21:24 -0000 --f403045e79765099630551183452 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 3, 2017 at 7:15 PM, Simon Hobson wrote: > BUT, I cannot see the logic behind your earlier comment that DHCP makes > NAT inevitable for IPv6. > The answers are in RFC 7934, --f403045e79765099630551183452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jun 3, 2017 at 7:15 PM, Simon Hobson <linux@thehobsons.co.uk&= gt; wrote:
BUT, I cannot see the l= ogic behind your earlier comment that DHCP makes NAT inevitable for IPv6.

The answers are in RFC 7934,=C2=A0
=
--f403045e79765099630551183452-- From nobody Sat Jun 3 18:29:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6938C12871F for ; Sat, 3 Jun 2017 18:29:00 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9eRLo9TzyJ3 for ; Sat, 3 Jun 2017 18:28:59 -0700 (PDT) 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 5E38912941C for ; Sat, 3 Jun 2017 18:28:59 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id p62so19047045vkp.0 for ; Sat, 03 Jun 2017 18:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y1LYiXxU0pyPnObkrTJmTXyEvuUFy0izEAVBZB1Ia98=; b=CDkqJi7IDGF+MXLW61O27DWaIRFR1NsrBj663S6LtGF3s9mTlASC2jcJy7NuMlNbM2 dT8G6riHkE5us73QMoeAjHJiYg8s4CJJ+72QbQSF+Bm+Uy62uVbYaUfgwnQCijqe2AD+ 2adghUmRnDKrn3FNU4QOLwqyMw9BhjGsRtiljYSfp3+H/WlGIrvB1qcFt5fP66OKur4u tGxx/MTsq4jUi9p9MucM7jyxuZ0qdNIndaUEZLOIsj/k/3uQX6AbC4xsnP7kVc0vaf0d ptYa6APVi1/4F01ld+Q5WaBUlrCsMc3lnBQwfIo0tIrCDwlKUflXSN2BPZhFmYmHMQeI oq7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y1LYiXxU0pyPnObkrTJmTXyEvuUFy0izEAVBZB1Ia98=; b=BZad+cZQI9Gzb2tYxvXXJ95K+KHcllnZuTFnI9E533rjrhPm8VPild2xdHUbiOda71 aD9rkj1TD/4Resc+XOFwGzF4W+A9aDmxmKb7R1z94eLD966MA9IGa05vtGkK45Kzz9D7 mqvuozgfmcCBXEEXL9064sHNab9H79Cy7mNNUgNtjIhQkPWQCFUeAMwUXeECMA3SA8Pf Nc22rH6VZrD8g59iM58x1lWuWumZwUId+EMn6o8nfH6izNhEc4aoylKQYpkrr5yKBIvB Nh7eUkz2zX7GHaVgLbp5/ZDhzvkdst1BGBJvG7IC8SGKf3uJCcnWzb6nZTVuYnp2DPfb c41g== X-Gm-Message-State: AODbwcCLSuVAXD+mPPJH6NLqQdCBs8RJ1LFa9CGtsKVHhz4/TBNB7x+t AXIuNiOlmaA+5wDlbvToQVg96ztH/lUz X-Received: by 10.31.170.2 with SMTP id t2mr7061509vke.100.1496539738183; Sat, 03 Jun 2017 18:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sat, 3 Jun 2017 18:28:37 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 10:28:37 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Tom Herbert Cc: Mark Andrews , IETF IPv6 Mailing List , Brian Haberman , Fernando Gont Content-Type: multipart/alternative; boundary="001a11430a727d22fe0551184fcc" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 01:29:00 -0000 --001a11430a727d22fe0551184fcc Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 12:49 AM, Tom Herbert wrote: > RFC7934 presents the arguments why hosts need multiple addresses, not > why hosts need 2^64 addresses. For RFC7421 the arguments seem to be > around operational simplicity. These don't answer my specific > question: Why does a low end device, like a phone, _need_ the > equivalent of four billion IPv4 address spaces assigned to it? Read the document again? The goal is not /64. The goal is that no general purpose host should ever be constrained in the number of IPv6 addresses that it gets. That means it should be able to form new addresses without asking the network, or it should get enough from the network that it never needs to asks again. Currently the only ways to do that are SLAAC, which operates on 64-bit prefix lengths, or DHCPv6 PD of a /64 or shorter, which allows other devices behind the host to run SLAAC. --001a11430a727d22fe0551184fcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 12:49 AM, Tom Herbert <tom@herbertland.com> wrote:
RFC7934 presents the argumen= ts why hosts need multiple addresses, not
why hosts need 2^64 addresses. For RFC7421 the arguments seem to be
around operational simplicity. These don't answer my specific
question: Why does a low end device, like a phone, _need_ the
equivalent of four billion IPv4 address spaces assigned to it?
=

Read the document again? The goal is not /64. The goal = is that no general purpose host should ever be constrained in the number of= IPv6 addresses that it gets. That means it should be able to form new addr= esses without asking the network, or it should get enough from the network = that it never needs to asks again. Currently the only ways to do that are S= LAAC, which operates on 64-bit prefix lengths, or DHCPv6 PD of a /64 or sho= rter, which allows other devices behind the host to run SLAAC.
<= /div>
--001a11430a727d22fe0551184fcc-- From nobody Sat Jun 3 18:34:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A3F1288B8 for ; Sat, 3 Jun 2017 18:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FS9qloHhNDm for ; Sat, 3 Jun 2017 18:34:17 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 0CBEB12871F for ; Sat, 3 Jun 2017 18:34:17 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id y4so61400089uay.2 for ; Sat, 03 Jun 2017 18:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jcFGGyBvSJfBXGOUWof+fI3ca8EiAire5UBzvC//gVI=; b=FPtRSBogWnKZRLzybNnDawGJf0LXc3dynKhHqXGdcwVTRJa7ap3RNKwe5rVdT+SmH0 xWZI8B8SO1J5pb/dOaJKXrDU8h1q8h9EWjkNFwRl6cMNIgP8rysgkGa0pAszRoVNqxX9 9IVZZR2RssK+YswZG1zUDzsGcyt1TwnrskBvYeJT9ORaB1di2vCy7MGDIWoLXfhlZbBl LHtrVYRkQc1QLC3gMKlmm1uqKJ8uNtyUjJqPqedsNzRc/tOCXiFnmuukZ0y7N/pc2q0x Xnnt1QVrGSo8+S8XA0OQrWPcNw87Annea2bMgYXia8SlTN069pBYOQH78bNcsqdwTnni GSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jcFGGyBvSJfBXGOUWof+fI3ca8EiAire5UBzvC//gVI=; b=DbMnEI6YEfOrbm5O6XEcEWt4HB/sMoaZ8XOcIinITY2vgZXt2jPdUinc4nW/CT4s47 BL8kXY5YEKLqki+BDqBm+azX4aAR0iZ+b4ePovLu8MSwgUY6l3RfG3nf9i36M50khMSY Te2AlbsdkDk35MJV0VXCmXCQb48D8Hr3onZW3EpVs14r33L/Tpmmb2TYp/SBC8t5IY0I YIRKH6jBynZrb+ZrHk562Qf+1YL+KqRREtdn4XDSoS7GpE5C3ky2+vFd/VAj89u58j2j lu6PUc7t9yRqJxi7U9tFcsFiBpv41JiXYKbJ0gE0JeYKY1na9tQ6k08MoPXFlUbrkHqs n3YQ== X-Gm-Message-State: AODbwcA4JbrGymuP0RNxPnY8CN32CfeIdpjYWomtjJxYZZYHkUZDm9jK zTqWpHkF2xHiJqh61t5kXte9KmqCu5ON X-Received: by 10.176.83.16 with SMTP id x16mr8051401uax.11.1496540056070; Sat, 03 Jun 2017 18:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sat, 3 Jun 2017 18:33:55 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 10:33:55 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c18f1ac6faa18055118625f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 01:34:18 -0000 --94eb2c18f1ac6faa18055118625f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 4, 2017 at 2:34 AM, Roger J=C3=B8rgensen wro= te: > > Please stop trying to make IPv6 be the same as IPv4. That will take awa= y > our > > ability to make the Internet better once IPv4 is gone. > > oh totaly agree, but it's already lost, the "operators" don't want to > move/change. But they *are* changing. For example: almost 20% of Google users these days come in over IPv6. Pretty much all of them are connected to networks that support SLAAC and use /64 prefixes. That's a huge number now matter how you look at it, and it's showing no signs of slowing down. --94eb2c18f1ac6faa18055118625f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 2:34 AM, Roger J=C3=B8rgensen <rogerj@gmail.com><= /span> wrote:
> Pleas= e stop trying to make IPv6 be the same as IPv4. That will take away our
> ability to make the Internet better once IPv4 is gone.

oh totaly agree, but it's already lost, the "operators"= ; don't want to
move/change.

But they *are* changing. For e= xample: almost 20% of Google users these days come in over IPv6. Pretty muc= h all of them are connected to networks that support SLAAC and use /64 pref= ixes. That's a huge number now matter how you look at it, and it's = showing no signs of slowing down.
--94eb2c18f1ac6faa18055118625f-- From nobody Sat Jun 3 18:35:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC63129553 for ; Sat, 3 Jun 2017 18:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmNdrEahX6dT for ; Sat, 3 Jun 2017 18:35:46 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C5412871F for ; Sat, 3 Jun 2017 18:35:46 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id w1so54133592vkd.2 for ; Sat, 03 Jun 2017 18:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VRtlRg6VSKBGD/JNo5f0d+1iKPgEPej3DgbUhUWetts=; b=Y4RU4GUjR4f2kNNnRmPiSdXyZ5FDXgFtxegRnQkO4+ViTl2PiDUuAWBwX/ZC4UGft/ 5atZIf2cbk+gpJVdbH371it/NAm2VaPTXIxyqTrQyGBvSgj0sUrqXqAwCtPPrmdOQ27G DC3Mfc3ZYDzVJbvVDTeemNI3/yNirrkYfxhhsIh/nZM79DBT9DzPhbbVC8gAmWKLzdYq tFd/BIIX8AkYh6Wxu9bVcsKEqOGHugXel1MlPyy5kQ5kLsq5rmXOqleyvoJpB54W0CfA rTaMk+2iDH+cxLdClCi7X1dW2nz6XBIdaVTMbHyj6KlzWXnFr20tH1qh0mERwKa+db+a 4bvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VRtlRg6VSKBGD/JNo5f0d+1iKPgEPej3DgbUhUWetts=; b=GkaXAxFK4rVk0QoGu1UolScdumqjtrjlM/D+UOZP8Ww418wEmvU8QJmJmgPSIaBPzM Zl2mqxComp+LPQDCded3UVnmO/BDrQ29cgzgMDhdrm6rsYgnpnfNgSC/4BS1l0i7O9/9 PeKtryoN0KSrL0JdQvq6oOH0OcTscUz6iaDalctnPnB4NMxKY0s7kZHLS61dyDL/XtNL CMYX5rIg0mVO4sD6Yb19PXddmWKDiBXOyqclhlvFKNx5aj9KcuRa959pcHfZC/4aBA/S srx14jJReUMzygNuOzVyTI4EECrCYI5H2BFPOQxI+j+Xl5I0C4q5fLrmh9otqeqaZk5m dg3Q== X-Gm-Message-State: AODbwcCXhWMsIWX8s4uQ6Bo5+uqXLfRlNlbCCqdnQscwJnxb4HzJYtwv tTg8zrw1kuO3qAIEAU+BxeVTHXQo/Qf7Bk0= X-Received: by 10.31.33.81 with SMTP id h78mr1115133vkh.29.1496540145680; Sat, 03 Jun 2017 18:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sat, 3 Jun 2017 18:35:24 -0700 (PDT) In-Reply-To: <5932DA16.9040008@foobar.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 10:35:24 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Nick Hilliard Cc: Tom Herbert , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a11c024cac6f9110551186750" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 01:35:48 -0000 --001a11c024cac6f9110551186750 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 12:47 AM, Nick Hilliard wrote: > let's say your device is assigned a /64, e.g. either on a mobile network > or via PD. Your device sits between upstream and downstream devices and > passes traffic between upstream and downstream. > No, Tom wants to assign a device a /96 or a /104. He wants the network to use the middle bits for mobility. --001a11c024cac6f9110551186750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 12:47 AM, Nick Hilliard <nick@foobar.org> w= rote:
let's say your device is assign= ed a /64, e.g. either on a mobile network
or via PD.=C2=A0 Your device sits between upstream and downstream devices a= nd
passes traffic between upstream and downstream.

No, Tom wants to assign a device a /96 or a /104. He wants the net= work to use the middle bits for mobility.
--001a11c024cac6f9110551186750-- From nobody Sat Jun 3 20:51:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA491294B8; Sat, 3 Jun 2017 20:51:28 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gId7hSDYsHyz; Sat, 3 Jun 2017 20:51:26 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 4DD55129482; Sat, 3 Jun 2017 20:51:26 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id h39so7246520uaa.3; Sat, 03 Jun 2017 20:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3+JceK5EaXLcVC+LzGZAV8OWGwzjglus8V60iYAlRxM=; b=ns/SxZvFj2YxnQYMddna+vH+WjpZZHr3/gh7rq5rszlqnzEdSCsSwsi4FWTHZ7FrEz 0roVnftR2taMKn8SskzTpwUwJYvSbQjeRfs7i+SIt6olpLBn3psLlMdqWohiaTUofhz+ u6MOE7k96ML9ipw59mm4fuHdQzhTxwpd1g8av4dNvmxk5b1sc3NYgkHmgjc8xYlPNhUG NBSDcTJgmfGOlK29yyaj9aMxPF3hqXrCrsXrX+D+V3hO0VTJIXngvIK++xrHSqq1Dc8T I3eVSjtejT62Qi5X1urVC7YylXw/eBS70yDulsfLy+iQxeelCcBGq66Nh2FfJwOPKjCW sENg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3+JceK5EaXLcVC+LzGZAV8OWGwzjglus8V60iYAlRxM=; b=Xo4rjn7pw3LtBpwYUvMJob+AEopAJOh+hkwHRS3w4BegHOzvkVAH4VJus5Kzh3nqzc ghQsQWS2nhUxbTCqIFma5vNsVnfwTy9XQqJTZ6z90u43BioZZNqFDg/ch6jLbX6r4sMD oJRD1DpgVbsVaFV/G6BxNg1S/KWsioZT0eNru6ZO6tKxmcAwMB7FDh6GHbsJPxZzvCUK gaU6z+GDcc/jqyEhVjopFUSDtVkfdC01jTh5reoFXWO4JjU+cg+7tvMInfXzq7W8sAl7 4xqRxu1/8KkLTscx57fVtOQXxQo2AIQIhARtRcUIycAgqh0Wwm/bBh1aFobL68DGk33Q aa6w== X-Gm-Message-State: AODbwcBkv6yZNiJGjGQ0ezwYybibi7od8bDQLFhgzJsBAIRoPjPNYoC5 U15PxXPHDOX6UI2yEfrAhcDXD07Wwg== X-Received: by 10.176.27.84 with SMTP id n20mr8029510uai.125.1496548285306; Sat, 03 Jun 2017 20:51:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Sat, 3 Jun 2017 20:50:54 -0700 (PDT) In-Reply-To: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Mark Smith Date: Sun, 4 Jun 2017 13:50:54 +1000 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Brian E Carpenter Cc: 6man , draft-bourbaki-6man-classless-ipv6@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 03:51:28 -0000 Hi Brian, On 4 June 2017 at 06:43, Brian E Carpenter wrote: > On 03/06/2017 15:23, Mark Smith wrote: > ... >> If this proposal is accepted, then I think /120s will become the >> defacto subnet size, despite what the draft says about /64s being the >> recommended default. > > Predicting the future of complex systems is hard, but I think this > prediction is wrong. Thinking about it more, I'll lessen that - I think this draft increases the likelihood of it occurring. If you know IPv4, and you don't want to or don't have time to properly learn IPv6 (which seems to be one of the motivations for this draft), then here is the easiest way to deploy IPv6 without understanding IPv6: 1. Take your IPv4 address in IPv4 format, leveraging your existing IPv4 addressing plan 2. Prepend it with the IPv6 GUA or ULA 96 bit prefix 3. Subtract the IPv4 host bits from 128 and append e.g., the resulting IPv6 addresses for 1.2.3.4/24 would be 2001:db8::1.2.3.4/120 That format address is accepted on loopback when I use the Linux 'ip' and 'ifconfig' utilities and I can ping it, so it has passed the first "can I even configure it" test. If it works on other IPv6 implementations, this way of deploying IPv6 while avoiding learning IPv6 could easily become popular because of its simplicity. > There are some very strong arguments against > prefixes that long, and it is the IPv6-over-foo specs that prevent > such long prefixes being used. > I agree, however I don't think this draft is discussing and emphasising them enough. For example, here is how I interpret a piece of the text in the Recommendations section (which is going to be the section people in a hurry will jump to) "For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136]." "For historical reasons" implies the only reason to continue with /64s is tradition, as though the situation has changed so much such that all of the past reasons for having /64s/64 bit IIDs now don't apply. "barring other considerations" That might seem to be the warning to make sure you understand the decision you're making, however there is no brief description or reference to those considerations. Initially I thought RFC7136 was the "why-64" RFC you and others put together, which does outline those sorts of considerations in a 64 bit IID context, however that is RFC7421. RFC7421 isn't referenced by this proposal anywhere, yet it is the key document that describes many things about 64 bit IIDs and their benefits as well as mentioning some of their drawbacks. The next paragraph text is further narrowing the scope of advice to just SLAAC. What about address assignment via stateful DHCPv6? Do general privacy and security concerns about IPv6 addresses go away entirely if stateful DHCPv6 is used? (Actually, stateful DHCPv6 can introduce them - OpenWRT supports it and uses the same sized IID range for DHCPv6 as it does for DHCPv4 addresses. Until I recently worked out how to turn it off (because that isn't obvious either), my Fedora hosts with wonderful RFC4941 and EUi-64 global addresses via SLAAC also had global IPv6 stateful DHCPv6 addresses from within a range of 100 addresses.) Another example is in the Security Considerations section: "Assuming that nodes employ unpredictable interface identifiers [RFC7721], the subnet size may have an impact on some security and privacy properties of a network. Namely, the smaller the subnet size, the more feasible it becomes to perform IPv6 address scans [RFC7707] [RFC7721]. For some specific subnets, such as point to point links, this may be less of an issue." This paragraph leads with a broad statement about security and privacy concerns, of which there are more than one as detailed in RFC7421, and then dismisses them all ("Namely,") to only describe the one threat of unsolicited inbound address probes. What about host or end-user security and privacy impacts when RFC4941 temporary address and RFC7217 stable opaque addresses operate with much smaller IIDs, or a caution against using IIDs smaller than e.g., 48 bits if end-users are to have RFC4941 addresses? These issues now need to be addressed because of they're all based on assumption of 64 bit IIDs. I think I can summarise the situation, and this draft and my view on it: - RFC4291, although not using RFC2119 capitalised words, is saying that IIDs MUST be 64 bits other than addresses that start with 000. Some people are objecting to the MUST. - This draft is commonly leading with text that reads or can easily be interpreted that this 64 bit MUST is being turned into a MAY on nearly equal terms with any other prefix length e.g., the Recommendations text above. I find further following advice in the text to understand the consequences of doing so is somewhat casual, and doesn't spend much time explaining and doesn't reference what those consequences and considerations are. - I don't think the "default" recommendation is strong enough. I read the default recommendation (in the Recommendations section) here to be saying something close to, "If you've read the text and don't already have chosen size, use a /64", because of use of soft expressions such as "For historical reasons". It reads like the fallback advice if you reach a point where you don't already have a preferred or chosen answer you're happy with (like,"I'll use that simple IPv4 to IPv6 scheme Mark Smith wrote about that saves me properly learning IPv6."). - If the /64 isn't going to be a MUST, I think /64 needs to be a universal SHOULD level and better emphasised at that level because of the code, privacy, security, etc. reasons that are well known and described in RFC7421. The text is currently reading more that its perspective and position is that a /64 is a MAY with some minor cautions due to either casual text or omission. Regards, Mark. > The IPv6 routing architecture has always been CIDRised. Please > remember that "ID" in CIDR stands for "inter-domain". So there > is nothing new there; even BCP198 was nothing new. > > IMNSHO we made a basic mistake by including the value of n in the addressing > architecture. > > That's the n in >> | n bits | 128-n bits | >> +-------------------------------+---------------------------------+ >> | subnet prefix | interface ID | >> +-------------------------------+---------------------------------+ > > All this draft really does is observe that n is a parameter. It could > be said in many fewer words, I suppose. > > If we'd been able to agree on simply removing n=64 from 4291bis, > I wouldn't have put my name on this draft. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jun 3 21:00:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66054129482 for ; Sat, 3 Jun 2017 21:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptEJKRGkBJqS for ; Sat, 3 Jun 2017 21:00:35 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 349BF1292CE for ; Sat, 3 Jun 2017 21:00:35 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id x47so62045015uab.0 for ; Sat, 03 Jun 2017 21:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0KLq7ryVAEUquAKaQ+e9dhyHBzyD06jF2llvI/5FWH8=; b=dQCZwlbSnOEgHLdnQqMCxDF5V1Ra3EGfm5/3GfRYmz4MiWRM6jrG4SyfJ3Np3Y3WN4 diXSLxa2emFH8JDEs315vmcr6cXxCwjIRfX2AK+l1WTlUp67VhTqO/SW14SuhZarerHs QdGvBbAmx7IgloI8nKh9HMI+4N4ELoJWZsIOmPctHU/yL7K3Xh1wdRSDbbqp0RWxeCb1 YktIj1KtbAI+uVgc7INh0CW4QRMmosLoo1zzQ/ra68/TIzNJHvlGe4MFtIBSRAb1SSCL hXvhI7eXqg66tiqMIId1V8FNVn30k6RObk7UcS9KpIUnmLulnTxMky1pOKEsZ0HR0Zes xlgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0KLq7ryVAEUquAKaQ+e9dhyHBzyD06jF2llvI/5FWH8=; b=ru9ibMeKZgdRveF3DT3AZ8x0HWhBQNULsyMG6k3fGHKwA58VtMhxw/x5PCocg/2lSh 2jqAzZDEoP6bGdgyKMVlHqJPwPk3gmc6toFwqC00lMD4lolIwDKgeQNmdteXVEIwIcRo jvjKk+a96nbCCRQi+tCCxCqTW/iHFJHGrT8WDBvOfsivSr9MqN6v3U8f5SIAfemL9pbt uQ15YOHqxBCJQ7tQws1ejwoqeQyNBLVh6dQA1Qi0IJTM6TFuqplPX86m/U7DLKij5g4j 7JsrcnzeFjAmt4ipt2+sAKLhb42XNiGC1+UFHzruit01r/tYnC+LKunvdH88CaA+y6Ug bv9g== X-Gm-Message-State: AODbwcDyxrr6Yw6RZNwRMyfwMSu2XrSGLpFDLEXmw1+HWKqE26JMcKFB 6XA4dPJSEX2welGSKasxCrG35zrntA== X-Received: by 10.159.55.161 with SMTP id q30mr6635575uaq.70.1496548834319; Sat, 03 Jun 2017 21:00:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Sat, 3 Jun 2017 21:00:03 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> From: Mark Smith Date: Sun, 4 Jun 2017 14:00:03 +1000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: =?UTF-8?Q?Roger_J=C3=B8rgensen?= , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 04:00:36 -0000 On 4 June 2017 at 11:33, Lorenzo Colitti wrote: > On Sun, Jun 4, 2017 at 2:34 AM, Roger J=C3=B8rgensen w= rote: >> >> > Please stop trying to make IPv6 be the same as IPv4. That will take aw= ay >> > our >> > ability to make the Internet better once IPv4 is gone. >> >> oh totaly agree, but it's already lost, the "operators" don't want to >> move/change. > > > But they *are* changing. For example: almost 20% of Google users these da= ys > come in over IPv6. Pretty much all of them are connected to networks that > support SLAAC and use /64 prefixes. That's a huge number now matter how y= ou > look at it, and it's showing no signs of slowing down. > I think the mistake people are making is that they're viewing lack of enterprise IPv6 adoption to indicate a lack of any IPv6 adoption. It's an easy mistake to make, I often do it myself. IPv6 isn't solving business problems that most enterprises have, which that is why it isn't being adopted by them. That's ok, technologies aren't adopted by businesses for technologies sake. It is solving the business problem that residential service providers have, which is why they're adopting it so quickly. Specifically, the problem it is solving for them is it is minimising the amount of Carrier Grade NAT capacity they'd have to buy. Some other enterprises are using it, I know it is being used in Advanced Metering Infrastructure (i.e. electricity smart meter networks). Even when an enterprise encounters an IPv6 only website that they need to access, their solution will be to put in an IPv4/IPv6 proxy on the edge of their network, as that is consistent with their private internal addressing / middlebox/security box on the edge of the network model. Regards, Mark. From nobody Sat Jun 3 21:51:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0B0126CBF for ; Sat, 3 Jun 2017 21:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNwz8knvog0H for ; Sat, 3 Jun 2017 21:51:44 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 4373C1200CF for ; Sat, 3 Jun 2017 21:51:44 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id g76so23399872wrd.1 for ; Sat, 03 Jun 2017 21:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lTv+zY/MM6CgCswxcXDZt7wzNNrbwu3pvpnxwjzXlo=; b=zY/qKsaFf0IMMgdfQuoYEnHLPCscA8Hex+LPczUSOhh3CLoZRR74f2RDGiiittGqI7 Iz6D1wihNjMtOl608Al3GSOTmCNrhru1nDc0KwMxo2wEtMdiITbEBmO/1pKia5uFPpMe eTtMPSTYnppbUkZdR7s4dXm0x9RHCzvIqej+9AcWx2XIIohwoVr1SvOEQIpI9UGBOgt3 mS51FZyWbBZkBn7GObNllHQP0s0Di7ZmARHVhthMwwqA1aOQfIX2QeG1XsLzZEr+Z6+n KN79NxabX3Q5yiI/TjSr8PKL+xJ7EbqzxmBUcirg5hdp6KfhNW0QchsoYi0WpyaJsIK/ tCAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0lTv+zY/MM6CgCswxcXDZt7wzNNrbwu3pvpnxwjzXlo=; b=fVsiXG+qjzyQJSYpqn42s/WCXR2QZpSNZ2UMOiEvF34qd+qJTon/nEuqxQ8ajea6Cj nCl2Br3Q+ZlJRaFqQW6V+GfGGsgRTpboWh3c+ha6Nmx8Ix7MUk8jzz22CJvmVRSjCfPX 6Vbc5JAk0UbCw+AxFdE7C24ZDqV48JrF31oVmEzwx2COpRonzJHFVDmHtW1UkyDyMmCz jEeuvxvXhf4jr0r1xAvAso2Y0dgx51O7LHinDVCrvKwF1yCDYqFRsOUZVD/4tjdqcWZ4 TphU2lbnjrTdOhZ+x7XwISJt2ckVWB1HoHVWLSEy61hM99PMv2MnoNqQeR4x+WFhnOUA u19A== X-Gm-Message-State: AODbwcCBKcNJltzR2fRtgvNXdmrYefuhRlIoasbPYNoA8bwCfQ1Ydl06 tf5JTc60KsMz8LvERPgXIIZDdFyt4E6M X-Received: by 10.223.166.196 with SMTP id t62mr8998087wrc.52.1496551902557; Sat, 03 Jun 2017 21:51:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sat, 3 Jun 2017 21:51:41 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> From: Tom Herbert Date: Sat, 3 Jun 2017 21:51:41 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Nick Hilliard , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 04:51:45 -0000 On Sat, Jun 3, 2017 at 6:35 PM, Lorenzo Colitti wrote: > On Sun, Jun 4, 2017 at 12:47 AM, Nick Hilliard wrote: >> >> let's say your device is assigned a /64, e.g. either on a mobile network >> or via PD. Your device sits between upstream and downstream devices and >> passes traffic between upstream and downstream. > > > No, Tom wants to assign a device a /96 or a /104. He wants the network to > use the middle bits for mobility. Lorenzo, That's correct. Consider use case for mobility would be a for a device that is a front end to a network, for example a bus driving down the road has offers WIFI to passengers. To use identifier/locator split addressing (ILA or ILNP) for mobility in this case we need M bits for locator of physical device in mobile network N bits for identifier of physical device 128 - M - N bits for delegated addresses by the physical device I don't see a workable solution if device is assigned a /64. Am I missing something? Tom From nobody Sun Jun 4 00:58:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF41275AB for ; Sun, 4 Jun 2017 00:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j08yHC6h3sre for ; Sun, 4 Jun 2017 00:58:31 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EEA1250B8 for ; Sun, 4 Jun 2017 00:58:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 2740A1BC37 for ; Sun, 4 Jun 2017 07:58:19 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Simon Hobson In-Reply-To: Date: Sat, 3 Jun 2017 19:13:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <715E81C1-6A48-4507-8C50-C94D1D68B842@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 07:58:33 -0000 Tom Herbert wrote: > I'm not going to use my phone as a router into > my enterprise network, I don't see any reason to have it delegate some > complex network hierarchy. We need the ability to tether a small > number of devices, anything more than we are talking about a different > type of device. OK, what about a situation where something that looks like a phone to = the network, but happens to not have much by way of telephony bits built = into it, is being used ? It really doesn't change the discussion that = the box is black, has no display, and is called a router - it's still = doing exactly the same thing as a phone doing tethering for downstream = devices. And at work, we have customers doing just that - connecting an entire = network (OK, not complex network) to the internet either as a temporary = measure until their proper connection gets installed, or in some cases = as a permanent measure as it's not worth getting a fibre circuit = installed for a temporary site (where temporary is typically in the = order of 2-4 years for a civil engineering project). Roger J=F8rgensen wrote: > But I guess the none technical side are a lost case for most IETF'ers. In reality the world is run by non-technical people - often derogatorily = referred to as bean counters. While not applicable here, I firmly = believe that one of the reasons for the slow adoption of IPv6 is it's = perceived complexity (and hence cost) on the part of the bean counters = who ultimately must sign off on any project in a business. > Not to mention that we remove one of the thing so many I've spoken to = over the years think is great - the standard LAN size. I'm inclined to agree there. At first I had to admit that I just couldn't bring myself to think = positively about what seems to be profligate wastage of address space - = having "cut my teeth" with IPv4 addressing. Now I'm getting my head = around it though it's taking some effort to adjust in many ways. As a thought, will there be discussions at some point in the future when = it turns out that some vendors have decided that nothing other than a = /64 exists and so their kit doesn't support (say) a /56 ? From nobody Sun Jun 4 01:27:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213421250B8 for ; Sun, 4 Jun 2017 01:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAKvDr0MyvQm for ; Sun, 4 Jun 2017 01:27:53 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5096124D68 for ; Sun, 4 Jun 2017 01:27:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <20[...] Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id D3BC31BC37 for ; Sun, 4 Jun 2017 08:27:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Simon Hobson In-Reply-To: Date: Sun, 4 Jun 2017 09:27:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 08:27:54 -0000 Lorenzo Colitti wrote: > On Sat, Jun 3, 2017 at 7:15 PM, Simon Hobson = wrote: > BUT, I cannot see the logic behind your earlier comment that DHCP = makes NAT inevitable for IPv6. >=20 > The answers are in RFC 7934,=20 I think you'll need to point them out then Lorenzo Colitti wrote: > That means it should be able to form new addresses without asking the = network, or it should get enough from the network that it never needs to = asks again. Ah, now I see where you are coming from - and I don't agree with you. I don't want to come across as being adversarial here, but one thing I = have noticed from your various posts is that you appear to have a quite = entrenched "SLAAC solves the problems I work with, there shouldn't be = any other solutions even if others have different problems/priorities" = approach to things. So for example, here you are adamant that a device should not have to = "ask the network" for more addresses. What about networks where there = are other priorities, what if the operator of a network requires to = track addresses/address usage for whatever reasons ? The answer to that cannot be "then the network operator is wrong". I can = assure you that there are networks around where devices just turning up = and assigning their own addresses is not allowed, and never will be = allowed (all I'll say is that the military have a different view of the = privacy/security tradeoff). In some cases, there is a LEGAL REQUIREMENT = to track devices in this manner - such as public WiFi operators. I = assume you'll consider that bad and not to be supported, but in the real = world that is the case whether we like it or not. There may be other ways around it involving routers tracking the = MAC-address mappings and so on, but this seems quite a lot more work = than having a centralised management system that deals with admitting = new devices onto the network, assigning addresses to them, and = monitoring their activity. From nobody Sun Jun 4 01:56:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517D1294C8 for ; Sun, 4 Jun 2017 01:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvmo2Jur2Uy4 for ; Sun, 4 Jun 2017 01:56:01 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156FE1294C7 for ; Sun, 4 Jun 2017 01:56:01 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id 4so637450ybl.1 for ; Sun, 04 Jun 2017 01:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cXtzOceEL9aJNfTHlqVoG867rJqXi2a6tIQgb1ymMXI=; b=s1kSQFdtiQkJd4ENPz4tts4x9WH4icstgdss4sdEWOUVBKmCAz0lAWNeDNFstaR+Xi 8mGOfJgtlVczyQzvFSJr0KW0O6EZ6fUvvE9ihQLQmopnk2DTLoFl0nw989bkmFJBvvsO 3PlN5igBwT/EegFbJ+HNoyKCWz+hNiHo0tzQWPmThk49fL30Yi80Pv0Y0a+f0s5UcLI+ GXR//hhSEPlWVF9kbYTo4iYUkn6APfrzVU3vlzWkZsyxLREOgItKdvBpMuIUnD+sQmGz G/aqJ4CDY9Jl3UVTq8sc/6U+elsOjeVde7Ym1VRo0tXXBJYxPEefwx67w9iSpe8fAHwq vU4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cXtzOceEL9aJNfTHlqVoG867rJqXi2a6tIQgb1ymMXI=; b=nSlMMxQVgKPeEBkx+oYOTKyw57ezIcxdJYFx6lBYrs0YHRX7GXZ1iFnutZIGpvwXwq JvRnRwsHaz1ye8z3yAC1JOh/jpZ3A/DfFoxXCFch73lDcAG16Tat5M2SsPhVVeIK8sah 4ijxpdejm6zys2E7pgbWrVRNZ41SZ2/e2GIgqbfeFGnlYEXo20mlWVL3BO3Y+q9hXdx4 EXeV5PIW+8bkSkrHgFIyH9EI2lkWM2qsmbhig9KYGtWLwSSCHOyDEwMx8GM/JKmOHTYz 7lylwVhBFntmDHbJNhZtd0ps5luZXNm6zwYWjxmO1S9fJ8DC9FudkmdlEcmdFtmfoDbq l0tw== X-Gm-Message-State: AODbwcBxGNWo0M3PRhJBdkJCeiLeAp9hK4MicmMsVKARJ1rK9sZ6Iy73 4sVe8/J6egiSSz31qXgsVZoxSYeLOr5Z X-Received: by 10.37.56.17 with SMTP id f17mr5467980yba.130.1496566560301; Sun, 04 Jun 2017 01:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Sun, 4 Jun 2017 01:55:59 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Sun, 4 Jun 2017 10:55:59 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 08:56:03 -0000 On Sun, Jun 4, 2017 at 3:33 AM, Lorenzo Colitti wrote: > On Sun, Jun 4, 2017 at 2:34 AM, Roger J=C3=B8rgensen w= rote: >> >> > Please stop trying to make IPv6 be the same as IPv4. That will take aw= ay >> > our >> > ability to make the Internet better once IPv4 is gone. >> >> oh totaly agree, but it's already lost, the "operators" don't want to >> move/change. > > > But they *are* changing. For example: almost 20% of Google users these da= ys > come in over IPv6. Pretty much all of them are connected to networks that > support SLAAC and use /64 prefixes. That's a huge number now matter how y= ou > look at it, and it's showing no signs of slowing down. look into the numbers, I assume there are one huge group missing there, the enterprises and that's where the money, and damage will be done. If/when this draft goes through I am pretty sure I in 10-15years time will = come across something like this : My device provided by the enterprise will have a /122 and when asking why the security department will say something along the line because there are= X devices allowed on that segment and we provide them all. And since X match with /122 we just configure them static on each device. If I am lucky enough that it's global address space, but most likely it wil= l be ULA with NAT, because NAT provide security...... No real security, just shortsighted missguided assumptions on howto provide "security." this draft don't consider the none-technical side where the real damage is coming. None will bother to look into why they should use a /64, they will just hear "oh, IPv6 is classless so we can use whatever we want", and they will go down that road. --=20 Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Sun Jun 4 02:31:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB334120724 for ; Sun, 4 Jun 2017 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ca3PqyqL_kM for ; Sun, 4 Jun 2017 02:31:35 -0700 (PDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (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 B68C01200C5 for ; Sun, 4 Jun 2017 02:31:35 -0700 (PDT) Received: by mail-it0-f52.google.com with SMTP id m62so39408433itc.0 for ; Sun, 04 Jun 2017 02:31:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=aggbTOkT9KmGwro7YhLE/UPFgCThPrjYRBxnpt1M2nc=; b=gWkDyGTRxSJR2t4th/1AGfW7WPEIIfZ54QozQG7flqWsvlusL2pcm2KJlyymlWUM92 mLNvL9Lt80oHjiZLMumHsqp1qBfhXsxsA+bMa6is/2zWywgf9UGAoLq1fqDHQZB7EooU jk8WxsiI8s9j2UgOCOtZs3maMDZeNOAIi2K1fFQQMl8Us/fj+3lmo5D6cIgb5XTc4IFX NChbWpOPyf+F7kdocgyll7dTrtj53rqQ2R+cLa9eKGSVTo98+Qllyr27KILt4YInfiDF pGghwC55np0W0zpdk9mnI/4sbV4gCYNHtp1bc1T+5A5llVJSPVj7c43O1GUilcAUX0rN 6G7w== X-Gm-Message-State: AODbwcD+KdT1OlSjVr2suUGS/lDC2aZnRpeE5IksD+eJUe138ehNPy7f CiTWDBKD7Cls0NJHbPDgCw== X-Received: by 10.107.19.194 with SMTP id 63mr18640020iot.188.1496568694215; Sun, 04 Jun 2017 02:31:34 -0700 (PDT) Received: from localhost ([12.130.119.140]) by smtp.gmail.com with ESMTPSA id y64sm3540222itb.31.2017.06.04.02.31.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 02:31:33 -0700 (PDT) Date: Sun, 4 Jun 2017 11:31:19 +0200 From: Job Snijders To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170604093119.nt733rb3ymmjssww@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 09:31:37 -0000 On Sun, Jun 04, 2017 at 10:55:59AM +0200, Roger Jørgensen wrote: > On Sun, Jun 4, 2017 at 3:33 AM, Lorenzo Colitti wrote: > > On Sun, Jun 4, 2017 at 2:34 AM, Roger Jørgensen wrote: > >> > >> > Please stop trying to make IPv6 be the same as IPv4. That will > >> > take away our ability to make the Internet better once IPv4 is > >> > gone. > >> > >> oh totaly agree, but it's already lost, the "operators" don't want to > >> move/change. > > > > But they *are* changing. For example: almost 20% of Google users > > these days come in over IPv6. Pretty much all of them are connected > > to networks that support SLAAC and use /64 prefixes. That's a huge > > number now matter how you look at it, and it's showing no signs of > > slowing down. > > look into the numbers, I assume there are one huge group missing > there, the enterprises and that's where the money, and damage will be > done. You talk about "damage", I think what you meant to say is "finally, the enterprise will deploy IPv6 too". > If/when this draft goes through I am pretty sure I in 10-15years time > will come across something like this : Would you be so kind to also point out which stock options we should invest in and what horses to bet on? Kind regards, Job From nobody Sun Jun 4 02:37:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8E127ABE for ; Sun, 4 Jun 2017 02:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db-vUp7j_Qze for ; Sun, 4 Jun 2017 02:37:55 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 8783D126B6D for ; Sun, 4 Jun 2017 02:37:55 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so32855668ywr.0 for ; Sun, 04 Jun 2017 02:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KZxIEj1adi8ZmQrHd5xP5WiJK9zofUDOZNICD0Y3ME4=; b=VO/vtVikc9Tekgofey2EHlpDxed83xtklIOlnqGDguLM81x7K03OV1ib/hbr53OzfB ZN8f8YQl3ecuLI6VZqjHIXwwbVcM453pfPx1b7N0CK25G2fzRUMp5GgyWfBM7WceMHp1 lEWxgd7DLGBSa0EB4TPEfPfntvfnv5ahwzHHiBlWcFqmcSTLGDDt+jEol8/jakOET57R adzkDUxt4oKrQhG4NHy0ci6IgD26H+zvgOlL7j4LDLOnmAYSXA9X41ZayACRHSGTVlvZ KNWgM+NhUC2JdpAeYJJ9+zkfNGOptWFIdu0UjRVhE7hh4evW3K/2ZE9qTUPDaZ/qOn2c ax0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KZxIEj1adi8ZmQrHd5xP5WiJK9zofUDOZNICD0Y3ME4=; b=jB7UjjW4HB2xpDlCAZ9c3iA3OWOCyYb6kWIEubjaU6SdHNP5AWNb/KkeseZR5T5ABr hNvBMKOUhijR0AXz5HkTUa60hZkCQIEceTm/s66XNgWfHL2iqidSPwy4HieixFAUIGd+ N/gs2lTpcUOEbEkdIaGcjEc4XfquSYkFaH+NKrroO39Y6Hk2kjqbbjFBVZAaTPnA26Pe V9a/+/0U3oOy/mgt/ybIEogknvDdY5JZLrPQFIeTU4fjOlRpqnSiqdBsYCyYZ1JpLaY+ jGWYSX4PFRzoTqRZpLlLcwyo6C0bGhJnpqMI00QzMfXfcRQeZKhTykbqQzCdGsfO8SzV aEuA== X-Gm-Message-State: AODbwcACaDaIw4kviBhG4kehAOyyO7EspK4/2BO6rs/5gIaf0Hut1vcJ qPskhIE77nEwsFxhzfgI/8hBVH3NNg== X-Received: by 10.129.91.136 with SMTP id p130mr11290172ywb.176.1496569074814; Sun, 04 Jun 2017 02:37:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Sun, 4 Jun 2017 02:37:53 -0700 (PDT) In-Reply-To: <20170604093119.nt733rb3ymmjssww@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Sun, 4 Jun 2017 11:37:53 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 09:37:57 -0000 On Sun, Jun 4, 2017 at 11:31 AM, Job Snijders wrote: > On Sun, Jun 04, 2017 at 10:55:59AM +0200, Roger J=C3=B8rgensen wrote: >> On Sun, Jun 4, 2017 at 3:33 AM, Lorenzo Colitti wro= te: >> > On Sun, Jun 4, 2017 at 2:34 AM, Roger J=C3=B8rgensen wrote: >> >> >> >> > Please stop trying to make IPv6 be the same as IPv4. That will >> >> > take away our ability to make the Internet better once IPv4 is >> >> > gone. >> >> >> >> oh totaly agree, but it's already lost, the "operators" don't want to >> >> move/change. >> > >> > But they *are* changing. For example: almost 20% of Google users >> > these days come in over IPv6. Pretty much all of them are connected >> > to networks that support SLAAC and use /64 prefixes. That's a huge >> > number now matter how you look at it, and it's showing no signs of >> > slowing down. >> >> look into the numbers, I assume there are one huge group missing >> there, the enterprises and that's where the money, and damage will be >> done. > > You talk about "damage", I think what you meant to say is "finally, the > enterprise will deploy IPv6 too". no, the questions is, is it really worth it? >> If/when this draft goes through I am pretty sure I in 10-15years time >> will come across something like this : > > Would you be so kind to also point out which stock options we should > invest in and what horses to bet on? that's low --=20 Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Sun Jun 4 02:38:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E67120724 for ; Sun, 4 Jun 2017 02:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GISUplecoFEI for ; Sun, 4 Jun 2017 02:38:35 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) (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 307E01200C5 for ; Sun, 4 Jun 2017 02:38:35 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id m62so39461237itc.0 for ; Sun, 04 Jun 2017 02:38:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=eA21jCmYVvIkzT0Edz89xB4BIpdGmpHNNkoa+dGtXzM=; b=EMkAO5ovlBf7q2rVccA6z76rXdCq/7ASxvGUT3UOHqTpT/RkH98S+eaW2MvojHMg12 hTxf3IfK/7QluvWRfMyTD55c4+h4lEl91+PPJ4CZrIgAU+IYVuq2Q1ZHG4KmKiF+8jqB GSTYtJ80c8gBOP6WGp0tVSvDYScZYU5KuQaH6szboqQzrBzX62B+S2dBEUXn8EMIlBvw rK1a4Cfaeo2ilzkbYMDASraoUPla4PjVFGJxhJCPOw3g+zlF7ZI9l1NhLrHIq7IPalUY h6zpB5dRYLFxZHprX9eRYpoi0HOJPPZib/8wGYend5rWUuFoA/0ObWmlAIiUeD39UwVd HdSA== X-Gm-Message-State: AODbwcA5gvMzFQEPwuxm1Yb18WFC4BCsK6PTtbVB9uD+ORGfQlkODm5P kJCSs8v7IKG/BonejM17yg== X-Received: by 10.36.123.137 with SMTP id q131mr7517387itc.23.1496569114264; Sun, 04 Jun 2017 02:38:34 -0700 (PDT) Received: from localhost ([12.130.119.140]) by smtp.gmail.com with ESMTPSA id g188sm12378965iof.6.2017.06.04.02.38.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 02:38:33 -0700 (PDT) Date: Sun, 4 Jun 2017 11:38:19 +0200 From: Job Snijders To: Simon Hobson Cc: IETF IPv6 Mailing List Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170604093819.xv7j24sbsfd3p64b@Vurt.local> References: <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 09:38:36 -0000 On Sun, Jun 04, 2017 at 09:27:48AM +0100, Simon Hobson wrote: > Lorenzo Colitti wrote: > > On Sat, Jun 3, 2017 at 7:15 PM, Simon Hobson > > wrote: BUT, I cannot see the logic behind > > your earlier comment that DHCP makes NAT inevitable for IPv6. > > > > The answers are in RFC 7934, > > I think you'll need to point them out then > > Lorenzo Colitti wrote: > > > That means it should be able to form new addresses without asking > > the network, or it should get enough from the network that it never > > needs to asks again. > > Ah, now I see where you are coming from - and I don't agree with you. > > I don't want to come across as being adversarial here, but one thing I > have noticed from your various posts is that you appear to have a > quite entrenched "SLAAC solves the problems I work with, there > shouldn't be any other solutions even if others have different > problems/priorities" approach to things. > > So for example, here you are adamant that a device should not have to > "ask the network" for more addresses. What about networks where there > are other priorities, what if the operator of a network requires to > track addresses/address usage for whatever reasons ? > > The answer to that cannot be "then the network operator is wrong". I > can assure you that there are networks around where devices just > turning up and assigning their own addresses is not allowed, and never > will be allowed (all I'll say is that the military have a different > view of the privacy/security tradeoff). In some cases, there is a > LEGAL REQUIREMENT to track devices in this manner - such as public > WiFi operators. I assume you'll consider that bad and not to be > supported, but in the real world that is the case whether we like it > or not. There may be other ways around it involving routers tracking > the MAC-address mappings and so on, but this seems quite a lot more > work than having a centralised management system that deals with > admitting new devices onto the network, assigning addresses to them, > and monitoring their activity. This is a really good summary. Even in my home environment I sometimes need absolute control on what source address is used by what device to connect to the outside world. Many online services perform poorly thought out geo-fencing, and through steering of source addresses (by using NAT, or by handing out specific addresses to specific devices) I can increase the chances that the legitimate user can access their legitimate content. Of course, some zeolots will say "well, those online services are doing it wrong and must fix their service offering". sure.... i'll ask them to get right on that! ;-) Kind regards, Job From nobody Sun Jun 4 04:05:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790D0127735 for ; Sun, 4 Jun 2017 04:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLuFkFAMnWv4 for ; Sun, 4 Jun 2017 04:05:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 220E6126CC7 for ; Sun, 4 Jun 2017 04:05:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dHTLx-0000DcC; Sun, 4 Jun 2017 13:05:49 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> In-reply-to: Your message of "Sun, 4 Jun 2017 11:31:19 +0200 ." <20170604093119.nt733rb3ymmjssww@Vurt.local> Date: Sun, 04 Jun 2017 13:05:48 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 11:05:55 -0000 >> look into the numbers, I assume there are one huge group missing >> there, the enterprises and that's where the money, and damage will be >> done. > >You talk about "damage", I think what you meant to say is "finally, the >enterprise will deploy IPv6 too". The way I see it, at a fundamental technical level, this draft is wrong. Now if this draft were to say that in the case of address assignment using DHCPv6 IA_NA or when using static addresses, hosts should support any prefix length, then I would be perfectly okay with that. In general we can assume that operators know how to run a network and it is perfectly possible to run a network on just DHCP or static. With this in mind, if enterprises want to make their lives easier, they should tell vendors that refuse to support DHCPv6, that in a couple of your their devices will not work anymore on enterprise networks. Support DHCPv6 or be gone. However, that is not what the draft actually says. The draft tries play games with SLAAC, and that is a bad idea. Traditionally, SLAAC used modified EUI-64 interface identifiers, which are of course exactly 64 bits. So that implies a hard 64-bit boundary. In recent years there has been a change to pseudo random interface identifiers. Because the boundary was effectively at 64 bits, none of those RFCs contains a specification of what the minimum amount of randomness has to be to avoid problems. Leaving that to the network operator without any kind of constraint or guidance is just a recipe for disaster. So without an RFC that properly sets a lower limit for pseudo random IIDs, this draft is a bad idea. Moving on to a network architecture point of view, when using pseudo random IIDs there will be a longest prefix that can be supported. Lets say for the sake of argument we can support of /96. Then the effect will be that if in the future hosts support SLAAC upto /96 then we are back at the same hard limit. We have just moved be boundary by 32 bits. At the moment we don't have an address shortage. Any kind of address shortage at the moment is due to a combination of political and commercial issues (with a hint of political issues masking as technical issues thrown in). There is no reason to expect this to change if we make longer prefixes possible. It is just that end users will then end up with a /96 and find that they can't subdivide it any further. So, to make a full circle, if you want to deploy long prefixes, limit yourself to DHCPv6 and static. If you find that hosts routinely have problems with long prefixes in combination with DHCPv6 or static then write a draft about that. Do not try to move the boundary for SLAAC. That may give a short term gain, in the long run that just locks ourselves in a small corner. From nobody Sun Jun 4 04:55:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5F128799 for ; Sun, 4 Jun 2017 04:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opusPwp_QKoC for ; Sun, 4 Jun 2017 04:55:52 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 B3016127058 for ; Sun, 4 Jun 2017 04:55:52 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id h39so9258012uaa.3 for ; Sun, 04 Jun 2017 04:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T6N7YlEhwhqs4r4SJeAZqhXe0wwS8innL5xa3Bon3hs=; b=QTdXnbKL4CjwKbVUf5VY8daGWn7iAsWPgYZtuEdc5F5eGK5Td/mpzPmzoPk9RC/an2 BpV7vyEs28X4B5+SgMatVlVlTUTVwG8+n7o9GNBy63Xc4o4sI6X3KRSSHnF6DQ61Kc9h bkUf+ab8nvY6zIlIeuiqW6UUWkV9xyr7pLF/cZgLajxZvhecAgN9GbvVF0Nef0GCw2U0 LWsUoc/Cn22zDN80VgRSG55/nTgY76U4kP0XD9qqQi35HMzkpLTorN6+sw/3oSZ0CH5U k4hn9Uw5/Hi8ZEKq+lsV9g62NUIRsIBBpAe5gEQKseCTqECQod8ykSSyTvD3RMWDilEn 7hgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T6N7YlEhwhqs4r4SJeAZqhXe0wwS8innL5xa3Bon3hs=; b=JJLUx4Ac+3M4Q0yI1oMS8hPGjdETq+b8Hg/z9odCro/nG1ipMoGXTFlUuhyjlWOmtQ ZCwxdV1e5fQGlRCQe0zT1fvrNpf7Z0aDFxk/TDJbRkqO2EyYspNnbFyBlqYRSB9VIlUR pzgv9uUvXCJs8Nd6Xn6axiouelbQgeuyNxQEUOKG5opdFpEBD3aRRb4wnL3qaPhxJUpo KhO6srOeUuJmyhGEJAhKMpVbYpAtpilj9QdrXf404dU6GZX56KteaskGUcneqZxPqazg 1XP5wKNXBbb4LRKzOZOmVkgBmeOTREDmqQNKx2fxVrgCPTsWUTwWLYWoYPF3YIdeYElC b1gQ== X-Gm-Message-State: AODbwcBbW/nr6AZ3ablRz/E/D+KX8XGno6jtJQ/Tn+SDu0GSMeCp9FLf a0MJnyW75BGsPHajt+KbvjW+4mVbjPu6BkE= X-Received: by 10.176.95.217 with SMTP id g25mr4638129uaj.71.1496577351690; Sun, 04 Jun 2017 04:55:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sun, 4 Jun 2017 04:55:30 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 20:55:30 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Tom Herbert Cc: Nick Hilliard , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="089e082049606d91b80551211109" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 11:55:54 -0000 --089e082049606d91b80551211109 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 1:51 PM, Tom Herbert wrote: > M bits for locator of physical device in mobile network > N bits for identifier of physical device > 128 - M - N bits for delegated addresses by the physical device > > I don't see a workable solution if device is assigned a /64. Am I > missing something? > There is no workable solution if you want to assign 64 bits to the bus, 64 bits to the routing system, and M bits for mobility, unless M = 0. --089e082049606d91b80551211109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 1:51 PM, Tom Herbert <tom@herbertland.com> wrote:
M bits for locator of physica= l device in mobile network
N bits for identifier of physical device
128 - M - N bits for delegated addresses by the physical device

I don't see a workable solution if device is assigned a /64. Am I
missing something?

There is no workable= solution if you want to assign 64 bits to the bus, 64 bits to the routing = system, and M bits for mobility, unless M =3D 0.
--089e082049606d91b80551211109-- From nobody Sun Jun 4 05:48:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4591294D8 for ; Sun, 4 Jun 2017 05:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0McYELQkWenv for ; Sun, 4 Jun 2017 05:48:32 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21DE128792 for ; Sun, 4 Jun 2017 05:48:31 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 4F20678985 for ; Sun, 4 Jun 2017 14:48:30 +0200 (CEST) Date: Sun, 4 Jun 2017 14:48:29 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170604124829.GI30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 12:48:33 -0000 On 2017 Jun 04 (Sun) at 20:55:30 +0900 (+0900), Lorenzo Colitti wrote: :On Sun, Jun 4, 2017 at 1:51 PM, Tom Herbert wrote: : :> M bits for locator of physical device in mobile network :> N bits for identifier of physical device :> 128 - M - N bits for delegated addresses by the physical device :> :> I don't see a workable solution if device is assigned a /64. Am I :> missing something? :> : :There is no workable solution if you want to assign 64 bits to the bus, 64 :bits to the routing system, and M bits for mobility, unless M = 0. That's *exactly* why bus and routing MUST NOT require a specific size. -- What is a magician but a practising theorist? -- Obi-Wan Kenobi From nobody Sun Jun 4 06:02:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF6129B17 for ; Sun, 4 Jun 2017 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmwH3gTPNUgt for ; Sun, 4 Jun 2017 06:02:43 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7F11294F3 for ; Sun, 4 Jun 2017 06:02:43 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y190so56783460vkc.1 for ; Sun, 04 Jun 2017 06:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zxq02LZWoawkIwkcXkN0p7j0xuGyWHWIrxNwrpnkTG4=; b=U4PtCiQN/O11D8Jq8OQCNAJWL4n551qi6t+/XxNV3FQ9PiftmJwxyFbq9jEHz8kln9 hnj7wOBafAR/0q04Dy43HeOxUghLPLsDUx/Suqnu6KoOjC4WjDWWtzGitLlEetRJtng0 OqkZEelH+Hd2PCA9kIO3qVUiKMpJBna919yNKoZEnZ7AYjO/w66mnFJRnWj7AjhN4ZQ1 xXgOaMunefviDgnGtUpqVFrwCy6EESAYR+hUQxz9Gi1TOUbIClLsSMw0SeE5vgSVMh+v ttKZYGjiStYhhP3RWfTq8gPMnywwMOBOBjvN5qPt69idYsjJkkZCCOaWveZJCgOcLZR6 U3yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zxq02LZWoawkIwkcXkN0p7j0xuGyWHWIrxNwrpnkTG4=; b=PH7yPGawb/IzzT6jjnkBwnyMy9UhpG3W6V+G89P7LoZfPe79X0THCP05MrrRGEtd8S 6SziLAz1WVfilxAUVQSi0RW9/8F0Djb/mv+a1KrNNcLcAUr0lXeBN/uwHjBT4ya9yogn 4P381x7D7PYvyWiltH6xE2HnES5emo2uHIE/TxHKvR0lUHtu3/aSX+9PMjYJJ6LLwcbo 3LgFAho/uL3n36yd7k0/H3nfDsUtd21V1Ta7/G+juBQzjVpj/7/5lHPhyYucEp72V+C+ iUjp+mHLElBrMdchJEb9lbjUtySyiX4VNoxIDv0D45P1OinX/+j6ktFocWYL/8thuW93 iXag== X-Gm-Message-State: AODbwcDTOVpsEV+jffGUlaPqnPTh+rVfc3NC6rYOPNQRdyMBvGPWICFp P0UYzqSB0F1MTX5fQ0wzdRY5kLMMCnJnniw= X-Received: by 10.31.33.81 with SMTP id h78mr1937639vkh.29.1496581361850; Sun, 04 Jun 2017 06:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sun, 4 Jun 2017 06:02:20 -0700 (PDT) In-Reply-To: <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 22:02:20 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Simon Hobson Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a11c024ca73c9520551220087" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:02:44 -0000 --001a11c024ca73c9520551220087 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 5:27 PM, Simon Hobson wrote: > So for example, here you are adamant that a device should not have to "ask > the network" for more addresses. What about networks where there are other > priorities, what if the operator of a network requires to track > addresses/address usage for whatever reasons ? > Again, the answers are in RFC 7934. See section 9.1 which goes into some detail on address tracking. But basically: tracking via DHCP is insecure unless you have L2 security, and if you have L2 security, you may as well use that to track addresses. --001a11c024ca73c9520551220087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 5:27 PM, Simon Hobson <linux@thehobsons.co.uk&= gt; wrote:
So for example, here yo= u are adamant that a device should not have to "ask the network" = for more addresses. What about networks where there are other priorities, w= hat if the operator of a network requires to track addresses/address usage = for whatever reasons ?

Again, the answe= rs are in RFC 7934. See section 9.1 which goes into some detail on address = tracking. But basically: tracking via DHCP is insecure unless you have L2 s= ecurity, and if you have L2 security, you may as well use that to track add= resses.
--001a11c024ca73c9520551220087-- From nobody Sun Jun 4 06:08:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E52129469 for ; Sun, 4 Jun 2017 06:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJyGyd90kD9L for ; Sun, 4 Jun 2017 06:08:08 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197B61293E0 for ; Sun, 4 Jun 2017 06:08:08 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l14so45977782ywk.1 for ; Sun, 04 Jun 2017 06:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AVQNV1sTxwZBlqpTr0xj35gFoLVhXiJVPfgjXySV1Kw=; b=ZnV0s23zRQh5QXEipTs7BYdVdXuwdz0plybKvYxEWkBowIiiremGhSRxjpjXHJWHMR vFxvcm9Rv6zGhoY8Rb0eFNQckD7AXebW9Ud88Uwnd2DKenDGOJYEOTCwzXggi5Z93EX+ uI1jHTo1OKI1PRNhTkfTPDE2bo9NM49xyzleFfkU66J699vw8uUsOnV35hJWpQHk8OS/ vZTZYrWHYXQHOZ4M+Knp56MPWUXDZNOZACa7Srku/MC3IQalL7lq7pHbnPaXVJC1bizS HHMVU8vMHnzgGIitkqlK1C0DOpYE/VvTuKF3PxopsCJHaHXvDWanmFPDX9DVNGF1X/+M E7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AVQNV1sTxwZBlqpTr0xj35gFoLVhXiJVPfgjXySV1Kw=; b=kG+ycWZdnQaqiEC8YW6qrleJKvsbTaySf6zU+q9Z2Q0vqgN57zM8mM5n96TYZdG/c1 yVOORc20fe+8EE4RqHQ+KHg/xTYoWH1+EpEdseet9KEFUe+2ZYrtGDF1nY2Sp2qOjWeW 914gZ37V+ioVEeaYqsLc7CFGSS5NpqC7cCbARJ1Iz1xou8lREtGIWxfGY0qCcLSJaZ94 dQeSEDSUNQOExUdLp3Q6Fg6VXVRYcLel0EdCxvsnjGtuwp1J5dWzHSOdJcvhi5g++JOD 2QbY4ZamMyCRu2eADCLmc1lqqRZw2MP1IdTMYTqA5PCrFutZCmFIFhfI3yRQfu+1go4y XrHw== X-Gm-Message-State: AODbwcC/TPBrTSqARhfEN1UgmQ8XfSzra83mpqJjt2LgWLPbI/xCpTdS JkoisiW8P9fqrtEVpU1i7j5bpyqBULtc X-Received: by 10.129.182.100 with SMTP id h36mr11826904ywk.318.1496581687357; Sun, 04 Jun 2017 06:08:07 -0700 (PDT) MIME-Version: 1.0 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> In-Reply-To: <20170604124829.GI30896@gir.theapt.org> From: Ca By Date: Sun, 04 Jun 2017 13:07:56 +0000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Peter Hessler , ipv6@ietf.org Content-Type: multipart/alternative; boundary="f403045d2c9eda35c505512213ee" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:08:10 -0000 --f403045d2c9eda35c505512213ee Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 5:48 AM Peter Hessler wrote: > On 2017 Jun 04 (Sun) at 20:55:30 +0900 (+0900), Lorenzo Colitti wrote: > :On Sun, Jun 4, 2017 at 1:51 PM, Tom Herbert wrote: > : > :> M bits for locator of physical device in mobile network > :> N bits for identifier of physical device > :> 128 - M - N bits for delegated addresses by the physical device > :> > :> I don't see a workable solution if device is assigned a /64. Am I > :> missing something? > :> > : > :There is no workable solution if you want to assign 64 bits to the bus, 64 > :bits to the routing system, and M bits for mobility, unless M = 0. > > That's *exactly* why bus and routing MUST NOT require a specific size. > I would say this level of mobility or "nomadacity" has proven through the years to NOT work at the network level in the INTERNET. Just like ipsec has has failed where TLS has succeed, same for Mobile IP, PMIP, and so on. The narror waist of the internet does not include mobility, especially at a level that is transparent to the user. Just like always on dynamic ipsec for security, fine grain mobility was not destine to be included in the routing system. Best to let go of this usecase rather than tilting more at the windmill. > > -- > What is a magician but a practising theorist? > -- Obi-Wan Kenobi > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f403045d2c9eda35c505512213ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jun 4, 2017 at 5:48 AM Pet= er Hessler <phessler@theapt.org> wrote:
On 2017 Jun 04 (Sun) = at 20:55:30 +0900 (+0900), Lorenzo Colitti wrote:
:On Sun, Jun 4, 2017 at 1:51 PM, Tom Herbert <tom@herbertland.com> wrote:
:
:> M bits for locator of physical device in mobile network
:> N bits for identifier of physical device
:> 128 - M - N bits for delegated addresses by the physical device
:>
:> I don't see a workable solution if device is assigned a /64. Am I=
:> missing something?
:>
:
:There is no workable solution if you want to assign 64 bits to the bus, 64=
:bits to the routing system, and M bits for mobility, unless M =3D 0.

That's *exactly* why bus and routing MUST NOT require a specific size.<= br>

I would say this level of mobility or &quo= t;nomadacity" has proven through the years to NOT work at the network = level in the INTERNET.=C2=A0

Just like ipsec has h= as failed where TLS has succeed, same for Mobile IP, PMIP, and so on. The n= arror waist of the internet does not include mobility, especially at a leve= l that is transparent to the user. =C2=A0

Just lik= e always on dynamic ipsec for security, fine grain mobility was not destine= to be included in the routing system.=C2=A0 Best to let go of this usecase= rather than tilting more at the windmill.=C2=A0

<= br>


--
What is a magician but a practising theorist?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Obi-Wan Kenobi
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--f403045d2c9eda35c505512213ee-- From nobody Sun Jun 4 06:10:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B9129B1E for ; Sun, 4 Jun 2017 06:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ1XjKWzVHKU for ; Sun, 4 Jun 2017 06:10:32 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 E8BE6129B1A for ; Sun, 4 Jun 2017 06:10:31 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id u10so64384148uaf.1 for ; Sun, 04 Jun 2017 06:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NadkxXP0qPHopjBHX49cH4RZ+QahJhD7aDipQ3Ky3jI=; b=XZ8V0EBoP4HsjgdDyAWfE1ld3ssC1k8foSiPml9d26RWvt2ImHxKBLOjSdVsJ4peXS Da2Gnt0mP8mmxgNP1cQHDKBxFdmzv+p6f8RmSUvmruZwaf0Gg4AvvgU9t5AVG53dMVGL 6oYn29IBtWuhLNBZcP/Tn7KZdj4JxDIa49Om12DFvTrv/qotkWLrf13jlyixQPnzXmd/ k+oxIzhz2ecMFWlG8/btjAsLg7XCqZsIlRzksui3gG7ur8aQT42hDAuibqpoZNjE3q3D eKKUs1o7uHBZ5duTzYXQ5wqAxRHLaUn/v34A9S7q1qCBybHW2Kz7VyZev30989jdHtL2 BUSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NadkxXP0qPHopjBHX49cH4RZ+QahJhD7aDipQ3Ky3jI=; b=U9FUI0xvx5rTrUKw/wG+J0pN96rz/uTnfFFbGGXnbqwNp97jYE7rJ2VdvtwjI+KkwX WOxNscUn8YKa7Oo/U6Egx9xdLsmDqNaA20KyawCOWWTVuXEOBx3NGrY/sxWr5CWwJKJy WYqIonGTO/p3yly3cVYCUyEPmeBGFgbNYEPtC6O5Fy+jMGex2t3gMVtbeXlkPCOpFB+5 fmmLlV2xVQhEJkpwtNdAJs/AXO/9Df5B28OZoXJJKedV8fRr4InYw8eKe3xl1asZYXUe CPuvgy8H5p5PynA5MoGYYI44St8Cz3FjN50dUvGs4PrfxtekvA34SSzPNTtKNdzawJNA BpOA== X-Gm-Message-State: AODbwcB1co751q2z91NIgq/y5WIzNjHdlhSH26JqTSzu+7ocbGNqkxvA SopEmMCG5HozRCZofKbKcT8v+zbR98jTp6SAkA== X-Received: by 10.176.17.228 with SMTP id q36mr6802799uac.20.1496581830901; Sun, 04 Jun 2017 06:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sun, 4 Jun 2017 06:10:09 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 22:10:09 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Philip Homburg Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403045e75fc68e5480551221cba" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:10:33 -0000 --f403045e75fc68e5480551221cba Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 8:05 PM, Philip Homburg < pch-ipv6-ietf-4@u-1.phicoh.com> wrote: > Moving on to a network architecture point of view, when using pseudo random > IIDs there will be a longest prefix that can be supported. Lets say for the > sake of argument we can support of /96. > > Then the effect will be that if in the future hosts support SLAAC upto /96 > then we are back at the same hard limit. We have just moved be boundary by > 32 bits. > That's *exactly* right. > There is no reason to expect this to change if we make longer prefixes > possible. > It is just that end users will then end up with a /96 and find that they > can't subdivide it any further. > Right. So then someone will say, "we need to extend the network at the edges!". And we move the boundary again, to /112. And then to 120, and then to /124, until we get to one /128 per device. But long before that, a) SLAAC is dead because there's not enough space in the prefix to form a random IID, b) the hosts start doing NAT because they don't want to waste their time. We now have 128-bit IPv4. Except that at least in IPv4, address shortage was real. In IPv6 it isn't. Or, if we remove the boundaries altogether, we end up with /128 straight away, because operational consistency. We now have 128-but IPv4 again. --f403045e75fc68e5480551221cba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 8:05 PM, Philip Homburg <pch-ipv6-ietf-4@u= -1.phicoh.com> wrote:
Moving on to a network architecture point of view, when using= pseudo random
IIDs there will be a longest prefix that can be supported. Lets say for the=
sake of argument we can support of /96.

Then the effect will be that if in the future hosts support SLAAC upto /96<= br> then we are back at the same hard limit. We have just moved be boundary by<= br> 32 bits.

That's *exactly* right.
=C2=A0
There= is no reason to expect this to change if we make longer prefixes possible.=
It is just that end users will then end up with a /96 and find that they can't subdivide it any further.

Rig= ht. So then someone will say, "we need to extend the network at the ed= ges!". And we move the boundary again, to /112. And then to 120, and t= hen to /124, until we get to one /128 per device. But long before that, a) = SLAAC is dead because there's not enough space in the prefix to form a = random IID, b) the hosts start doing NAT because they don't want to was= te their time. We now have 128-bit IPv4. Except that at least in IPv4, addr= ess shortage was real. In IPv6 it isn't.

Or, i= f we remove the boundaries altogether, we end up with /128 straight away, b= ecause operational consistency. We now have 128-but IPv4 again.
=
--f403045e75fc68e5480551221cba-- From nobody Sun Jun 4 06:12:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D683129B22 for ; Sun, 4 Jun 2017 06:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfht8yGocZvG for ; Sun, 4 Jun 2017 06:12:22 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8AC4129469 for ; Sun, 4 Jun 2017 06:12:21 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id p62so21511734vkp.0 for ; Sun, 04 Jun 2017 06:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H1a1K4MtYRUJ+JdW8keRlNRD0hTsLrAhN9AFTZS2c1A=; b=CAcpCYntx5ED9BhSbHNpp7d+LGuhvtO7HwNzdUL8iphP5umDiN3+bI60vejrF6tJIg Pw+b9HDkGAl6LfRjumi9gTx7+oLMZrYNaeExuZmoowEAT34IlBmfUXBww8h9NnHwLDoL 986byejhFhUKwJvOOl6WgIKg7HyhUl+d9VNlRde6NGC0jfO2jH8XXgFTwEv04CDJaDoO zlMR2Hwr5BxRndK+m1ZaKERGRJdBRVFUWJERZPKmwf1lsJdwR0mi0QSZV90k2msSmdev pgtg8sL4ifehXT/7QgoxofuoDr+6LPNwGLEbRDg0E0aTJqcBMeaBTCGoTTtTtqVVx5zU 0Crw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H1a1K4MtYRUJ+JdW8keRlNRD0hTsLrAhN9AFTZS2c1A=; b=kBix3MT5IrHH6KM2Ux8Xk/lS4mhDaOSauUO7QwEHZ2we/Obw02MbqHqDDGkM90qUex r5NXQ/1gkJWNC3meF+ojvl16NAfPtEtChEvAWv844qXIt1q/OIqMWnjdcB03czLqbgor EW7XqcUGGIa+rfwwgpTqh5kW/0JWGYBgP7oCnzxiDy4L/R2DQ+6PAfIZndENhXEL81jW E3wktLL3naF0DAtm0atZCmlJ7WC4jum8blOXLgnvHlY4yuyKYNNgUYKFqavIIB6bsNZG jp1SBbj0so/OlMli5IzxukKvnsMZUg6mNoDJSEehKW/XxohAJ4fq/i4WBuZCrIxzPKle rzvA== X-Gm-Message-State: AODbwcBUv56+qPYTpRRer5V1N1aTVECDnFFidD31851fDvG+FC5CG2AR 7hnfNeDzk76jPEdzyMgwU5t/NfPscuIKvMU= X-Received: by 10.31.180.144 with SMTP id d138mr7584890vkf.44.1496581940909; Sun, 04 Jun 2017 06:12:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Sun, 4 Jun 2017 06:11:59 -0700 (PDT) In-Reply-To: <20170604124829.GI30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> From: Lorenzo Colitti Date: Sun, 4 Jun 2017 22:11:59 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Peter Hessler Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a1144073af7a3c605512222da" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:12:23 -0000 --001a1144073af7a3c605512222da Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 9:48 PM, Peter Hessler wrote: > :There is no workable solution if you want to assign 64 bits to the bus, 64 > :bits to the routing system, and M bits for mobility, unless M = 0. > > That's *exactly* why bus and routing MUST NOT require a specific size. > If you don't require a specific size "operational consistency with IPv4" will inevitably lead to one /128 per device and NAT. As a host developer I don't want to implement NAT, because it's bad for my users. --001a1144073af7a3c605512222da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 9:48 PM, Peter Hessler <phessler@theapt.org> wrote:
:Ther= e is no workable solution if you want to assign 64 bits to the bus, 64
:bits to the routing system, and M bits for mobility, unless M =3D 0.

That's *exactly* why bus and routing MUST NOT require a spe= cific size.

If you don't require a = specific size "operational consistency with IPv4" will inevitably= lead to one /128 per device and NAT. As a host developer I don't want = to implement NAT, because it's bad for my users.
--001a1144073af7a3c605512222da-- From nobody Sun Jun 4 06:16:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BAD129B2B for ; Sun, 4 Jun 2017 06:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVhRk60_5oM2 for ; Sun, 4 Jun 2017 06:16:22 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A699129B22 for ; Sun, 4 Jun 2017 06:16:22 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id BB63778985 for ; Sun, 4 Jun 2017 15:16:20 +0200 (CEST) Date: Sun, 4 Jun 2017 15:16:19 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170604131619.GJ30896@gir.theapt.org> References: <20170602141259.GD30896@gir.theapt.org> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:16:23 -0000 On 2017 Jun 02 (Fri) at 20:14:11 +0000 (+0000), Templin, Fred L wrote: :Another question that we would have to ask is what is the longest prefix that :we should expect an ISP (or a core Internet router, for that matter) to carry :in its routing tables? A /80? A /96? OpenBGPD is intended for use on the default-free-zone, and has a default configuration that allows /16 - /48 for IPv6 prefixes. In looking at RIR policies, and recommendations from vendors and operational documents, /48 looks to be the longest prefix length that you can consider reliably routable beyond your own AS. *Inside* an AS however, I see no reason to artificially limit the prefix size. Operators should aggregrate where it makes sense (region/metro/building/cage/row/rack/etc), but that is good design regardless of the size or even IP version. -- First Law of Socio-Genetics: Celibacy is not hereditary. From nobody Sun Jun 4 06:22:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C084129AE0 for ; Sun, 4 Jun 2017 06:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdIjt3KetVL7 for ; Sun, 4 Jun 2017 06:22:02 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39F7129469 for ; Sun, 4 Jun 2017 06:22:02 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 687F278985 for ; Sun, 4 Jun 2017 15:22:01 +0200 (CEST) Date: Sun, 4 Jun 2017 15:22:00 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170604132200.GK30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:22:04 -0000 On 2017 Jun 04 (Sun) at 22:11:59 +0900 (+0900), Lorenzo Colitti wrote: :On Sun, Jun 4, 2017 at 9:48 PM, Peter Hessler wrote: : :> :There is no workable solution if you want to assign 64 bits to the bus, 64 :> :bits to the routing system, and M bits for mobility, unless M = 0. :> :> That's *exactly* why bus and routing MUST NOT require a specific size. :> : :If you don't require a specific size "operational consistency with IPv4" :will inevitably lead to one /128 per device and NAT. As a host developer I :don't want to implement NAT, because it's bad for my users. One address per device *is a good thing*. From the OS perspective, having to select which ******** address to use as the source IP is horrible. NAT means two things: 1) You can't depend on directly accessing the device. This is true with Firewalls, so you have to consider that anyways. 2) You can't embed the IP address inside the packet data. That's a stupid idea, and shouldn't be done. Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*. -- You will feel hungry again in another hour. From nobody Sun Jun 4 06:56:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A0129AE0 for ; Sun, 4 Jun 2017 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fajokGoRZ3xX for ; Sun, 4 Jun 2017 06:56:36 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FFE129515 for ; Sun, 4 Jun 2017 06:56:36 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id d73so6293327wma.0 for ; Sun, 04 Jun 2017 06:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vfXzOkpOCY4HyZyxHmNsPtqcKM5SVxz3ytsSC4GQcZk=; b=XF17WuffJy3h4Ol0Ek+BpDjqefshGnljTu2G+C4HJPT5RPRA29OqWTJIUybvr2Xqlk +Gny0sB67a2j9r3TZUf+bRRMRSVPgxEz+WGUmien4K10OtyugRxwNo7HJs8T6YxDU9AN DRVgn5SDLFX49G/qVPJUzSeuSq7+njZqGK9LvCTOAjnR/NpFCQ8uhQfMy+bv92BrOs8N 4nzkKoUJpP+pAVDqGFRNhYwTZLqw4X6GjCK9ELvpQxa7Y9EEYtogvd9bjyXtkV+J/H9a sgTufRpLWv4gXYmn4uXpr2VAirL/ZKRaa9IcfDPZY1xxQDqYWJ5tLlLJTBiz2HetGrFI j8Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vfXzOkpOCY4HyZyxHmNsPtqcKM5SVxz3ytsSC4GQcZk=; b=PJ60bXI3na6TDauCLfkV7EGw2GV99eQmjuGC++oBhLdjlC05P3EbZyZImbFA3W9KuZ dWwmriumuKMjoxJi5RvaQYl0d/a6VibwnS2TCgy0qHMFhh/D0e7jMe4HrqWpnYgPo8XE zA0anBTID7a0to0foZe56kxDxBKG9OGBf+N8iFsxVBCVkYUxDtpx+JGtwIw0FWMjM62M Gz/PsYtsDzqPi6clO/mV1X4q1Xo6HarB0Zwbv8QwkPZyu0ZSaQ0+rnm4V8vyX70oi6jY vzeWwTcN9zAW04ChbtPT3OgsbyaFinLZsTawPxfXGqitNrI18v5A3K1wXER1GAnLYcJv jc6Q== X-Gm-Message-State: AODbwcBLGIQWq9iVzwSTUPHLW4xd2iIDSbVwiOBwbdsp8c6dqpKK0v2R z9el0o+6q+2kErsqc54h0cJOhMq3Cfhw X-Received: by 10.28.54.204 with SMTP id y73mr4317643wmh.53.1496584594711; Sun, 04 Jun 2017 06:56:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sun, 4 Jun 2017 06:56:33 -0700 (PDT) In-Reply-To: <20170604132200.GK30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> <20170604132200.GK30896@gir.theapt.org> From: Tom Herbert Date: Sun, 4 Jun 2017 06:56:33 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Peter Hessler Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:56:38 -0000 On Sun, Jun 4, 2017 at 6:22 AM, Peter Hessler wrote: > On 2017 Jun 04 (Sun) at 22:11:59 +0900 (+0900), Lorenzo Colitti wrote: > :On Sun, Jun 4, 2017 at 9:48 PM, Peter Hessler wrote: > : > :> :There is no workable solution if you want to assign 64 bits to the bus, 64 > :> :bits to the routing system, and M bits for mobility, unless M = 0. > :> > :> That's *exactly* why bus and routing MUST NOT require a specific size. > :> > : > :If you don't require a specific size "operational consistency with IPv4" > :will inevitably lead to one /128 per device and NAT. As a host developer I > :don't want to implement NAT, because it's bad for my users. > > One address per device *is a good thing*. From the OS perspective, > having to select which ******** address to use as the source IP is > horrible. > It wouldn't be particularly difficult to implement random address selection in an OS, but I imagine that might confuse some applications that assume there is only one address in the system. However, for the purposes of address obfuscation I don't see why a host would need 2^64 addresses, a few billion addresses should suffice. > NAT means two things: > > 1) You can't depend on directly accessing the device. This is true with > Firewalls, so you have to consider that anyways. > > 2) You can't embed the IP address inside the packet data. That's a > stupid idea, and shouldn't be done. > > Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*. > NAT is bad because it requires networks nodes to maintain and track connection state (like stateful firewalls which also need to go away!). It only supports certain protocols and extension headers, it has motivated the use of NAT keepalives in UDP which are nothing but junk packets, and for connections all packets must go through the same network device which becomes a bottleneck and prevents multi-homing. Tom > > -- > You will feel hungry again in another hour. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Jun 4 07:01:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D82129AE0 for ; Sun, 4 Jun 2017 07:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7FpQtjzdI1F for ; Sun, 4 Jun 2017 07:01:07 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002: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 5E246129505 for ; Sun, 4 Jun 2017 07:01:07 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 202so27524119ybd.0 for ; Sun, 04 Jun 2017 07:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4e9oMHUfxTkpPjp+CzKulXB8NCs95Fqxa/4fIz7K/7E=; b=kGLYJx80vAZKgiBdXXzZ5qSdW2v1TAsiMHOUboXItUAkxgCspZ4fGzgWQtzmQw84sL 0BG8vquJ43Nj/+xQFutYjEfoVhAa2pjEOEI1wQna0oGCT9ZmE9AzImls5eQiW8A0zPPC uCx8CU3VmfUN0roERScpZrGNmCwXLT/t0UOiavrudotHdJIqJF+5gChbCmgLAFbOtezO CJcHNmKK/Wfj5pzjze160bfMzFEIi4Hja57/CwGuC7R2sy8MaXGtBZlHfhcGrxruez8m Swd8/tJeHoY6ceksL2lPtoinO17zGtaThrBiHvRtYr01sS27VZ057kZmfbKGh0YBgHkz gCRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4e9oMHUfxTkpPjp+CzKulXB8NCs95Fqxa/4fIz7K/7E=; b=hjHlbIj7UB27d7LKg/64FylLdMiIq/gHur+etjmc//UqDnaMs5ZMOY6k4XkjEVdwi3 5E+tzzJ1cP5GgUkq7ioa753+sqc46uwWsGhbMbhV3jhurCm5dt70sNoMCnLab/fLdYBh i6+lT83gjkR325VlZOLMgibd1z7tMLQ771tPq+GSTQfZ1bHFa+V/k2a81pCeTiWdQcEx rllBsD5LzKQYJ/9v7aUIzp0GbQn0i7FYcc3ynkq7/a7TTbaJz7a2Q9mJReyZm3ozoZkx VyehdT75RnbWHedvPzEpIWT3fJtMXtvbg7rtDiX6XS3OTXa07PVYCEEa4bZZ2P9pYy6u zvGA== X-Gm-Message-State: AODbwcDO835cfcdrqzuITgyU/rTsatA+DREKgW1H/Ic/wl82yAXuqIN5 1nwvq/vo/oPNdCytq1BhiaxQ2w9YaA== X-Received: by 10.37.54.20 with SMTP id d20mr6308598yba.191.1496584866428; Sun, 04 Jun 2017 07:01:06 -0700 (PDT) MIME-Version: 1.0 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> In-Reply-To: From: Ca By Date: Sun, 04 Jun 2017 14:00:55 +0000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti , Philip Homburg Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c1b1dd0576672055122d1a7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:01:09 -0000 --94eb2c1b1dd0576672055122d1a7 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 6:10 AM Lorenzo Colitti wrote: > On Sun, Jun 4, 2017 at 8:05 PM, Philip Homburg < > pch-ipv6-ietf-4@u-1.phicoh.com> wrote: > >> Moving on to a network architecture point of view, when using pseudo >> random >> IIDs there will be a longest prefix that can be supported. Lets say for >> the >> sake of argument we can support of /96. >> >> Then the effect will be that if in the future hosts support SLAAC upto /96 >> then we are back at the same hard limit. We have just moved be boundary by >> 32 bits. >> > > That's *exactly* right. > > >> There is no reason to expect this to change if we make longer prefixes >> possible. >> It is just that end users will then end up with a /96 and find that they >> can't subdivide it any further. >> > > Right. So then someone will say, "we need to extend the network at the > edges!". And we move the boundary again, to /112. And then to 120, and then > to /124, until we get to one /128 per device. But long before that, a) > SLAAC is dead because there's not enough space in the prefix to form a > random IID, b) the hosts start doing NAT because they don't want to waste > their time. We now have 128-bit IPv4. Except that at least in IPv4, address > shortage was real. In IPv6 it isn't. > > Or, if we remove the boundaries altogether, we end up with /128 straight > away, because operational consistency. We now have 128-but IPv4 again. > Assuming the above path is true .... A 64 bit random iid is a very real security advantage. i will point out that things like the recent "wannacry" worm (like many worms before it) relied on dense guessable host ip addressing scheme that make address scanning effective. Making small guessable prefixes increases discoverability and decreases security. Please update the security section to include this massive regression in security posture for ipv6 that favors known and commonly used network scanning malware techniques of ipv4 will now be used in ipv6. -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c1b1dd0576672055122d1a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jun 4, 2017 at 6:10 AM Lor= enzo Colitti <lorenzo@google.com> wrote:
On Sun, Jun 4, 2017 at 8:05 PM, Phili= p Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
Moving on to a network architec= ture point of view, when using pseudo random
IIDs there will be a longest prefix that can be supported. Lets say for the=
sake of argument we can support of /96.

Then the effect will be that if in the future hosts support SLAAC upto /96<= br> then we are back at the same hard limit. We have just moved be boundary by<= br> 32 bits.

That's *exactly* right= .
=C2=A0
There is no reason to expect this to change if we make longer prefixes pos= sible.
It is just that end users will then end up with a /96 and find that they can't subdivide it any further.

R= ight. So then someone will say, "we need to extend the network at the = edges!". And we move the boundary again, to /112. And then to 120, and= then to /124, until we get to one /128 per device. But long before that, a= ) SLAAC is dead because there's not enough space in the prefix to form = a random IID, b) the hosts start doing NAT because they don't want to w= aste their time. We now have 128-bit IPv4. Except that at least in IPv4, ad= dress shortage was real. In IPv6 it isn't.

Or,= if we remove the boundaries altogether, we end up with /128 straight away,= because operational consistency. We now have 128-but IPv4 again.

Assuming the above path is t= rue ....

A 64 bit random iid is a very real securi= ty advantage. =C2=A0i will point out that things like the recent "wann= acry" worm (like many worms before it) relied on dense guessable host = ip addressing scheme that make address scanning effective. =C2=A0

Making small guessable prefixes increases discoverability a= nd decreases security. Please update the security section to include this m= assive regression in security =C2=A0posture for ipv6 that favors known and = commonly used network scanning malware techniques of ipv4 will now be used = in ipv6.=C2=A0


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--94eb2c1b1dd0576672055122d1a7-- From nobody Sun Jun 4 07:13:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B4C129505 for ; Sun, 4 Jun 2017 07:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK8UUZTlMaV3 for ; Sun, 4 Jun 2017 07:13:24 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 1D91512704B for ; Sun, 4 Jun 2017 07:13:24 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id v104so26682370wrb.0 for ; Sun, 04 Jun 2017 07:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0BMw64e01nW1+Bnc07uWZt4RLXB6G/loisCNbfhVfKw=; b=SzQ8bykUitOEPdjyhkQ+MrfAN30ojq1JxsQMSDUHH4n0xvANnYvZfiryMISFFAWheC MCbgKUJK1UXhQKkubEn9GelI58bdxGeNYvShMbIpJ+24ISGFeswZ5e0cUsyLAb2G8oba elttrgW40Fc3S5uW3HXxGQdp0CF7LpQyAsnCV3CVQ3nwIYr3KXwba+5hdAfaUpWJl4VT /3G0HtpwCetLh4rMMWZiKJQpTP0IONPphgOH+yKGtEaDpIQiKw7LHnZv0SPdXlDHhMST RFWd9/PON2v1W2mIOFWrL5JrnL7Tsd0gjcpUaXyJNi/N3ALaFP9y1d5REWFs8o//K2yh C/PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0BMw64e01nW1+Bnc07uWZt4RLXB6G/loisCNbfhVfKw=; b=dL3SSDqBvtsB5KAnzbKe0A4tKkhQ/G5jvNL2W/VIuK/PhGVYBPGju2xpsWLfknzVmn uIC5EOlM4VLUkiysBrhXsc4/hXoe2jWJGYae9bMolHBzIxidlC2futQ/wS4LWfdwKhNM s2MYq3y+ho3blb///mPJtmJlvhzXk/XhcC7G8gNjjTcKTvtV0665WAWiXiubjx8iDe5T EZ6UAQpV8Q/kqVcANbBvSKR6sashaQKaZCBiTjLRzX1FQ4F+bheFcTaa9TfO0Vjk5DqK kF7rD50Vxm96cVA2bEGmNvO7eM8ruZho6jXjTuDIuZWoYrHgjh+XElMnuwk+ojhTVDdX 3+Ww== X-Gm-Message-State: AODbwcAu6gIde+DLpjNC2ygKdfltcpSKjdIplSf48h7mZDqhPEAQSyW/ LkfSK871FgYSqaBoPf0tLkDH6bRQ/3MB X-Received: by 10.223.166.196 with SMTP id t62mr10058458wrc.52.1496585602596; Sun, 04 Jun 2017 07:13:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sun, 4 Jun 2017 07:13:21 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> From: Tom Herbert Date: Sun, 4 Jun 2017 07:13:21 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Ca By Cc: Peter Hessler , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:13:26 -0000 On Sun, Jun 4, 2017 at 6:07 AM, Ca By wrote: > > On Sun, Jun 4, 2017 at 5:48 AM Peter Hessler wrote: >> >> On 2017 Jun 04 (Sun) at 20:55:30 +0900 (+0900), Lorenzo Colitti wrote: >> :On Sun, Jun 4, 2017 at 1:51 PM, Tom Herbert wrote: >> : >> :> M bits for locator of physical device in mobile network >> :> N bits for identifier of physical device >> :> 128 - M - N bits for delegated addresses by the physical device >> :> >> :> I don't see a workable solution if device is assigned a /64. Am I >> :> missing something? >> :> >> : >> :There is no workable solution if you want to assign 64 bits to the bus, >> 64 >> :bits to the routing system, and M bits for mobility, unless M = 0. >> >> That's *exactly* why bus and routing MUST NOT require a specific size. > > > I would say this level of mobility or "nomadacity" has proven through the > years to NOT work at the network level in the INTERNET. > That is not what we are proposing (in ILA at least). This is not intended to work over the Internet. Mobility would be implemented within a carrier network, external to that network it is transparent. Logically, this provides the same functionality as encapsulation does with the benefit of not incurring the overhead of encapsulation. Tom > Just like ipsec has has failed where TLS has succeed, same for Mobile IP, > PMIP, and so on. The narror waist of the internet does not include mobility, > especially at a level that is transparent to the user. > > Just like always on dynamic ipsec for security, fine grain mobility was not > destine to be included in the routing system. Best to let go of this > usecase rather than tilting more at the windmill. > > >> >> >> -- >> What is a magician but a practising theorist? >> -- Obi-Wan Kenobi >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sun Jun 4 07:20:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81F129B38 for ; Sun, 4 Jun 2017 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOLYmX8SZU8X for ; Sun, 4 Jun 2017 07:20:16 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820A129B33 for ; Sun, 4 Jun 2017 07:20:16 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A8355E6067; Sun, 4 Jun 2017 16:20:14 +0200 (CEST) Date: Sun, 04 Jun 2017 16:20:14 +0200 (CEST) Message-Id: <20170604.162014.74657518.sthaug@nethelp.no> To: lorenzo@google.com Cc: linux@thehobsons.co.uk, ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: sthaug@nethelp.no In-Reply-To: References: <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:20:18 -0000 > > So for example, here you are adamant that a device should not have to "ask > > the network" for more addresses. What about networks where there are other > > priorities, what if the operator of a network requires to track > > addresses/address usage for whatever reasons ? > > > > Again, the answers are in RFC 7934. See section 9.1 which goes into some > detail on address tracking. But basically: tracking via DHCP is insecure > unless you have L2 security, and if you have L2 security, you may as well > use that to track addresses. Tracking via DHCP is good enough in many cases, and already implemented in lots of support systems. L2 tracking has an extra cost. Guess which will be used? Steinar Haug, AS2116 From nobody Sun Jun 4 07:26:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7F129B33 for ; Sun, 4 Jun 2017 07:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUST0axOPcte for ; Sun, 4 Jun 2017 07:26:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B2DA1128B4E for ; Sun, 4 Jun 2017 07:26:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dHWU5-0000HLC; Sun, 4 Jun 2017 16:26:25 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> In-reply-to: Your message of "Sun, 4 Jun 2017 07:13:21 -0700 ." Date: Sun, 04 Jun 2017 16:26:24 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:26:29 -0000 In your letter dated Sun, 4 Jun 2017 07:13:21 -0700 you wrote: >That is not what we are proposing (in ILA at least). This is not >intended to work over the Internet. Mobility would be implemented >within a carrier network, external to that network it is transparent. >Logically, this provides the same functionality as encapsulation does >with the benefit of not incurring the overhead of encapsulation. The current IPv6 address architecture is basically a relatively densely allocated /64 prefix plus an extremely sparse 64-bit IID. With DHCPv6 you can today have dense IIDs that allow space for experiments. However, without a clear consensus that embedding identifiers in IPv6 addresses is good idea, it strikes me as bad to use that as an argument to change how SLAAC works. At least for me, messing up the IPv6 address architecure just to save the overhead of encapsulation is not worth it. From nobody Sun Jun 4 07:44:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BFD129B5B for ; Sun, 4 Jun 2017 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_rOlPwW9rfb for ; Sun, 4 Jun 2017 07:44:17 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2427F129B5A for ; Sun, 4 Jun 2017 07:44:17 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id d73so6788476wma.0 for ; Sun, 04 Jun 2017 07:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PA/K+Jd1jmS0rLnFNDhVlElwYo3sCXLp/9BrdNNKwMo=; b=MZCKdeBFpDvzMaJsFw53aZ6pghDbyzpLSmNAEZQ83cUmGnoZ0Aljs1liYSQyjafCJU DvVM6ymwuwVfis52CBpFHosXsh/Cuvm/f8Ttr43PfjSbYMxw83kRg+xB0BRSczyt3b1P 4UdvFbrngKJbOBSe7U5S76hI3DB6IPBvyq9eRBWg2xj8ytP7N22WKZOGwh2Nzc4VT5YT LY5eikFZBmNBNdbS8WJWqWk5fyQnIEoJicAyyUbxCO9y9uni5tHT55DkVWM+bIAQiTHk mFsdzHG5sLfomtBzZBT53l2sgZcG/LrvVmu2TE7xHCWhNo4Sb7hkye83u626TpW1G7zo 63ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PA/K+Jd1jmS0rLnFNDhVlElwYo3sCXLp/9BrdNNKwMo=; b=nF8X9RNMUWnKEtCca4emp4T93GvVXpO32gNmemmliDWYiZatRHzG1GQ5cFgjR9Bugz jbdE+hSZIR84h7dWsCGDCiirPFgXAKY3zdd8WvmhJkVBAO93EEUyQ54gaM9FhGqdLUPJ FlJAZ27vn4E5GsuAGhtuiezI9TKpg1vS2xLorKadLuVSq09ygxb7dFwkxVKykN2CX3ru +w0cMq/Lit0i8e66gU2l4e2yDh52ntv9xLSTni9Dw4FHgGKQJz7EyLdMEH+Jw7BnyFNr 0JVM/JfVO8CiKg+JZPRYf64eZSiC9WZDQY1Nc+tCjoRjJtimMNK+rYumJnCGh2QlkBif n0qA== X-Gm-Message-State: AODbwcDoOUFDKxb52S69TIZahcxmDoyHZ2jK4slodN6KHVaaEPxBbDGd gQf7LkK4TxTps7LC7GAqXQyiQwobM6fp X-Received: by 10.28.56.198 with SMTP id f189mr4778153wma.111.1496587455540; Sun, 04 Jun 2017 07:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Sun, 4 Jun 2017 07:44:14 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> From: Tom Herbert Date: Sun, 4 Jun 2017 07:44:14 -0700 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Philip Homburg Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:44:21 -0000 On Sun, Jun 4, 2017 at 7:26 AM, Philip Homburg wrote: > In your letter dated Sun, 4 Jun 2017 07:13:21 -0700 you wrote: >>That is not what we are proposing (in ILA at least). This is not >>intended to work over the Internet. Mobility would be implemented >>within a carrier network, external to that network it is transparent. >>Logically, this provides the same functionality as encapsulation does >>with the benefit of not incurring the overhead of encapsulation. > > The current IPv6 address architecture is basically a relatively densely > allocated /64 prefix plus an extremely sparse 64-bit IID. > > With DHCPv6 you can today have dense IIDs that allow space for experiments. > > However, without a clear consensus that embedding identifiers in IPv6 > addresses is good idea, it strikes me as bad to use that as an argument > to change how SLAAC works. > > At least for me, messing up the IPv6 address architecure just to save the > overhead of encapsulation is not worth it. > Maybe it will be proven to be be worth it, maybe not. And this probably true of other interesting things we could do with the large IPv6 address space. But, I think imposing an artificial architectural constraint that prevents us from even *trying* an alternative like this is unfortunate. For all the talk that this draft forces IPv6 to be like IPv4 I think it's the exact opposite at least in the this case: /64 is preventing us from doing something different and potentially innovative in IPv6 compared to IPv4. Tom > From nobody Sun Jun 4 12:50:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119D2129410 for ; Sun, 4 Jun 2017 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdEnUjDWKRvD for ; Sun, 4 Jun 2017 12:49:58 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A11128CD5 for ; Sun, 4 Jun 2017 12:49:58 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 9E13997A for ; Sun, 4 Jun 2017 19:49:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VunE-d5XugPF for ; Sun, 4 Jun 2017 14:49:57 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 6B4D3284 for ; Sun, 4 Jun 2017 14:49:57 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id p85so35181621vkd.10 for ; Sun, 04 Jun 2017 12:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=922DgpUKVq0dSPM2f30i6sW34PKhgT3++qTKNBySQEk=; b=Sq81FBq2kjKx30RPbcKLmAGwTwbCt2jPh/KAZ+xWsvqZg9ViNc6xX2LcLrcLi1cmqY tQnWSIDItjHDPuXMIvtJoDlLCmTfbURb+q+3CMUsPu4xyHtDndDptWKYJUO3hKpRC8Ql SttgAiXEvymN78vh7pgggainJjapCX3GHH2u2StQugsrZ1si/Xb5ef6NkkZcMjGU0cIg o1bYWohQlgCSipF9ohoKZXF0Q+xiu3GU4QiF3GYNKVGfr8b3fYdbwbCMfb8aXphuXlHv BEZB5JyIOHcE3w5AtT/x0tamvqSUqs1o2smMhaA/quktv0wlFSqOT4BXUPLfjefirqvf aQeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=922DgpUKVq0dSPM2f30i6sW34PKhgT3++qTKNBySQEk=; b=PnQWTK/deQWNZEVL2kt8bVIHZ/rKQiOyLwtp4GtdS3f4q2hnZjMI+7pKZIAL4WciNz ZNQE9NZ2p6IZWbcoWDjZk05bbQJIs4xHtVXaoowEzVPg6BVhmXGUjDjDcilCLVbhj0Vb dxgpWBhup1zVgOIF1uwgk3me7WDdyQOMs6X/Y0V80U7++ICHt9YjFIxkF4Bx3gL/l5gr QwG63WPLkgLzfinhYyjPNCeIz0i0laCdwDqRbLr0hsja6EmdyWrPdO9rpSBCubvWhXxj nHjcBY7jQAEYoaxvGaFFAA0ZDM2YA9DjZzuIkZPCqsY6lF93bZ+ssTgmUZ6RJW5LleHI 0CFw== X-Gm-Message-State: AODbwcA+U/zNGOn+HXg89Ydp51e6bkXVYbrd2SS13Rfh/ZKMQhyHp6lf 3V4fOQqBz52Rz9oYpyTQnKKjTJDFkyr4+ZsTFTxA100q4v8OTb0CnsxceNBDmYLrsWcKkMFtMu3 JBFGknbjpSbKj68U= X-Received: by 10.31.65.197 with SMTP id o188mr8275707vka.7.1496605796649; Sun, 04 Jun 2017 12:49:56 -0700 (PDT) X-Received: by 10.31.65.197 with SMTP id o188mr8275700vka.7.1496605796458; Sun, 04 Jun 2017 12:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.137 with HTTP; Sun, 4 Jun 2017 12:49:55 -0700 (PDT) In-Reply-To: <20170604.162014.74657518.sthaug@nethelp.no> References: <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> <20170604.162014.74657518.sthaug@nethelp.no> From: David Farmer Date: Sun, 4 Jun 2017 14:49:55 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "sthaug@nethelp.no" Cc: Lorenzo Colitti , 6man WG Content-Type: multipart/alternative; boundary="001a114dde62ddf4e0055127b0ee" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 19:50:00 -0000 --001a114dde62ddf4e0055127b0ee Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 9:20 AM, wrote: > > > So for example, here you are adamant that a device should not have to > "ask > > > the network" for more addresses. What about networks where there are > other > > > priorities, what if the operator of a network requires to track > > > addresses/address usage for whatever reasons ? > > > > > > > Again, the answers are in RFC 7934. See section 9.1 which goes into some > > detail on address tracking. But basically: tracking via DHCP is insecure > > unless you have L2 security, and if you have L2 security, you may as well > > use that to track addresses. > > Tracking via DHCP is good enough in many cases, and already implemented > in lots of support systems. L2 tracking has an extra cost. Guess which > will be used? > > Steinar Haug, AS2116 > On this point I have to agree with Lorenzo, tracking MAC addresses with DHCP without the addition of L2 security to enforce it is pointless. What about static assignment of addresses, without L2 security there would be no way to prevent it. We scrape Neighbor Discovery tables out of routers just like we do for ARP tables in IPv4. It is independent of how the addresses are assigned, it works with static assignment, DHCP, SLACC, and what ever else comes along. The whole point of address tracking is accountability, having accountability only for the people that follow a rule, what ever it is, is kind of pointless, you need to track the rule breakers too. Therefore you need a tracking solution that is independent of address assignment. Since we can track any address used, in most parts of our network we allow SLACC for IPv6 address assignment, because it's the easiest to use in most cases. That said I still think DHCP is a perfectly valid mechanism for address assignment as well. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114dde62ddf4e0055127b0ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jun 4, 2017 at 9:20 AM, <sthaug@nethelp.no> wro= te:
> > So for example, here you ar= e adamant that a device should not have to "ask
> > the network" for more addresses. What about networks where t= here are other
> > priorities, what if the operator of a network requires to track > > addresses/address usage for whatever reasons ?
> >
>
> Again, the answers are in RFC 7934. See section 9.1 which goes into so= me
> detail on address tracking. But basically: tracking via DHCP is insecu= re
> unless you have L2 security, and if you have L2 security, you may as w= ell
> use that to track addresses.

Tracking via DHCP is good enough in many cases, and already implemented
in lots of support systems. L2 tracking has an extra cost. Guess which
will be used?

Steinar Haug, AS2116

On this point I ha= ve to agree with Lorenzo, tracking MAC addresses with DHCP without the addi= tion of L2 security to enforce it is pointless. What about static assignmen= t of addresses, without L2 security there would be no way to prevent it. = =C2=A0

We scrape Neighbor Discovery tables out of = routers just like we do for ARP tables in IPv4. It is independent of how th= e addresses are assigned, it works with static assignment, DHCP, SLACC, and= what ever else comes along.=C2=A0 The whole point of address tracking is a= ccountability, having accountability only for the people that follow a rule= , what ever it is, is kind of pointless, you need to track the rule breaker= s too.=C2=A0 Therefore you need a tracking solution that is independent of = address assignment. =C2=A0

Since we can trac= k any address used, in most parts of our network we allow SLACC for IPv6 ad= dress assignment, because it's the easiest to use in most cases. That s= aid I still think DHCP is a perfectly valid mechanism for address assignmen= t as well.=C2=A0

Thanks.
--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Tele= communication Services
Office of Information Technology
University of= Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612= -812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
--001a114dde62ddf4e0055127b0ee-- From nobody Sun Jun 4 16:06:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2B112E056 for ; Sun, 4 Jun 2017 16:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRLIct_HAKhz for ; Sun, 4 Jun 2017 16:06:01 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52470127B5A for ; Sun, 4 Jun 2017 16:06:01 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id m17so74430695pfg.3 for ; Sun, 04 Jun 2017 16:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Qg5KMarbbzI2vHng2L05JMUtbymogTI265SxWD5fSdg=; b=RFBKWApINLusDEAudO5aIenhkSElBiXEQqAdHxEnUadrS4SD6Tr1iY65CyOq3jHWRM G+vH8dhOdNwj/e55qg3pRmujR+novDvlAjh602vW7INyhcAoYWBob2kcvrYX113Z86ai DsPT9vuEdvzDpkoCNpWXWHffvV1fGpQ+Gzd4tdTd+Np8j1iz8Jub3mztAC2+JHVK3lJ9 mTlNe4WfRXDinuj/mIkQvT8U82JiIdsBhzQz+bok+czAd/lUAd3pKpKbiBXac8dIYdcR Tdpg9tbk81AzmtaosoBhrmNrHrVk/7TbeMesOUUB2kmWTva82cidrVQDEgCM0WVIyl5z 5EVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Qg5KMarbbzI2vHng2L05JMUtbymogTI265SxWD5fSdg=; b=hHwRALUzbVizeLgOMwrGQmMSjsRBOnKr8godGqMs+lbDLMwX1ZzqMmJGiLqPqUBb5U hfo1DPanD1N5ouQV0EcMsJCQ9iTzGTJgiFKGVn+0RHv+15nPpEYJrpz89oqbPhulmv4d KCKtaq6Gs80xSpIG6D6SU9QBtJsZpXA2QpUCUtZB5ye4sPtyvhrOnovrUGaXCtD4rYbI qnLYX2GFNTu9LRMQE6lGYaOlpR/QYNAtGbyhP5YCi+3R+WCUI2BocXq1Ob5Dw65R2c4n P1B7AQ/rM/uzhB0WlCq6MvK/MSS0f1zeAgzIrYaC5hQkEsnE4+IQHQ5TJ1V8WmerwQeC wmoA== X-Gm-Message-State: AODbwcBtAsPS+XFx7hZO7dBkV/+c8W2JtciqIdc6v/YTiZ+QnwEb3DaE 8tyY81Vib/hq7mA0 X-Received: by 10.84.224.6 with SMTP id r6mr11576804plj.132.1496617560628; Sun, 04 Jun 2017 16:06:00 -0700 (PDT) Received: from ?IPv6:2406:e001:3d38:1:28cc:dc4c:9703:6781? ([2406:e001:3d38:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 189sm22471004pgi.66.2017.06.04.16.05.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 16:06:00 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Ca By , Lorenzo Colitti , Philip Homburg Cc: IETF IPv6 Mailing List References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> From: Brian E Carpenter Organization: University of Auckland Message-ID: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> Date: Mon, 5 Jun 2017 11:05:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 23:06:03 -0000 On 05/06/2017 02:00, Ca By wrote: > On Sun, Jun 4, 2017 at 6:10 AM Lorenzo Colitti wrote: > >> On Sun, Jun 4, 2017 at 8:05 PM, Philip Homburg < >> pch-ipv6-ietf-4@u-1.phicoh.com> wrote: >> >>> Moving on to a network architecture point of view, when using pseudo >>> random >>> IIDs there will be a longest prefix that can be supported. Lets say for >>> the >>> sake of argument we can support of /96. >>> >>> Then the effect will be that if in the future hosts support SLAAC upto /96 >>> then we are back at the same hard limit. We have just moved be boundary by >>> 32 bits. >>> >> >> That's *exactly* right. >> >> >>> There is no reason to expect this to change if we make longer prefixes >>> possible. >>> It is just that end users will then end up with a /96 and find that they >>> can't subdivide it any further. >>> >> >> Right. So then someone will say, "we need to extend the network at the >> edges!". And we move the boundary again, to /112. And then to 120, and then >> to /124, until we get to one /128 per device. But long before that, a) >> SLAAC is dead because there's not enough space in the prefix to form a >> random IID, b) the hosts start doing NAT because they don't want to waste >> their time. We now have 128-bit IPv4. Except that at least in IPv4, address >> shortage was real. In IPv6 it isn't. >> >> Or, if we remove the boundaries altogether, we end up with /128 straight >> away, because operational consistency. We now have 128-but IPv4 again. >> > > Assuming the above path is true .... > > A 64 bit random iid is a very real security advantage. i will point out > that things like the recent "wannacry" worm (like many worms before it) > relied on dense guessable host ip addressing scheme that make address > scanning effective. > > Making small guessable prefixes increases discoverability and decreases > security. Please update the security section to include this massive > regression in security posture for ipv6 that favors known and commonly > used network scanning malware techniques of ipv4 will now be used in ipv6 Yes. Any IPv6-over-foo that proposes a boundary at, say, /96 would have to explain why 32 bits of pseudorandomness is enough. And we could perfectly well have a guaranteed security DISCUSS on boundaries beyond some magic number. Maybe that number would even be /64, but I think /80 is more likely. None of that is the point. The point is to establish that routing is classless and /64 is a parameter of specific addressing schemes. Probably the draft is too long, which obscures that simple message. Brian From nobody Sun Jun 4 17:45:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5A124234 for ; Sun, 4 Jun 2017 17:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTWW0dcuP5tU for ; Sun, 4 Jun 2017 17:45:35 -0700 (PDT) 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 A972B1200C1 for ; Sun, 4 Jun 2017 17:45:35 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id p62so24634821vkp.0 for ; Sun, 04 Jun 2017 17:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JJ01tSBG4Q700gxX8VijNJlUZiUwbz/s/KsHw6GbGY4=; b=XT6szkwFXWg9S/+ckBWcMxYIPYO9SSii+gksWmXG6G5Eaiu8vptLDmEb1UR9XEGz7H +KD5Mzlp+5Tt150yMk0FiNAU2p+Xa1wjw7zPrA3hglec1gnQa5vPBm3hXxiyounbxake PMtAbsi6XltEl25VpQ1uvBHU2LKhFuv/gqdtdniIF7wPhYG5aQPls1hDfq/wzOdG46gz 1MDspM1iVSarbDk1oRktYinc7cShcOhaIrN2RmjJhbomhZf0FDBLC4aiDWm2SL/KzazL o5kcdnzYf8dOvC6XZKhd9Zb6B5otDd2WcMRKHRWMz8q0+aQAvW+fNo5RZvq9HNFm0Xy5 /80w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JJ01tSBG4Q700gxX8VijNJlUZiUwbz/s/KsHw6GbGY4=; b=IRbnNneiMJ8IHV5GQKsqfoRkZl2UTSJxnfvT4Q2osZBp+MuozM4Ix9XAMRKvUTkLTH V4RX6gYQDAihZwCbFuIbaTk+uWYU/AEd23y0bC2sdzDgFv08M6SFG/TGh7dGAdiMgyIM O9beXeWal7hekhIdQerPav6XRSBCAyld+AvzBqP4FKBHEr0CXqE2U7pjd0u5BhThkLXL 9T9MRKyR0tpbSrY4xlS1yreMTGxcQLtqn3QrG9bDAlj7SnveC5pZ0RbrjT+wMRpoovK4 DGyR1uWaOLbHAd1KutPTC+6UUfZwaAb6vsSaYmXwnja54d85cKRSnnWa0yKo0OQO60WK 8aLg== X-Gm-Message-State: AODbwcDA6JomIKBlqXS+ZVelC8FXzZK9jRn010+QA/ugsIiwyhjyDh04 cacy6+3qMsJQtIa56vp1HNjZ7wULb/io X-Received: by 10.31.158.195 with SMTP id h186mr8834564vke.30.1496623534760; Sun, 04 Jun 2017 17:45:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Sun, 4 Jun 2017 17:45:04 -0700 (PDT) In-Reply-To: <20170604093119.nt733rb3ymmjssww@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> From: Mark Smith Date: Mon, 5 Jun 2017 10:45:04 +1000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 00:45:37 -0000 Adding new features to try to encourage adoption or making it resemble IPv4 as much as possible still won't make a difference to adoption by businesses if it isn't the best way to solve a business problem. On 4 June 2017 at 19:31, Job Snijders wrote: > On Sun, Jun 04, 2017 at 10:55:59AM +0200, Roger J=C3=B8rgensen wrote: >> On Sun, Jun 4, 2017 at 3:33 AM, Lorenzo Colitti wro= te: >> > On Sun, Jun 4, 2017 at 2:34 AM, Roger J=C3=B8rgensen wrote: >> >> >> look into the numbers, I assume there are one huge group missing >> there, the enterprises and that's where the money, and damage will be >> done. > > You talk about "damage", I think what you meant to say is "finally, the > enterprise will deploy IPv6 too". > In enterprises, the only "marketing" IPv6 needs is that it solves a business problem, either better than IPv4 does or that cannot be solved by IPv4. It doesn't need new features purely to try to encourage adoption or to better resemble IPv4 to encourage adoption. There are enterprises where IPv6 is the better way to solve a business problem than IPv4 - service providers and utilities using smart meters. A great way to remember this view on technology - when you go to the hardware store to buy a drill, what you're really buying is a hole. Regards, Mark. From nobody Sun Jun 4 20:38:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F0F126D73 for ; Sun, 4 Jun 2017 20:38:30 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoTlPj5I3H1R for ; Sun, 4 Jun 2017 20:38:29 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 5F1F6120046 for ; Sun, 4 Jun 2017 20:38:29 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id x47so69374058uab.0 for ; Sun, 04 Jun 2017 20:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=24LeTCILcGiRXZS8amaefg+cnNtZ4LDxNCIeDe6cJmk=; b=WcddglOK+52jRHvSl0eWmvACenbS3uNfJsRO6g55a3/xzawTDM1u2BJY5uHBbqtBqW Gxmi2sNzuWgQcTGLX8Vh63rUOqsZDBTiZxSodKwwfE1NTBjV4XhxIYonjIVyUHp+WE0s wXMCkRBEzOeEaqotFB3PYL/4xKgjqYUh9FYLxaE5FJ0PgGEAeIF87qkdfED7mjWdkYqK 3xdln2uqaGX99QhmD+RMkf0v0BiZSiF+c2I+4TSSgh3GczMDOVGUZUFFJuRHSfIEsM/n hRTW9GvrlpMXMBHS5ue6teJRBEKyKneqDTtL4apeYnOw9XXdfhYwWyEnigcL5ZJ1Gh14 qNbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=24LeTCILcGiRXZS8amaefg+cnNtZ4LDxNCIeDe6cJmk=; b=ldH9sMhhhl5dhiEXovSjMA3UEehK7k9nAuWxClW18Aj0CVokHMRwPdyrCp0hOKdMWp 2egJMya/pTpmhJXfXlAohYMn+VEhbd5ZWhklvpP5AAF4m9M05RE+fWBApYp8qRAWMDSI v8OEXaZXQjB+vcLnjysWMSa8fBgO+mA0wBoUk2wy3o5nMEZ15ylICItuywGdl71mpoBr AAcF7PWf8E8yvaGWU6wzkjlWhYd6Ef602prUn3HS2nSFieQVWue+fA8u6xqPzM7SQh4R 4hDRm6xivW88FWzVG59iF4tia2ZucdYYIBqb/n1MFhImT6CMq6VrWbrecbh7+puC6pbX GBjw== X-Gm-Message-State: AODbwcAK2ReXz5WI9JsGyk+jIMN9EjQBVA0sJ4cHU/w/TdoHqwq2q+Rm Ormw+efokW+/Wrrkcwe0p3u0/PLqC1SJ X-Received: by 10.159.60.156 with SMTP id s28mr10140633uai.94.1496633908374; Sun, 04 Jun 2017 20:38:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Sun, 4 Jun 2017 20:38:07 -0700 (PDT) In-Reply-To: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Jun 2017 12:38:07 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Brian E Carpenter Cc: 6man , draft-bourbaki-6man-classless-ipv6@ietf.org Content-Type: multipart/alternative; boundary="089e08e4d381781cb705512e3c6b" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 03:38:30 -0000 --089e08e4d381781cb705512e3c6b Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 5:43 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > If this proposal is accepted, then I think /120s will become the > > defacto subnet size, despite what the draft says about /64s being the > > recommended default. > > Predicting the future of complex systems is hard, but I think this > prediction is wrong. There are some very strong arguments against > prefixes that long, and it is the IPv6-over-foo specs that prevent > such long prefixes being used. > None of which the people deploying /120s will understand or even be aware of. Seriously: I've seen premier-grade IT departments - even in well-funded, very technical companies with a very high hiring bar - deploy NAT66 in their corporate networks without understanding that it would break applications. --089e08e4d381781cb705512e3c6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 5:43 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
> If this proposal is accepted, then I think /120s will become = the
> defacto subnet size, despite what the draft says about /64s being the<= br> > recommended default.

Predicting the future of complex systems is hard, but I think this prediction is wrong. There are some very strong arguments against
prefixes that long, and it is the IPv6-over-foo specs that prevent
such long prefixes being used.

None of = which the people deploying /120s will understand or even be aware of. Serio= usly: I've seen premier-grade IT departments - even in well-funded, ver= y technical companies with a very high hiring bar - deploy NAT66 in their c= orporate networks without understanding that it would break applications.
--089e08e4d381781cb705512e3c6b-- From nobody Sun Jun 4 20:43:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6D112702E for ; Sun, 4 Jun 2017 20:43:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvCzzDztTF46 for ; Sun, 4 Jun 2017 20:43:39 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 A274B126D73 for ; Sun, 4 Jun 2017 20:43:39 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id x47so69410088uab.0 for ; Sun, 04 Jun 2017 20:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wnaHrorj5Z7wZHTjAhFQ1GpDMyFtxW+v5uxnfWLNBYA=; b=FNPY8llubtMJfQLAI4mkS3Jn+955GjAntMA86bpXkCVvazQG+b7J4AU8xNVj2Yo3gW usJTKcftoWxVd9l/izweMYFA5L77PJb7oyGoA99eV6ddw/ftO3be6Ujo/u8q6nkxSf0K YxPcHIX18Tht5ykIe6XoU+rdH1NXje3ufNqrvyP0ZavKSpOZaDR7GnSQnC9I3RpXheas zb1iZs0V6kVaR2+qy7B9yN/mUWG9RW1p9fds1UxsHhlEJwWwyA0RIXgjLrLQ968ILw8S uOwFXZEYXMVZWIqWlhFBgUTF8ixt9Yzsts9gtQU8jYn0iXUlrL6NR/oIPaSqXzCcgkM/ ozCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wnaHrorj5Z7wZHTjAhFQ1GpDMyFtxW+v5uxnfWLNBYA=; b=TMYnklSEZ+2m6By3E3im6tjVtYqlfMAGVguyG3IpwQusuPAlhbCjsJRJU7m/QifiRm LVS0iV/pL4xq8tAcjpewS1fQwzCsywKHjO9eF4Z437A36/hFcT/cBi6iu2QiRzD/ItzQ NrNx8fEXrZ0mSh5O29MtCOimz5KObZLDq2ttZX8D2bMKm1yg4zbz5Rr1nw8D+ImCjHSV GQ3L62NRNB/qPujigHGsxobMlyCq2b7ltmcY9BSusrK2AScfZPGfwuL09d8AWjjKWEjb yrtMseafsoG5Y0q2YT/MbqlllRCQP4POetndG+G4fP4jGMt8na/2XsUhTKXK3D6d5WMP h6pg== X-Gm-Message-State: AODbwcCYylxK8hKXGp8me9TsuxKH2hUtzjwBwAsHaU0wOuhqmDYjH2uj O5r+wEbSwssJWi/SSLxPVYytI5xHj3jh X-Received: by 10.176.95.217 with SMTP id g25mr6002554uaj.71.1496634218659; Sun, 04 Jun 2017 20:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Sun, 4 Jun 2017 20:43:17 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Jun 2017 12:43:17 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Brian E Carpenter , draft-bourbaki-6man-classless-ipv6@ietf.org, 6man , Steven Barth Content-Type: multipart/alternative; boundary="089e08204960f6a35b05512e4e11" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 03:43:41 -0000 --089e08204960f6a35b05512e4e11 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 12:50 PM, Mark Smith wrote: > If you know IPv4, and you don't want to or don't have time to properly > learn IPv6 (which seems to be one of the motivations for this draft), > then here is the easiest way to deploy IPv6 without understanding > IPv6: > > 1. Take your IPv4 address in IPv4 format, leveraging your existing > IPv4 addressing plan > 2. Prepend it with the IPv6 GUA or ULA 96 bit prefix > 3. Subtract the IPv4 host bits from 128 and append > > e.g., the resulting IPv6 addresses for 1.2.3.4/24 would be > > 2001:db8::1.2.3.4/120 > > That format address is accepted on loopback when I use the Linux 'ip' > and 'ifconfig' utilities and I can ping it, so it has passed the first > "can I even configure it" test. If it works on other IPv6 > implementations, this way of deploying IPv6 while avoiding learning > IPv6 could easily become popular because of its simplicity. > Exactly. Realistically, the only reason this is not a widespread practice is that some OSes do not support DHCPv6. > (Actually, stateful DHCPv6 can introduce them - OpenWRT supports it > and uses the same sized IID range for DHCPv6 as it does for DHCPv4 > addresses. Until I recently worked out how to turn it off (because > that isn't obvious either), my Fedora hosts with wonderful RFC4941 and > EUi-64 global addresses via SLAAC also had global IPv6 stateful DHCPv6 > addresses from within a range of 100 addresses.) > That sounds *really* bad for privacy and security. With end-to-end connectivity, it's trivial to scan the first 255 addresses and find all hosts on the subnet very quickly. Steven, are you the DHCPv6 maintainer for openwrt? Were you aware of this? --089e08204960f6a35b05512e4e11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 12:50 PM, Mark Smith <markzzzsmith@gmail.com&g= t; wrote:
If you know IPv4, and yo= u don't want to or don't have time to properly
learn IPv6 (which seems to be one of the motivations for this draft),
then here is the easiest way to deploy IPv6 without understanding
IPv6:

1. Take your IPv4 address in IPv4 format, leveraging your existing
IPv4 addressing plan
2. Prepend it with the IPv6 GUA or ULA 96 bit prefix
3. Subtract the IPv4 host bits from 128 and append

e.g., the resulting IPv6 addresses for 1.2.3.4/24 would be

2001:db8::1.2.3.4/120

That format address is accepted on loopback when I use the Linux 'ip= 9;
and 'ifconfig' utilities and I can ping it, so it has passed the fi= rst
"can I even configure it" test. If it works on other IPv6
implementations, this way of deploying IPv6 while avoiding learning
IPv6 could easily become popular because of its simplicity.

Exactly. Realistically, the only reason this is not a = widespread practice is that some OSes do not support DHCPv6.
=C2= =A0
(Actually, stateful DHCPv6 can intr= oduce them - OpenWRT supports it
and uses the same sized IID range for DHCPv6 as it does for DHCPv4
addresses. Until I recently worked out how to turn it off (because
that isn't obvious either), my Fedora hosts with wonderful RFC4941 and<= br> EUi-64 global addresses via SLAAC also had global IPv6 stateful DHCPv6
addresses from within a range of 100 addresses.)

<= /div>
That sounds *really* bad for privacy and security. With end-to-en= d connectivity, it's trivial to scan the first 255 addresses and find a= ll hosts on the subnet very quickly. Steven, are you the DHCPv6 maintainer = for openwrt? Were you aware of this?
--089e08204960f6a35b05512e4e11-- From nobody Sun Jun 4 21:13:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55766126D73; Sun, 4 Jun 2017 21:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsdU7bQ2zl27; Sun, 4 Jun 2017 21:13:37 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F33124234; Sun, 4 Jun 2017 21:13:36 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id m17so76932056pfg.3; Sun, 04 Jun 2017 21:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8cesbhOW0WDD4XAW7P+ac059QgVAT6nsM/rPtshsFlI=; b=XhViEu3xO0I1YEF+J4d/2hi/oEdyCoF8slGXlt9DBkw20oEq8ZZ6A2lcxprkVc9cgn 6tO7kbpbh/6zKEeNfl+uy7vvFC5re6auAPfCEXep2Pg0Yq5OpXXK1hVXDY/GTnHRJT6R EZxfEDDlV/Nlaf91VbPnXCZr7XZxW6ZEZGBdP0XQIXRlHDdoG92z+aQRTzV5/dPJnui8 JkRsjIi5obbGHnp9s9qPr55TeHNP9E44UmOTtZZM4sNZ9FYB2fUmedgbz2WxoBqzrOXT 2Lx2bWPMmixNWtYFtEp90f/ZTIcczbtBX7nPO2bIXiEOwsFO/NDTTlx6BW2Ig0rONn0E jN2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8cesbhOW0WDD4XAW7P+ac059QgVAT6nsM/rPtshsFlI=; b=S2bSLAWVK2CXU7KaT4P8hy7aQFIExg2c6qlIylVkyXJJuFClcNNNjqSuT8ZHNNztBh D7DUhqbHMzdcuVek6AeB2x+2NK7ZLCgcsVAQwNyitdPl02Foko8zwHLuF6n077OgxZ0v MyF52Kbo4d0WoStDAjR4O6dlj8NiDyP8hhWwQ+9E7oGwiE1SEcDXOeAFoT3j027jrC0U ge6Q3oiIboHYENN0/LSRA6+sKc7h6AW52ERx/77GCv2/CcvDAqYqXEO8ahV9h7kwSJCc X9A8U7kneESvEcOtUfggsd18rOXKJ2GOo2asQYd2jfzJV1H5l9zZopveSE0VA0pQa9y8 C/Ig== X-Gm-Message-State: AODbwcDEq10UkNZippGs8+KJor+A0o5ZEo7J7pwHnDUGL2VskDmvLkVK WH/+j29Clu7nm2TJ X-Received: by 10.98.35.148 with SMTP id q20mr3430160pfj.237.1496636016374; Sun, 04 Jun 2017 21:13:36 -0700 (PDT) Received: from ?IPv6:2406:e001:3d38:1:28cc:dc4c:9703:6781? ([2406:e001:3d38:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e20sm12511897pfh.121.2017.06.04.21.13.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 21:13:35 -0700 (PDT) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti Cc: 6man , draft-bourbaki-6man-classless-ipv6@ietf.org References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 5 Jun 2017 16:13:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 04:13:38 -0000 On 05/06/2017 15:38, Lorenzo Colitti wrote: > On Sun, Jun 4, 2017 at 5:43 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> If this proposal is accepted, then I think /120s will become the >>> defacto subnet size, despite what the draft says about /64s being the >>> recommended default. >> >> Predicting the future of complex systems is hard, but I think this >> prediction is wrong. There are some very strong arguments against >> prefixes that long, and it is the IPv6-over-foo specs that prevent >> such long prefixes being used. >> > > None of which the people deploying /120s will understand or even be aware > of. Seriously: I've seen premier-grade IT departments - even in > well-funded, very technical companies with a very high hiring bar - deploy > NAT66 in their corporate networks without understanding that it would break > applications. I don't doubt it. But nothing today stops them using DHCPv6 exclusively and deploying /120s - just too bad for any users of an o/s that doesn't support DHCPv6, right? I don't mean I like this. Actually I see no reason today to deploy anything other than /64. I just want to see a correct architectural description of what we have. Brian From nobody Sun Jun 4 21:57:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF423126BF7 for ; Sun, 4 Jun 2017 21:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTYItn3AObEC for ; Sun, 4 Jun 2017 21:57:19 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 7D0FB1242F5 for ; Sun, 4 Jun 2017 21:57:19 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id v104so31950531wrb.0 for ; Sun, 04 Jun 2017 21:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:cc; bh=xIAyj1KXcX0c86yqaSXgpJMjya1lmREO81DbNBQQKeQ=; b=rnHbIEHDS489FFcXFU01f/uwZy3fpHdG1ikNw7aFKxWRc32aDF/3lE9+ihFeIMTfQ2 jWUP4FN+k7wtCUUTg4DGJHNXfvc1jxdlg7HlVvgkH9YPkWMd5zpEGwh+W1gXCP9bbNze yhLP3mFpJBrevhaPrQQJE+KLXbDufOK38bAqbjURdmBs/Skf38y1WJ7uWqtAF8BL5PSS 5L0EmqVtO3asUjFvzn1Jm7vFqiSDStUqBvkepDUvUZfu+a0AOdlZh8qT7wj87QdDaHhJ /wJi6VGdH5uKd4TKcjulMxhe2KkdDW1P3f31pZ58wfTkk7MYffRjj6V3dios17I25T8K Abvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc; bh=xIAyj1KXcX0c86yqaSXgpJMjya1lmREO81DbNBQQKeQ=; b=C7uei8e6uhkDHoaZVYyZ3fs7NI4Wyn2UkGEvEsFQVwWprH7+lLWv1Bp4gepucoM16e RwX7wKnCPx5Fq8C8ualDU0YN0zbZpk5y0fkVRXURlRL3hjI8TwV0ILqdN3vGTpeLNo61 AtesF/PsXqkgHHLUsZJVt6WjPv6ZjWSgf0KTbbEbpRZvIlwyXB6qSif452Faznei0Eoj QfRpPSELhZFa9DtP/3Tq096HfMk576xB+NlIZS5QkX4AnCLu/hSVsqJLeZ/P81euYm63 Ic0exxrWj11m6wybCGnAXvBzhOYUw3JZIVu5pdCyUg1o40yqjmaayKgxcgxZ8cKbIw1p m5Wg== X-Gm-Message-State: AODbwcAByT9gbCEyP2Iisu3xSSrFMMU7LA2U8TIPZhRmBMjHwOZTXwIj /2O5ncAmRbWbL+gFW9tqx3f9y8OIjg== X-Received: by 10.223.139.30 with SMTP id n30mt6000095wra.105.1496638637973; Sun, 04 Jun 2017 21:57:17 -0700 (PDT) MIME-Version: 1.0 Sender: mpetach@gmail.com Received: by 10.28.164.134 with HTTP; Sun, 4 Jun 2017 21:57:17 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Matthew Petach Date: Sun, 4 Jun 2017 21:57:17 -0700 X-Google-Sender-Auth: SRb0mQwOvYK3Fo6Zmb4PhKSg3oI Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Cc: draft-bourbaki-6man-classless-ipv6@ietf.org, 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 04:57:21 -0000 Many of the arguments against this draft seem to be of the form "this is bad because it might allow uninformed people to make bad decisions which could have bad outcomes." I find this line of reasoning to be somewhat disturbing. Imagine, if you will, early man, out hunting for food using his typical tool, a blunt club. Along comes Thag, with a sharpened stick, ready to join the hunt. Early man looks at it and says "wait...that looks dangerous; someone could use that the wrong way, and hurt themselves, or potentially hurt me. Rather than take that risk, and potentially learn new, more efficient ways of getting food, let's just ban it now, before anyone gets any new ideas." We could still be out on the plains, beating our meat with blunt clubs instead of learning new ways of hunting. We shouldn't fear progress, even if it comes with a few roadbumps and bruises. This draft isn't saying you *have* to use a bit boundary other than /64; it's simply saying you have the *option* to do so, if you like. It's giving people the flexibility to try new combinations out; some of them may be ill-advised; a few warriors may come back with one less limb, having discovered the _pointy_ end goes towards the prey. But on the whole, the potential for advancement would seem to outweigh the risks of people maybe doing something stupid here and there. I support this draft for its ability to look beyond the classful box, to a world in which creative new possibilities open up before us, enabling new and unusual addressing models and the potential for discovering new network topologies we'd never considered before. We shouldn't let ourselves be ruled by the fear of what someone *might* do, and hold ourselves back from the chance to progress and expand outside of our current box. Let's bring innovation back to the Internet. Thanks! Matt From nobody Sun Jun 4 23:35:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235AA127F0E for ; Sun, 4 Jun 2017 23:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWaVKlmtaQ2s for ; Sun, 4 Jun 2017 23:35:28 -0700 (PDT) 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 88324127599 for ; Sun, 4 Jun 2017 23:35:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 100E6A3; Mon, 5 Jun 2017 08:35:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1496644525; bh=g96+4t+rSWOVfjBtrD/y2U7sjnxtZfgqWs8qmRE79aw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iWqFHI8Y+nwl+hFa/JIAqwx1ih/K+2d8WXVR9iTSiG+2XISTPio5qNaIohiY7kzDb EFBXh1bXQaWM457MRYuAHqWD0dUI6Zgf5tEr49NEElUs/H/zoTIWUjVSBzULXZPdUI /PSn0UZLk9RRKl52YjcJfdlmvwN73+ZLhIPS5lOw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0C7A9A1; Mon, 5 Jun 2017 08:35:25 +0200 (CEST) Date: Mon, 5 Jun 2017 08:35:25 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter cc: 6man Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) In-Reply-To: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> Message-ID: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 06:35:31 -0000 On Sun, 4 Jun 2017, Brian E Carpenter wrote: > If we'd been able to agree on simply removing n=64 from 4291bis, I > wouldn't have put my name on this draft. My take on this (and I don't think I am alone) is that this is a slippery slope down to where when I in 10 years connect to a wifi, I'll get an RA with PIO /128 with A=1, because the ISP decided they only wanted devices have single address, because that's what the product people wanted because then people wouldn't be able to have more than a single device per subscription (which is false, but some people believe this can be achieved). Down that /128 path leads NAT66 and all kinds of complexity to work around these problems, and we'll have gained very little by introducting IPv6. I am totally fine in Job statically configures his devices with /126:es, but how do we make sure that device/applicaton developers don't have to spend a lot of time in the future handling NAT66 traversal and hiding multiple services behind a single address? I don't believe in people saying that the IETF is powerless to stop this. We have technical means to at least make it a lot harder for people to get away with that. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Jun 4 23:47:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8243612944E for ; Sun, 4 Jun 2017 23:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bt2Mk4bH7jx for ; Sun, 4 Jun 2017 23:47:00 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E54129440 for ; Sun, 4 Jun 2017 23:47:00 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id p62so26886167vkp.0 for ; Sun, 04 Jun 2017 23:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IxUaS2vU8p7Wpbns27iMk+8H57YoWE3AXVDyeY+LneQ=; b=ROe29aUWPO/F4nmiF5TC6/w7tmxK/fFVDIVod68XlkHcwDr0V4EMtQgcbjDj3YsNUS vSIFH0axbQtu+xd4OCEoetOP8lLyMCgwt6iNjk9rNIxKbrd4FerzMMea/D+URig1X4NE lSG3kNEMju25+9Nhcv7dNC+QoiaiWnr2a+MRcFNRQ07td5o3MM78Hw54fxlaiz2NI0dt /QYjp2gcMFcc0eG671HYpmpRvNCLQU9VFhEmA59FZ4yi3dkb+sGDzDlQh3jWF25nw45f nHCzsqZQPLvZ1iIb11LM9YU5FHj3ZBMahWRLCAgFfeMB5sukEddBsnM+34XTMihPvBa2 Kckg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IxUaS2vU8p7Wpbns27iMk+8H57YoWE3AXVDyeY+LneQ=; b=MEpaBCIPEbrCoon30ri+Bco0Uh6GiHjhtwYkW9Hoa58Lzu/Ueku5UfM/zEuRSTMQz3 pfDBNa4bhZvq4AOOQoExRCGjP0mTjRSQuCI9K0UKX7aSxy3qqpt9PB2PvZ27hrzzV57c KxxA1aRogy602Ljj3f8rP3lcLF3GdxlFkHwdRmAk3SVX1M4YcBoWv6Cjc+ub328Lzega M1uP5tvuMTTeltKapRfOmCEVDWdUSIxuJKKnHLpBfIkefZHPjLi7FCtdoDoyR/QAI9qH KlY70b0L8UvpFO0TUvPvbEwvTgGNauhbPs8dEZjz7TnNBj5S+k9cXk7jGUxnABE1Rfoa ccJQ== X-Gm-Message-State: AODbwcBMA9HZdhFhEbLY2M+4J2xDzaRsOiQWAhH2EESHvQ53YCpcCkMK J6BQgxiV2qba8ZTJM6QosS8Wly+MHSLO X-Received: by 10.31.33.81 with SMTP id h78mr3526308vkh.29.1496645219161; Sun, 04 Jun 2017 23:46:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Sun, 4 Jun 2017 23:46:38 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Jun 2017 15:46:38 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Brian E Carpenter Cc: 6man , draft-bourbaki-6man-classless-ipv6@ietf.org Content-Type: multipart/alternative; boundary="001a11c024caa525cc055130de38" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 06:47:01 -0000 --001a11c024caa525cc055130de38 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 1:13 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I don't doubt it. But nothing today stops them using DHCPv6 exclusively > and deploying /120s - just too bad for any users of an o/s that doesn't > support DHCPv6, right? > Today there's little penalty, because those users will be IPv4-only and still have connectivity. Not sure what they would decide when they start thinking about turning off IPv4. I suppose it would depend on how many of their users use OSes that don't support DHCPv6. --001a11c024caa525cc055130de38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 5, 2017 at 1:13 PM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
I don&#= 39;t doubt it. But nothing today stops them using DHCPv6 exclusively=
and deploying /120s - just too bad for any users of an o/s that doesn't=
support DHCPv6, right?

Today there'= s little penalty, because those users will be IPv4-only and still have conn= ectivity. Not sure what they would decide when they start thinking about tu= rning off IPv4. I suppose it would depend on how many of their users use OS= es that don't support DHCPv6.
--001a11c024caa525cc055130de38-- From nobody Mon Jun 5 00:00:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45D1129486 for ; Mon, 5 Jun 2017 00:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or4CNrl7RsRK for ; Mon, 5 Jun 2017 00:00:05 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 98E4D129481 for ; Mon, 5 Jun 2017 00:00:05 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id x47so71004881uab.0 for ; Mon, 05 Jun 2017 00:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fd2+CjD7grncYZid/rJIeXJuWLqITNPLbu7PZlbaZS8=; b=mxf3AzF5H9ZbvGfZsIew+yx4jYP+Py9Yv6X895XcTAxtNzl+a1cirS3EaxDHRtg3IH Y7L7f8enPn+7Ko0/q9rc9kesYW2r1wWKjnmuT5o9xDUGsnJH9HtvvbB4kLWdBLcg3DAJ rhPnkXIriP0W2bBnH6wODyDOHii07QBYnfUYjooi9VEoNhcxDvYv9Veu9mjyuBG7KyP8 +f37B8xedCfUXfWyu9kG+W24H+/3jiMq2tA3xrro/NomE/mVRwOKyAcoNmwernrTsnBS DBy4ABq+70guDchKAUhlr1KJDtJ4saR65Ah07MICHwYSOOw+vMvCODmMdwWMfqx6v+Rd 5xOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fd2+CjD7grncYZid/rJIeXJuWLqITNPLbu7PZlbaZS8=; b=rkm/wmrJLgqGcjWukCwkNvDsPvGXnGz+XtdiBfi0TSZKeBlRZ6nvl39zNJ/crY/yCo uZ6QyWoQoX3MFhnV63S6kLzxq0kGWQqU8fZ2B1Pg5sJxoGufz3LATVSAieEE8TZIGS7D eSv2o3RsVdCi8DbTZstqXR1H1SYPr3bjj2pAzp0BKaR/Noi+8oD0pg/cYi2hOxy+DOy9 xANfBZCzooW9/CuiSlUBTXvBfyTloD/t7UKBDoGTfp7k/ihOSTkk0fCYgBNn/cXXZD0k Z5nCyv4xJbn2FjS4birRgoasyM14eV0EiMqtgkhS/Kc0dq/3O2aTzkgzz/G/+AXI+oHl R00Q== X-Gm-Message-State: AODbwcC9BBru4kABxh7/uHR9LFTcDrOxY1aZvIEVk5nQ3XAePlBE6JrU A9vpuGJGY3d1Ny6ShPxGUk2hCdCOqKSz/VutYA== X-Received: by 10.159.60.156 with SMTP id s28mr10483094uai.94.1496646004642; Mon, 05 Jun 2017 00:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Sun, 4 Jun 2017 23:59:43 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Jun 2017 15:59:43 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Matthew Petach Cc: draft-bourbaki-6man-classless-ipv6@ietf.org, 6man Content-Type: multipart/alternative; boundary="089e08e4d3817677630551310dd0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:00:08 -0000 --089e08e4d3817677630551310dd0 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 1:57 PM, Matthew Petach wrote: > Along comes Thag, > with a sharpened stick, ready to join the hunt. Early > man looks at it and says "wait...that looks dangerous; > someone could use that the wrong way, and hurt > themselves, or potentially hurt me. Rather than > take that risk, and potentially learn new, more > efficient ways of getting food, let's just ban it > now, before anyone gets any new ideas. While we're in the realm of not-directly-applicable analogies, would note that if you substitute "sharpened stick" for "rocket launcher" most people would agree that they should be banned. This draft isn't saying you *have* to use a bit boundary > other than /64; it's simply saying you have the *option* > to do so, if you like. You have this option today. As Job will tell you, you can manually configure a /117 and it will work on pretty much any implementation. What you don't have are the ability to claim that others should support your /117 network, and the ability to define automatic configuration mechanisms for your /117 network. --089e08e4d3817677630551310dd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 5, 2017 at 1:57 PM, Matthew Petach <mpetach@netflight.com&= gt; wrote:
Alon= g comes Thag,
with a sharpened stick, ready to join the hunt.=C2=A0 Early
man looks at it and says "wait...that looks dangerous;
someone could use that the wrong way, and hurt
themselves, or potentially hurt me.=C2=A0 Rather than
take that risk, and potentially learn new, more
efficient ways of getting food, let's just ban it
now, before anyone gets any new ideas.

Whil= e we're in the realm of not-directly-applicable analogies, would note t= hat if you substitute "sharpened stick" for "rocket launcher= " most people would agree that they should be banned.

This draft isn't = saying you *have* to use a bit boundary
other than /64; it's simply saying you have the *option*
to do so, if you like.

You have this option= today. As Job will tell you, you can manually configure a /117 and it will= work on pretty much any implementation. What you don't have are the ab= ility to claim that others should support your /117 network, and the abilit= y to define automatic configuration mechanisms for your /117 network.
=
--089e08e4d3817677630551310dd0-- From nobody Mon Jun 5 00:18:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C249C129AE3 for ; Mon, 5 Jun 2017 00:18:14 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUDV3F-7TNuc for ; Mon, 5 Jun 2017 00:18:13 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 29DCE129ADF for ; Mon, 5 Jun 2017 00:18:13 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id o9so14272883yba.3 for ; Mon, 05 Jun 2017 00:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rvuPHdD1dA3cnZZS+y9o9tCJtvzPx6LSmh9JFLMshc4=; b=cluUIKERVboFv7Dem6eV1nb7w0U8jjjayNFVAtTCICYF827LtMla3Y+D8N29YxPK+r houbCmpaFFc/4vEnuiAPDxlacmEOahbIbLzqb0DFOHuIgSIIWPIaqmDYUum9ryMl2f1o 6Hh+U/hsJHrV0rDY9wL7+4aAbV5ZO571N3G+30tAWhuG2vn3MQGSX2yenNNyhYHqu6BS 9A/MOjZm4O7tu0GkkfxiLsZ+ovBe9XBNlF4obi4p6sLx3mur4gjd4v0eO1tbgQ54Maf7 3ojUahjB/d50GuBhBlaq9cdsdcDHNHx8dtK3WYgffKhpcgRVpR4/AkTeINCRJ09Dd+5B MNIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rvuPHdD1dA3cnZZS+y9o9tCJtvzPx6LSmh9JFLMshc4=; b=t1q2jCSltiCbi2pZmwD2rX5lfmod9quAY79GiSBA1fIm9uHiYhv5IJZJ8ViOThpKFj MBRbN/FKjHkS2KNFD1PJbQzXiRrlDqUXii+SZmzWVJMMEPNkFBqRX7QsRj4XYnmhbzCP V/DTlxltTFGelHeCwhMxUBM8tbkd45DfmLakaPChQ3XP+kA9jag4Nuh7dX+ePMBdRoCv y6mUIK3pS1UaagKH0jTgAtnN+QmSf+Z3x8sWr7Kfllznu/Y2JgP3BXbEgYfmczyYgno5 YM2EsH/DZPS9lmmNcXAbR+M2BSN/aw3Qdu8sDBDSpSmRdLbxbsHEQ/y+aRCriUvwEKLJ 44vw== X-Gm-Message-State: AODbwcBCl4ilDtC1rKD4FIzYVFaI170DeJVPUWbCjHcMGnAvM9rVrp8g 1cEn6LjR0VQRZ772mSKUurVg7m11sRnpczs= X-Received: by 10.37.48.7 with SMTP id w7mr5428698ybw.84.1496647092244; Mon, 05 Jun 2017 00:18:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Mon, 5 Jun 2017 00:17:51 -0700 (PDT) In-Reply-To: <20170604132200.GK30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> <20170604132200.GK30896@gir.theapt.org> From: Erik Kline Date: Mon, 5 Jun 2017 16:17:51 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Peter Hessler Cc: IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1148af2a4f66e50551314e33" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:18:15 -0000 --001a1148af2a4f66e50551314e33 Content-Type: multipart/alternative; boundary="001a1148af2a4a5fef0551314e9b" --001a1148af2a4a5fef0551314e9b Content-Type: text/plain; charset="UTF-8" > > Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*. > Citations? Of course you can deploy a network that does whatever you want. That alone does not imply standards action is required. --001a1148af2a4a5fef0551314e9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Besides, *Lots of people are already deplyoing I= Pv6 NAT in the wild*.

Citations?
<= div>
Of course you can deploy a network that does whatever yo= u want.=C2=A0 That alone does not imply standards action is required.
=
--001a1148af2a4a5fef0551314e9b-- --001a1148af2a4f66e50551314e33 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgZd+wNfGNSL8dMB9fID/WsBNJGZTj/O1N aCMoDtrXO/UwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjA1 MDcxODEyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAB420q2FYbcWXw4nYnQrVMy88Z4i3jSoAuD/f2arYhXWUYaOhYiR +CNSm5m6pFr6bYzjP7rEjejGMBwrCSro8tZLSVWuLWUZ1PQbdAez3Qmha0OdZudROX64EzUsPQRv hi7/oj9nKhjVobdkGCXgE5PhRxTtBYjxj+wHiY41D9OLZoMOgEJZqq9crI3k5jLtV8OzdsU7zE8Y oZIFqOOY72VmGfy9fXMabJmEnyyjpJ0vGxk8Vdt+HgJtJkGENj5X7/AdOjWOtbOgqAovB7Zolsvj tTa3Y/VwNCjttgiTxQgZtHEa5JQZCw4PdLNtSnQpM0aa/XdTmk7kSlreWINVG3Y= --001a1148af2a4f66e50551314e33-- From nobody Mon Jun 5 00:23:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12208129B7F for ; Mon, 5 Jun 2017 00:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YB7tkYHyDF3 for ; Mon, 5 Jun 2017 00:23:46 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70AF129B60 for ; Mon, 5 Jun 2017 00:23:45 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 8FE1A78946 for ; Mon, 5 Jun 2017 09:23:44 +0200 (CEST) Date: Mon, 5 Jun 2017 09:23:43 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170605072343.GO30896@gir.theapt.org> Reply-To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> <20170604132200.GK30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:23:47 -0000 On 2017 Jun 05 (Mon) at 16:17:51 +0900 (+0900), Erik Kline wrote: :Of course you can deploy a network that does whatever you want. That alone :does not imply standards action is required. This draft is requesting that the standards reflect reality, and acknolwedge that non-/64 subnets are legal. This group has tried to force the standards to require only /64 subnets and that is, quite frankly, offensive. -- Grabel's Law: 2 is not equal to 3 -- not even for large values of 2. From nobody Mon Jun 5 00:46:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562261286D6 for ; Mon, 5 Jun 2017 00:46:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_8lEBhdwJWo for ; Mon, 5 Jun 2017 00:46:11 -0700 (PDT) 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 F0400126D05 for ; Mon, 5 Jun 2017 00:46:10 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id p62so27401776vkp.0 for ; Mon, 05 Jun 2017 00:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EUWVYkMkX5OhQBIaNYNHuIoEjwFx8cX9Rv2qqUY8vjY=; b=ZewLwGgXa6W5K1UywjUzWp2TzEWFJ+kojkffc57VJsPUq4P/McIJdLF7kuOe8gMLuo zdfeEwtXL+QFLkL0/hqJN1ZwKS4mZSBisXNXun8gsgPxW7P4Nrts2mAlylAHDizCUWaD 5NRlWrlMaOMfTvCcEYETZXw2b3SECt8bDmxVSGdOPxnx7oPf7vCYpHRHJifhQYf40Un8 DPwUIpYQ4x4Os3yXG4NPSbyyQReLJJH3k9ZwXKy8ZJczzJ8xUhCbKoAbkkAogCp/KGOw WrLWh+hSITau9Wola0YMoci7CkpEtY5wTbGvl3Zq3JTSqp5a9qQSz93Zy5yYH/qXI3Ap +/Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EUWVYkMkX5OhQBIaNYNHuIoEjwFx8cX9Rv2qqUY8vjY=; b=uk7zjc4UHR/jxnUYosUQ6MrJOjYMrQaKF9UYo10sObdKsb0pISJ1BdycgF8CU9gmTu oY3yWWmyPBTuUfSWFraXZ9O+Gnkg8V55xLCMjdeYq3N85bxO3OAKtm7wFyUjwy/3EBjH GR59NoPcMRMVrF9EK6HaXL8qttUYbThafFVaRkqHnDLpmf0Ylspo+91j5gEABoaYShMX g9SVDZBSVRChloGJ4vJSngbj0qMPR+1cbxTTupvdtRGQQQuUTYwT0SSWq84Pg4eML4kK pmAkliiy70MirHDHV1PI5g/ZZUfMNsPpi1Tyk8nk64By5kyrurIcgOi+GpdoWfBB41cY 8tvg== X-Gm-Message-State: AODbwcBJAiaUjKjNvynbl27m3oSeN0z/D/sY5oWJqGwRUini9MGgBHS8 +PoydD15e3lCwHgtkhL+a4SQcH98cCQr X-Received: by 10.31.210.1 with SMTP id j1mr9075417vkg.144.1496648769941; Mon, 05 Jun 2017 00:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Mon, 5 Jun 2017 00:45:48 -0700 (PDT) In-Reply-To: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Jun 2017 16:45:48 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Ca By , Philip Homburg , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a114bc9e24a1758055131b27c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:46:12 -0000 --001a114bc9e24a1758055131b27c Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > None of that is the point. The point is to establish > that routing is classless Routing is already classless because BCP 198. > and /64 is a parameter of specific addressing schemes. > It *is* a parameter. The parameter's value is 64 for all unicast addresses except those starting with 000. --001a114bc9e24a1758055131b27c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
<= span style=3D"color:rgb(34,34,34)">None of that is the point. The point is = to establish
that routing is classless

Routing is alread= y classless because BCP 198.
=C2=A0
and /64 is a parameter of specific addressing schemes.

It *is* a parameter. The parameter's value is 64= for all unicast addresses except those starting with 000.
--001a114bc9e24a1758055131b27c-- From nobody Mon Jun 5 00:54:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A459126D05 for ; Mon, 5 Jun 2017 00:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lobvsmdl0mSO for ; Mon, 5 Jun 2017 00:54:24 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C986F129BAC for ; Mon, 5 Jun 2017 00:54:23 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id p85so62476489vkd.3 for ; Mon, 05 Jun 2017 00:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YoVXDU0la3XLpZDcA/ctERHqyBdEUp3PR9yrMSNT9v0=; b=TVF5MnWPFr5Rh9RzQMOXOty5cUqI4rJ4apK66/xoWaAw05MtKhFOlWlS1pLjfh82GQ 84vcodVvU98C0xlcb4X/CuDmVfiCT8zmav6Zkaf93yRw89NLyLTyqYh6JHIGvtPVYJ32 Ct2fXm/LdxB1jGc/wxrQPinM0EAh01OaXzvk6xAFbGKn+CXRKup+7pjI6HarzDpu7u0j HF6VErqR+euP2fLlmPYjUpaGcZejel8azN7zVVQx59cGncOIEk6RTZwJM0OBW+H+G/rd lyHJRR8s3NvG4G7y6QzbUcwVsytURnEfizhiVlP6/vSh6zRgHo7ybcpLRYAyxxIU9YyK 5yUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YoVXDU0la3XLpZDcA/ctERHqyBdEUp3PR9yrMSNT9v0=; b=qTKmFTxfexQQTD4I9Dm1fPjYwqornq/5ZXjH9S+aZHKYETCP2O0Ja0PMsxJRK1EXZI 1lUBOhbcrJfV+7BiWtakl6iJDN0STupBECpay8Cvf8j8B18UjJ+H5PmXqDB+J/UA0Yfa JRczllUd/z7GUmg1bWB8trlbw2VbJ3DL1uUMKsv6y3+2SG7t2M+3Myl8qaXeVR82aFrf npnNAKtJeCanTo4UkzPemDXK1n0P+yjiFcZilvdjtRKHuJ+thBtuwEdxnyfgbTu5VASd Qbyr2edVlOo22CeXdHe58p4tY6qtZ/LeLxNejCPxH9MLgWXKNLknwZDFOJVzA/e4j94X BydQ== X-Gm-Message-State: AODbwcAroSZT2b8Aw21XoIelDYBOWdz96WO2PQogYjDfIplUl90uVXCT SFPS1STDQiqgXjaAIp/kwhZ72bppXdPryOA= X-Received: by 10.31.69.138 with SMTP id s132mr6334141vka.13.1496649262615; Mon, 05 Jun 2017 00:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Mon, 5 Jun 2017 00:54:01 -0700 (PDT) In-Reply-To: <20170605072343.GO30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> <20170604132200.GK30896@gir.theapt.org> <20170605072343.GO30896@gir.theapt.org> From: Lorenzo Colitti Date: Mon, 5 Jun 2017 16:54:01 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a114dd2d2a75351055131cf89" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:54:25 -0000 --001a114dd2d2a75351055131cf89 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 4:23 PM, Peter Hessler wrote: > This draft is requesting that the standards reflect reality, I don't think longer-than-64 IIDs are an appreciable portion of reality. The number of IPv6 prefixes in use every day is well into the hundreds of millions. The number of non-/64 IIDs is likely a rounding error in comparison. > and acknolwedge that non-/64 subnets are legal. What is legal is what is written in the standards, and it's /64. What is implemented may vary. Lots of devices allow configuration of longer prefix lengths. Lots of devices don't. > This group has tried to force the standards to require only /64 subnets > and that is, quite frankly, offensive. > I think that's incorrect. "Has tried" is incorrect because /64 has been the current state of the standards for about 20 years. "This group" is incorrect because a lot of the people who made those decisions are no longer in this group. They have just been replaced by other people who happen to agree that that decision was a good one. --001a114dd2d2a75351055131cf89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 5, 2017 at 4:23 PM, Peter Hessler <phessler@theapt.org> wrote:
This draft is requesting tha= t the standards reflect reality,

I don'= t think longer-than-64 IIDs are an appreciable portion of reality. The numb= er of IPv6 prefixes in use every day is well into the hundreds of millions.= The number of non-/64 IIDs is likely a rounding error in comparison.
=
=C2=A0
and=C2=A0acknolwedge that = non-/64 subnets are legal.

What is legal is= what is written in the standards, and it's /64. What is implemented ma= y vary. Lots of devices allow configuration of longer prefix lengths. Lots = of devices don't.
=C2=A0
= This group has tried to force the standards to require only /64 subnets and= that is, quite frankly, offensive.

I t= hink that's incorrect. "Has tried" is incorrect because /64 h= as been the current state of the standards for about 20 years. "This g= roup" is incorrect because a lot of the people who made those decision= s are no longer in this group. They have just been replaced by other people= who happen to agree that that decision was a good one.
--001a114dd2d2a75351055131cf89-- From nobody Mon Jun 5 01:21:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8191A12E957; Mon, 5 Jun 2017 01:21:30 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScQcG1U1mc2W; Mon, 5 Jun 2017 01:21:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 99C5812E91F; Mon, 5 Jun 2017 01:21:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dHnGO-0005Bj-KS; Mon, 05 Jun 2017 08:21:26 +0000 Date: Mon, 05 Jun 2017 14:21:21 +0600 Message-ID: From: Randy Bush To: 6man , draft-bourbaki-6man-classless-ipv6@ietf.org Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 08:21:30 -0000 sorry, but i have neither time, energy, ... to talk about pointed sticks, horrible things which stupid people might do (which they can do today anyway), and other hyperbole. i am just trying to deal with the reality of running networks. and i will admit to being biased to the opinions of those who actually run networks. so can we focus on the actual document? in particular --- 4. Recommendations For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136]. The length of the Interface Identifier in Stateless Address Autoconfiguration [RFC4862] is a parameter; its length SHOULD be sufficient for effective randomization for privacy reasons. For example, a /48 might be sufficient. But operationally we recommend, barring strong considerations to the contrary, using 64-bits for SLAAC in order not to discover bugs where 64 was hard-coded, and to favor portability of devices and operating systems. Nonetheless, there is no reason in theory why an IPv6 node should not operate with different interface identfier lengths on different physical interfaces. Thus, a correct implementation of SLAAC must in fact allow for any prefix length, with the value being a parameter per interface. For instance, the Interface Identifier length in the recommended (see [RFC8064]) algorithm for selecting stable interface identifiers [RFC7217] is a parameter, rather than a hardcoded value. --- the above are actual reality today; the draft just tries to clarify subtle confusions caused by existing and proposed ipv6 addressing documents. as the draft says, this is to prevernt mismatches between formal specification and long-standing field deployment practices are never wise, not least because of the strong risk of mis- implementation, which can easily result in serious operational problems. in talking to operators here, at home, and ripe, i heard some desire to say something to clarify that /128s (or /80s or whatever) to end sites/customers etc. are not being recommended. can we do this without overly-prescribing how operators run their networks or stepping into the RIR allocation policy swamp? randy From nobody Mon Jun 5 02:20:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C536C126D05; Mon, 5 Jun 2017 02:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOZG0ASvetWV; Mon, 5 Jun 2017 02:20:50 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9E00B124E15; Mon, 5 Jun 2017 02:20:50 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 5F38943E9B9; Mon, 5 Jun 2017 11:20:47 +0200 (CEST) Date: Mon, 05 Jun 2017 11:20:47 +0200 (CEST) Message-Id: <20170605.112047.1868975436553913398.he@uninett.no> To: randy@psg.com Cc: ipv6@ietf.org, draft-bourbaki-6man-classless-ipv6@ietf.org Subject: Re: Deprecating IPv6 From: Havard Eidnes In-Reply-To: References: 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 09:20:53 -0000 Hi, a tangential remark related to the wording in the draft: > The length of the Interface Identifier in Stateless Address > Autoconfiguration [RFC4862] is a parameter; its length SHOULD be > sufficient for effective randomization for privacy reasons. For > example, a /48 might be sufficient. I think the "a /48 might be sufficient" part is not the best way to express it. When you talk about a /48 in IPv6, that's usually interpreted to correspond to an address space which contains 2^16 /64s. Suggestions for other ways of expressing what I think is intended would be "For example, a 48 bit long suffix might be sufficient" or "For exmple, 48 bits of address space might be sufficient". Regards, - H=E5vard From nobody Mon Jun 5 02:28:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6066212785F; Mon, 5 Jun 2017 02:28:10 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDPjn4vPl5fM; Mon, 5 Jun 2017 02:28:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4635D127137; Mon, 5 Jun 2017 02:28:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dHoIw-0005Zj-29; Mon, 05 Jun 2017 09:28:06 +0000 Date: Mon, 05 Jun 2017 15:28:03 +0600 Message-ID: From: Randy Bush To: Havard Eidnes Cc: ipv6@ietf.org, draft-bourbaki-6man-classless-ipv6@ietf.org Subject: Re: Deprecating IPv6 In-Reply-To: <20170605.112047.1868975436553913398.he@uninett.no> References: <20170605.112047.1868975436553913398.he@uninett.no> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 09:28:10 -0000 hi havard, > a tangential remark related to the wording in the draft: i would not call actually talking about the draft's wording to tangential. :) >> The length of the Interface Identifier in Stateless Address >> Autoconfiguration [RFC4862] is a parameter; its length SHOULD be >> sufficient for effective randomization for privacy reasons. For >> example, a /48 might be sufficient. > > I think the "a /48 might be sufficient" part is not the best way > to express it. When you talk about a /48 in IPv6, that's usually > interpreted to correspond to an address space which contains 2^16 > /64s. > > Suggestions for other ways of expressing what I think is intended > would be "For example, a 48 bit long suffix might be sufficient" > or "For exmple, 48 bits of address space might be sufficient". thanks for actually suggesting useful text. beat us up if something reasonable addressing this is in not the next version. randy From nobody Mon Jun 5 02:53:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508301293D9 for ; Mon, 5 Jun 2017 02:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKt5FLR-4lCu for ; Mon, 5 Jun 2017 02:53:55 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 09E881267BB for ; Mon, 5 Jun 2017 02:53:55 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id v111so28739237wrc.3 for ; Mon, 05 Jun 2017 02:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mNCY3TnRR3Qs2NFL0P6men9njDiy1ah8dDEVnfSpBw8=; b=W6EXdQqBM3y0lrqBSaKSqXdg/Bk7uMlLaRm39jqTE/HBrHRocxLD+eSwhrQMnLFYQg /Q1XxQZhvMK4DZ87+u7KNhGP1Pjw6NHEDD0e3FqLgCU1WTzWcgNLcaZrcYEpxwbSshZH NovNe7ta4gWjFrRzgFHwR4PvIPVbpffmi8d1k9yp4ynLSsqzB61Ualz/iVvidvARWaOT nOaZmasyT+DXPIbSyQv/HEhP6ict9Ks5W7Akx2jVU9WjtH11Ulmyjvqk92lzX+fgz7/f 30NLPdoncdXKPTNvsE7WkwmTQZ/7dVOUJFLM7Xg7PJSTR9RzxsFYsT0HNw2NRJuLhgUx p4uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mNCY3TnRR3Qs2NFL0P6men9njDiy1ah8dDEVnfSpBw8=; b=taepcHX3ce04Mfl5e83RXJWvzF6bg/WjhLgRdIeZW14Az2PatY4848bpBRqKCQj2bD XrMSwg9iTXkWhL8PUJwlKPs0dbZfLV5kojko7NdHR62VtRepvc9g9WWDF6xb6YVsCev3 6E1q9FukGtzeRVm+xLn2HxxC1HpEiks7VFwH4j7epmIIT7ZQpaaOkTV0PANKou/BwNVu UskX8ePP4o9v6xdXSWzq5eMB4PqU/zaH8cz8kq95pAK3wkXRHTIHWL3jkPn8nl71IBX3 ZhFkq7iUrAxK3svtwvQQ9l+DZWfR5BMpViyrEWWEGafxQf0zcV5ElXCkm4hpqrHauNUd VfaQ== X-Gm-Message-State: AODbwcDFz7u9M5eVt3eA8erq0xnYg3X1x7PucOtprpQyFKxxY/bAqfmz 7m+N/WYmaxywc/cC X-Received: by 10.223.129.6 with SMTP id 6mr8808665wrm.104.1496656433422; Mon, 05 Jun 2017 02:53:53 -0700 (PDT) Received: from [192.168.0.26] (mry91-1-82-229-156-225.fbx.proxad.net. [82.229.156.225]) by smtp.googlemail.com with ESMTPSA id q98sm32690878wrb.3.2017.06.05.02.53.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 02:53:52 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> Message-ID: <3bca0f2c-78be-4554-33a3-53240864fa63@gmail.com> Date: Mon, 5 Jun 2017 11:53:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 09:53:56 -0000 Le 04/06/2017 à 13:05, Philip Homburg a écrit : [...] > Moving on to a network architecture point of view, when using pseudo > random IIDs there will be a longest prefix that can be supported. > Lets say for the sake of argument we can support of /96. > > Then the effect will be that if in the future hosts support SLAAC > upto /96 then we are back at the same hard limit. We have just moved > be boundary by 32 bits. Similar worries were expressed. However, as I read this draft it does not propose to substitute new hard limit for old hard limit. The proposal is leave it at 'n', i.e. a variable. The optimistic evolution of this could be that in some IP-over-foo this variable could be exceptionally /96 and largely over-ridden by a backward compatible /64. Maybe something could be written down that clarifies this is not a proposal to substitute new hard limit for old hard limit. Alex From nobody Mon Jun 5 08:14:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D308612947B for ; Mon, 5 Jun 2017 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU3Nx37rgaYj for ; Mon, 5 Jun 2017 08:14:07 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 17983128B4E for ; Mon, 5 Jun 2017 08:14:07 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id g76so40028368wrd.1 for ; Mon, 05 Jun 2017 08:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KFSDI7cIjNJs61E4QAGir0ivkDG1WA5uhJbBcdvTCpY=; b=t7BCG0Fp8CYY57YQnUKRMCIZ0MKRaQoGMcatO7z0F1Q/WcAhJm8Q72njcYGxNJXJN+ avKb8xgN2U+8doJVuldpJf6fCNSqoJKcF4gZw6eL5A3N+pfym6bVybncdfhRpV6OZU+2 +CVLGbnlej78aenRR6jG5bt/9hL2wTkZoy2dbWJJyq60t7/BP8ODMT10UjSO+YWmhlxO ZLi1/mvsoDy7irMnn0xBOMGzeK13sZ1sppGvrLcnmFIRiyoU7DvhVb20imvKXVQzdOOS dYpOLwYyQiDASi9dJN5VysDX89h0kjPzSCt7W1MtFvnQp6mx+RIvRVnV+1nHRPjfzwHc HLbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KFSDI7cIjNJs61E4QAGir0ivkDG1WA5uhJbBcdvTCpY=; b=tHETu3h6vzv5rB0YH72XZIyEaBgsMKRS0zXRtwhI5UhhBUi3Ue/G2g2bZSwIR8wxgG 3IHDWRsuTzqe1j95RhBdf2hdfyIdvAgrzgRU1gd8JtyC2ROMkjJMGjDjcdA4tYNvrOOq VIgJfGuNPcdgcsDf1sTmRk0v0/gvuq5GeFOPP0bAR375TthJop9vtqNtamjxfwcvCydW HQBnq3FrUVW4SlT2EN86ZPr+7SV/4PdvHor5N90tbP6KWzplFxElVhVmjSCWXzoR08cl WtyZK3s8+BMCs5Wsz2NG4UMRLDDmKckvOIPGD6pdDYNo1g5u/s+QE1zJj8+fEXj2CvEC y3Lg== X-Gm-Message-State: AODbwcDDDvLHsUDyhLlcWVYVcxnygr4ZWWSTjWH+nhWUGvN8NgdGMTZX H0qfK22AeqQ+UlfpNaAoUkSgQn2Y/po/arU= X-Received: by 10.223.183.32 with SMTP id l32mr6499514wre.115.1496675645249; Mon, 05 Jun 2017 08:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Mon, 5 Jun 2017 08:14:04 -0700 (PDT) From: Tom Herbert Date: Mon, 5 Jun 2017 08:14:04 -0700 Message-ID: Subject: Comments on draft-bourbaki-6man-classless-ipv6-00 To: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:14:09 -0000 Section 1: "Recent proposed changes to the IP Version 6 Addressing Architecture specification [RFC4291] have caused controversy. While link prefixes of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been successfully deployed for many years, glaring mismatches between a formal specification and long-standing field deployment practices are never wise, not least because of the strong risk of mis-implementation, which can easily result in serious operational problems." I'm not sure what this paragraph is trying to say. I think might be overly philosophical. Section 4: "For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136]." Historical reason seems like a weak technical argument, maybe just say it's recommended and reference RFC7421. Section 4: "But operationally we recommend, barring strong considerations to the contrary, using 64-bits for SLAAC in order not to discover bugs where 64 was hard-coded, and to favor portability of devices and operating systems." Not using something allowed by the standard in order to avoid hitting bugs is self defeating. Bugs that are not discovered don't get fixed, so in the future when someone has a legitimate reason to do something different it might be too late to fix problems. Section 4 seems to bounce back and forth: First, /64 is recommended, but then /48 might be okay, but then /64 is recommended again because SLAAC might have bugs, and finally any length is okay because SLAAC should be correctly implemented. I think it would be clearer to say that any length is allowed but /64 is recommended and here's why. Section 5: "On the other hand, we assume that a number of IPv6 implementations fail to enforce limits on the size of some of the data structures they employ for communicating with neighboring nodes, such as the Neighbor Cache." I think this argument is weak. This problem has more to do with the number of neighbors than the prefix size. In this regard, using a longer prefix doesn't have impact until it gets really long. For instance, a /96 can already allow 4B addresses which should be more than enough to kill any ND cache. I think this a case where implementations should be fixed instead of the network trying to force a workaround. Tom From nobody Mon Jun 5 08:34:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E724E129AF3 for ; Mon, 5 Jun 2017 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SheG5asA3Veh for ; Mon, 5 Jun 2017 08:34:23 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26AE129AFF for ; Mon, 5 Jun 2017 08:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1496676841; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=+d6I6j+rKm4uLzpI13mMtJsQcPwge6x42R4NWsviGPI=; b=RWR21hAl1vUTgB3pe7DuNtihHqrRNEcqiWIduvIcsRVdqoitoPWLKcTLDMWFVOgVq2jp43xKmBNztkOJwWLUlGqnb60NW25IIwx6eDqzk/h59eRIWlg5wAoR8qwyhHAeUOMFEh+lUllN3nOH7mnrA7IHwNt+h/azllvaX4eaz9g= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0112.outbound.protection.outlook.com [213.199.154.112]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-108-kNzjLzMeNrK8oZwSGAiBAQ-1; Mon, 05 Jun 2017 16:33:59 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB388.eurprd07.prod.outlook.com (10.242.111.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.3; Mon, 5 Jun 2017 15:33:58 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d2f:d4cd:c3bf:b708]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d2f:d4cd:c3bf:b708%15]) with mapi id 15.01.1157.010; Mon, 5 Jun 2017 15:33:57 +0000 From: Tim Chown To: Brian E Carpenter CC: =?utf-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= , 6man Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS26op9UKMgETCHEKlrb4cRNK+sqITZ4CAgAA9gACAAsX2gA== Date: Mon, 5 Jun 2017 15:33:57 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <68b68b48-dcdd-baef-53b0-c68bf0965ce7@gmail.com> In-Reply-To: <68b68b48-dcdd-baef-53b0-c68bf0965ce7@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [128.86.23.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB388; 7:fArUYmE1qIL7CXy7YEg3wdQci+iVJJm7HMqVMXm1JzQmTRFnpLgONzA+9/GQhjy2rGQWE7oyVWorCsy5IycPAhWVUQDSvuh+02OT7oNRWy0I26ruo4R8glQ/3N3bbhbB9voNPGutPbC9ucSeOhIDNzWX6mD7IJxt3stMaciWSQ0yTWR59to59ESjE2rqxI1r+gJQRRUJMKpdI3/phap4qGdg1QsLVR8efaxOj8mZk2FtIxsixbIlPaai1UoZwqrYTKDotR1yr7AOuecydkfjFl7nxK8gJvvwWdtB+KtHuv1g4aO72V9pYhbY8L+kkB/nUlIehM8eWQmXUo8Y3zeU1A==; 20:MEh9+oDu8PMvHAjhYMZItkKilZ5N/bLM34oeXJmnNINxpgfXBWjZXRPnTJomJUSpgtTuH8xLp/SMBqfCxEdMDas1YFGVnPGcAH2MaITH6hbjewKU2BLO5yOotM9JsCPgUhveKw14tNtYiAIEBaRwehvPFKwX5qqktf4/2bzyxME= x-ms-traffictypediagnostic: AM3PR07MB388: x-ms-office365-filtering-correlation-id: 4c6bd551-2cc5-4edf-f9f1-08d4ac28486c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB388; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB388; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB388; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39840400002)(39450400003)(39410400002)(377454003)(24454002)(8936002)(38730400002)(110136004)(99286003)(54906002)(6246003)(3280700002)(33656002)(86362001)(50226002)(6512007)(5660300001)(6916009)(53546009)(6506006)(36756003)(42882006)(2900100001)(6486002)(25786009)(6436002)(53936002)(76176999)(39060400002)(3660700001)(50986999)(3846002)(2906002)(478600001)(83716003)(82746002)(4326008)(305945005)(189998001)(2950100002)(14454004)(66066001)(6116002)(7736002)(57306001)(5250100002)(102836003)(8676002)(74482002)(72206003)(229853002)(230783001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB388; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <04E0815BE214984F808D981AF58C00DE@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 15:33:57.8915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB388 X-MC-Unique: kNzjLzMeNrK8oZwSGAiBAQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:34:25 -0000 SGksDQoNCj4gT24gMyBKdW4gMjAxNywgYXQgMjI6MTIsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMDQvMDYvMjAxNyAwNToz MiwgUm9nZXIgSsO4cmdlbnNlbiB3cm90ZToNCj4+IE9uIEZyaSwgSnVuIDIsIDIwMTcgYXQgNDox MSBQTSwgSm9iIFNuaWpkZXJzIDxqb2JAbnR0Lm5ldD4gd3JvdGU6DQo+PiA8c25pcD4NCj4+PiBB YnN0cmFjdDoNCj4+PiAgIE92ZXIgdGhlIGhpc3Rvcnkgb2YgSVB2NiwgdmFyaW91cyBjbGFzc2Z1 bCBhZGRyZXNzIG1vZGVscyBoYXZlIGJlZW4NCj4+PiAgIHByb3Bvc2VkLCBub25lIG9mIHdoaWNo IGhhcyB3aXRoc3Rvb2QgdGhlIHRlc3Qgb2YgdGltZS4gIFRoZSBsYXN0DQo+Pj4gICByZW1uYW50 IG9mIElQdjYgY2xhc3NmdWwgYWRkcmVzc2luZyBpcyBhIHJpZ2lkIG5ldHdvcmsgaW50ZXJmYWNl DQo+Pj4gICBpZGVudGlmaWVyIGJvdW5kYXJ5IGF0IC82NC4gIFRoaXMgZG9jdW1lbnQgcmVtb3Zl cyB0aGUgZml4ZWQgcG9zaXRpb24NCj4+PiAgIG9mIHRoYXQgYm91bmRhcnkgZm9yIGludGVyZmFj ZSBhZGRyZXNzaW5nLg0KPj4gDQo+PiB3aGF0IEkgZmluZCBvZGQgaXMgdGhhdCB3ZSBvdmVyIGFu ZCBvdmVyIGFnYWluIGFyZSBtb3JwaGluZyBJUHY2IGludG8gSVB2NA0KPj4gd2l0aCBqdXN0IG1v cmUgSVAgYWRyZXNzZXMuLi4gDQo+IA0KPiBUaGF0IHNpbXBseSBpc24ndCB0cnVlLiBUaGUgZHJh ZnQgZG9lc24ndCBhYm9saXNoIHRoZSBjb25jZXB0IG9mICdpbnRlcmZhY2UNCj4gaWRlbnRpZmll cicsIHdoaWNoIGRvZXNuJ3QgZXhpc3QgaW4gSVB2NC4gSXQgZG9lc24ndCBhdHRhY2sgU0xBQUMu IEl0DQo+IGRvZXNuJ3QgYXR0YWNrIElMTlAgb3IgZHJhZnQtaGVyYmVydC1udm8zLWlsYS4gSXQg ZG9lc24ndCBhdHRhY2sgdGhlIGNob2ljZQ0KPiBvZiAvNjQgZm9yIGFsbCBJUHY2LW92ZXItZm9v cyB0byBkYXRlLg0KPiANCj4gSXQgZG9lcyBzYXkgdHdvIHRoaW5ncy4NCj4gDQo+IDEuIEJDUDE5 OA0KPiAyLiBuIGluIHRoZSBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZSBpcyBhIHBhcmFtZXRlci4N Cg0KQW5kIGl0IHRoYXQgc2Vuc2UsIGl04oCZcyBmaW5lLCBpLmUuIC82NCBpcyBSRUNPTU1FTkRF RCwgYW5kIHVzZWQgZm9yIHRoZSB2YXJpb3VzIElQdjYtb3Zlci1mb29zIHRoYXQgQnJpYW4gbWVu dGlvbmVkLCBidXQgYWxzbyBpdCBzZW5kcyBhIG1lc3NhZ2UgdG8gbm90IGhhcmRjb2RlIC82NC4N Cg0KVGhlIGRyYWZ0IGNvdWxkIGNpdGUgUkZDNzQyMSBhbmQgKGZvciB0aGUgcG9pbnQgYWJvdXQg YWRkcmVzcyBhdmFpbGFiaWxpdHkpIFJGQzc5MzQuIA0KDQpMaWtlIERhdmlkLCBhdCB0aGUgdW5p dmVyc2l0eSB3aGVyZSB3ZSBkZXBsb3llZCBJUHY2LCB3ZSBkaWRu4oCZdCB0cnkgdG8gbG9jayBk b3duIGFkZHJlc3NlcyB0byBob3N0czsgcmF0aGVyIHdlIHVzZWQgU05NUC1iYXNlZCBwb2xsaW5n IG9mIG5ldHdvcmsgZGV2aWNlcyBmb3IgYWNjb3VudGFiaWxpdHkuIFdlIGFsc28gaGFkIDgwMi4x WCAodGhyb3VnaCBlZHVyb2FtKSBvbiBXaUZpLCBhbmQgSSBrbm93IG9mIHNvbWUgdW5pdmVyc2l0 aWVzIGRlcGxveWluZyA4MDIuMVggZm9yIHdpcmVkIG5ldHdvcmtzIGFzIHdlbGwuIFRoZXJl4oCZ cyBhbHNvIHRoZSBDaXNjbyBORCBzeXNsb2dnaW5nIGNhcGFiaWxpdHkgaWYgeW91IHVzZSB0aGVp ciBwbGF0Zm9ybS4gDQoNClRpbQ== From nobody Mon Jun 5 08:47:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D76A1294B2 for ; Mon, 5 Jun 2017 08:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5ZkelDlRtTR for ; Mon, 5 Jun 2017 08:47:54 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D301273E2 for ; Mon, 5 Jun 2017 08:47:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v55FlrKE003337; Mon, 5 Jun 2017 08:47:53 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v55FljZw003222 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 5 Jun 2017 08:47:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 08:47:44 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 5 Jun 2017 08:47:44 -0700 From: "Templin, Fred L" To: Tim Chown , Brian E Carpenter CC: 6man Subject: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIw== Date: Mon, 5 Jun 2017 15:47:44 +0000 Message-ID: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:47:56 -0000 SGksIG9uZSBleGFtcGxlIHdoZXJlIC82NCBpcyB2ZXJ5IHVzZWZ1bCBpcyBmb3IgdGhlIGNvbnN0 cnVjdGlvbiBvZiBBRVJPDQphZGRyZXNzZXMgYXMgZG9jdW1lbnRlZCBpbjoNCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi02bWFuLWFlcm9hZGRyLw0KDQpU aGUgZHJhZnQgaXMgdmVyeSBzaG9ydCwgYnV0IGhlcmUgYXJlIHRoZSBtYWluIHRocnVzdHM6DQoN CiAgICJBbiBBRVJPIGFkZHJlc3MgaXMgYW4gSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3Mgd2l0aCBh biBpbnRlcmZhY2UNCiAgIGlkZW50aWZpZXIgYmFzZWQgb24gYSBwcmVmaXggdGhhdCBoYXMgYmVl biBkZWxlZ2F0ZWQgdG8gYSBub2RlIGZvcg0KICAgaXRzIG93biBleGNsdXNpdmUgdXNlLiAgQUVS TyBhZGRyZXNzZXMgYmVnaW4gd2l0aCB0aGUgcHJlZml4DQogICBmZTgwOjovNjQgYW5kIGluY2x1 ZGUgaW4gdGhlIGludGVyZmFjZSBpZGVudGlmaWVyIChpLmUuLCB0aGUgbG93ZXINCiAgIGJpdHMp IGEgNjQtYml0IHByZWZpeCB0YWtlbiBmcm9tIG9uZSBvZiB0aGUgbm9kZSdzIGRlbGVnYXRlZA0K ICAgcHJlZml4ZXMuICBGb3IgZXhhbXBsZSwgaWYgdGhlIG5vZGUgcmVjZWl2ZXMgdGhlIElQdjYg cHJlZml4Og0KDQogICAgICAyMDAxOmRiODoxMDAwOjIwMDA6Oi82NA0KDQogICBpdCBjb25zdHJ1 Y3RzIGl0cyBjb3JyZXNwb25kaW5nIEFFUk8gYWRkcmVzc2VzIGFzOg0KDQogICAgICBmZTgwOjoy MDAxOmRiODoxMDAwOjIwMDAiDQoNCiAgICJUaGUgQUVSTyBhZGRyZXNzIGlzIGludGVuZGVkIGZv ciB1c2UgYnkgbW9iaWxlIG5ldHdvcmtzIHRoYXQgY29tcHJpc2UNCiAgIGEgbW9iaWxlIHJvdXRl ciBhbmQgYSB0ZXRoZXJlZCBuZXR3b3JrIG9mICJJbnRlcm5ldCBvZiBUaGluZ3MiDQogICBkZXZp Y2VzIHRoYXQgdHJhdmVsIHRvZ2V0aGVyIHdpdGggdGhlIHJvdXRlciBhcyBhIHNpbmdsZSB1bml0 LiAgVGhlDQogICBtb2JpbGUgcm91dGVyIGFzc2lnbnMgdGhlIEFFUk8gYWRkcmVzcyB0byBpdHMg dXBzdHJlYW0gaW50ZXJmYWNlIG92ZXINCiAgIHdoaWNoIGl0IHJlY2VpdmVzIGEgcHJlZml4IGRl bGVnYXRpb24gZnJvbSBhIGRlbGVnYXRpbmcgcm91dGVyLiAgVGhlDQogICBtYW5uZXIgZm9yIHJl Y2VpdmluZyB0aGUgZGVsZWdhdGVkIHByZWZpeCBjb3VsZCBiZSB0aHJvdWdoIHN0YXRpYw0KICAg Y29uZmlndXJhdGlvbiBvciBzb21lIGF1dG9tYXRlZCBwcmVmaXggZGVsZWdhdGlvbiBzZXJ2aWNl LiINCg0KSSBmdXJ0aGVyIGJlbGlldmUgdGhpcyBsaW5rLWxvY2FsIGFkZHJlc3MgZm9ybWF0IG1h eSBwcm92ZSB0byBiZSB1c2VmdWwgZm9yDQphbnkgc2NlbmFyaW9zIHdoZXJlIGEgcHJlZml4IGRl bGVnYXRpb24gaXMgcmVjZWl2ZWQuDQoNClRoYW5rcyBpbiBhZHZhbmNlIGZvciBjb21tZW50cy4N Cg0KRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBUaW0gQ2hvd24NCj4gU2VudDogTW9uZGF5LCBKdW5lIDA1LCAyMDE3IDg6MzQg QU0NCj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ DQo+IENjOiA2bWFuIDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogZHJhZnQtYm91cmJh a2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMA0KPiANCj4gSGksDQo+IA0KPiA+IE9uIDMgSnVuIDIw MTcsIGF0IDIyOjEyLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu Y29tPiB3cm90ZToNCj4gPg0KPiA+IE9uIDA0LzA2LzIwMTcgMDU6MzIsIFJvZ2VyIErDuHJnZW5z ZW4gd3JvdGU6DQo+ID4+IE9uIEZyaSwgSnVuIDIsIDIwMTcgYXQgNDoxMSBQTSwgSm9iIFNuaWpk ZXJzIDxqb2JAbnR0Lm5ldD4gd3JvdGU6DQo+ID4+IDxzbmlwPg0KPiA+Pj4gQWJzdHJhY3Q6DQo+ ID4+PiAgIE92ZXIgdGhlIGhpc3Rvcnkgb2YgSVB2NiwgdmFyaW91cyBjbGFzc2Z1bCBhZGRyZXNz IG1vZGVscyBoYXZlIGJlZW4NCj4gPj4+ICAgcHJvcG9zZWQsIG5vbmUgb2Ygd2hpY2ggaGFzIHdp dGhzdG9vZCB0aGUgdGVzdCBvZiB0aW1lLiAgVGhlIGxhc3QNCj4gPj4+ICAgcmVtbmFudCBvZiBJ UHY2IGNsYXNzZnVsIGFkZHJlc3NpbmcgaXMgYSByaWdpZCBuZXR3b3JrIGludGVyZmFjZQ0KPiA+ Pj4gICBpZGVudGlmaWVyIGJvdW5kYXJ5IGF0IC82NC4gIFRoaXMgZG9jdW1lbnQgcmVtb3ZlcyB0 aGUgZml4ZWQgcG9zaXRpb24NCj4gPj4+ICAgb2YgdGhhdCBib3VuZGFyeSBmb3IgaW50ZXJmYWNl IGFkZHJlc3NpbmcuDQo+ID4+DQo+ID4+IHdoYXQgSSBmaW5kIG9kZCBpcyB0aGF0IHdlIG92ZXIg YW5kIG92ZXIgYWdhaW4gYXJlIG1vcnBoaW5nIElQdjYgaW50byBJUHY0DQo+ID4+IHdpdGgganVz dCBtb3JlIElQIGFkcmVzc2VzLi4uDQo+ID4NCj4gPiBUaGF0IHNpbXBseSBpc24ndCB0cnVlLiBU aGUgZHJhZnQgZG9lc24ndCBhYm9saXNoIHRoZSBjb25jZXB0IG9mICdpbnRlcmZhY2UNCj4gPiBp ZGVudGlmaWVyJywgd2hpY2ggZG9lc24ndCBleGlzdCBpbiBJUHY0LiBJdCBkb2Vzbid0IGF0dGFj ayBTTEFBQy4gSXQNCj4gPiBkb2Vzbid0IGF0dGFjayBJTE5QIG9yIGRyYWZ0LWhlcmJlcnQtbnZv My1pbGEuIEl0IGRvZXNuJ3QgYXR0YWNrIHRoZSBjaG9pY2UNCj4gPiBvZiAvNjQgZm9yIGFsbCBJ UHY2LW92ZXItZm9vcyB0byBkYXRlLg0KPiA+DQo+ID4gSXQgZG9lcyBzYXkgdHdvIHRoaW5ncy4N Cj4gPg0KPiA+IDEuIEJDUDE5OA0KPiA+IDIuIG4gaW4gdGhlIGFkZHJlc3NpbmcgYXJjaGl0ZWN0 dXJlIGlzIGEgcGFyYW1ldGVyLg0KPiANCj4gQW5kIGl0IHRoYXQgc2Vuc2UsIGl04oCZcyBmaW5l LCBpLmUuIC82NCBpcyBSRUNPTU1FTkRFRCwgYW5kIHVzZWQgZm9yIHRoZSB2YXJpb3VzIElQdjYt b3Zlci1mb29zIHRoYXQgQnJpYW4gbWVudGlvbmVkLCBidXQgYWxzbyBpdCBzZW5kcw0KPiBhIG1l c3NhZ2UgdG8gbm90IGhhcmRjb2RlIC82NC4NCj4gDQo+IFRoZSBkcmFmdCBjb3VsZCBjaXRlIFJG Qzc0MjEgYW5kIChmb3IgdGhlIHBvaW50IGFib3V0IGFkZHJlc3MgYXZhaWxhYmlsaXR5KSBSRkM3 OTM0Lg0KPiANCj4gTGlrZSBEYXZpZCwgYXQgdGhlIHVuaXZlcnNpdHkgd2hlcmUgd2UgZGVwbG95 ZWQgSVB2Niwgd2UgZGlkbuKAmXQgdHJ5IHRvIGxvY2sgZG93biBhZGRyZXNzZXMgdG8gaG9zdHM7 IHJhdGhlciB3ZSB1c2VkIFNOTVAtYmFzZWQNCj4gcG9sbGluZyBvZiBuZXR3b3JrIGRldmljZXMg Zm9yIGFjY291bnRhYmlsaXR5LiBXZSBhbHNvIGhhZCA4MDIuMVggKHRocm91Z2ggZWR1cm9hbSkg b24gV2lGaSwgYW5kIEkga25vdyBvZiBzb21lIHVuaXZlcnNpdGllcw0KPiBkZXBsb3lpbmcgODAy LjFYIGZvciB3aXJlZCBuZXR3b3JrcyBhcyB3ZWxsLiBUaGVyZeKAmXMgYWxzbyB0aGUgQ2lzY28g TkQgc3lzbG9nZ2luZyBjYXBhYmlsaXR5IGlmIHlvdSB1c2UgdGhlaXIgcGxhdGZvcm0uDQo+IA0K PiBUaW0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Mon Jun 5 09:07:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D4F129B15 for ; Mon, 5 Jun 2017 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZxRDzdn0XYh for ; Mon, 5 Jun 2017 09:07:24 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FB3127369 for ; Mon, 5 Jun 2017 09:07:23 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id 7so77038997wmo.1 for ; Mon, 05 Jun 2017 09:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Iy87JzFhLmtLYYvC+zIyi41eL9xgvswXvwrIrF2Lm+M=; b=jqt1cXvwwFjpSplq/x2aCKU/1PuoDLtY2gze7rqvU/aZ09bBB+RTrKmKJ1fZ3fBwe4 YMNlFFMeO5an6bKYQVQ5W5Y8Ack3NjqHdfG4y7n0r8+8MQ7e5KwFF3nOpPe8zh7vmzsP grWl8RV6Ea9SoKPJu09cKn0DTWb0qTboUKuc1wITEE036oW8NHusTykDcqF7NZ1wVhiA k1JHgT//lRnZCLoZzavHi/wj0qhviEq45qjbxhhE9gS2QCeD/25mn+0X5BuY7KzkKruD wqlwFMAXmwpCN936McLLuOOIW92mRrvG4MdfbsT4YI8hOVT3WyK2aQ8RFhS+7flRojkM 5vog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Iy87JzFhLmtLYYvC+zIyi41eL9xgvswXvwrIrF2Lm+M=; b=Jdt8mFePMuW62q4X+QhTGQ4zi1BjHy0wXN4s2Tg4mgAgDLoaCuaebcmkYzYtPqmYEp 7Them7G3U+OkhNy48XQx66gjlyPX1m6kEIBLv+7rumd2ox2daYyEBX7vpAWfC2PWGsec 5Yy4i+sAROAYMa7r5KKA36kj7Si7zdiMqcnYdSHlWYT+RSsfPyHP+VTaFFo6DAvw2a8h fBnj+/uzFY7GAEmRB4FSWOtb1lhrlPRGe3Ue6eHR08FYxCkLqeYpikwt2Jur0bTbLGbI whHazzHAttUlu7UIwz4nCLo1MgShqvcJyzqX5KSLktfFtEZM32ySn/7eRwHAvTDnUdOV 4k2g== X-Gm-Message-State: AODbwcCiCMClaAUuChKxJrxcnrNimMYG+Awv6VWGWjL8LIdyNH9Re52W S7EgUnXDkvD3ZGVi X-Received: by 10.28.132.210 with SMTP id g201mr8327490wmd.26.1496678841825; Mon, 05 Jun 2017 09:07:21 -0700 (PDT) Received: from [192.168.0.26] (mry91-1-82-229-156-225.fbx.proxad.net. [82.229.156.225]) by smtp.googlemail.com with ESMTPSA id r10sm12015966wmd.9.2017.06.05.09.07.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 09:07:21 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> Message-ID: <83076d88-9891-0d37-ecc0-69200d73517c@gmail.com> Date: Mon, 5 Jun 2017 18:07:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:07:26 -0000 Le 05/06/2017 à 09:45, Lorenzo Colitti a écrit : > On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter > > wrote: > > None of that is the point. The point is to establish > that routing is classless > > > Routing is already classless because BCP 198. > > > and /64 is a parameter of specific addressing schemes. > > > It *is* a parameter. The parameter's value is 64 for all unicast > addresses except those starting with 000. But 001-prefixed addresses are forbidded. Alex > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jun 5 10:04:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2AC129B73 for ; Mon, 5 Jun 2017 10:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhIIqjrqA4A1 for ; Mon, 5 Jun 2017 10:04:11 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D62129B6F for ; Mon, 5 Jun 2017 10:04:11 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id d73so29315091wma.0 for ; Mon, 05 Jun 2017 10:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r2afan6tLt777JtfjeDDgW1As/0HY7yF0Ffiw3D4PSI=; b=r1GO68mytneek+cKYnkrrxrfVBjcDmToB8Ijyujh4EThzlloeboO00kcD89MnGfJ8b L0GcMW4rJL0mbczp7btddkQm0ureuPRbgsRyZoY3a3X18LBSpLULyw1Ne68NvZUix+VU wf17HAW7vibyaUzi4382AGArkvGe9fqKD5K8WPGxgERUBKJPwrou69YFwqBXUfF5q9w1 Aw7x6RT8jNnu7UHojUfJL85bsxRhoA7JuiM0qft6qKYlCqUba4CukyTDQwqRrBD+xxik uDZFqpT2udn8TrfVRnbAY0y4/0bCRt38enZ2G5Ztg6FTYvzQJQDQQJUeva3oYDdg/JQG bWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r2afan6tLt777JtfjeDDgW1As/0HY7yF0Ffiw3D4PSI=; b=tRA5W9COLpXNLX87686ljCKB87N5oZ3SL+s24I3J8yg/4oeYg21dslJxwUucLtMuJ2 r/aNgmmAvCSV+kwBn0XgrCcSvDTYQ3nePz5MkDABPDvlbvMqgnS92frg42ybPtsYUZ9t rTk7v7jDV/G/NBagPnRZZbyimvh+n9pWPl0FhwQSvSDuybk5rk0i5siDPOBfpXp++dL1 eW0QaadkxfZfLbtN4KvDE/4sjtNK5AujnRXjFVS6QJ82/Z/jTRUvDHJ5OOdwM+bTsSEi wKpXk0C/6TXtPX4NL/kZtQ32zK05TEoq8v64vDlwJtFNpZsgfm54N22QN5IiyQw9g0gv EYMQ== X-Gm-Message-State: AODbwcDA1q5hDsbrvqty3MYBnvTCT+Ibr5gq8Rz4v5C+HP8Z26NyvLKV mhipjEyC2xcknI+CFsmG7Freb7WgUbPk X-Received: by 10.28.54.204 with SMTP id y73mr8052472wmh.53.1496682249395; Mon, 05 Jun 2017 10:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Mon, 5 Jun 2017 10:04:08 -0700 (PDT) In-Reply-To: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> From: Tom Herbert Date: Mon, 5 Jun 2017 10:04:08 -0700 Message-ID: Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) To: "Templin, Fred L" Cc: Tim Chown , Brian E Carpenter , 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 17:04:14 -0000 On Mon, Jun 5, 2017 at 8:47 AM, Templin, Fred L wrote: > Hi, one example where /64 is very useful is for the construction of AERO > addresses as documented in: > > https://datatracker.ietf.org/doc/draft-templin-6man-aeroaddr/ > > The draft is very short, but here are the main thrusts: > > "An AERO address is an IPv6 link-local address with an interface > identifier based on a prefix that has been delegated to a node for > its own exclusive use. AERO addresses begin with the prefix > fe80::/64 and include in the interface identifier (i.e., the lower > bits) a 64-bit prefix taken from one of the node's delegated > prefixes. For example, if the node receives the IPv6 prefix: > > 2001:db8:1000:2000::/64 > > it constructs its corresponding AERO addresses as: > > fe80::2001:db8:1000:2000" > > "The AERO address is intended for use by mobile networks that comprise > a mobile router and a tethered network of "Internet of Things" > devices that travel together with the router as a single unit. The > mobile router assigns the AERO address to its upstream interface over > which it receives a prefix delegation from a delegating router. The > manner for receiving the delegated prefix could be through static > configuration or some automated prefix delegation service." > > I further believe this link-local address format may prove to be useful f= or > any scenarios where a prefix delegation is received. > Couldn't you do this same trick with any delegated prefix up to 118 bits le= ngth? Tom > Thanks in advance for comments. > > Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tim Chown >> Sent: Monday, June 05, 2017 8:34 AM >> To: Brian E Carpenter >> Cc: 6man >> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 >> >> Hi, >> >> > On 3 Jun 2017, at 22:12, Brian E Carpenter wrote: >> > >> > On 04/06/2017 05:32, Roger J=C3=B8rgensen wrote: >> >> On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders wrote: >> >> >> >>> Abstract: >> >>> Over the history of IPv6, various classful address models have bee= n >> >>> proposed, none of which has withstood the test of time. The last >> >>> remnant of IPv6 classful addressing is a rigid network interface >> >>> identifier boundary at /64. This document removes the fixed posit= ion >> >>> of that boundary for interface addressing. >> >> >> >> what I find odd is that we over and over again are morphing IPv6 into= IPv4 >> >> with just more IP adresses... >> > >> > That simply isn't true. The draft doesn't abolish the concept of 'inte= rface >> > identifier', which doesn't exist in IPv4. It doesn't attack SLAAC. It >> > doesn't attack ILNP or draft-herbert-nvo3-ila. It doesn't attack the c= hoice >> > of /64 for all IPv6-over-foos to date. >> > >> > It does say two things. >> > >> > 1. BCP198 >> > 2. n in the addressing architecture is a parameter. >> >> And it that sense, it=E2=80=99s fine, i.e. /64 is RECOMMENDED, and used = for the various IPv6-over-foos that Brian mentioned, but also it sends >> a message to not hardcode /64. >> >> The draft could cite RFC7421 and (for the point about address availabili= ty) RFC7934. >> >> Like David, at the university where we deployed IPv6, we didn=E2=80=99t = try to lock down addresses to hosts; rather we used SNMP-based >> polling of network devices for accountability. We also had 802.1X (throu= gh eduroam) on WiFi, and I know of some universities >> deploying 802.1X for wired networks as well. There=E2=80=99s also the Ci= sco ND syslogging capability if you use their platform. >> >> Tim >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jun 5 10:42:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F730127A90 for ; Mon, 5 Jun 2017 10:42:52 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH1Wu_B4tDIT for ; Mon, 5 Jun 2017 10:42:50 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 8C7A01200B9 for ; Mon, 5 Jun 2017 10:42:50 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id o9so18622876yba.3 for ; Mon, 05 Jun 2017 10:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YZb+0DOAIX3If9yPxlwBejiTnkKVjIONNUxwkYyZLE8=; b=RgD+H1UpfQGA1UxLqGjCPmMvrwMzDq+o1Y2FFP9Fii1qzjkyVpGFOjQZCuRcNsFioD LOZj2pd5Jcgt8zKOvlQ5MBbHR7RT4ugoZVZJXOa2KryIFhucSqw2aXfeWPXjjS30Sxj2 xuyGtbLizjfDLW9GkgsDjE8rz2bgtb9CG/kYliYnhvyLQVeSNq1fmCXuX5JhaXanKpdF bCVzVS8s5gbstYuB6Y5jWhLjsM16gZnT7Qws5Mi4T0cp/Rh9w6A9+yj+b21JiGX3aRpD LR5fc5QEm3djyGcphh2trPkEMTiNeQwEqYRCmV+9Wml/kjdlwq21XEs16rIdCquTGA2p 2wfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YZb+0DOAIX3If9yPxlwBejiTnkKVjIONNUxwkYyZLE8=; b=H8VmvAiC3z0lRabcSfsRrPkiiyKLdrTVxQ/JpNNGF4oBmdw0PBu0VX1xK+MRSNG0dO SSEc9ClUMp124FeBtJltONXhtbidodhd7OZrCp34zIwsGa1XIiSdWBNxb5B2UKWVIb+B 125kDyrGno+f7obMELMPGmGDVE7vsy1ORR5PXrMWlh8ouymkjFKJOjiwaI7bnhPN9Fj7 F4SGz8fgjwOU78U1MZU1Pc6OM5OBpYhMUE5ynmBNaF/akevnsQyn3AzJBkkDVMHuJ9jW p6PvHq3PJwvQEy+wqhAgSoASyGHA2Ke3TzW4BusoVpPqUNU3HuN7jchWAOgP3EWNPbOy ef1A== X-Gm-Message-State: AODbwcCqfSk6fhd28n3uTSnBbmt6Nrq2TLhkX5hhfWo54iTRcQRVH0GI uTiaMvcF/TPZDzo9QdBjtPt/aB0SKHjH X-Received: by 10.37.56.17 with SMTP id f17mr9891447yba.130.1496684569686; Mon, 05 Jun 2017 10:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Mon, 5 Jun 2017 10:42:48 -0700 (PDT) In-Reply-To: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Mon, 5 Jun 2017 19:42:48 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 17:42:52 -0000 sorry for the language in this email, and it's not direct at you Brian, it's toward us all. On Mon, Jun 5, 2017 at 1:05 AM, Brian E Carpenter wrote: > ......... The point is to establish > that routing is classless and /64 is a parameter of specific > addressing schemes. If we here in this group forget that most people that will use IPv6 don't care at all about anything in any RFC, they actual don't really care that there are a RFC system - what they care about is that their daily life is easy. This _I_ think is very true for the enterprise world. They go for quick and dirty, and cheapest solution. So, for most of them they will only hear and see "IPv6 is classless", and with their IPv4 background they _will_ start todo all kind of crazy stuff, all the things WE seems to think we can handle by putting in extra words in a RFC. Really - if we are stupid, yes that's the word, that we think any words we put into an RFC will prevent NAT66, /128 and /120 and all the crazy things people do in IPv4 and now will be doing in IPv6, then well ... let's just rename IPv6 into IPv4+ and be done with it. So sure we will get more IPv6 deployment, but NOT the kind that actual will solve application layer problem created by NAT & alike, and we are not any better of at all. Not to forget that we very likely are to trigger a routing/policy change because there are no hard /64 anymore...... This one universal /64 is what almost every none-technical, and most technical I've ever meet understand about IPv6. Some think it's a waste of space but it's accepted and they work with it. With that said - sure I agree with Brian on that one sentence. I actual also agree with the intent of the draft, no hardcoded /64's anywhere (from my lenghty discussion with Job online over the last few days), it should be DEFAULT /64, but changable. I just can't accept the followups that "classless & IPv6" will create since most people would never read the finer details of what that actual mean and we will have IPv4+, not IPv6. But if most people are fine with the draft and don't belive it will cause the havoc I think it will, then count me in the rough, I'm fine with that. Also, I think I remember that most hardware are optimized around that /64 boundary, how will this affect newer chipset and hardware? Should they optimize their hardware to route anything from /8 to /128? Sounds very expensive and not something that will make IPv6 more popular. -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Mon Jun 5 11:13:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291A3129B2A for ; Mon, 5 Jun 2017 11:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTJ0DVFvRVUD for ; Mon, 5 Jun 2017 11:13:47 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE82F129B35 for ; Mon, 5 Jun 2017 11:13:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v55IDjCr025388; Mon, 5 Jun 2017 11:13:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v55IDcRD025294 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 5 Jun 2017 11:13:38 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 11:13:37 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 5 Jun 2017 11:13:37 -0700 From: "Templin, Fred L" To: Tom Herbert CC: Tim Chown , Brian E Carpenter , 6man Subject: RE: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIwARYZ8AAAxi0HA= Date: Mon, 5 Jun 2017 18:13:37 +0000 Message-ID: <8333195fe502477e85f06cfd7895590b@XCH15-06-08.nw.nos.boeing.com> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 18:13:49 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDA1 LCAyMDE3IDEwOjA0IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+DQo+IENjOiBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPjsgQnJpYW4g RSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT47IDZtYW4gPGlwdjZAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiAvNjQgYW5kIEFFUk8gYWRkcmVzc2VzIChSRTogZHJhZnQt Ym91cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMCkNCj4gDQo+IE9uIE1vbiwgSnVuIDUsIDIw MTcgYXQgODo0NyBBTSwgVGVtcGxpbiwgRnJlZCBMDQo+IDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPiB3cm90ZToNCj4gPiBIaSwgb25lIGV4YW1wbGUgd2hlcmUgLzY0IGlzIHZlcnkgdXNlZnVs IGlzIGZvciB0aGUgY29uc3RydWN0aW9uIG9mIEFFUk8NCj4gPiBhZGRyZXNzZXMgYXMgZG9jdW1l bnRlZCBpbjoNCj4gPg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRlbXBsaW4tNm1hbi1hZXJvYWRkci8NCj4gPg0KPiA+IFRoZSBkcmFmdCBpcyB2ZXJ5IHNob3J0 LCBidXQgaGVyZSBhcmUgdGhlIG1haW4gdGhydXN0czoNCj4gPg0KPiA+ICAgICJBbiBBRVJPIGFk ZHJlc3MgaXMgYW4gSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3Mgd2l0aCBhbiBpbnRlcmZhY2UNCj4g PiAgICBpZGVudGlmaWVyIGJhc2VkIG9uIGEgcHJlZml4IHRoYXQgaGFzIGJlZW4gZGVsZWdhdGVk IHRvIGEgbm9kZSBmb3INCj4gPiAgICBpdHMgb3duIGV4Y2x1c2l2ZSB1c2UuICBBRVJPIGFkZHJl c3NlcyBiZWdpbiB3aXRoIHRoZSBwcmVmaXgNCj4gPiAgICBmZTgwOjovNjQgYW5kIGluY2x1ZGUg aW4gdGhlIGludGVyZmFjZSBpZGVudGlmaWVyIChpLmUuLCB0aGUgbG93ZXINCj4gPiAgICBiaXRz KSBhIDY0LWJpdCBwcmVmaXggdGFrZW4gZnJvbSBvbmUgb2YgdGhlIG5vZGUncyBkZWxlZ2F0ZWQN Cj4gPiAgICBwcmVmaXhlcy4gIEZvciBleGFtcGxlLCBpZiB0aGUgbm9kZSByZWNlaXZlcyB0aGUg SVB2NiBwcmVmaXg6DQo+ID4NCj4gPiAgICAgICAyMDAxOmRiODoxMDAwOjIwMDA6Oi82NA0KPiA+ DQo+ID4gICAgaXQgY29uc3RydWN0cyBpdHMgY29ycmVzcG9uZGluZyBBRVJPIGFkZHJlc3NlcyBh czoNCj4gPg0KPiA+ICAgICAgIGZlODA6OjIwMDE6ZGI4OjEwMDA6MjAwMCINCj4gPg0KPiA+ICAg ICJUaGUgQUVSTyBhZGRyZXNzIGlzIGludGVuZGVkIGZvciB1c2UgYnkgbW9iaWxlIG5ldHdvcmtz IHRoYXQgY29tcHJpc2UNCj4gPiAgICBhIG1vYmlsZSByb3V0ZXIgYW5kIGEgdGV0aGVyZWQgbmV0 d29yayBvZiAiSW50ZXJuZXQgb2YgVGhpbmdzIg0KPiA+ICAgIGRldmljZXMgdGhhdCB0cmF2ZWwg dG9nZXRoZXIgd2l0aCB0aGUgcm91dGVyIGFzIGEgc2luZ2xlIHVuaXQuICBUaGUNCj4gPiAgICBt b2JpbGUgcm91dGVyIGFzc2lnbnMgdGhlIEFFUk8gYWRkcmVzcyB0byBpdHMgdXBzdHJlYW0gaW50 ZXJmYWNlIG92ZXINCj4gPiAgICB3aGljaCBpdCByZWNlaXZlcyBhIHByZWZpeCBkZWxlZ2F0aW9u IGZyb20gYSBkZWxlZ2F0aW5nIHJvdXRlci4gIFRoZQ0KPiA+ICAgIG1hbm5lciBmb3IgcmVjZWl2 aW5nIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGNvdWxkIGJlIHRocm91Z2ggc3RhdGljDQo+ID4gICAg Y29uZmlndXJhdGlvbiBvciBzb21lIGF1dG9tYXRlZCBwcmVmaXggZGVsZWdhdGlvbiBzZXJ2aWNl LiINCj4gPg0KPiA+IEkgZnVydGhlciBiZWxpZXZlIHRoaXMgbGluay1sb2NhbCBhZGRyZXNzIGZv cm1hdCBtYXkgcHJvdmUgdG8gYmUgdXNlZnVsIGZvcg0KPiA+IGFueSBzY2VuYXJpb3Mgd2hlcmUg YSBwcmVmaXggZGVsZWdhdGlvbiBpcyByZWNlaXZlZC4NCj4gPg0KPiANCj4gQ291bGRuJ3QgeW91 IGRvIHRoaXMgc2FtZSB0cmljayB3aXRoIGFueSBkZWxlZ2F0ZWQgcHJlZml4IHVwIHRvIDExOCBi aXRzIGxlbmd0aD8NCg0KVmVyeSBnb29kIHF1ZXN0aW9uLCBzaW5jZSBsaW5rLWxvY2FsIHByZWZp eCBpcyB0ZWNobmljYWxseSBmZTgwOjovMTAuIEJ1dCwNCndoYXQgd291bGQgaW1wbGVtZW50YXRp b25zIGRvIHdpdGggYSBsaW5rLWxvY2FsIHRoYXQgZG9lc24ndCBiZWdpbiB3aXRoDQpmZTgwOjov NjQ/DQoNClRoYW5rcyAtIEZyZWQNCg0KPiBUb20NCj4gDQo+ID4gVGhhbmtzIGluIGFkdmFuY2Ug Zm9yIGNvbW1lbnRzLg0KPiA+DQo+ID4gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5j b20NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBpcHY2 IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGltIENob3duDQo+ ID4+IFNlbnQ6IE1vbmRheSwgSnVuZSAwNSwgMjAxNyA4OjM0IEFNDQo+ID4+IFRvOiBCcmlhbiBF IENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiA+PiBDYzogNm1hbiA8 aXB2NkBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IGRyYWZ0LWJvdXJiYWtpLTZtYW4tY2xh c3NsZXNzLWlwdjYtMDANCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+ID4gT24gMyBKdW4gMjAx NywgYXQgMjI6MTIsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b20+IHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4gT24gMDQvMDYvMjAxNyAwNTozMiwgUm9nZXIgSsO4 cmdlbnNlbiB3cm90ZToNCj4gPj4gPj4gT24gRnJpLCBKdW4gMiwgMjAxNyBhdCA0OjExIFBNLCBK b2IgU25pamRlcnMgPGpvYkBudHQubmV0PiB3cm90ZToNCj4gPj4gPj4gPHNuaXA+DQo+ID4+ID4+ PiBBYnN0cmFjdDoNCj4gPj4gPj4+ICAgT3ZlciB0aGUgaGlzdG9yeSBvZiBJUHY2LCB2YXJpb3Vz IGNsYXNzZnVsIGFkZHJlc3MgbW9kZWxzIGhhdmUgYmVlbg0KPiA+PiA+Pj4gICBwcm9wb3NlZCwg bm9uZSBvZiB3aGljaCBoYXMgd2l0aHN0b29kIHRoZSB0ZXN0IG9mIHRpbWUuICBUaGUgbGFzdA0K PiA+PiA+Pj4gICByZW1uYW50IG9mIElQdjYgY2xhc3NmdWwgYWRkcmVzc2luZyBpcyBhIHJpZ2lk IG5ldHdvcmsgaW50ZXJmYWNlDQo+ID4+ID4+PiAgIGlkZW50aWZpZXIgYm91bmRhcnkgYXQgLzY0 LiAgVGhpcyBkb2N1bWVudCByZW1vdmVzIHRoZSBmaXhlZCBwb3NpdGlvbg0KPiA+PiA+Pj4gICBv ZiB0aGF0IGJvdW5kYXJ5IGZvciBpbnRlcmZhY2UgYWRkcmVzc2luZy4NCj4gPj4gPj4NCj4gPj4g Pj4gd2hhdCBJIGZpbmQgb2RkIGlzIHRoYXQgd2Ugb3ZlciBhbmQgb3ZlciBhZ2FpbiBhcmUgbW9y cGhpbmcgSVB2NiBpbnRvIElQdjQNCj4gPj4gPj4gd2l0aCBqdXN0IG1vcmUgSVAgYWRyZXNzZXMu Li4NCj4gPj4gPg0KPiA+PiA+IFRoYXQgc2ltcGx5IGlzbid0IHRydWUuIFRoZSBkcmFmdCBkb2Vz bid0IGFib2xpc2ggdGhlIGNvbmNlcHQgb2YgJ2ludGVyZmFjZQ0KPiA+PiA+IGlkZW50aWZpZXIn LCB3aGljaCBkb2Vzbid0IGV4aXN0IGluIElQdjQuIEl0IGRvZXNuJ3QgYXR0YWNrIFNMQUFDLiBJ dA0KPiA+PiA+IGRvZXNuJ3QgYXR0YWNrIElMTlAgb3IgZHJhZnQtaGVyYmVydC1udm8zLWlsYS4g SXQgZG9lc24ndCBhdHRhY2sgdGhlIGNob2ljZQ0KPiA+PiA+IG9mIC82NCBmb3IgYWxsIElQdjYt b3Zlci1mb29zIHRvIGRhdGUuDQo+ID4+ID4NCj4gPj4gPiBJdCBkb2VzIHNheSB0d28gdGhpbmdz Lg0KPiA+PiA+DQo+ID4+ID4gMS4gQkNQMTk4DQo+ID4+ID4gMi4gbiBpbiB0aGUgYWRkcmVzc2lu ZyBhcmNoaXRlY3R1cmUgaXMgYSBwYXJhbWV0ZXIuDQo+ID4+DQo+ID4+IEFuZCBpdCB0aGF0IHNl bnNlLCBpdOKAmXMgZmluZSwgaS5lLiAvNjQgaXMgUkVDT01NRU5ERUQsIGFuZCB1c2VkIGZvciB0 aGUgdmFyaW91cyBJUHY2LW92ZXItZm9vcyB0aGF0IEJyaWFuIG1lbnRpb25lZCwgYnV0IGFsc28g aXQNCj4gc2VuZHMNCj4gPj4gYSBtZXNzYWdlIHRvIG5vdCBoYXJkY29kZSAvNjQuDQo+ID4+DQo+ ID4+IFRoZSBkcmFmdCBjb3VsZCBjaXRlIFJGQzc0MjEgYW5kIChmb3IgdGhlIHBvaW50IGFib3V0 IGFkZHJlc3MgYXZhaWxhYmlsaXR5KSBSRkM3OTM0Lg0KPiA+Pg0KPiA+PiBMaWtlIERhdmlkLCBh dCB0aGUgdW5pdmVyc2l0eSB3aGVyZSB3ZSBkZXBsb3llZCBJUHY2LCB3ZSBkaWRu4oCZdCB0cnkg dG8gbG9jayBkb3duIGFkZHJlc3NlcyB0byBob3N0czsgcmF0aGVyIHdlIHVzZWQgU05NUC1iYXNl ZA0KPiA+PiBwb2xsaW5nIG9mIG5ldHdvcmsgZGV2aWNlcyBmb3IgYWNjb3VudGFiaWxpdHkuIFdl IGFsc28gaGFkIDgwMi4xWCAodGhyb3VnaCBlZHVyb2FtKSBvbiBXaUZpLCBhbmQgSSBrbm93IG9m IHNvbWUgdW5pdmVyc2l0aWVzDQo+ID4+IGRlcGxveWluZyA4MDIuMVggZm9yIHdpcmVkIG5ldHdv cmtzIGFzIHdlbGwuIFRoZXJl4oCZcyBhbHNvIHRoZSBDaXNjbyBORCBzeXNsb2dnaW5nIGNhcGFi aWxpdHkgaWYgeW91IHVzZSB0aGVpciBwbGF0Zm9ybS4NCj4gPj4NCj4gPj4gVGltDQo+ID4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+ PiBpcHY2QGlldGYub3JnDQo+ID4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+ IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Mon Jun 5 11:47:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510AA129C0E for ; Mon, 5 Jun 2017 11:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl27at1tUYOn for ; Mon, 5 Jun 2017 11:47:49 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 77949129BE6 for ; Mon, 5 Jun 2017 11:47:49 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id f185so24051228pgc.0 for ; Mon, 05 Jun 2017 11:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=6XJQaPhHsO4cpuWz2bCymU8Idd5USfFqEe3SWBdRJ4s=; b=aXye6Z0NnqTPwKIl/DlTTWsEN4E9aZLKoTb8EhSnDsaU9SBxVWXHOaGNodTsJJoxGL SWQUkuP20jcqU0+51tLdUf9nqUfiPJvf84QOMzagN9PSJDpZahBd+6SUYN7NH0uFnVAd DBd7BqEWxyUXufvV9+iTmlULmLFuU3hZsXe8maaZ31f3dxwNuRyKDOuwbktsWU862nAt 7Sr9y0m0vbQrXGRZJfOJWebLvylW1J6N0PFkb+IkAHTjjWNPvMIN90+WNC6m1lORAVu9 cttJ52VW8QrWE6vlGWOYDgaoSQIns46dfO33L4btfF73St7OrT6MBhRIGSizxe3TZgXB tvpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=6XJQaPhHsO4cpuWz2bCymU8Idd5USfFqEe3SWBdRJ4s=; b=YewpuVaaJLk6W09zezJgMHptcfkwmr7XrgvTeULkVDjpOCb+OxXzVe1WmnogN45gha fXhDqC0IbHI2FnHn187u+kQTKXGo1xWdueOljFi6gJnb2NSu27P/bjiD7BrrAnC3Z1y5 LLX+NjC5/b0eeMfRXSJajH9B/T1jcWgbUhZZr5dfT0yLi93DQtkoWuXOa5PbNUaJlI4l N3fENVWk+F/VaG3oPF2+hsKFz7XZ32MgTUwEVvHdl3MnYY94zVfHr2tRE6cq8DUu3vqN sF1X6E83qZ20/gsAIqZBfpnE/spjodVK0Sao+BqKypB/l5YkvQDeVHuIna7zyLYdwIFo JCjg== X-Gm-Message-State: AODbwcDTJkL+oB1+uJEdLEHf105vNMhR2nldRm7vgbM7S2wH6SkjmPV+ VEgvXKGbjuRSHGvBKQHvIQ== X-Received: by 10.98.72.129 with SMTP id q1mr21734744pfi.161.1496688468439; Mon, 05 Jun 2017 11:47:48 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:3426:b996:825d:220a? ([2620:0:10e7:10:3426:b996:825d:220a]) by smtp.gmail.com with ESMTPSA id z7sm4676800pfi.43.2017.06.05.11.47.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 11:47:47 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_80C3EF2D-B467-4E26-967F-705EBEF8D056" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Mon, 5 Jun 2017 11:47:46 -0700 References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> To: 6man In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 18:47:51 -0000 --Apple-Mail=_80C3EF2D-B467-4E26-967F-705EBEF8D056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 4, 2017, at 23:35, Mikael Abrahamsson wrote: > On Sun, 4 Jun 2017, Brian E Carpenter wrote: >>=20 >> If we'd been able to agree on simply removing n=3D64 from 4291bis, I = wouldn't have put my name on this draft. >=20 > My take on this (and I don't think I am alone) is that this is a = slippery slope down to where when I in 10 years connect to a wifi, I'll = get an RA with PIO /128 with A=3D1, because the ISP decided they only = wanted devices have single address, because that's what the product = people wanted because then people wouldn't be able to have more than a = single device per subscription (which is false, but some people believe = this can be achieved). >=20 > Down that /128 path leads NAT66 and all kinds of complexity to work = around these problems, and we'll have gained very little by introducting = IPv6. Now is as good a time as any to repeat that I=E2=80=99m working on = delivering *basically* this now. Not in ten years. Now. The only difference between what I=E2=80=99m working on now and what = Mikael describes is that I=E2=80=99m dealing with the situation where = I=E2=80=99m a 6LoWPAN border router connecting to a home Wi-Fi=E2=84=A2 = LAN segment, and I can=E2=80=99t get a DHCPv6 prefix because either a) = the router isn=E2=80=99t capable of DHCPv6-PD as RFC 7084 recommends, b) = the router doesn=E2=80=99t have any more subnet prefixes to delegate = (because other routers have consumed them all, usually by cascading one = or more RFC 7084 routers behind the ISP border), or c) the router will = never have enough subnet prefixes to delegate because the ISP didn=E2=80=99= t delegate the CPE border router enough space. We are already on the path to IPv6/NAT w/ address amplification. We had = a chance to stop it, and we blew it. It=E2=80=99s time to move on from = that mistake. --james woodyatt > --Apple-Mail=_80C3EF2D-B467-4E26-967F-705EBEF8D056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 4, 2017, at 23:35, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
On Sun, 4 Jun 2017, Brian E Carpenter wrote:

If we'd = been able to agree on simply removing n=3D64 from 4291bis, I wouldn't = have put my name on this draft.

My take on this (and I don't think I am alone) is that this = is a slippery slope down to where when I in 10 years connect to a wifi, = I'll get an RA with PIO /128 with A=3D1, because the ISP decided they = only wanted devices have single address, because that's what the product = people wanted because then people wouldn't be able to have more than a = single device per subscription (which is false, but some people believe = this can be achieved).

Down that /128 path = leads NAT66 and all kinds of complexity to work around these problems, = and we'll have gained very little by introducting IPv6.

Now is as = good a time as any to repeat that I=E2=80=99m working on delivering = *basically* this now. Not in ten years. Now.

The only difference between what I=E2=80=99m = working on now and what Mikael describes is that I=E2=80=99m dealing = with the situation where I=E2=80=99m a 6LoWPAN border router connecting = to a home Wi-Fi=E2=84=A2 LAN segment, and I can=E2=80=99t get a DHCPv6 = prefix because either a) the router isn=E2=80=99t capable of DHCPv6-PD = as RFC 7084 recommends, b) the router doesn=E2=80=99t have any more = subnet prefixes to delegate (because other routers have consumed them = all, usually by cascading one or more RFC 7084 routers behind the ISP = border), or c) the router will never have enough subnet prefixes to = delegate because the ISP didn=E2=80=99t delegate the CPE border router = enough space.

We are already on the = path to IPv6/NAT w/ address amplification. We had a chance to stop it, = and we blew it. It=E2=80=99s time to move on from that = mistake.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_80C3EF2D-B467-4E26-967F-705EBEF8D056-- From nobody Mon Jun 5 13:05:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7951293DA for ; Mon, 5 Jun 2017 13:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vQarQMlRJyW for ; Mon, 5 Jun 2017 13:05:31 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 11303126CE8 for ; Mon, 5 Jun 2017 13:05:31 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 8A2766BE for ; Mon, 5 Jun 2017 20:05:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zCFYx6X2WO3 for ; Mon, 5 Jun 2017 15:05:30 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 5700F85C for ; Mon, 5 Jun 2017 15:05:30 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id 44so22277370uae.2 for ; Mon, 05 Jun 2017 13:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V4I+10s/Sn+ak5S9ctbanYM9Z8eD1+JiWhDNUR0DR8s=; b=M2g56/6zUYP7UQ56XzTI1weRUPL53QBdJhkhz68ziDWh3bcVEm9sZv2/nnIoODvTbL vMUqtHjx4lsyL7sqT15PDIYukAthXOvnaSj46QlQPWXn+IYi5vRGskEmgBXbThuxM5Ak GwarYEDVWirQe3OOAC255g5tE8GsRaAnAxeIKtA/17DB4uJOPrB4ofe5Fxa3hoz5sa3F ubB2o7v3fbxGEMK6ZtjlhcTFN80vlUWVh8HvNfMeP0a36qjwMPDRlvWFs5SPJQsLYrKZ T2P73GpFbcIV9kJCfH/s4Yi64NUZlKpNYGMsT3/UTmrkw8y9jwZn2T+TDIjxLTCB5zd3 geag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V4I+10s/Sn+ak5S9ctbanYM9Z8eD1+JiWhDNUR0DR8s=; b=UiHa8SAHeYvEoab0734sy1V3Ttyc7Mm6TKEzdGb702HkRa4mIypWxPUrTYZg1VOrXF PT9MqFoR9tNNvQoCF813NHYcti73GuGfUQdRAwN9Knsqz4YsPwE+tTjOrL8rRT9fyf38 3yKkpabhctSwhgzOsbGZw9wFdw+XcSThy+1tuoII2zuZqhxBJIJwkKhK10phqgbTG0VV nxDbNGKEwp/cCHImjEr9olxKYgyxv1voFdXA/1CjDw+oCvmI3NsI+FWpy7+icTLhEGFr bWDDb/1d56p7+Cc5eX+54GSc8IdTexdRumZP9Fh/bulBqndCA82pa0g8X7afg238QbuI S7wQ== X-Gm-Message-State: AODbwcBwQMZe8uKlkNXTJKBB7KcK3F4F7AZpaOzDZp2D2TE75wWk5hN5 NF8o9dg9+RN9rXsgkJRAsS1cpY0cwNBbu9b0246wsrvp42QNEDQqXOPFA3rMxzA9DTwmVcuhdEP PXrrQpFsvPEuFhfI= X-Received: by 10.176.23.201 with SMTP id p9mr10349071uaf.24.1496693129037; Mon, 05 Jun 2017 13:05:29 -0700 (PDT) X-Received: by 10.176.23.201 with SMTP id p9mr10349065uaf.24.1496693128810; Mon, 05 Jun 2017 13:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Mon, 5 Jun 2017 13:05:27 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> From: David Farmer Date: Mon, 5 Jun 2017 15:05:27 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Cc: Brian E Carpenter , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="089e0820012448608105513c0619" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:05:32 -0000 --089e0820012448608105513c0619 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 5, 2017 at 12:42 PM, Roger J=C3=B8rgensen wr= ote: > > Also, I think I remember that most hardware are optimized around that > /64 boundary, how will this affect newer chipset and hardware? Should the= y > optimize their hardware to route anything from /8 to /128? Sounds very > expensive and not something that will make IPv6 more popular. > I'm fine with systems being optimized for /64, they just can't ignore or assume there will never be anything longer than /64. If they assume there will never be any prefixes longer than /64, that's not optimizing for /64, that's building a broken system. Optimizing for /64 is assuming something like approximately 60-75% of prefixes will be /64 or shorter, maybe even 80-90% for that matter, but the latter is probably a little over optimized in my opinion. To one extent that's already covered in BCP198/RFC7608, this draft is more about the IID length, but they are really just opposite sides of the same coin. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --089e0820012448608105513c0619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 5, 2017 at 12:42 PM, Roger J=C3=B8rgensen <rogerj@gmail.com= > wrote:

Also, I think I remember that most hardware are optimized around that
/64 boundary, how will this affect newer chipset and hardware? Should they<= br> optimize their hardware to route anything from /8 to /128? Sounds very
expensive and not something that will make IPv6 more popular.

I'm fine with systems being optimized for /64, t= hey just can't ignore or assume there will never be anything longer tha= n /64. If they assume there will never be any prefixes longer than /64, tha= t's not optimizing for /64, that's building a broken system. Optimi= zing for /64 is assuming something like approximately 60-75% of prefixes wi= ll be /64 or shorter, maybe even 80-90% for that matter, but the latter is = probably a little over optimized in my opinion.

To= one extent that's already covered in BCP198/RFC7608, this draft is mor= e about the IID length, but they are really just opposite sides of the same= coin.

Thanks.
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
Networking & Telecommunication Services
Office of I= nformation Technology
University of Minnesota=C2=A0=C2=A0
2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis,= MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e0820012448608105513c0619-- From nobody Mon Jun 5 14:44:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CE129B2C for ; Mon, 5 Jun 2017 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPN3K5H60e4S for ; Mon, 5 Jun 2017 14:44:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F9512E042 for ; Mon, 5 Jun 2017 14:44:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 16BCB203CD; Mon, 5 Jun 2017 17:44:45 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CCD8B6380F; Mon, 5 Jun 2017 17:44:02 -0400 (EDT) From: Michael Richardson To: "Templin\, Fred L" cc: 6man Subject: draft-templlin-6man-aeroaddr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 21:44:08 -0000 --=-=-= Content-Type: text/plain Templin, Fred L wrote: > Hi, one example where /64 is very useful is for the construction of AERO > addresses as documented in: > https://datatracker.ietf.org/doc/draft-templin-6man-aeroaddr/ > The draft is very short, but here are the main thrusts: > "An AERO address is an IPv6 link-local address with an interface > identifier based on a prefix that has been delegated to a node for > its own exclusive use. AERO addresses begin with the prefix > fe80::/64 and include in the interface identifier (i.e., the lower > bits) a 64-bit prefix taken from one of the node's delegated > prefixes. For example, if the node receives the IPv6 prefix: > 2001:db8:1000:2000::/64 > it constructs its corresponding AERO addresses as: > fe80::2001:db8:1000:2000" Interesting idea. I'm not quite sure I see the win, but I don't see any downside either. PPP links just make up random stuff, with the option that they can keep it around across reboots. Or is the point to offload that state into the network? Is your uplink is more ethernet-like? You don't want to use the old-style EUI-64 (maybe you don't have one?), and the stable-private address doesn't work for you? It's not clear to me if this behaviour even needs to be standardized... It doesn't seem to have any operational affects outside the node in question. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk10KIACgkQgItw+93Q 3WXmHgf+LIxKHGUrFyifT7nyJqopkpO8sn3nKmw5nqFVNvktjt4wctb1H35TYr6K aBjD0TpteU+NKw2T4dXTTMzRsOFaLhfg3mWXkVtkO9VJS9HKl1oivsA6/LiNdDTh bvE1QsG9cuipqJwdDUEByH1ZuCu44qoKVv2zC9RSvtT9B1syzc+0y+CxfWULwqie NAOxK7MTByOIfNPVaLvK0YUSkm3ptd88lsoS+XDx1HTyyBqR8UAinrec4vGYDslV qxodKnS2cfWz1v5e7lsSrx7qPNBX5VPgARSXEiCZ4zYdmxBZ9lTGIQVzWURulpgo nYkXQI4/MHnYKTJYhQkAdxnVeH0txA== =v9jA -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 5 15:25:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3B1293DB for ; Mon, 5 Jun 2017 15:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txDATuQs5Noi for ; Mon, 5 Jun 2017 15:25:23 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D78126557 for ; Mon, 5 Jun 2017 15:25:23 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id l89so14845784pfi.2 for ; Mon, 05 Jun 2017 15:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jF3XGY1nhAg1CQcaB8QtIyqqspUy6ULc/qcjZOCIHcg=; b=grdOG4KQFsq6diT7fjjEyZUwR3pxgjT4bGTGUIWPAbJZ5llsAMElOzZMsyXSRd66FT Wj+16gip7YgteDRWNe64xxg8YYKcGJ/e1ju9lC2ggGW89AAaMQXoDgwIXCXKry6WseSd xeky7i6WsO3L1KT7C8klZUZPH7bR/9BulVay2QQmyv9prBws8YO3vir+ejBVpDm/SQe8 jxOMmqU6x4AFydzIzapl2bZMzGp9SOYMYdrz0nXNg5hL/YUtuK01wde1saXi8cnfy9JR zUvZfHRphy1ZLIP1q8zW0+jcgzeTXnZ1AU43BdLklx6dde0mfRDLH+OkZF/3RZymYHGm XZfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jF3XGY1nhAg1CQcaB8QtIyqqspUy6ULc/qcjZOCIHcg=; b=TxFcgLRr4SnccuLH+N4GbNWFw+u0Vda0xsy8zeXSZXkoB7FIKmo06bYdK3xU42Erhf 9M0kgIMAMoe5w6uK+sIt6XT8TnpUTtPbIM+/4pVQyD4LF0xhMvJUDkSxbFKWGKvkv/SL IOubA9X7HPcFC5hHCpDzKHBKUF4gjwh3njKkNRPzEcaStZdhVUluIGvrKfKOrRpNkF55 4ovOaHnsDQUWiXhUQVF/+qPcPyYdp7PsAquLGSjuaU8WCkfkLeyy/Sr7rpl9ATAISgok R8TM60S+2qrbA1tslsQs1rUybLLq741uCL6FhLi1WdkyQnuImihXOnBMod5RQn+0QFHp UKoA== X-Gm-Message-State: AODbwcAVz3t+3lVMH9ioUtgEiiBJOxhgWNvquA3YdD2/Oh5UyZip3Her 7HznoWLDVSaaO/fS X-Received: by 10.98.207.132 with SMTP id b126mr22308485pfg.167.1496701523179; Mon, 05 Jun 2017 15:25:23 -0700 (PDT) Received: from ?IPv6:2406:e001:5517:1:28cc:dc4c:9703:6781? ([2406:e001:5517:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o20sm54862583pfa.96.2017.06.05.15.25.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 15:25:22 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Ca By , Philip Homburg , IETF IPv6 Mailing List References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> Date: Tue, 6 Jun 2017 10:25:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 22:25:25 -0000 On 05/06/2017 19:45, Lorenzo Colitti wrote: > On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> None of that is the point. The point is to establish >> that routing is classless > > > Routing is already classless because BCP 198. > > >> and /64 is a parameter of specific addressing schemes. >> > > It *is* a parameter. The parameter's value is 64 for all unicast addresses > except those starting with 000. The parameter's *current* value, yes. But should we really be fixing the value of the parameter once and for all in the addressing architecture? Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design assumes? Brian Brian From nobody Mon Jun 5 15:44:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE01127775 for ; Mon, 5 Jun 2017 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf1iL6RPth1A for ; Mon, 5 Jun 2017 15:44:18 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F05120721 for ; Mon, 5 Jun 2017 15:44:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v55MiH9W002276; Mon, 5 Jun 2017 15:44:17 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v55MiGwP002272 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 5 Jun 2017 15:44:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Jun 2017 15:44:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 5 Jun 2017 15:44:15 -0700 From: "Templin, Fred L" To: Michael Richardson CC: 6man Subject: RE: draft-templlin-6man-aeroaddr Thread-Topic: draft-templlin-6man-aeroaddr Thread-Index: AQHS3kThU4/e1NUcP0q+n3y/e7rPeaIW2p6A Date: Mon, 5 Jun 2017 22:44:15 +0000 Message-ID: <8b4caaafb6fc4b9d8245600993bf1f44@XCH15-06-08.nw.nos.boeing.com> References: <4234.1496699042@obiwan.sandelman.ca> In-Reply-To: <4234.1496699042@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 22:44:20 -0000 Hi Michael, > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: Monday, June 05, 2017 2:44 PM > To: Templin, Fred L > Cc: 6man > Subject: draft-templlin-6man-aeroaddr >=20 >=20 > Templin, Fred L wrote: > > Hi, one example where /64 is very useful is for the construction of= AERO > > addresses as documented in: >=20 > > https://datatracker.ietf.org/doc/draft-templin-6man-aeroaddr/ >=20 > > The draft is very short, but here are the main thrusts: >=20 > > "An AERO address is an IPv6 link-local address with an interface > > identifier based on a prefix that has been delegated to a node for > > its own exclusive use. AERO addresses begin with the prefix > > fe80::/64 and include in the interface identifier (i.e., the lower > > bits) a 64-bit prefix taken from one of the node's delegated > > prefixes. For example, if the node receives the IPv6 prefix: >=20 > > 2001:db8:1000:2000::/64 >=20 > > it constructs its corresponding AERO addresses as: >=20 > > fe80::2001:db8:1000:2000" >=20 > Interesting idea. I'm not quite sure I see the win, but I don't see any > downside either. >=20 > PPP links just make up random stuff, with the option that they > can keep it around across reboots. Or is the point to offload that state > into the network? I am using it on NBMA links where a node first obtains a delegated prefix then next statelessly constructs an AERO address for itself. The AERO address then statelessly links IPv6 ND with IPv6 forwarding; if there is a neighbor cache entry with an AERO address that matches the packet's IPv6 destination address then there is no need to also look up the destination in the IPv6 forwarding table. > Is your uplink is more ethernet-like? You don't want to use the old-style > EUI-64 (maybe you don't have one?), and the stable-private address doesn'= t > work for you? It gives a way for a node that receives a prefix delegation to statelessly configure a unique IPv6 link-local address for itself that does not need to be tested with DAD. And, it can be assigned to any of the node's interfaces that honor the address format even if the same address would be assigned to multiple interfaces (since the scope is link-local). > It's not clear to me if this behaviour even needs to be standardized... > It doesn't seem to have any operational affects outside the node in quest= ion. If you want to run a link where every node on the link plays by the same rules it might be better to have it written down somewhere. Thanks - Fred fred.l.templin@boeing.com > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon Jun 5 15:48:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C70127775 for ; Mon, 5 Jun 2017 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpDLXCDhCtVN for ; Mon, 5 Jun 2017 15:48:55 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 7925A120721 for ; Mon, 5 Jun 2017 15:48:55 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id u19so49838653qta.3 for ; Mon, 05 Jun 2017 15:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8Sr9W9s4N83qpLNm5izZ6dkuzaDNgVdRI1YxXffMr1w=; b=O5lR0kBUCRjeSZxR0jwZx2vD6rKIYEuh8JuNSgHKct0T8t/qSHsrma09fx280STRPQ +R9ZCNSrjmVBkCvXYDxblvYLFoiYRb5vjmF32rAq+tZ1mF+q3ldSWkkdiHASl5Hi4Xbw HMbSVdTMF8b/A15thQCtHXqEA1gV1Sw8DZsjvOoNewPADas6bsEIoxbtWPmZwz7Hi0/N tfz7vFUMfkK3sL4gV/4FU2Ptfpxi5hl2piGF6SkeMwBtv3JMg7EloJin0guvYZ53LJfB yRNKnxkMxAXlGZtSjLT88P+egkCoLoUFedNCIJnvOK601HCDYS6lmMbqaMheqJbE0Xfz hQkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8Sr9W9s4N83qpLNm5izZ6dkuzaDNgVdRI1YxXffMr1w=; b=Fo0mD481ZJKTQWLncRo5yWbyT+cVDaGnoq7h/6wkLV8tE+6oN3eKB9dQASc8TBQ7es +qiUU69FlasyL/0x/qZMYNoqSF9qbzCoa+Ec52XBEVnNu7gEeJbtkyzff2SoVx69b4+j QTwLMYkLvPwMq1f5mhhGMvmwYsQT7snBMSmJZDxlD58Dp1jmrsfuES+JO8CI8VExx2gV fmwpuPHWN89UWYEVyRUb/IA71jLM+I78lLiU9yl5U3se6fgkocPH/Y7DnEyXalfq6VfF 6NA5UT/RVbEoGNh0BirHII7bIhKQsbX1vkg3LGWAf+yWUZO9dt9eHpmB5UQkEsah91Ba iEbA== X-Gm-Message-State: AKS2vOw0K/sSTzLG8YXDLatrn2fxXBS4NFNWlLUEFaIBXo+xEk9nWGVq V7778DuDnrEPQ5LH2KjvoehwGEABzQ== X-Received: by 10.55.22.193 with SMTP id 62mr25482186qkw.242.1496702934461; Mon, 05 Jun 2017 15:48:54 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Mon, 5 Jun 2017 15:48:53 -0700 (PDT) In-Reply-To: <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 5 Jun 2017 15:48:53 -0700 X-Google-Sender-Auth: qo8k0ShZY2cIvWAdYf73ESLY_ng Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Lorenzo Colitti , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 22:48:56 -0000 At Tue, 6 Jun 2017 10:25:20 +1200, Brian E Carpenter wrote: > > It *is* a parameter. The parameter's value is 64 for all unicast addresses > > except those starting with 000. > The parameter's *current* value, yes. But should we really be fixing > the value of the parameter once and for all in the addressing architecture? > Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design > assumes? Is this what this draft tries to propose? Then the number will be still 64 in most links used today anyway according to RFC2464. My initial impression of the draft is that it even tries to remove that number for IPv6-over-Ethernet, or even make it independent from IPv6-over-foo but subject to operator's choice. If the proposal is really to make the length of the interface identifier only dependent on IPv6-over-foo (but not on the addressing architecture spec anymore), I think the draft should explicitly state so. I'd still expect a lot of discussion on that proposal, but it will at least help avoid having some of the controversy we're seeing in this very long thread. -- JINMEI, Tatuya From nobody Mon Jun 5 17:03:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D845126BF0 for ; Mon, 5 Jun 2017 17:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2prq8qBH58x for ; Mon, 5 Jun 2017 17:03:31 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD5112E04D for ; Mon, 5 Jun 2017 17:03:30 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id 7so85287521wmo.1 for ; Mon, 05 Jun 2017 17:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C+2LXeoJIRZ8FnGtTe/nDKjSzamNiODRHTFPnv8k8lI=; b=fJyK77itLYZ52eHQNYMPPEuRRyViQxlhw9+SttoLvgfoUD6BQholmic6KjNhxKxro+ kJKnkKo/+XgW6ZUrxklL4ZNMvmIIkDKtXQK5HvLSHLvHYgCOei3DD/VWCpe1ksoQ5N5e QCEvOf2PokUK2yvU9NJbwD8Nyr3iLSW2No4qcSTKxb4KRW/XaIrL/1sWGmVEl4Vwv95k ItbrqQx3H6Iu8aBoXlK7bH2DrNLM2QmF10UBd1sBjW0rlr4gFbgaMSybEwejO8SuY0lk 1HQ4PwnizZWsSQafbyUmOcLbe81SIUVHIbh+OkOfs72VFIbFqHTNKlMpijCvixRruBpS ogoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C+2LXeoJIRZ8FnGtTe/nDKjSzamNiODRHTFPnv8k8lI=; b=NleUjau7h3vi6chNYsKNvFs+Jim5TfgdQ2k7gmdVFAn3ZEcejF/sjlhN9BnaIT+2tx p3g/eTt59S8Rqzvx7aZZv/8hBpbuS2kSVNpw5nGcTmuqSEEQeJCjGvXhoNFKyFemMUZo nCoYwzywuZY26jPZ1SEhbm/st9M3OdcmjSFOAcEY9KQ3O8sgzU433FEgipoLTkomo2NL bc3RoENqA2zuUr/9UK+yxc75TaopLFCXCW+LUrSvt24HZaGGTLkw1XYoSFL09pcOCFN2 8e+XVCqQ0BerwBJ3DhSwkuQM3wMnTbjFDamRXwZjzBRfal03YGkR2Yr0LLET7oPU3j6/ 7uJg== X-Gm-Message-State: AODbwcDitoEVw+BtShgL5Px5qgsfK9+xXwP6yScoR1BFBewNnvpPU8oz Rs/g7xxIfPADXFBhDdJM9TGTwC5qPzXc X-Received: by 10.28.87.72 with SMTP id l69mr8951180wmb.111.1496707409434; Mon, 05 Jun 2017 17:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Mon, 5 Jun 2017 17:03:28 -0700 (PDT) In-Reply-To: <8333195fe502477e85f06cfd7895590b@XCH15-06-08.nw.nos.boeing.com> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <8333195fe502477e85f06cfd7895590b@XCH15-06-08.nw.nos.boeing.com> From: Tom Herbert Date: Mon, 5 Jun 2017 17:03:28 -0700 Message-ID: Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) To: "Templin, Fred L" Cc: Tim Chown , Brian E Carpenter , 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 00:03:33 -0000 On Mon, Jun 5, 2017 at 11:13 AM, Templin, Fred L wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Monday, June 05, 2017 10:04 AM >> To: Templin, Fred L >> Cc: Tim Chown ; Brian E Carpenter ; 6man >> Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-i= pv6-00) >> >> On Mon, Jun 5, 2017 at 8:47 AM, Templin, Fred L >> wrote: >> > Hi, one example where /64 is very useful is for the construction of AE= RO >> > addresses as documented in: >> > >> > https://datatracker.ietf.org/doc/draft-templin-6man-aeroaddr/ >> > >> > The draft is very short, but here are the main thrusts: >> > >> > "An AERO address is an IPv6 link-local address with an interface >> > identifier based on a prefix that has been delegated to a node for >> > its own exclusive use. AERO addresses begin with the prefix >> > fe80::/64 and include in the interface identifier (i.e., the lower >> > bits) a 64-bit prefix taken from one of the node's delegated >> > prefixes. For example, if the node receives the IPv6 prefix: >> > >> > 2001:db8:1000:2000::/64 >> > >> > it constructs its corresponding AERO addresses as: >> > >> > fe80::2001:db8:1000:2000" >> > >> > "The AERO address is intended for use by mobile networks that compr= ise >> > a mobile router and a tethered network of "Internet of Things" >> > devices that travel together with the router as a single unit. The >> > mobile router assigns the AERO address to its upstream interface ov= er >> > which it receives a prefix delegation from a delegating router. Th= e >> > manner for receiving the delegated prefix could be through static >> > configuration or some automated prefix delegation service." >> > >> > I further believe this link-local address format may prove to be usefu= l for >> > any scenarios where a prefix delegation is received. >> > >> >> Couldn't you do this same trick with any delegated prefix up to 118 bits= length? > > Very good question, since link-local prefix is technically fe80::/10. But= , > what would implementations do with a link-local that doesn't begin with > fe80::/64? > RFC3513 defines link address with zero in the 54 bits following the 10 bit prefix. I doubt any implementation would care if those bits weren't zeroes, hopefully it's just treated as a /10 IP address that can be configured and used. Tom > Thanks - Fred > >> Tom >> >> > Thanks in advance for comments. >> > >> > Fred >> > fred.l.templin@boeing.com >> > >> >> -----Original Message----- >> >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tim Chown >> >> Sent: Monday, June 05, 2017 8:34 AM >> >> To: Brian E Carpenter >> >> Cc: 6man >> >> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 >> >> >> >> Hi, >> >> >> >> > On 3 Jun 2017, at 22:12, Brian E Carpenter wrote: >> >> > >> >> > On 04/06/2017 05:32, Roger J=C3=B8rgensen wrote: >> >> >> On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders wrote: >> >> >> >> >> >>> Abstract: >> >> >>> Over the history of IPv6, various classful address models have = been >> >> >>> proposed, none of which has withstood the test of time. The la= st >> >> >>> remnant of IPv6 classful addressing is a rigid network interfac= e >> >> >>> identifier boundary at /64. This document removes the fixed po= sition >> >> >>> of that boundary for interface addressing. >> >> >> >> >> >> what I find odd is that we over and over again are morphing IPv6 i= nto IPv4 >> >> >> with just more IP adresses... >> >> > >> >> > That simply isn't true. The draft doesn't abolish the concept of 'i= nterface >> >> > identifier', which doesn't exist in IPv4. It doesn't attack SLAAC. = It >> >> > doesn't attack ILNP or draft-herbert-nvo3-ila. It doesn't attack th= e choice >> >> > of /64 for all IPv6-over-foos to date. >> >> > >> >> > It does say two things. >> >> > >> >> > 1. BCP198 >> >> > 2. n in the addressing architecture is a parameter. >> >> >> >> And it that sense, it=E2=80=99s fine, i.e. /64 is RECOMMENDED, and us= ed for the various IPv6-over-foos that Brian mentioned, but also it >> sends >> >> a message to not hardcode /64. >> >> >> >> The draft could cite RFC7421 and (for the point about address availab= ility) RFC7934. >> >> >> >> Like David, at the university where we deployed IPv6, we didn=E2=80= =99t try to lock down addresses to hosts; rather we used SNMP-based >> >> polling of network devices for accountability. We also had 802.1X (th= rough eduroam) on WiFi, and I know of some universities >> >> deploying 802.1X for wired networks as well. There=E2=80=99s also the= Cisco ND syslogging capability if you use their platform. >> >> >> >> Tim >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- > From nobody Mon Jun 5 18:23:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB48112EB72 for ; Mon, 5 Jun 2017 18:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvZd30-U4aM9 for ; Mon, 5 Jun 2017 18:23:00 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 7A29412EB6C for ; Mon, 5 Jun 2017 18:23:00 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 83so33101072pfr.0 for ; Mon, 05 Jun 2017 18:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4llVZZUlkv3X95CQearIFbqjuHEcV/5MBVOq4qetp8Y=; b=lp4/9dR5IF/1mm9w4mBl9ec+/c2cVP5swx7Wg0PfGN/P9HzfEc4p8R5Oxcvd3tIn9r UGXJkOq5cl0n1xKfa5EPGWd045ZgRi3EXcqHpww0Jx2if9SkcYdHE7X4/Cn3fHIOKXAi /6AJ7/EGiwrZUV4b52PvwwZXHFtdzYFAAqzll7bvOoN3+NeCOQLPXJgQ1QaIPTYL0Nq9 p+36VD/q3trGk//p0ViXXAMhbY0YnekPmQW5atWEtgshwWk1xLtk9L6qb0yL13oyHAO4 mKDULP7OKApv+8dsJqg+21acI++ewY8HNa/VkCt5rAAnXao9V/mEfXLJmgo1QVQSyhNC oHMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4llVZZUlkv3X95CQearIFbqjuHEcV/5MBVOq4qetp8Y=; b=GS4sAIPInmrFkiIh9s4EEoEIYua7YsurJa874YIfZHSgQVVVFlGMifZybSs+3sV6Cy XRkdbaCcVX1IVjj7RaHbroA+JRuKzaaNXlX6LAmhrwPscpllkPH4dJIFueiulS/ErKY8 GCw/MdalLYUMXFz8L8qbKYc75hE/XhazBbaYp2e3rfWeBjlq+3pUfi72sG7OOCSZdqW6 QEIkRHSFk/A581jiiScoT3jhRAaqCmv7e20KpPu4IqHfbfgE283SS8Y/nzSAStYhTd7X 0zAl+duiJOQ6Sa7k4oki+Bm2F1Ulgcva811CTNx6S/yDyMT7a+2qwRDCuBkIfJP2nROC 9B+w== X-Gm-Message-State: AODbwcC5/OTVLQ5MnI0cexLQJ1eLgYmRNvQGKpnbfFbKeuUzRmRyhFx+ 36Pqw1mPiD/tAPZl X-Received: by 10.99.174.77 with SMTP id e13mr23997040pgp.145.1496712179906; Mon, 05 Jun 2017 18:22:59 -0700 (PDT) Received: from ?IPv6:2406:e001:5517:1:28cc:dc4c:9703:6781? ([2406:e001:5517:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 67sm60506982pfn.84.2017.06.05.18.22.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 18:22:59 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <3bca0f2c-78be-4554-33a3-53240864fa63@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <18bc765d-8900-c986-2757-870822a0a9f7@gmail.com> Date: Tue, 6 Jun 2017 13:22:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3bca0f2c-78be-4554-33a3-53240864fa63@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 01:23:02 -0000 On 05/06/2017 21:53, Alexandre Petrescu wrote: > Le 04/06/2017 =C3=A0 13:05, Philip Homburg a =C3=A9crit : > [...] >> Moving on to a network architecture point of view, when using pseudo >> random IIDs there will be a longest prefix that can be supported. >> Lets say for the sake of argument we can support of /96. >> >> Then the effect will be that if in the future hosts support SLAAC >> upto /96 then we are back at the same hard limit. We have just moved >> be boundary by 32 bits. >=20 > Similar worries were expressed. >=20 > However, as I read this draft it does not propose to substitute new har= d=20 > limit for old hard limit. The proposal is leave it at 'n', i.e. a vari= able. >=20 > The optimistic evolution of this could be that in some IP-over-foo this= =20 > variable could be exceptionally /96 and largely over-ridden by a=20 > backward compatible /64. >=20 > Maybe something could be written down that clarifies this is not a > proposal to substitute new hard limit for old hard limit. Alexandre, I think that is what the draft says. Most of the discussion here has not been about what the draft says, but about what operators who don't read RFCs anyway might or might not do because they don't understand that IPv6= isn't IPv4+. That's an interesting discussion, but I wish people would give it a relevant subject like "IPv6 isn't IPv4+". Brian From nobody Mon Jun 5 18:30:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33784127201 for ; Mon, 5 Jun 2017 18:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6qv3NfVVjaR for ; Mon, 5 Jun 2017 18:30:16 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 4054A1200E5 for ; Mon, 5 Jun 2017 18:30:16 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 8so42537383pgc.2 for ; Mon, 05 Jun 2017 18:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KYf+uM/Ozdo3IiQ1oe3wwlsN3KnGXLMlsD76aPS45qU=; b=c8/zhNXkPgBnzDLmHAcxtfJM3fnvBigj/H2sj3YwRs77IMuaNktFhgYPqqE4DHn/V/ iHQX8dZG7/mam9Frr2yIZg6nsiQAO9F1nOQBhyKUIQvBb1S8JJPpdepBSKHgrKnbIiIy muq6qKWWJh91LnWFaH7b+GPR8A4P1uNJnxuGWsBPdd7z97q9rxUMdQ4xQMdCEhPK5RVp +QuBYiKMoQdnIShwRZA6zrt3cybcW+YGbTgX2yp4Ib1FDhdMKNCzb4nNY+06raeXm4sf 5F6CLeo+RQSmPRP9U6nL8RR8weXnyw9zRpgmeS580rXezUktArOP7RLrxi+vT3tKd4NF c81Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KYf+uM/Ozdo3IiQ1oe3wwlsN3KnGXLMlsD76aPS45qU=; b=C5/mR5PGFeH7tjNmkNvrPt/YC52xKqAOVPrqcYkHbNorvtglsGx3R6VWzEdzRlA7oz SPhgQ8IWbnMClVMMR5ORcjW6FFkj9KNRsWwzpbBeg2AjjsqiJeNyPch6nS0sReJHKBC+ z0X8Efe7vq/Krus4bMTxc55QtFYuuFv6R71xGFWpVc/PS6c4Pil03kw/Bo3E8KAuFyXh gfGKmJpJPAgHTx1GBMjxSuXNs2ar2RDjQE802elIhHxUbM0TMnixRR0eSu3Fq7fLUVQD vcKndiF72JXViS+o7Y5MudsH3T9Vc11FkxiAF+EaeUOmbcl1Jyl0HjTC2QlseszP/I4B aqZQ== X-Gm-Message-State: AODbwcCBwSjDIdemzNFwxeqsDKxBDZF8mkiLoXynKJSrB3pmCih20YKf EiOEzUNNB6P5Yq9n X-Received: by 10.98.67.86 with SMTP id q83mr23260421pfa.68.1496712615526; Mon, 05 Jun 2017 18:30:15 -0700 (PDT) Received: from ?IPv6:2406:e001:5517:1:28cc:dc4c:9703:6781? ([2406:e001:5517:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 71sm36209275pgd.57.2017.06.05.18.30.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 18:30:15 -0700 (PDT) Subject: Re: Comments on draft-bourbaki-6man-classless-ipv6-00 To: Tom Herbert , "ipv6@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 6 Jun 2017 13:30:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 01:30:18 -0000 Thanks for commenting on what the draft actually says. All good points, IMHO. Regards Brian On 06/06/2017 03:14, Tom Herbert wrote: > Section 1: "Recent proposed changes to the IP Version 6 Addressing > Architecture specification [RFC4291] have caused controversy. While > link prefixes of varied lengths, e.g. /127, /126, /124, /120, ... > /64 have been successfully deployed for many years, glaring mismatches > between a formal specification and long-standing field deployment > practices are never wise, not least because of the strong risk of > mis-implementation, which can easily result in serious operational > problems." > > I'm not sure what this paragraph is trying to say. I think might be > overly philosophical. > > Section 4: "For historical reasons, when a prefix is needed on a link, > barring other considerations, a /64 is recommended [RFC7136]." > > Historical reason seems like a weak technical argument, maybe just say > it's recommended and reference RFC7421. > > Section 4: "But operationally we recommend, barring strong > considerations to the contrary, using 64-bits for SLAAC in order not > to discover bugs where 64 was hard-coded, and to favor portability of > devices and operating systems." > > Not using something allowed by the standard in order to avoid hitting > bugs is self defeating. Bugs that are not discovered don't get fixed, > so in the future when someone has a legitimate reason to do something > different it might be too late to fix problems. > > Section 4 seems to bounce back and forth: First, /64 is recommended, > but then /48 might be okay, but then /64 is recommended again because > SLAAC might have bugs, and finally any length is okay because SLAAC > should be correctly implemented. I think it would be clearer to say > that any length is allowed but /64 is recommended and here's why. > > Section 5: "On the other hand, we assume that a number of IPv6 > implementations fail to enforce limits on the size of some of the data > structures they employ for communicating with neighboring nodes, such > as the Neighbor Cache." > > I think this argument is weak. This problem has more to do with the > number of neighbors than the prefix size. In this regard, using a > longer prefix doesn't have impact until it gets really long. For > instance, a /96 can already allow 4B addresses which should be more > than enough to kill any ND cache. I think this a case where > implementations should be fixed instead of the network trying to force > a workaround. > > Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jun 5 18:58:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9512EB95 for ; Mon, 5 Jun 2017 18:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX3YeMBryGTG for ; Mon, 5 Jun 2017 18:58:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D631212EB80 for ; Mon, 5 Jun 2017 18:58:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C9F2203BC; Mon, 5 Jun 2017 21:59:18 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BA0F76380F; Mon, 5 Jun 2017 21:58:35 -0400 (EDT) From: Michael Richardson To: "Templin\, Fred L" cc: 6man Subject: Re: draft-templlin-6man-aeroaddr In-Reply-To: <8b4caaafb6fc4b9d8245600993bf1f44@XCH15-06-08.nw.nos.boeing.com> References: <4234.1496699042@obiwan.sandelman.ca> <8b4caaafb6fc4b9d8245600993bf1f44@XCH15-06-08.nw.nos.boeing.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 01:58:38 -0000 --=-=-= Content-Type: text/plain Templin, Fred L wrote: >> PPP links just make up random stuff, with the option that they >> can keep it around across reboots. Or is the point to offload that state >> into the network? > I am using it on NBMA links where a node first obtains a delegated > prefix then next statelessly constructs an AERO address for itself. > The AERO address then statelessly links IPv6 ND with IPv6 forwarding; > if there is a neighbor cache entry with an AERO address that matches > the packet's IPv6 destination address then there is no need to also > look up the destination in the IPv6 forwarding table. So you are taking advantage of the mapping to implicitely do the routing? What kind of NBMA link is it? This could be useful for the ANIMA ACP, which is a mesh of IPsec (normally) over LL tunnels. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk2DEsACgkQgItw+93Q 3WVFFQgAqYw0Byr/yqkZIs5E9JL4prFHtr9SE3ow4vSTJu+yvErHHQR6Hs8+FEtY fsdvdVKx8i9HnpgkmZIu0eCPcemK3qU6h5GexHxz86hY5k51vq1IMkOBY3MBfNne 2zqHhKhppvJyEng0xQqaYmAbMMs3YRPXELjoD8nD5Hlun51gQdKHUUFAnIOywEdp PrD1Kx2eswTMIwpz6VfcMzci77ZV0W2rISi5ieL1+tHkMEuacyQ7GDXFEKA9slWZ y5WjHN7bIguJ9TF4MNVhJsbdb5SOBUay7LFqH7khNdKFlj+Sj21tz3vJEfagX10E eqy6K+/jOZZVgEq0j7+V7eIMFN+HTQ== =Cfgi -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 5 20:57:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BF012EACD for ; Mon, 5 Jun 2017 20:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS8_IBuy62LE for ; Mon, 5 Jun 2017 20:57:49 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F21126CD8 for ; Mon, 5 Jun 2017 20:57:49 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id 141so1198767ywe.2 for ; Mon, 05 Jun 2017 20:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eMNKxirMj9mP9XzPEshpRZF1OBFg94dmZeCcS5ardgQ=; b=qlIetfWukbam5/+T8VqkLcdfNGTruE29PUxIfL+MCMSxYy5dFWoTUnE8HgYta2OVkb U0howazc+S7iIyBXrxExHiJ2TlYALmuuZmmh6eakYib/g46P7r4zd9cMBHu8h1Cl28T4 r6IeM4yDI9SK2PzlMvaiJHePjOxcnl6ZdBGTNJMVfhP7zNptcNNBZvtiHSx3X059n5Cb SrgT1fRSOG/SOwgguKeMg6EXbfjrJ5fObgV7vS6eHZ7eEsNm/862hjJC/+zbtkajHf7M UiERzSD2KxQOTaychCSf/+aFo3G3+NhgsM23SKSA0X7ZVK+7zYXJiFygZcFj3gePBgna S50w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eMNKxirMj9mP9XzPEshpRZF1OBFg94dmZeCcS5ardgQ=; b=tgrh+0w4QSKtg6pRrkpONKtNG+mpUGIHAnAoNj759twA+Dv/WgtT3v8LJqc9NJ4RFc rPmu6qd6oFcu00scdQWOkORVetbEc4F6fDcAnIYXngzNX/5FYMAAFgBOSB3/dMdcHu1W mvNJfebcmLNJUuc5N3fTEpojxFJKFeJaRM1wnDKZ34oaursD7/+X0YKAdvKqgAuKZE+8 Ln3W5RxOdUbtrjqiOeUm5bFMivOtkHo3xlVOK4IId+G8Cp60hC6BKz8bD/rpPyrVD8OT pl3KcGU7dTuqpOj6NDbnVePfY2l7Sa9TLK//e4sE6PaEWq6tQBm0Jf7vIxnNvLUXeUre XYcg== X-Gm-Message-State: AODbwcBH2sFNFJIqje0Az2nd93dNkUO2/Q8TiXMOhCXko9qlfYIZQwXo OwD0BQDiy09NW0o4clLLf7pBixVYZF/k X-Received: by 10.129.173.74 with SMTP id l10mr1233999ywk.114.1496721468523; Mon, 05 Jun 2017 20:57:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Mon, 5 Jun 2017 20:57:27 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Erik Kline Date: Tue, 6 Jun 2017 12:57:27 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: james woodyatt Cc: 6man Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045ea6f67aaa820551429f2c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 03:57:51 -0000 --f403045ea6f67aaa820551429f2c Content-Type: multipart/alternative; boundary="f403045ea6f67635ab0551429fb9" --f403045ea6f67635ab0551429fb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6 June 2017 at 03:47, james woodyatt wrote: > On Jun 4, 2017, at 23:35, Mikael Abrahamsson wrote: > > On Sun, 4 Jun 2017, Brian E Carpenter wrote: > > > If we'd been able to agree on simply removing n=3D64 from 4291bis, I > wouldn't have put my name on this draft. > > > My take on this (and I don't think I am alone) is that this is a slippery > slope down to where when I in 10 years connect to a wifi, I'll get an RA > with PIO /128 with A=3D1, because the ISP decided they only wanted device= s > have single address, because that's what the product people wanted becaus= e > then people wouldn't be able to have more than a single device per > subscription (which is false, but some people believe this can be achieve= d). > > Down that /128 path leads NAT66 and all kinds of complexity to work aroun= d > these problems, and we'll have gained very little by introducting IPv6. > > > Now is as good a time as any to repeat that I=E2=80=99m working on delive= ring > *basically* this now. Not in ten years. Now. > > The only difference between what I=E2=80=99m working on now and what Mika= el > describes is that I=E2=80=99m dealing with the situation where I=E2=80=99= m a 6LoWPAN border > router connecting to a home Wi-Fi=E2=84=A2 LAN segment, and I can=E2=80= =99t get a DHCPv6 > prefix because either a) the router isn=E2=80=99t capable of DHCPv6-PD as= RFC 7084 > recommends, b) the router doesn=E2=80=99t have any more subnet prefixes t= o delegate > (because other routers have consumed them all, usually by cascading one o= r > more RFC 7084 routers behind the ISP border), or c) the router will never > have enough subnet prefixes to delegate because the ISP didn=E2=80=99t de= legate the > CPE border router enough space. > > We are already on the path to IPv6/NAT w/ address amplification. We had a > chance to stop it, and we blew it. It=E2=80=99s time to move on from that= mistake. > Consider ND proxy or application/CoAP proxying. We are in fact missing some APIs on host operating systems whereby userspace can request the kernel to get an address for its use. This would be the companion piece to 7934's recommendations. --f403045ea6f67635ab0551429fb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On 6 June 2017 at 03:47, james woodyatt <jhw@google.com> wrote:=
On Jun 4, 2017, at 23:35, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Sun, 4 Jun 2017, Brian E Carpenter= wrote:

If we'd been able to agree on simply removing n=3D64 from 4291bis,= I wouldn't have put my name on this draft.

My take= on this (and I don't think I am alone) is that this is a slippery slop= e down to where when I in 10 years connect to a wifi, I'll get an RA wi= th PIO /128 with A=3D1, because the ISP decided they only wanted devices ha= ve single address, because that's what the product people wanted becaus= e then people wouldn't be able to have more than a single device per su= bscription (which is false, but some people believe this can be achieved).<= br>
Down that /128 path leads NAT66 and all kinds of complexity to work = around these problems, and we'll have gained very little by introductin= g IPv6.

Now is as good a = time as any to repeat that I=E2=80=99m working on delivering *basically* th= is now. Not in ten years. Now.

The only difference= between what I=E2=80=99m working on now and what Mikael describes is that = I=E2=80=99m dealing with the situation where I=E2=80=99m a 6LoWPAN border r= outer connecting to a home Wi-Fi=E2=84=A2 LAN segment, and I can=E2=80=99t = get a DHCPv6 prefix because either a) the router isn=E2=80=99t capable of D= HCPv6-PD as RFC 7084 recommends, b) the router doesn=E2=80=99t have any mor= e subnet prefixes to delegate (because other routers have consumed them all= , usually by cascading one or more RFC 7084 routers behind the ISP border),= or c) the router will never have enough subnet prefixes to delegate becaus= e the ISP didn=E2=80=99t delegate the CPE border router enough space.
=

We are already on the path to IPv6/NAT w/ address ampli= fication. We had a chance to stop it, and we blew it. It=E2=80=99s time to = move on from that mistake.

Cons= ider ND proxy or application/CoAP proxying.

We are= in fact missing some APIs on host operating systems whereby userspace can = request the kernel to get an address for its use.=C2=A0 This would be the c= ompanion piece to 7934's recommendations.
--f403045ea6f67635ab0551429fb9-- --f403045ea6f67aaa820551429f2c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgkj961PI0cKtYsrbYbjU8cd09BrxapT2i oqiD9MskZgowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjA2 MDM1NzQ4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBALbtC3i+5SyJpr0Ut9gJd6LXyCPuHrQ/0UASbZBxPX82+oW0KlSw JLs2wAhL85ni9iGI3iw7rogDs3I0HyTtquTa3rwrez7YZ3VyWddxAgLEVZcn/MBOUqpkGqURpYDj A0LZ18/glOQKom1SAwoRr1k4G4SwpGd3VcPmnmfeGYJHRM/M6CMZ70rzOTz4n9/pykWdQddPgXfG JpnY+3OZ5Mvpl5kL4kYb3mcRu5ggBmiGMuqVhncfa882S+zGNSfGlcOt50eY+kpwZdQs+9akoz4b ooXu+XskFSnn/Z8DMJ/sv+Jn/hapbYa75LLmET9z1tImIldfUjVZW8h0hzcKtl0= --f403045ea6f67aaa820551429f2c-- From nobody Mon Jun 5 21:26:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FED1205F1 for ; Mon, 5 Jun 2017 21:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4XsXJEyXzGZ for ; Mon, 5 Jun 2017 21:26:36 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947071201F8 for ; Mon, 5 Jun 2017 21:26:36 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l14so63471417ywk.1 for ; Mon, 05 Jun 2017 21:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FKWJkgU6Az6GSG8Z5y8gpu9zlyLtRFuLMStKv7RQz+4=; b=A4o0X9/kkix/RrpMV0DH+i/PM9rTRZSfUAF/pmPJOsrGPr+oFY9XUeRYWxqDp+uDal SmL9AJXV3bfBTJN88h36ozI8DWEs/iXQAWB0HKBnNRcL+1V8k24HNhsU1LhZM04MeWjX NDD3NjXb0BM+QelTzaDy3Q8pZi7FJ5KcMnuET5T6Kld5IgPCiT5PLmH00oOTFqX65jHz rDdhW9MyLXZttuPTOJ6n+unns54OelSHzA6EcTMmNl1OwlJE31Qe3Hj+x40pq4791cXg +eoXsCpH2izHiZ0Uyxn+vbkSKwWPlxvAlpqN7RsVcJLFyTfvhJfLUrFMs8B4yVQZtM6s WK1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FKWJkgU6Az6GSG8Z5y8gpu9zlyLtRFuLMStKv7RQz+4=; b=KVDhhQKUw9N6BGJ5U2ppUjV+eji7wq8nOciXhBgLn/n+mOYmIjnrqECDsPJ9B6SyJM 3e7XU65DcwzSPJGKBmFqSxjXkIMzuYXxV9whPDdkY3/OUa0U8yImZDVwVkkwyOLlN7i2 HRRZQUvb8oRgsJ/SYsSANg5fhFbB76mDw1ER2eJfLAFAr5ZHzaQfBoy7Ob/2s+cWiRFr 2uxoNpKfgU1PGO97K6IDKEktTOPaounD4nCTeRJJoAxpHxj4qpX39kyr0pQD3VxoWUic FeMVDdUlrsfnxruFryjpRJGSg0JX1sUVPfrW80dxuEHzxrwAhc+xx871/Kcjw9aMhq/w SIow== X-Gm-Message-State: AODbwcA0jKa+bcCSLb9S46pa0xvknVl4M9u3dRW7to7bAmvJ1DcgG6Mo C2nuqzIhPh/7BPa4w6R5aD9uDsSuMnqY X-Received: by 10.129.89.135 with SMTP id n129mr1249842ywb.181.1496723195665; Mon, 05 Jun 2017 21:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Mon, 5 Jun 2017 21:26:14 -0700 (PDT) In-Reply-To: <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> From: Erik Kline Date: Tue, 6 Jun 2017 13:26:14 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Lorenzo Colitti , IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11470b746de5c40551430693" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 04:26:39 -0000 --001a11470b746de5c40551430693 Content-Type: multipart/alternative; boundary="001a11470b7468394005514306e8" --001a11470b7468394005514306e8 Content-Type: text/plain; charset="UTF-8" On 6 June 2017 at 07:25, Brian E Carpenter wrote: > On 05/06/2017 19:45, Lorenzo Colitti wrote: > > On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> None of that is the point. The point is to establish > >> that routing is classless > > > > > > Routing is already classless because BCP 198. > > > > > >> and /64 is a parameter of specific addressing schemes. > >> > > > > It *is* a parameter. The parameter's value is 64 for all unicast > addresses > > except those starting with 000. > > The parameter's *current* value, yes. But should we really be fixing > the value of the parameter once and for all in the addressing architecture? > Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design > assumes? > Because I doubt there is any good argument about things specific to the Foo layer for having something shorter than a 64 when 64 gets you many so nice guarantees for randomness, security and non-collision. This document does not include a problem statement -- it doesn't say what problem exists that need solving. If all this is about being able to execute the OS-specific equivalent of "ifconfig eth0 add 2001:db8::1/123" then I think that should absolutely work fine. We should file bugs to get OS tools to understand what this actually means. That, however, is completely orthogonal to 64bit IIDs. The 64bit boundary pretty much only has meaning in a SLAAC context. Not doing SLAAC? 64bit IIDs don't really affect to you then. If OS's make assumptions that there must be some 2001:db8::/64 route when in fact 2001:db8::1/123 was specified then that's an obvious error. IMHO, if /n isn't specified: use n=64 and if /n is specified then use /n. Seems simple enough. You can put a /123 PIO in an RA so why not on a command line. This document however burns down the whole house for the sake of lighting a candle that was in fact already lit. The only thing meaningfully affected by removing 64bit IIDs is removal of the last backstop that ensures network operators and users alike share -- however unequally -- the benefits of IPv6 and it permanently demotes IPv6 to little more than 128bit IPv4 with quaint, warty rules about fragments and extension headers. --001a11470b7468394005514306e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 6 June 2017 at 07:25, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
On 05/06/20= 17 19:45, Lorenzo Colitti wrote:
> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> None of that is the point. The point is to establish
>> that routing is classless
>
>
> Routing is already classless because BCP 198.
>
>
>> and /64 is a parameter of specific addressing schemes.
>>
>
> It *is* a parameter. The parameter's value is 64 for all unicast a= ddresses
> except those starting with 000.

The parameter's *current* value, yes. But should we really = be fixing
the value of the parameter once and for all in the addressing architecture?=
Why don't we fix it in each IPv6-over-foo, which is what the SLAAC desi= gn
assumes?

Because I doubt there is any g= ood argument about things specific to the Foo layer for having something sh= orter than a 64 when 64 gets you many so nice guarantees for randomness, se= curity and non-collision.

This document does = not include a problem statement -- it doesn't say what problem exists t= hat need solving.

If all this is about being= able to execute the OS-specific equivalent of "ifconfig eth0 add 2001= :db8::1/123" then I think that should absolutely work fine.=C2=A0 We s= hould file bugs to get OS tools to understand what this actually means.

That, however, is completely orthogonal to 64bit IIDs= .=C2=A0 The 64bit boundary pretty much only has meaning in a SLAAC context.= =C2=A0 Not doing SLAAC? =C2=A064bit IIDs don't really affect to you the= n.=C2=A0 If OS's make assumptions that there must be some 2001:db8::/64= route when in fact 2001:db8::1/123 was specified then that's an obviou= s error.=C2=A0 IMHO, if /n isn't specified: use n=3D64 and if /n is spe= cified then use /n.=C2=A0 Seems simple enough.=C2=A0 You can put a /123 PIO= in an RA so why not on a command line.

This docum= ent however burns down the whole house for the sake of lighting a candle th= at was in fact already lit.

The only thing meaning= fully affected by removing 64bit IIDs is removal of the last backstop that = ensures network operators and users alike share -- however unequally -- the= benefits of IPv6 and it permanently demotes IPv6 to little more than 128bi= t IPv4 with quaint, warty rules about fragments and extension headers.

--001a11470b7468394005514306e8-- --001a11470b746de5c40551430693 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgkjo9XA/DKWrss0WSLSMu43D4jfLEvXX2 Vc6XJAg+qqgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjA2 MDQyNjM2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAE7nPJ5G2PfWUlj/B7dUtrPK3QLCAgMO7bcfyxB8qjBMG1c91fhn Ba0sVcsHCqKwcANVH4xp7KPRR6bqx++dmO4I29z2Zx+erb+4uOsDaD3Pm2e8zqZLXP0Cz1WSobjj 7BIO6P1UmE3zcXxHfZlYEqhhh4w04HNYhXpwCMfmXjbJfOdSoEJ5LqHsOscmE7UtC//hjs6cnoo8 DYOpcfNhey7acyauGtuy/dhjBJhgD8x4sUGSDp5sgQVHjQAK7g2KM1AD7m7ixJDTvL1AGahcdKXU 97oiwgelzg5JYzl2DG+WDNGvFFZwt7bN26MmsqdyBGUXKXkFVwc+QzGgpZbqhoM= --001a11470b746de5c40551430693-- From nobody Mon Jun 5 21:41:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655931201F8 for ; Mon, 5 Jun 2017 21:41:16 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYB7vpxcD_XE for ; Mon, 5 Jun 2017 21:41:15 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 BC031126CD8 for ; Mon, 5 Jun 2017 21:41:14 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id h39so32773786uaa.3 for ; Mon, 05 Jun 2017 21:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=LcOuNStlKGRPVmuycN1nYRcykuAdwVFO6koZBaT1OgY=; b=FDHGQYCj1rxRmxZUhIqiexXESnn0aU2S6xaUSLjg1Tu+90bZmoHUg8ewPxLrXB5kUY vomyXacjCDiiYmYN/38r/XVn8YxuFOVu8f8k1dN2rNc9kv62Ot4jmH4L/JXN/n6F1rf4 jqDTL9837bxego+bEY/FBNV1gWsCieAs+ksmq+KcBqcPH3uO2hgWxSlQdX0wchy4bJNy /c6iKrnV0iZYDnDBZ/Ayc7LlPXoTC6Z6gKbn9vevVTWsqcuWg5jvw/ooKjovnpeZ/VmB YX5lkRKKrMNMw2A+UfzU11Bvmt+/RpcXO5p/NmvstKTvsFSc8T6nyFQwWULkjJx/Qo/e oPoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=LcOuNStlKGRPVmuycN1nYRcykuAdwVFO6koZBaT1OgY=; b=Tou0jvLnPJ3DgEUsg7AIXqyvGFbK5U4vFBopS+z2v0JEFerAgnnlLaIckKxR7U9iYS SMgRbZpF2/lS47YIWpCmLOdwSgkqIKgzKxvcqFF2cgUjFB5wnbzH22+O+lKXTGOL/lhN mJNGKvgZ9iuA1qb54oN9wbdzIk5qgq+2bBD03NzFnWulbd5VuMalShqSP5HqgMnHdVEF feTX3K49jofkr7bkeGFZWtqi45IhJVJJO703yTVDYce6oVpZ72aGKgoZv+I/YG5pOrHR oEN/DVWJgspAU2b0nb1Y4BaVpAW1WWySyUiLfAP1l6RLSZv5Jp99jiIo/7PJ6dSrIgjI X1IQ== X-Gm-Message-State: AODbwcDxirNdYSs5gEIEiBLAd91hBk32Di+x1sd3yGQXbMbky5uloNvM 4zvNr0Xko208AO4jyfjdA5TmjGfuPQ== X-Received: by 10.176.90.211 with SMTP id x19mr13872174uae.153.1496724073752; Mon, 05 Jun 2017 21:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Mon, 5 Jun 2017 21:40:43 -0700 (PDT) From: Mark Smith Date: Tue, 6 Jun 2017 14:40:43 +1000 Message-ID: Subject: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Brian E Carpenter Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 04:41:16 -0000 On 6 June 2017 at 11:22, Brian E Carpenter wr= ote: > On 05/06/2017 21:53, Alexandre Petrescu wrote: >> Le 04/06/2017 =C3=A0 13:05, Philip Homburg a =C3=A9crit : >> [...] >>> Moving on to a network architecture point of view, when using pseudo >>> random IIDs there will be a longest prefix that can be supported. >>> Lets say for the sake of argument we can support of /96. >>> >>> Then the effect will be that if in the future hosts support SLAAC >>> upto /96 then we are back at the same hard limit. We have just moved >>> be boundary by 32 bits. >> >> Similar worries were expressed. >> >> However, as I read this draft it does not propose to substitute new hard >> limit for old hard limit. The proposal is leave it at 'n', i.e. a varia= ble. >> >> The optimistic evolution of this could be that in some IP-over-foo this >> variable could be exceptionally /96 and largely over-ridden by a >> backward compatible /64. >> >> Maybe something could be written down that clarifies this is not a >> proposal to substitute new hard limit for old hard limit. > > Alexandre, > > I think that is what the draft says. Most of the discussion here has not > been about what the draft says, but about what operators who don't read > RFCs anyway might or might not do because they don't understand that IPv6 > isn't IPv4+. If the goal of this document is to state that the IPv6 prefix length and IID size is a parameter, then I think the title is incorrect. The title would be better and more accurate if it was something like "IPv6 prefix length (and IID size) is a parameter not a constant". One the title of a document is accurate, I've found it easier to determine what is in and out of scope for the document. With a title of "IPv6 prefix length (and IID size) is a parameter not a constant", I think the topics would at least be and be in this sort of order: * Prefix length and IID size is a parameter - text and references describing why and where * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) - text and references describing why, mostly a summary and reference to RFC= 7421 * Possible consequences and considerations when choosing not to use 64 - privacy, security and operational implications to end-user hosts and applications - privacy, security and operational implications to infrastructure - a specific consideration is the type and scope of reachability of the address/prefix e.g., ND cache DoS less likely of a concern for a ULA /64, because it isn't reachable over the Internet, and local network users have a vested interest in the network being available - summaries and refs to appropriate RFCs and sections of such as RFC7707, RFC7721, RFC7421 section 4. Regards, Mark. From nobody Mon Jun 5 22:09:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8953B1201F8 for ; Mon, 5 Jun 2017 22:09:45 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X92N1w3ujD9Q for ; Mon, 5 Jun 2017 22:09:42 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 CB247126BFD for ; Mon, 5 Jun 2017 22:09:41 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id x47so87656864uab.0 for ; Mon, 05 Jun 2017 22:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QUTj2HDjem0UGQT5GdBIRpJh+9Dz2720zwT2V06B3OM=; b=BiTUtN/lbUSZVqw8AsSjm87C1A3XjLx0l7zOgsNwHVgHxy1Jfefu750u5LaDguru4B DvHpZMS37TK8BY6Gw2loMsp08ZHyZTB3od41lnYfvNV6ZDX85/pMM9c+O0AqV6k7t6Gu Tteqmzial3ib/NSXCcDqa1Z33NlPwGgkP14UEvHGdrZi+iB7eth8+c7uyCdvuX3tr+Kj sACyakDHWaYFK+RWdhNZNHlOiyM18ZP9nB2+7M0fgLmPY9KJLuUSx5cBxzprqiE6MYWj R6hxAXJeb+zVSvI/KXwnszHw+aIgSLBXuMT9ECWIGeWM+WpV7JxYgU4TjkFcOhS69I+0 WwtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QUTj2HDjem0UGQT5GdBIRpJh+9Dz2720zwT2V06B3OM=; b=I/CToefHFFvueepX8Eb1e+JM5JF0w4zth6oEd6zO+EntHVHbP+bW7aQ1YNPeG8y6yT j9KGkDTuUbxQdzyuDAqguDROzcqe+mQ/z5ou+Jv+hkqGtV9alNt493n0kZ/fADbiLA1g XbV3gY2tF/9CFEgE5pHOVYJT8bGmh15v6QSxxt0pxJVfgoUYPVFUr/usQ64NH1G7ZWIR j/2jhAa6ktWCS9mnvWsZtRFSAKKzD7xB00D0IAYKFkwmOA/nzoC9o5pJ1Q6L+D+cmIj5 ihEUbD3WaFdIqF8GwHuQ1nnMLL3gQJVQPARSGmFxY96HBU2qw83omFWoEU0kBQkL4qwX mVTA== X-Gm-Message-State: AODbwcD50O1rMCph2ey3NBigfrDYG9odTDWC4dv3+VPBc2vN+Y1W/No9 A6YdzQaQbU7k7FbKE7ihG24Vum1RdxCi X-Received: by 10.176.83.16 with SMTP id x16mr14265029uax.11.1496725780838; Mon, 05 Jun 2017 22:09:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Mon, 5 Jun 2017 22:09:20 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Lorenzo Colitti Date: Tue, 6 Jun 2017 14:09:20 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: james woodyatt Cc: 6man Content-Type: multipart/alternative; boundary="94eb2c18f1ac7e96c5055143a0de" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:09:46 -0000 --94eb2c18f1ac7e96c5055143a0de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 6, 2017 at 3:47 AM, james woodyatt wrote: > Now is as good a time as any to repeat that I=E2=80=99m working on delive= ring > *basically* this now. Not in ten years. Now. > Here's a solution that works now: ND proxying. OpenWRT has had code to do it for a few years now. IIRC they're on to their second implementation, the first one was here . IIRC when I wrote my own proof-of-concept implementation it wasn't too hard. It's particularly easy when you don't need to support autoconf on the southbound interface, which you presumably don't need to support since 6LoWPAN has IPv6 addresses that are known in advance. AIUI this is similar to what the Android on ChromeOS does: the Android code runs in a separate namespace (equivalent role to the 6LoWPAN network), and gets an IPv6 address. There's a daemon on the root namespace (equivalent role to the BR) runs ND proxy for that address. That code may be open sourced under a license that would allow you to use it as is. Running ND proxying on Linux is pretty easy even without writing any packet handling code using the IPV6_JOIN_ANYCAST socket option. Apache licensed code (running on production Android devices) is here , look for do_anycast_setsockopt. We are already on the path to IPv6/NAT w/ address amplification. We had a > chance to stop it, and we blew it. It=E2=80=99s time to move on from that= mistake. > You may be on that path at the moment, but I don't think you were obliged to take it. You could have (and maybe still can) implement ND proxying. --94eb2c18f1ac7e96c5055143a0de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 3:47 AM, james woodyatt <jhw@google.com> wro= te:
Now is as good a time as any to repeat that I=E2=80= =99m working on delivering *basically* this now. Not in ten years. Now.=C2= =A0

Here's a solution that = works now: ND proxying.

OpenWRT has had code to do= it for a few years now. IIRC they're on to their second implementation= , the first one was he= re.

IIRC when I wrote my own proof-of-concept = implementation it wasn't too hard. It's particularly easy when you = don't need to support autoconf on the southbound interface, which you p= resumably don't need to support since 6LoWPAN has IPv6 addresses that a= re known in advance. AIUI this is similar to what the Android on ChromeOS d= oes: the Android code runs in a separate namespace (equivalent role to the = 6LoWPAN network), and gets an IPv6 address. There's a daemon on the roo= t namespace (equivalent role to the BR) runs ND proxy for that address. Tha= t code may be open sourced under a license that would allow you to use it a= s is.

Running ND proxying on Linux is pretty easy = even without writing any packet handling code using the IPV6_JOIN_ANYCAST s= ocket option. Apache licensed code (running on production Android devices) = is here, look for do_anycast_setsockopt.
We are already on the path to IPv6/NAT w/ address a= mplification. We had a chance to stop it, and we blew it. It=E2=80=99s time= to move on from that mistake.

<= div>You may be on that path at the moment, but I don't think you were o= bliged to take it. You could have (and maybe still can) implement ND proxyi= ng.
--94eb2c18f1ac7e96c5055143a0de-- From nobody Mon Jun 5 22:13:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6A1243F6 for ; Mon, 5 Jun 2017 22:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lun4tSNP-1oO for ; Mon, 5 Jun 2017 22:13:24 -0700 (PDT) Received: from fe3.lbl.gov (fe3.lbl.gov [128.3.41.68]) by ietfa.amsl.com (Postfix) with ESMTP id 21E701201F8 for ; Mon, 5 Jun 2017 22:13:24 -0700 (PDT) X-Ironport-SBRS: 2.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GHAAD8ODZZf0fWVdFcHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhRyODJICiCqNVYIQhiQCgwg/GAEBAQEBAQEBAQEBAhABAQkLCwg?= =?us-ascii?q?mMYIzJAENcgEBAQEBAQEBAUwCPi0BAgIBOgYBATcBBAsLISUPBQ0TAQUBIhOKE?= =?us-ascii?q?gMNCAMCoF0/ix2DEIMJAQEFhC4NhDgBAQEBAQEBAQEBAQEBAQEBARkICQEIhD+?= =?us-ascii?q?DcIMggliFVIIxkT6MQDsCilmDfIRNiwyGfos+h1szgRUfgUN/ChyFIQ8cggJYi?= =?us-ascii?q?SoBAQE?= X-IronPort-AV: E=Sophos;i="5.39,304,1493708400"; d="scan'208";a="77614817" Received: from mail-it0-f71.google.com ([209.85.214.71]) by fe3.lbl.gov with ESMTP; 05 Jun 2017 22:13:23 -0700 Received: by mail-it0-f71.google.com with SMTP id v184so74798456itc.15 for ; Mon, 05 Jun 2017 22:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2XE8TLmyCc/OBH81oAeCi8+m22SJ+CXS2OEoOMAoheo=; b=Hg6G1jW4dNTRscFt4rZBGlaWNuQBadIS2XXfPNlT9W2u34mDYI+vKOfJob7ybCj8oQ 3Iu607YyqXmceXhh+Lgwx+wfEILHKahUBmg57f7Usqx5iJpDVmyiCDtfarZa2NrSksxs vfaiQ9vWSIT7HgUkCp4E4zKfwfNqRHZtYCwmGllYgQRkTt31aPtLRB+65m+oD46YytYR D12tj7hh7/Ys6UEyFabJ0/lrqlBY6Qbw4vEJouMlqaaZVi0cN/Fl1/4S+kdMxxDv1N1X UD/QwghxnK7YaBJ4iOen1eek26ZdgaIDuz4tADJf7PFFeZO7XudQe3G9/lqRlh87UxHs 5mgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2XE8TLmyCc/OBH81oAeCi8+m22SJ+CXS2OEoOMAoheo=; b=cR09GqXmOXhq5aBZ95Hr+blqkEaWbZqMw8Pr4qyJp8vyXZiMomfAH19O3l3LmSpIoH ysJb1O3Wlx5RjaQFUovz6ajjZp1O18LyhZ3hSxUbaFZi/2fDOpfNbjRkW3nSKHlIWy4C EvU8t02qdXMpahHGRN1R3Y1SQ9zba9kX/hSv3SclgwY8N6k3ogkrNh7RW4d9ojyPBZEK 8GdgEFCN+Vfj/rwmempYicFClDGXBIUmn/kuY94WZuQzdWLC5B7tLL2CrZ8iaug1cRE6 CgTbj/lOw0s1ehRzOQDpiqlOdTAJj4OH44SR/nixALDTSI8SJhPYcdHSsdK8+CMf05gH ua+A== X-Gm-Message-State: AKS2vOwFVC9CgRw/WXuQ7XQ50qVfhhAG6TjVe8RNmur5A2NQLB7473oc hP7IySfQDzoFk0LyC4SHByDs7ZHGOyAmwdEM7JYPD2ndYIXFbNsEWyFTQb1Uwg9AjTdkbY2u X-Received: by 10.107.169.207 with SMTP id f76mr784389ioj.71.1496726003014; Mon, 05 Jun 2017 22:13:23 -0700 (PDT) X-Received: by 10.107.169.207 with SMTP id f76mr784366ioj.71.1496726002773; Mon, 05 Jun 2017 22:13:22 -0700 (PDT) Received: from localhost ([47.41.164.78]) by smtp.gmail.com with ESMTPSA id p204sm1920128ioe.14.2017.06.05.22.13.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 22:13:22 -0700 (PDT) Date: Tue, 6 Jun 2017 00:13:21 -0500 From: "Dale W. Carder" To: Mark Smith Cc: Brian E Carpenter , 6man WG Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) Message-ID: <20170606051321.GA69252@cs-it-6805697.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:13:25 -0000 Thus spake Mark Smith (markzzzsmith@gmail.com) on Tue, Jun 06, 2017 at 02:40:43PM +1000: > If the goal of this document is to state that the IPv6 prefix length > and IID size is a parameter, then I think the title is incorrect. The > title would be better and more accurate if it was something like "IPv6 > prefix length (and IID size) is a parameter not a constant". This is sort of where I got hung up also. Section 4 deals mostly with the IID for SLAAC, but this didn't seem to match the introduction: ... varied lengths, e.g. /127, /126, /124, /120, ... /64 have been successfully deployed for many years, glaring mismatches between a formal specification and long-standing field deployment practices are never wise, not least because of the strong risk of mis- implementation, which can easily result in serious operational problems. So to me, that wasn't a problem statement this draft addresses. Would it be appropriate to rework this to something on the order of "/127, /126, /124, /120, ... /64 have been successfully deployed for many years and this draft seeks to clarify that the IID parameter in SLAAC would applicable to these deployments." > One the title of a document is accurate, I've found it easier to > determine what is in and out of scope for the document. With a title > of "IPv6 prefix length (and IID size) is a parameter not a constant", > I think the topics would at least be and be in this sort of order: > > > * Prefix length and IID size is a parameter > - text and references describing why and where In section 2, I-D.jinmei-6man-prefix-clarify is mentioned, but is rfc5942 not clear enough on this front? Particularly its section 5 deals with an implementation making assumptions about /64. Section 3, Additionally, this document clarifies that a node or router MUST support routing of any valid network prefix length, even if SLAAC or other standards are in use, because routing could choose to differentiate at a different granularity than is used by any such automated link local address configuration tools. This isn't really clear to me, is this in reference to the nodes routing table, or is this about different Prefix Information options in RA's that are at different granularity? Section 5, I had heard anecdotally that one enterprise had specifically chosen to deploy their datacenter networks with /65 subnets specifically as an approach to disable "all the automatic stuff" (nobody told them about link-local I guess). I do not know if that was actually deployed, but I would be pretty curious if there are in fact intentionally short prefixes deployed that would cause surprises if SLAAC, etc started working one day. Dale From nobody Mon Jun 5 22:15:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A51294A6 for ; Mon, 5 Jun 2017 22:15:24 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGst-5-aUMt0 for ; Mon, 5 Jun 2017 22:15:23 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 2858C1201F8 for ; Mon, 5 Jun 2017 22:15:23 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id u10so87667993uaf.1 for ; Mon, 05 Jun 2017 22:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7IkmDZQdvSxsdnRHHYQLZdtLR2Jwv+x0uB5uw6VRZyw=; b=lGqu0mh8hn1E1MehTtu9nEl0HlpVnFwnS74nMy7zmHDU9mjNhEB9hLA/Fyoji0E/+x 420o/s3ZiWyLZVI6cshM7m9zTVLojuA9dMhoo0ny6ByhZZS5/oDk/GzNdXHnQjaS6CJD R9/CT1wLbbHwNNd/M893sgKzevCjLtzbR9/fVcOQE9yWO9tr01Q/JBMenyar7Dom1281 SR28HXzKMdA87jstPyMvdNTRtpEkF/KEqg2GA4vaBGW6EPkK65r5zF7f7Wmt0ckb/9af v0wxqR7iEhjo5qbWPLxJF5g9jcq/aogfUzANWpj+1yQPFKD+uqBkdBSLw7w1Sswk4GFa kQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7IkmDZQdvSxsdnRHHYQLZdtLR2Jwv+x0uB5uw6VRZyw=; b=RMureoOMFPUCCacDUgwhi252n2H9vGnsikSvaMi8vygi8s+NGcE4h9qJ7u9GeyMQw/ EshCG5O0y8xM+jMbS0CVUB3ROQ5FcxdiTZwILWWsMqpmZ7+Cnwnxlxlg8eDPYzSeGKHG REvfCFKccGrQmmMB+Csapm0qh12O11IP0ndl31hiWH9pyKxGLJoW6AEFgvjy2mxbJoOu 7kVMxXHeJxLI9UJQHMsh/8s9cAnXjCnH5ewXa3qaO//xwyJV4hKSGKAcageHDbqMOrm2 vzQF52rC4MjbuhevqGMR4fA+9m95+Nc2QnP2++x5j/Kr7TCiuSq9I3s7WI4r+gCE9TFZ DIag== X-Gm-Message-State: AODbwcAHHKm6s47gKHwLMLNdKk0nQaE5nxAQpwWaGmkV7DRKdkYirRnX yD1PBz1CQAieOrd/t0VemNf3F+/+hVB3 X-Received: by 10.176.27.90 with SMTP id n26mr1736381uai.94.1496726122189; Mon, 05 Jun 2017 22:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Mon, 5 Jun 2017 22:15:01 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 6 Jun 2017 14:15:01 +0900 Message-ID: Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="f403045ea092d73401055143b4b7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:15:25 -0000 --f403045ea092d73401055143b4b7 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith wrote: > One the title of a document is accurate, I've found it easier to > determine what is in and out of scope for the document. With a title > of "IPv6 prefix length (and IID size) is a parameter not a constant", > I think the topics would at least be and be in this sort of order > I think you forgot that if you want to run non-64-bit IIDs on any currently-defined link type you need to deprecate all the IPv6-over-foo documents. Remember, Job's original motivation for this draft was "I want to assign a /123 in my network", and that is not just a violation of RFC 4291, it's a violation of RFC 2464 as well. To be clear, I still think this document is a bad idea. I still see no reason for us to do this, and lots of reasons why we shouldn't. --f403045ea092d73401055143b4b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 1:40 PM, Mark Smith <markzzzsmith@gmail.com>= ; wrote:
One the title of a docume= nt is accurate, I've found it easier to
determine what is in and out of scope for the document. With a title
of "IPv6 prefix length (and IID size) is a parameter not a constant&qu= ot;,
I think the topics would at least be and be in this sort of order

I think you forgot that if you want to run non-6= 4-bit IIDs on any currently-defined link type you need to deprecate all the= IPv6-over-foo documents. Remember, Job's original motivation for this = draft was "I want to assign a /123 in my network", and that is no= t just a violation of RFC 4291, it's a violation of RFC 2464 as well.

To be clear, I still think this document is a bad i= dea. I still see no reason for us to do this, and lots of reasons why we sh= ouldn't.
--f403045ea092d73401055143b4b7-- From nobody Mon Jun 5 22:42:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B4412EB71 for ; Mon, 5 Jun 2017 22:42:51 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6REgxo6rM6O for ; Mon, 5 Jun 2017 22:42:49 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 98A6B126BF7 for ; Mon, 5 Jun 2017 22:42:49 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id u10so87896460uaf.1 for ; Mon, 05 Jun 2017 22:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hMdDfc43+WvhTf/0/F8i/t6abQmE8RWyOe1zWTv6k3k=; b=qapEZLE7/BchOjPtiGKzwbmAeYF0O/Klq4sXZhPKFhg1KBpv5cU7y2hsd+7W4VTeqC PXKDLuaiQQDpJADfGo/AH8f1B+HPggy98xcTjeC+2NNH9UItp66vXCFh+Kco/Wg4D9GJ Jzkpfjg1+Nhvm8Nj1T8YoN4rXEUL5hyPCAN630KIikvveE7CniTLBwBlbECvPARzZGkz wScRwmvW39kBtx0irgqHblBY3CPNlf8j6RYLsP/0w+/cVzYoVnCBhmTBAwwX4eN4ZCnp SDVlIsXpO7WRRaIgt99Ydq2pS1Ym5lqZJthkbvZU5Stgylv3olzj6vmz+TWqW+hm8wGM gcbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hMdDfc43+WvhTf/0/F8i/t6abQmE8RWyOe1zWTv6k3k=; b=m3wjDw2HhZjm/869FiUz/KDJT37pozac1CUQS/edzyTdTIhH8kf33gxrTGZxXBpW48 NT2y/I20ydUqKo2dgTo87B8TIh40tA+7wHWyMmaqEIURZIlrkFZhy/jnIJcT9ftfoW8Y 59Af2SQkRKLGsVpIlYvn1fbbFhdxwz0fOQ1WMN9y3UyWZwzkfsv9lXaIByKn+9M6k0kx CSjza4UrJZo14WA5KbK8a2bjU1Qy98KCYbWNvjSGEJkCirxR51jigyhoVzpBeMdhGov3 RjGOA/ciPqp6ZJP7eVN9PhGJWPfy9rRfFcdRwUB0WT/PBp/1SqiAd8SKxOACJ/EMpjdr JjPg== X-Gm-Message-State: AODbwcAL2od6t5GKLC+AoLDVouMbV11VxJIHdHfDI0jT4hzr0oYrBkFW xZ9nDCtD8E6JO/7IwEZWehcGZVGjhBXk X-Received: by 10.159.40.136 with SMTP id d8mr14074348uad.48.1496727768578; Mon, 05 Jun 2017 22:42:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Mon, 5 Jun 2017 22:42:28 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 6 Jun 2017 14:42:28 +0900 Message-ID: Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="94eb2c124714f918120551441691" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:42:51 -0000 --94eb2c124714f918120551441691 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith wrote: > * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) > As an host implementer, I strongly object to this. In practice (if you ignore the will-never-be-used space in ::/3), the current state of affairs is that the parameter value MUST be 64. That means that an implementation that is compliant with IETF best practices can simply not work when the value is not 64. Saying that the value MAY be larger than 64 is bad for host users for all the reasons written in RFC 7934. I don't think we should support this on general purpose hosts because we as the users of those hosts will all suffer from the reduced functionality and decreased efficiency that that brings. --94eb2c124714f918120551441691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 1:40 PM, Mark Smith <markzzzsmith@gmail.com>= ; wrote:
* The = parameter's default value SHOULD be 64 ("SHOULD" per RFC2119)=

As an host implementer, I strongly obj= ect to this.

In practice (if you ignore the will-n= ever-be-used space in ::/3), the current state of affairs is that the param= eter value MUST be 64. That means that an implementation that is compliant = with IETF best practices can simply not work when the value is not 64.

Saying that the value MAY be larger than 64 is bad for= host users for all the reasons written in RFC 7934. I don't think we s= hould support this on general purpose hosts because we as the users of thos= e hosts will all suffer from the reduced functionality and decreased effici= ency that that brings.
--94eb2c124714f918120551441691-- From nobody Mon Jun 5 23:36:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714B7126B7F for ; Mon, 5 Jun 2017 23:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ753lzdfXkq for ; Mon, 5 Jun 2017 23:36:06 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DF7126B6E for ; Mon, 5 Jun 2017 23:36:06 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 141so2063648ywe.2 for ; Mon, 05 Jun 2017 23:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sAVZr5C8miVmqXPkK2s1Z9zBB7MrkdI2Fmr+81ppiik=; b=SZtqn8y2GUsh5bxYEx34UUrOheIbd/C+FiUpg1AKm3zl0oBKWBHr8TmPHJQsDvMORv AN2NIJ5TCWtrkjHBmU6rCG/IGzhcHBPnwVPJ0yjj0SoKGNg1j5L3WFdab7UKFZjMUzV6 WBSioHFqtQx0rMJ2v14jL/KncRU9QEnxgZXJe9lo/mrilhFTBhsnF9SHAiRzwfzWx8mE C1NCBUDRRa/cjM2qoBw/vzJ/wjDrvZkoHxSYouvn0p2XRY2OJ8vSDzLf6N1/u8S43y2n a52z0LSsJIDUNHaJvWHchd8jCVz96RSUby6tt6HQ0Sry0gLvx5t0NEOATEZKfitft8fz h+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sAVZr5C8miVmqXPkK2s1Z9zBB7MrkdI2Fmr+81ppiik=; b=PF6ewrAIzhaumTabaDvXoVq+2oqJ35taIy+l8cR4HSD83Z6dH6MEuC2Rh0ferwBB8y 17e2IcSoBVC8OYnoCi1OJbeeFW1+AWcsAaBr+n/vlvItJ0IxXCvhMNWv4zWPXXUzOSdM vGEtzTVkmV6E3OeklWioL5BiTiaUSSenM1JHVYzSeizodn5jv0pYNJD9LUvOBW76dNg7 lUtOCB3zMvfYgmhQOpwSV7UugnSyc7b1YoZ194zIbTwGu8D6QxtqWhDODY4nTmoYqJpr 4WUC2IT4RASznqiSRTR8aw+Ajj1drPegWjJFcGTfJN1CcWZl3eKrMEOUvAxSV5zFmYcj lw0g== X-Gm-Message-State: AODbwcBGUmfFZSykm8m1vBIkW9FtWlWX7F1MfFuGrqH9aBW+3eL4MTtQ HbSAaVnp8ZQ6Ds9gC1lrEQL/LRv3jA== X-Received: by 10.13.245.71 with SMTP id e68mr1480551ywf.269.1496730965325; Mon, 05 Jun 2017 23:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Mon, 5 Jun 2017 23:36:04 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Tue, 6 Jun 2017 08:36:04 +0200 Message-ID: Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 06:36:07 -0000 On Tue, Jun 6, 2017 at 7:42 AM, Lorenzo Colitti wrote: > On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith wrote: >> >> * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) > > > As an host implementer, I strongly object to this. > > In practice (if you ignore the will-never-be-used space in ::/3), the > current state of affairs is that the parameter value MUST be 64. That means > that an implementation that is compliant with IETF best practices can simply > not work when the value is not 64. > > Saying that the value MAY be larger than 64 is bad for host users for all > the reasons written in RFC 7934. I don't think we should support this on > general purpose hosts because we as the users of those hosts will all suffer > from the reduced functionality and decreased efficiency that that brings. Why can't we say RECOMMANDED 64, and default SHOULD be 64, and for the protocols that require 64 it is a MUST? ... shouldn't that handle your issue and Job's issue and everyone's issue? I can't really see why I shouldn't be able to MANUAL configure a /125 on my interface and have default gateway being provided by RA on link-local using /64. Two different address "types". -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Tue Jun 6 00:18:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F85126B6E for ; Tue, 6 Jun 2017 00:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrf80QhWAIlf for ; Tue, 6 Jun 2017 00:18:05 -0700 (PDT) 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 1EC281200CF for ; Tue, 6 Jun 2017 00:18:05 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id p85so77625266vkd.3 for ; Tue, 06 Jun 2017 00:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=19fIMX0aaNMHcQnCUMy8NnA5QQrTf+zPk5ZecbyPe8o=; b=EOjqzSeWxxhORCL8is/tlA5skLXsDl78MV0U71hsRDAigMXNMuW/d1MSwK9gRUKVQh LN1lAdkexAWpHsDXg+YKVSqmBX5zyZws2ou7+d+IloEHIsKNkIRYPeX7L61px9eQdtxs yiW9jphy4iGZVmae3s+6Y12T1v3dQEve77bT0kdaqvpiV1ozOvfC+4odXtvWoLme0jZl QEskVafD6ogr+NTBO1vngumHxcE+y72WhTO2xqqBstirY37FhwqmDr2r/OiJ06DwZOWD l1J8cIVgmTzwHQxN8UhqkNhtdqmu/E66yMjz1FyyZ3z1QPP6Hnwh2oASNeqrsusltocm G4ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=19fIMX0aaNMHcQnCUMy8NnA5QQrTf+zPk5ZecbyPe8o=; b=dPFmC2J7hQEWNUvAxXJwStnN3WDYmsYeTqSfyZTJ6E2yxX9viSPQC76ySWSuaCvDQl coGTt14TyohkhvNtwf2hB7ZQC1T4cUcOJsxCjeeuOpCk8RgXCOm39Tjvfgt2+cl4GOlH DSr08ffKuUlKhH4voVggqJGJBv1Ba0GPpUlYID2V3fAJyvpXB8cKNVojXradZrWIqB/b bRp1KbYno92mn03cjSe7bPlmc4+ct3sHVGhgS8bm1wvVIl96hiN0dohesd1mPPhPgc1F 5pIjOeg3V5HSPEuoSuhMgWBPql9zT8Ep4LXmHbLgijOSvwWtt7rpGSO103VFUbRwrWnj sBxg== X-Gm-Message-State: AODbwcCDRTm2HUbWy7ZBP8BxRQheWTggznmMWp56LepDqN2Ni5V2NJmS 3MOjISsoSx9jclIVJ8LI5jAYAdSDNyHi+PE= X-Received: by 10.31.33.81 with SMTP id h78mr6519341vkh.29.1496733484081; Tue, 06 Jun 2017 00:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 6 Jun 2017 00:17:43 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 6 Jun 2017 16:17:43 +0900 Message-ID: Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Cc: 6man WG Content-Type: multipart/alternative; boundary="001a11c024caa4f18b0551456b70" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 07:18:06 -0000 --001a11c024caa4f18b0551456b70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 6, 2017 at 3:36 PM, Roger J=C3=B8rgensen wro= te: > I can't really see why I shouldn't be able to MANUAL configure a /125 > on my interface and have default gateway being provided by RA on > link-local using /64. Two different address "types". > I have absolutely no problems with manual configuration by the device operator. If that's all we're talking about here, then let's write that up and publish it. --001a11c024caa4f18b0551456b70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 3:36 PM, Roger J=C3=B8rgensen <rogerj@gmail.com><= /span> wrote:
I can't really see why= I shouldn't be able to MANUAL configure a /125
on my interface and have default gateway being provided by RA on
link-local using /64. Two different address "types".

I have absolutely no problems with manual configura= tion by the device operator. If that's all we're talking about here= , then let's write that up and publish it.
--001a11c024caa4f18b0551456b70-- From nobody Tue Jun 6 00:48:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1252412EBB8 for ; Tue, 6 Jun 2017 00:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgycXsUY8oyi for ; Tue, 6 Jun 2017 00:48:22 -0700 (PDT) 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 C0070129C1A for ; Tue, 6 Jun 2017 00:48:22 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id g66so19711928vki.1 for ; Tue, 06 Jun 2017 00:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9IiiseqvgAfMSdxO3KLHxq1pSyuJKpUgTsWB7oM5F4w=; b=YNEwYuTbIfQjT5AcgX2fiSMEHC9J94y+UrrtD5fJqUy6J1EJbQUj7vk19e63Iu731p CldGB+dEZKL5Duru/OCFMXx0a3D7Fr5QMdCSF89rS3CxOY7MNmgWBzo7t6xSu6pu68iF eBUVtBSNTu8hpWN1so6m/1oYYJs/J+8reeACQ3TZz/2wAHr89mkVDOrBaxevz2LopRar +ijSEHofR8+3AE37eJVhs7r7vmTw+D8dKod092ES+ejrWqY7gjqVNe6ZwAx2tT3wf8qt qyCcgiDufYAbo26F316MPsu7z7JTrZjHBuA3GcWx0MzKh6TyzopePHN+EXNuL3rcIUaa DdsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9IiiseqvgAfMSdxO3KLHxq1pSyuJKpUgTsWB7oM5F4w=; b=aGNSisvPAttvomF2bkgzRlcB6Ex4SvKn48i40U11mWJSPcgcbmLrG6YKDraKQ7wgSx /agHEQLDn9/gGdGw/P0pAAxE2TWvhMQDnop+XhvA0KdhAAuWoi2krfJTWmJy4fn8k1+/ IqZLGvyPlTiCfo1i/aCsPyAWSvcpKy8rUfaCLxbPXr8KCreLSEnygEBFFDk90655e9xH uQZLlK7CTMRZRyPNBQwepuoHpnO5MX4lwbV9ZISuW5S4/VTM/8WG1/ncA82MLvONw4WC kolh9soND3sMfHEe0Y5wvQtwHYHpymNAH0o2XdeygKjp4+znqfeTP5yyW0FCHZI0ZwGm mNjg== X-Gm-Message-State: AODbwcCfEtoLluAOcmgUU5GET+C8duznElAjY2czmwoaxBWQqdwKRScU YBFC8H2014ysG3VK/VOt7D3tTXbOjkrQ X-Received: by 10.31.69.138 with SMTP id s132mr9393112vka.13.1496735301697; Tue, 06 Jun 2017 00:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 6 Jun 2017 00:48:00 -0700 (PDT) In-Reply-To: <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> From: Lorenzo Colitti Date: Tue, 6 Jun 2017 16:48:00 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Ca By , Philip Homburg , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a114dd2d2fb960d055145d7c6" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 07:48:24 -0000 --001a114dd2d2fb960d055145d7c6 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 7:25 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The parameter's *current* value, yes. But should we really be fixing > the value of the parameter once and for all in the addressing architecture? > Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design > assumes? > If that is the authors' goal, then what the draft should say is that the IID length is 64 unless otherwise specified by an IPv6-over-foo layer. That is not what the draft says today. I also suspect it's not the authors' goal. At least Randy and Job have clearly stated that what they want to do is run non-/64 prefixes on today's links (Ethernet, maybe wifi), not on some future link layer. --001a114dd2d2fb960d055145d7c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 7:25 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
The par= ameter's *current* value, yes. But should we really be fixing
the value of the parameter once and for all in the addressing architecture?=
Why don't we fix it in each IPv6-over-foo, which is what the SLAAC desi= gn
assumes?

If that is the authors' go= al, then what the draft should say is that the IID length is 64 unless othe= rwise specified by an IPv6-over-foo layer.

That is= not what the draft says today.

I also suspect it&= #39;s not the authors' goal. At least Randy and Job have clearly stated= that what they want to do is run non-/64 prefixes on today's links (Et= hernet, maybe wifi), not on some future link layer.
--001a114dd2d2fb960d055145d7c6-- From nobody Tue Jun 6 00:52:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20AD12949E for ; Tue, 6 Jun 2017 00:52:44 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4eV5sovnafh for ; Tue, 6 Jun 2017 00:52:44 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 C57CC129490 for ; Tue, 6 Jun 2017 00:52:43 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id h39so34670460uaa.3 for ; Tue, 06 Jun 2017 00:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=BePpOWhf+AAxZb1Q4uI9VglZ25GJcdhuyhdnIWNTvzM=; b=rP7qIQ+WkKTnPPZbwesIaZmTP7LGc6Bs+ZApOi6xruWCLs18Q2oUAtGlXDc/ZGfHBq BY4wLDFBNfKgMcxe+gpvrSrDVogK6lIIhg9eW7XhIVU+3vVlVTBW8nH/kGh+c7XA4o0D q4ewO5LR5ME/c9z3VjT6jA2hP/rbYUB4EIFpZsXlryLElsI3r15QMcH9h1M2L8ENl9qU WX6QVU0WWfT/snWBDgIae0f+2JwgHveeLaV/2PBlJl52q9hW8IFeItqz3o7Y+M7Ql5bi r3I+LH2UoK+szBUu6/heaQDQsZOFgRVpy14aDQ39krp3uX1XimIA7d/mG7PwLuRNpmKG rxKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=BePpOWhf+AAxZb1Q4uI9VglZ25GJcdhuyhdnIWNTvzM=; b=neFBS/0ZhCodlP3gHjTGCsseGOTJ8V1JwXYPjLApfuuRIc16fMWAZ+Q7P6dAyfPS4T YsMNDQajNT6frIDKhkd4qOgpZU8n5s/uJ10/Z0C2+s4NCgNYIZAGWqDBuYjGmks6b+UE CpB760WZJRtf1YKTZvg1B76AiNIUNAOSBT6kPm5WK2MlZdMtrPfCtr4IuczvRojFsJAR jcIoDc8fe3uI0HtHUZji69Rimo4r3o2LkBFhKl6GtEl9uizDZhNXPSq31DhbSW2SO8Ua 6u5KvsK3fVPyibGTZquBWu9ADSy7mQI9uyEqJ7Mdjde1hRHTuc3oPS+GcIuxS+Fe4GXC /Sog== X-Gm-Message-State: AODbwcA8DHGtpHRN/d3IEBuuojkNnsoZc8uWs3qgu2XckETfUDinifqK Gu582rQmc8iRMNq/PL9oorU1o/pAow== X-Received: by 10.176.24.78 with SMTP id j14mr3510653uag.125.1496735562847; Tue, 06 Jun 2017 00:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Tue, 6 Jun 2017 00:52:12 -0700 (PDT) From: Mark Smith Date: Tue, 6 Jun 2017 17:52:12 +1000 Message-ID: Subject: Different sets of needs (Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00)) To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Cc: Lorenzo Colitti , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 07:52:44 -0000 On 6 June 2017 at 16:36, Roger J=C3=B8rgensen wrote: > On Tue, Jun 6, 2017 at 7:42 AM, Lorenzo Colitti wrot= e: >> On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith wrot= e: >>> >>> * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) >> >> >> As an host implementer, I strongly object to this. >> >> In practice (if you ignore the will-never-be-used space in ::/3), the >> current state of affairs is that the parameter value MUST be 64. That me= ans >> that an implementation that is compliant with IETF best practices can si= mply >> not work when the value is not 64. >> >> Saying that the value MAY be larger than 64 is bad for host users for al= l >> the reasons written in RFC 7934. I don't think we should support this on >> general purpose hosts because we as the users of those hosts will all su= ffer >> from the reduced functionality and decreased efficiency that that brings= . > > Why can't we say RECOMMANDED 64, and default SHOULD be 64, and for the > protocols that require 64 it is a MUST? > > ... shouldn't that handle your issue and Job's issue and everyone's issue= ? > > I can't really see why I shouldn't be able to MANUAL configure a /125 > on my interface and have default gateway being provided by RA on > link-local using /64. Two different address "types". > > I think this is a significant part of the issue. There's really two sets of needs or desires here, network operators and host operators/implementers. IPv6 has really been designed to solve a host addressing problem. There is no significant inter-router link addressing problem in IPv4 compared to hosts having to sit behind NATs to get enough host addresses. Host operators/implementers won't care what prefix length is used by network operators on inter-router links, as long as the hosts' packets are successfully forwarded across them. Where prefix length matters to host operators is at the edge of the network where the hosts are attached. If some of IPv4 addressing practices are carried over to IPv6 at the edge of the network (e.g., /120s on link-layers that have the capacity to support far more hosts than that, or a /128 to a CPE), it may recreate the sorts of IPv4 host addressing and addressing related problems that IPv6 was meant to prevent. I think that is the fear (that's my fear), and if it becomes the case, IPv6 won't have solved the fundamental problem it was meant to solve. (Although it'd be controversial and contrary to the robustness principle, one approach host implementers could take to ensuring they're provided with enough edge address space is to refuse to bring up IPv6 unless the received PIO(s) has/(have) a large enough prefix length. An absolute failure presented to an end-user is commonly a better user experience than partial and possibly subtle intermittent ones.) Regards, Mark. From nobody Tue Jun 6 00:53:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D657129AA8 for ; Tue, 6 Jun 2017 00:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v0xRts5rOpW for ; Tue, 6 Jun 2017 00:53:50 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE514129490 for ; Tue, 6 Jun 2017 00:53:49 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id 63so52268680ywr.0 for ; Tue, 06 Jun 2017 00:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G/aC+6zvTHJ3YsGKofbFQi928i80P7cotinVb/foj+o=; b=rRlzrTzysAelqEvpgz1zmkZX60aPe1+dA5KMrf9nzt0GoNBM2Wjf4pptc5iSWv3uO3 k9S3qErWJXfwVSVB+sVV0VNlqp6KK631TV3UTSqApqB62PmmZdM9pjArC8zc5MoPQcCQ 0nnQxwgW4GmyaHRfGrKAbEg+RDTgCzaE56vtFrmeP80gDt/k6fd7azvAGKolX1rumQuw KZ/pTm4ky9v2LaAPSA9zJuwfRvO9l98hWLoYqSOIaBHbRiUDA742JSWL1wAY6ZfJ1z8L yRGZLasWHZaYv+OQ6U8ZQ6eRB7Ry00e1hj/ZaLl0P7kYIuTn9j6FtjhkTxrHVcnl4+M1 oPPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G/aC+6zvTHJ3YsGKofbFQi928i80P7cotinVb/foj+o=; b=gv9Xuz8n2iqNsySGWyhVa1tObmpgToaYEtLRTrTzWISRHJrYl7cu99y4xbeOG4V+Ui jRTAFnX/dAkbFxCaLUCw4LQ/4bjSc0V11H+iQPkxtpRmCoNAqJFm3KcOql4MMAeG7Ss8 cSQvUXmdYBadeu0GwEtEXB/8XsfK7cE/Eo2nZv0XOzM497oPTfbWErjzeRixD2jU16iw Dv++qSjD8UlSrTld52WHyMkhr0DQFAxCCjWuuIA3aRprhvxu5atGrmLQQ4udIwesKFG2 TqLjcst1qKowrxVg+5l7djkRmQ72WVDRQgdfhqJOPXXZhC5cw7Wxq6oGD02dB9qdZSv+ aA9A== X-Gm-Message-State: AODbwcDEAwfJM/jzaX3fbhAAKAXbYnPg7ajuG7QJ49bso/uMu5uY8KF6 WXS+SddeQP7NzWWQD5CYQdT4kxqtFw== X-Received: by 10.13.245.71 with SMTP id e68mr1632334ywf.269.1496735629156; Tue, 06 Jun 2017 00:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Tue, 6 Jun 2017 00:53:47 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Tue, 6 Jun 2017 09:53:47 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 07:53:51 -0000 On Tue, Jun 6, 2017 at 9:48 AM, Lorenzo Colitti wrote: > I also suspect it's not the authors' goal. At least Randy and Job have > clearly stated that what they want to do is run non-/64 prefixes on today's > links (Ethernet, maybe wifi), not on some future link layer. why shouldn't they? If it's manual configured it should work, ref the last few emails, default 64 unless manual configured. .... but yes the draft is horrible written/title if this is what the goal is. And is it really needed in a new draft if we could get it into one of the -bis documents...... ? -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Tue Jun 6 01:00:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECA012949E for ; Tue, 6 Jun 2017 01:00:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBZBtRI_H97a for ; Tue, 6 Jun 2017 01:00:11 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 30C13129490 for ; Tue, 6 Jun 2017 01:00:11 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id h39so34757273uaa.3 for ; Tue, 06 Jun 2017 01:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RyL6IyZX/1oKl2daEP1JGKRnLLy3y+YuOYbhRsEHfBA=; b=tW+X20etbzSH9y/7V+kuzf3bCXe8Lun/nOKteakVDyquNfM2bdpoQ92iXOS+sbt4AK UFFXeYx7dFeeQkCvTCQIbBdVx1j7vNqCAk6cCdPAp/z3785BTE5j7bbqEpo8c1XB28Gn nD8V1Lc60AE3b0E9wutoEkPLhc2i6hSYYLjxN3p+s1y9mOWKX2799QQt210JKssC2GCo lO1oTo1jqdJ15rfGsJnyckgVsJgxr8+j9B9tUyNnaBBgckahmqrYIUTmIAAF65sW+k9d 3H+AO5yqM40DN+qRA7QvyA8/0/m4KM2OkylW+Kk+AQ0ods6sxLYcIkZh0Oed6NCt+Ojl 2z3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RyL6IyZX/1oKl2daEP1JGKRnLLy3y+YuOYbhRsEHfBA=; b=nJLhx7qMH8JE5iA/jpfc0eV9gep9MG/t0D30gtGlXQyI/9OHjL5ReBcFULtv7SKr6x c+sv0//uAh0ottsj92QPaV/58FCSpr0yGd/D5nsB5iaEUJ5o3If0Y753jDmlQX/Na32K wQ8/x6OsWfg0JJl20LhEDRrTDvFSw/obXUSFp4Yurz23mFECrt7VdIooYLda9P4MJAbo iV06Sq1vP5M3Bj3PkDHkj4FMU/wOikRvd78Qvv5w6VYve3c9JBd/6Q/Q0uVkdfJxwtTe fAOqIk1JF/R8FFNvhFxaljYzGTeN3uycqqlICagimvgSh5aC5hshPfZNhgfz//jZAIsw 3NMQ== X-Gm-Message-State: AODbwcDNXxEw33Gf4X6OwruI3xkgxJyvfNX4liF6+YzdP1XbIuEJRFmV pdWgimmfr8ajDYjWWLvHR1pZols6EaHZ X-Received: by 10.176.17.228 with SMTP id q36mr12003101uac.20.1496736010201; Tue, 06 Jun 2017 01:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 6 Jun 2017 00:59:49 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 6 Jun 2017 16:59:49 +0900 Message-ID: Subject: Re: Different sets of needs (Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00)) To: Mark Smith Cc: =?UTF-8?Q?Roger_J=C3=B8rgensen?= , 6man WG Content-Type: multipart/alternative; boundary="f403045e75fc3648e7055146027d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 08:00:13 -0000 --f403045e75fc3648e7055146027d Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 4:52 PM, Mark Smith wrote: > Host operators/implementers won't care what prefix length is used by > network operators on inter-router links, as long as the hosts' packets > are successfully forwarded across them. > > Where prefix length matters to host operators is at the edge of the > network where the hosts are attached. If some of IPv4 addressing > practices are carried over to IPv6 at the edge of the network (e.g., > /120s on link-layers that have the capacity to support far more hosts > than that, or a /128 to a CPE), it may recreate the sorts of IPv4 host > addressing and addressing related problems that IPv6 was meant to > prevent. I think that is the fear (that's my fear), and if it becomes the case, IPv6 won't have solved the fundamental problem it was meant to solve. > +1 Yes, I think that is what host operators are concerned about. But if the network operators only care about servers and inter-router links, can we just put in an exception to cover manual configuration, and move on? I don't think anybody would object to that. > (Although it'd be controversial and contrary to the robustness > principle, one approach host implementers could take to ensuring > they're provided with enough edge address space is to refuse to bring > up IPv6 unless the received PIO(s) has/(have) a large enough prefix > length. An absolute failure presented to an end-user is commonly a > better user experience than partial and possibly subtle intermittent > ones.) > If host operators want to do that they also have to decline to implement DHCPv6. From the host's perspective, there is little difference between a 64-bit prefix on which the device can only get one IPv6 address, and a 128-bit prefix. --f403045e75fc3648e7055146027d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 6, 2017 at 4:52 PM, Mark Smith <markzzzsmith@gmail.com>= ; wrote:
Host o= perators/implementers won't care what prefix length is used by
network operators on inter-router links, as long as the hosts' packets<= br> are successfully forwarded across them.

Where prefix length matters to host operators is at the edge of the
network where the hosts are attached. If some of IPv4 addressing
practices are carried over to IPv6 at the edge of the network (e.g.,
/120s on link-layers that have the capacity to support far more hosts
than that, or a /128 to a CPE), it may recreate the sorts of IPv4 host
addressing and addressing related problems that IPv6 was meant to
prevent.=C2=A0
I th= ink that is the fear (that's my fear), and if it becomes the case,
IPv6 won't have solved the fundamental problem it was meant to solve.

+1

Yes, I = think that is what host operators are concerned about. But if the network o= perators only care about servers and inter-router links, can we just put in= an exception to cover manual configuration, and move on? I don't think= anybody would object to that.
=C2=A0
(Although it'd be controversial and c= ontrary to the robustness
principle, one approach host implementers could take to ensuring
they're provided with enough edge address space is to refuse to bring up IPv6 unless the received PIO(s) has/(have) a large enough prefix
length. An absolute failure presented to an end-user is commonly a
better user experience than partial and possibly subtle intermittent
ones.)

If host operators want to do tha= t they also have to decline to implement DHCPv6. From the host's perspe= ctive, there is little difference between a 64-bit prefix on which the devi= ce can only get one IPv6 address, and a 128-bit prefix.
--f403045e75fc3648e7055146027d-- From nobody Tue Jun 6 01:28:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3666F129AE7 for ; Tue, 6 Jun 2017 01:28:23 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMj13rcn-KUZ for ; Tue, 6 Jun 2017 01:28:22 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 F0E78129AFA for ; Tue, 6 Jun 2017 01:28:21 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id q15so5703448uaa.2 for ; Tue, 06 Jun 2017 01:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nfbhYxVWNinGUoemyqRll7dJK7TQzzNLzLzQg5KZjDU=; b=G/t9+zBDxIRfwiTEeVmILTNV7IxoQsuHLDY8fL7jTUnxl3MnfNGS8Thixr1ybvtBC8 6fh3qfkeQ91anO5EwkQKCY33vM8Kldo8KPbEM2RnQpNgOXYiZb40iUANohi4w6Z1M210 yaXv94kFTdBCIrkgiPlyIC+0dRiyCOOznulamEB33oXTq/KEDXErgEQ5ZqhcYqG9eDs9 /1wwaMVBO6M7gXBvKQBwd+lRTtjp/d5f3/MQJhWfkfk/pJjVElDOj6LMOevsWjyfDWlg vFE3Aq982TQwrxbijKBcDBzQc/SouHcplkv1ZqIxfsTYUuCYZ1PajYMcmb4CdoTa/ChH lO0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nfbhYxVWNinGUoemyqRll7dJK7TQzzNLzLzQg5KZjDU=; b=IZat+ktvibSJgMQLhBTyidxu86+3fEB6SYhz/sgT9FDHK1wNpOcKKR0ryjBAg8l+Vu D3ypls5oeVnQJQaBPAqrv1YzPoakOJGeIIxCmyhW856jnH2yZ6Dq4JOk5F1wiR8R0Hpo z//o0JhRxumrYk3/AW8pQ3ikHbpiEf/KCXeYMMSYLat7mRhHNKZw8VsXAcgcPX4BZVZd Jel1l7D+fMcPGlLjoInOlhYq7M6BckKjipiexosEliGBEUH8UaXd9+GBZbzev4pR6XKz WAwt96+FFq3yfYELp5dviSQBZfn4lR30xrFab/G3cTEd9XoKCYDmbJX4nRz8tuBCfCNr 6xWQ== X-Gm-Message-State: AODbwcB/x1ytPbTs3TYJY/S9MT168su7wZgb5BVNFUGwM0357iXLkP0o nsxIUlk/i36v0q63Pw6hviSwpHeVwg== X-Received: by 10.176.23.41 with SMTP id j41mr14399088uaf.32.1496737700996; Tue, 06 Jun 2017 01:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Tue, 6 Jun 2017 01:27:50 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 6 Jun 2017 18:27:50 +1000 Message-ID: Subject: Re: Different sets of needs (Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00)) To: Lorenzo Colitti Cc: =?UTF-8?Q?Roger_J=C3=B8rgensen?= , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 08:28:23 -0000 On 6 June 2017 at 17:59, Lorenzo Colitti wrote: > On Tue, Jun 6, 2017 at 4:52 PM, Mark Smith wrote: >> >> Host operators/implementers won't care what prefix length is used by >> network operators on inter-router links, as long as the hosts' packets >> are successfully forwarded across them. >> >> Where prefix length matters to host operators is at the edge of the >> network where the hosts are attached. If some of IPv4 addressing >> practices are carried over to IPv6 at the edge of the network (e.g., >> /120s on link-layers that have the capacity to support far more hosts >> than that, or a /128 to a CPE), it may recreate the sorts of IPv4 host >> addressing and addressing related problems that IPv6 was meant to >> prevent. >> >> >> >> I think that is the fear (that's my fear), and if it becomes the case, >> >> IPv6 won't have solved the fundamental problem it was meant to solve. > > > +1 > > Yes, I think that is what host operators are concerned about. But if the > network operators only care about servers and inter-router links, My experience having worked in both network operator and host operator roles is that network operators don't care much about servers either! In most organisations there a usually an operational and responsibility boundary between the groups who worry about devices that carry the packets and those who worry about the devices that send and receive them. > can we > just put in an exception to cover manual configuration, and move on? I don't > think anybody would object to that. > >> >> (Although it'd be controversial and contrary to the robustness >> principle, one approach host implementers could take to ensuring >> they're provided with enough edge address space is to refuse to bring >> up IPv6 unless the received PIO(s) has/(have) a large enough prefix >> length. An absolute failure presented to an end-user is commonly a >> better user experience than partial and possibly subtle intermittent >> ones.) > > > If host operators want to do that they also have to decline to implement > DHCPv6. No necessarily. If stateful DHCPv6 is being used for addressing, at the time of attachment, a host could ask for as many addresses as it needs/wants and if it doesn't get them, take IPv6 down. > From the host's perspective, there is little difference between a > 64-bit prefix on which the device can only get one IPv6 address, and a > 128-bit prefix. To be a bit clearer, I was thinking of a host refusing to attach unless the RA PIO had a prefix length of 64 in it (or some other large value). A general "is this link's IPv6 prefix(es) size(s) unnecessarily small" test, rather than any sort of test for availability of as many addresses the host itself may want or need (which is different to the DHCPv6 test I described before). Regards, Mark. From nobody Tue Jun 6 02:25:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6BB12426E for ; Tue, 6 Jun 2017 02:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jd1Ih5qKXpA for ; Tue, 6 Jun 2017 02:25:13 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 6F5CA129B8D for ; Tue, 6 Jun 2017 02:25:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v569P9Zt009175 for ; Tue, 6 Jun 2017 11:25:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D01422019DA for ; Tue, 6 Jun 2017 11:25:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4B58201888 for ; Tue, 6 Jun 2017 11:25:08 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v569P8ma014300 for ; Tue, 6 Jun 2017 11:25:08 +0200 Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> From: Alexandre Petrescu Message-ID: <76437b98-8c03-2f92-3663-dd1826e756f6@gmail.com> Date: Tue, 6 Jun 2017 11:25:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:25:15 -0000 Le 06/06/2017 à 07:09, Lorenzo Colitti a écrit : > On Tue, Jun 6, 2017 at 3:47 AM, james woodyatt > wrote: > > Now is as good a time as any to repeat that I’m working on > delivering *basically* this now. Not in ten years. Now. > > > Here's a solution that works now: ND proxying. But it's EXPERIMENTAL. And the technique does not scale. Alex > > OpenWRT has had code to do it for a few years now. IIRC they're on to > their second implementation, the first one was here > . > > IIRC when I wrote my own proof-of-concept implementation it wasn't too > hard. It's particularly easy when you don't need to support autoconf on > the southbound interface, which you presumably don't need to support > since 6LoWPAN has IPv6 addresses that are known in advance. AIUI this is > similar to what the Android on ChromeOS does: the Android code runs in a > separate namespace (equivalent role to the 6LoWPAN network), and gets an > IPv6 address. There's a daemon on the root namespace (equivalent role to > the BR) runs ND proxy for that address. That code may be open sourced > under a license that would allow you to use it as is. > > Running ND proxying on Linux is pretty easy even without writing any > packet handling code using the IPV6_JOIN_ANYCAST socket option. Apache > licensed code (running on production Android devices) is here > , > look for do_anycast_setsockopt. > > We are already on the path to IPv6/NAT w/ address amplification. We > had a chance to stop it, and we blew it. It’s time to move on from > that mistake. > > > You may be on that path at the moment, but I don't think you were > obliged to take it. You could have (and maybe still can) implement ND > proxying. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 6 02:27:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD240129B8D for ; Tue, 6 Jun 2017 02:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKavSTcRH7Bl for ; Tue, 6 Jun 2017 02:27:14 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 4D506129B8B for ; Tue, 6 Jun 2017 02:27:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v569RC2o010311 for ; Tue, 6 Jun 2017 11:27:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9A7C220136F for ; Tue, 6 Jun 2017 11:27:11 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2D1E0201A80 for ; Tue, 6 Jun 2017 11:27:10 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v569R9ec016652 for ; Tue, 6 Jun 2017 11:27:09 +0200 Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <4614ca88-fe00-64df-649f-34d52ee80a8e@gmail.com> Date: Tue, 6 Jun 2017 11:27:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:27:16 -0000 Le 06/06/2017 à 07:15, Lorenzo Colitti a écrit : > On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith > wrote: > > One the title of a document is accurate, I've found it easier to > determine what is in and out of scope for the document. With a title > of "IPv6 prefix length (and IID size) is a parameter not a constant", > I think the topics would at least be and be in this sort of order > > > I think you forgot that if you want to run non-64-bit IIDs on any > currently-defined link type you need to deprecate all the IPv6-over-foo > documents. YEs, but IP-over-USBnet is not defined, so it's easy to write a draft for it about IID len == 63 on a smartphone. Alex > Remember, Job's original motivation for this draft was "I > want to assign a /123 in my network", and that is not just a violation > of RFC 4291, it's a violation of RFC 2464 as well. > > To be clear, I still think this document is a bad idea. I still see no > reason for us to do this, and lots of reasons why we shouldn't. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 6 02:53:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E10129BFC for ; Tue, 6 Jun 2017 02:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhVzVjEcFLi9 for ; Tue, 6 Jun 2017 02:53:30 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 D94C7129B91 for ; Tue, 6 Jun 2017 02:53:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v569rSR6022820 for ; Tue, 6 Jun 2017 11:53:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07699201877 for ; Tue, 6 Jun 2017 11:53:28 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F1C09201A77 for ; Tue, 6 Jun 2017 11:53:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v569rR7u012805 for ; Tue, 6 Jun 2017 11:53:27 +0200 Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> Date: Tue, 6 Jun 2017 11:53:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:53:32 -0000 Le 05/06/2017 à 17:47, Templin, Fred L a écrit : > Hi, one example where /64 is very useful is for the construction of AERO > addresses as documented in: > > https://datatracker.ietf.org/doc/draft-templin-6man-aeroaddr/ > > The draft is very short, but here are the main thrusts: > > "An AERO address is an IPv6 link-local address with an interface > identifier based on a prefix that has been delegated to a node for > its own exclusive use. AERO addresses begin with the prefix > fe80::/64 I am not sure whether fe80::/64 or the fe80::/10 is the right prefix for link-local addresses. So I am not sure whether the below method is ok. > and include in the interface identifier (i.e., the lower > bits) a 64-bit prefix taken from one of the node's delegated > prefixes. For example, if the node receives the IPv6 prefix: > > 2001:db8:1000:2000::/64 > > it constructs its corresponding AERO addresses as: > > fe80::2001:db8:1000:2000" > > "The AERO address is intended for use by mobile networks that comprise > a mobile router and a tethered network of "Internet of Things" > devices that travel together with the router as a single unit. The > mobile router assigns the AERO address to its upstream interface over > which it receives a prefix delegation from a delegating router. The > manner for receiving the delegated prefix could be through static > configuration or some automated prefix delegation service." > > I further believe this link-local address format may prove to be useful for > any scenarios where a prefix delegation is received. Why is it more useful to form address fe80::2001:db8:1000:2000 instead of fe80::random? Is it such that the route in the Access Router easily knows the address of the mobile router? (there could be some alternatives to learn that address). Is the method dependent on that 64 be 64? Or could it work with 65? Alex > > Thanks in advance for comments. > > Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tim Chown >> Sent: Monday, June 05, 2017 8:34 AM >> To: Brian E Carpenter >> Cc: 6man >> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 >> >> Hi, >> >>> On 3 Jun 2017, at 22:12, Brian E Carpenter wrote: >>> >>> On 04/06/2017 05:32, Roger Jørgensen wrote: >>>> On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders wrote: >>>> >>>>> Abstract: >>>>> Over the history of IPv6, various classful address models have been >>>>> proposed, none of which has withstood the test of time. The last >>>>> remnant of IPv6 classful addressing is a rigid network interface >>>>> identifier boundary at /64. This document removes the fixed position >>>>> of that boundary for interface addressing. >>>> >>>> what I find odd is that we over and over again are morphing IPv6 into IPv4 >>>> with just more IP adresses... >>> >>> That simply isn't true. The draft doesn't abolish the concept of 'interface >>> identifier', which doesn't exist in IPv4. It doesn't attack SLAAC. It >>> doesn't attack ILNP or draft-herbert-nvo3-ila. It doesn't attack the choice >>> of /64 for all IPv6-over-foos to date. >>> >>> It does say two things. >>> >>> 1. BCP198 >>> 2. n in the addressing architecture is a parameter. >> >> And it that sense, it’s fine, i.e. /64 is RECOMMENDED, and used for the various IPv6-over-foos that Brian mentioned, but also it sends >> a message to not hardcode /64. >> >> The draft could cite RFC7421 and (for the point about address availability) RFC7934. >> >> Like David, at the university where we deployed IPv6, we didn’t try to lock down addresses to hosts; rather we used SNMP-based >> polling of network devices for accountability. We also had 802.1X (through eduroam) on WiFi, and I know of some universities >> deploying 802.1X for wired networks as well. There’s also the Cisco ND syslogging capability if you use their platform. >> >> Tim >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 6 03:19:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A20212878D for ; Tue, 6 Jun 2017 03:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=irs.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3y2pdNqOhoc for ; Tue, 6 Jun 2017 03:19:06 -0700 (PDT) Received: from EMG3.irs.gov (emg3.irs.gov [IPv6:2610:30:4000:25::91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4971201F2 for ; Tue, 6 Jun 2017 03:19:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,305,1493697600"; d="scan'208";a="76917806" Received: from unknown (HELO mtb0120vprelay3.is.irs.gov) ([10.207.43.148]) by mtb0120emg3.mcc.irs.gov with ESMTP; 06 Jun 2017 06:19:03 -0400 Received: from MTB0120PPEXB060.ds.irsnet.gov (mtb0120ppexb060.ds.irsnet.gov [10.207.136.42]) by mtb0120vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id v56AJ3hJ004836 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 06:19:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; s=irs-20130926; t=1496744343; bh=YKJFGjdD4tC52bwihJDRK/iV3Ethz22FyUqrLjvcbAc=; h=From:To:Subject:Date:References:In-Reply-To; b=lf6gl1zomFThQqSciNSi81x6g85IWBfXwcyOtPDdYGmrbqPpmOSXJTa4BSttenhoi vZUfNuVh019+RtgkPqUAB0ScUe9DHjnMSuvsQFeawHW5vkVfziJW3QE+cLtLolsaYI qD4qZvc11ud+ariDzt5wOIWew8GEoq725m9LjmBE= Received: from MTB0120PPEXB060.ds.irsnet.gov (10.207.136.42) by MTB0120PPEXB060.ds.irsnet.gov (10.207.136.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 6 Jun 2017 06:19:01 -0400 Received: from MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969]) by MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969%19]) with mapi id 15.01.0845.034; Tue, 6 Jun 2017 06:19:01 -0400 From: Morizot Timothy S To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIwAuWEqAAAgIVAA= Date: Tue, 6 Jun 2017 10:19:01 +0000 Message-ID: References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> In-Reply-To: <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.219.81.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 10:19:07 -0000 QWxleGFuZHJlIFBldHJlc2N1IHdyb3RlOg0KPkkgYW0gbm90IHN1cmUgd2hldGhlciBmZTgwOjov NjQgb3IgdGhlIGZlODA6Oi8xMCBpcyB0aGUgcmlnaHQgcHJlZml4IGZvciANCj5saW5rLWxvY2Fs IGFkZHJlc3Nlcy4gIFNvIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgYmVsb3cgbWV0aG9kIGlz IG9rLg0KDQpUaGUgUkZDIHNlZW1zIHByZXR0eSBjbGVhciB0byBtZS4gZmU4MDo6LzEwIGlzIHJl c2VydmVkLiBBdCBwcmVzZW50IG9ubHkgZmU4MDo6LzY0IGlzIGRlZmluZWQgZm9yIGxpbmsgbG9j YWwuIFdoaWNoIG1ha2VzIHNlbnNlIHNpbmNlIGEgZGV2aWNlIGNvbm5lY3RpbmcgbmVlZHMgdG8g a25vdyB3aGF0IHRoZSBsaW5rIGxvY2FsIC82NCBpcyBiZWZvcmUgaXQgaGFzIGFueSBvdGhlciBp bmZvcm1hdGlvbi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQyOTENCg0KMi41 LjYuICBMaW5rLUxvY2FsIElQdjYgVW5pY2FzdCBBZGRyZXNzZXMNCg0KDQogICBMaW5rLUxvY2Fs IGFkZHJlc3NlcyBhcmUgZm9yIHVzZSBvbiBhIHNpbmdsZSBsaW5rLiAgTGluay1Mb2NhbA0KICAg YWRkcmVzc2VzIGhhdmUgdGhlIGZvbGxvd2luZyBmb3JtYXQ6DQoNCiAgIHwgICAxMCAgICAgfA0K ICAgfCAgYml0cyAgICB8ICAgICAgICAgNTQgYml0cyAgICAgICAgIHwgICAgICAgICAgNjQgYml0 cyAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfDExMTExMTEwMTB8ICAgICAgICAgICAw ICAgICAgICAgICAgIHwgICAgICAgaW50ZXJmYWNlIElEICAgICAgICAgfA0KICAgKy0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KDQpTaW5jZSBJIGhhZCBzb21lb25lIGNvbmZpZ3VyZSAiY3VzdG9tIiBsaW5rIGxvY2FsIGFk ZHJlc3NlcyBvbiBhIG5ldHdvcmsgdXNpbmcgb3RoZXIgc3VibmV0cyBpbiBmZTgwOjovMTAgb25j ZSB1cG9uIGEgdGltZSwgSSBhbHNvIGtub3cgdGhhdCBzb21lIGRldmljZXMgd2lsbCBub3Qgd29y ayBhdCBhbGwgd2l0aG91dCBtYW51YWxseSBhbmQgc3RhdGljYWxseSBjb25maWd1cmluZyB0aGVt IGluIHRoZSBuZWlnaGJvciB0YWJsZSwgd2hpY2ggaXMgd2hhdCB3ZSBkaWQgdW50aWwgSSBmaWd1 cmVkIG91dCB3aGF0IHdhcyBtaXNjb25maWd1cmVkIGFuZCBoYWQgdGhlbSBmaXggaXQuIFNvIGlu IG1vc3QgaW5zdGFuY2VzLCBpdCB3b3VsZCBiZSB1bndpc2UgdG8gY29uZmlndXJlIGFueXRoaW5n IGVsc2Ugb24gcm91dGVycy4NCg0KU2NvdHQNCg0K From nobody Tue Jun 6 05:06:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E79E12943F for ; Tue, 6 Jun 2017 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbUtWiIIS27J for ; Tue, 6 Jun 2017 05:05:53 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 2D9CE1241FC for ; Tue, 6 Jun 2017 05:05:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v56C5obh005670; Tue, 6 Jun 2017 14:05:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C4B2F20136F; Tue, 6 Jun 2017 14:05:50 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B809F200EF1; Tue, 6 Jun 2017 14:05:50 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v56C5nrr026774; Tue, 6 Jun 2017 14:05:50 +0200 Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) To: Morizot Timothy S , "ipv6@ietf.org" References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> From: Alexandre Petrescu Message-ID: <76f3c581-065c-dcc1-d434-929a40875bf0@gmail.com> Date: Tue, 6 Jun 2017 14:05:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 12:06:01 -0000 Le 06/06/2017 à 12:19, Morizot Timothy S a écrit : > Alexandre Petrescu wrote: >> I am not sure whether fe80::/64 or the fe80::/10 is the right prefix for >> link-local addresses. So I am not sure whether the below method is ok. > > The RFC seems pretty clear to me. fe80::/10 is reserved. At present only fe80::/64 is defined for link local. fe80::/10 is 'reserved' at IANA page https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml Where is fe80::/64 'defined'? Alex > Which makes sense since a device connecting needs to know what the link local /64 is before it has any other information. > > https://tools.ietf.org/html/rfc4291 > > 2.5.6. Link-Local IPv6 Unicast Addresses > > > Link-Local addresses are for use on a single link. Link-Local > addresses have the following format: > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > > Since I had someone configure "custom" link local addresses on a network using other subnets in fe80::/10 once upon a time, I also know that some devices will not work at all without manually and statically configuring them in the neighbor table, which is what we did until I figured out what was misconfigured and had them fix it. So in most instances, it would be unwise to configure anything else on routers. > > Scott > From nobody Tue Jun 6 05:17:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411E51272E1 for ; Tue, 6 Jun 2017 05:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NieUO7-MouA2 for ; Tue, 6 Jun 2017 05:17:32 -0700 (PDT) Received: from EMG3.irs.gov (emg3.irs.gov [IPv6:2610:30:4000:25::91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873D8127868 for ; Tue, 6 Jun 2017 05:17:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,306,1493697600"; d="scan'208";a="76941539" Received: from unknown (HELO mem0200vprelay3.is.irs.gov) ([10.207.43.148]) by mtb0120emg3.mcc.irs.gov with ESMTP; 06 Jun 2017 08:17:29 -0400 Received: from MTB0120PPEXB050.ds.irsnet.gov (mtb0120ppexb050.ds.irsnet.gov [10.207.136.41]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id v56CHSXC021041 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 07:17:29 -0500 Received: from MTB0120PPEXB060.ds.irsnet.gov (10.207.136.42) by MTB0120PPEXB050.ds.irsnet.gov (10.207.136.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 6 Jun 2017 08:17:28 -0400 Received: from MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969]) by MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969%19]) with mapi id 15.01.0845.034; Tue, 6 Jun 2017 08:17:28 -0400 From: Morizot Timothy S To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIwAuWEqAAAgIVAD//+S4gIAAQMWg Date: Tue, 6 Jun 2017 12:17:28 +0000 Message-ID: <6116f8e95251414ab42cea153de8178c@irs.gov> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> <76f3c581-065c-dcc1-d434-929a40875bf0@gmail.com> In-Reply-To: <76f3c581-065c-dcc1-d434-929a40875bf0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.219.81.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 12:17:34 -0000 QWxleGFuZHJlIFBldHJlc2N1IHdyb3RlOg0KPmZlODA6Oi8xMCBpcyAncmVzZXJ2ZWQnIGF0IElB TkEgcGFnZQ0KPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lwdjYtYWRkcmVzcy1z cGFjZS9pcHY2LWFkZHJlc3Mtc3BhY2UueGh0bWwNCg0KPldoZXJlIGlzIGZlODA6Oi82NCAnZGVm aW5lZCc/DQoNClVtLCBJIGluY2x1ZGVkIHRoZSBsaW5rIGZyb20gdGhlIFJGQyB0aGF0IHNwZWNp ZmllcyB1bmljYXN0IGxpbmsgbG9jYWwgYW5kIGV2ZW4gY29waWVkIGFuZCBwYXN0ZWQgdGhlIGFj dHVhbCBzcGVjaWZpY2F0aW9uIGludG8gbXkgcmVzcG9uc2UuDQoNClNvIEknbSBhIGJpdCBjb25m dXNlZCBieSB5b3VyIHF1ZXN0aW9uLiANCg0KV2FzIHNvbWV0aGluZyBpbiB0aGUgYmluYXJ5IHJl cHJlc2VudGF0aW9uIG9mIHRoZSBzcGVjaWZpY2F0aW9uIChpbnN0ZWFkIG9mIGhleCkgY29uZnVz aW5nPyBBbnl3YXksIHRoZXJlIGFyZSBjZXJ0YWlubHkgcGxlbnR5IG9mIG5vbi1yb3V0ZXJzIHdo byBpbXBsZW1lbnQgbGluayBsb2NhbCBhcyBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkIFJGQy4N Cg0KU2NvdHQNCg0K From nobody Tue Jun 6 05:22:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABB3129440 for ; Tue, 6 Jun 2017 05:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIGjzK0jRbSR for ; Tue, 6 Jun 2017 05:22:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 CC4F1120724 for ; Tue, 6 Jun 2017 05:22:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v56CMfoK083953 for ; Tue, 6 Jun 2017 14:22:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 651F7201250 for ; Tue, 6 Jun 2017 14:22:41 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 535F6202227 for ; Tue, 6 Jun 2017 14:22:41 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v56CMfWf017819 for ; Tue, 6 Jun 2017 14:22:41 +0200 Subject: Re: Comments on draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <6c57549f-dd56-feda-bb0c-a33e2a3b88ed@gmail.com> Date: Tue, 6 Jun 2017 14:22:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 12:22:45 -0000 Le 05/06/2017 à 17:14, Tom Herbert a écrit : [...] > Section 4: "But operationally we recommend, barring strong > considerations to the contrary, using 64-bits for SLAAC in order not > to discover bugs where 64 was hard-coded, and to favor portability > of devices and operating systems." > > Not using something allowed by the standard in order to avoid > hitting bugs is self defeating. Bugs that are not discovered don't > get fixed, so in the future when someone has a legitimate reason to > do something different it might be too late to fix problems. > > Section 4 seems to bounce back and forth: First, /64 is recommended, > but then /48 might be okay, but then /64 is recommended again > because SLAAC might have bugs, and finally any length is okay > because SLAAC should be correctly implemented. I think it would be > clearer to say that any length is allowed but /64 is recommended and > here's why. This can be a matter of backwards compatibility. One wants SLAAC/Ethernet systems continue working even if plen in RA is 65 or 63. The old receiver of a new RA will not break, since SLAAC spec says that if the plen and IIDlen make not for 128 then discard. Alex From nobody Tue Jun 6 05:40:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20828129485 for ; Tue, 6 Jun 2017 05:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU7WWMK1WBxT for ; Tue, 6 Jun 2017 05:40:53 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 3EE1A12946F for ; Tue, 6 Jun 2017 05:40:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v56CeoqZ091543; Tue, 6 Jun 2017 14:40:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8431B2022BE; Tue, 6 Jun 2017 14:40:50 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 756FF202296; Tue, 6 Jun 2017 14:40:50 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v56Cene4032085; Tue, 6 Jun 2017 14:40:50 +0200 Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) To: Morizot Timothy S , "ipv6@ietf.org" References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 6 Jun 2017 14:40:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 12:40:55 -0000 Le 06/06/2017 à 12:19, Morizot Timothy S a écrit : > Alexandre Petrescu wrote: >> I am not sure whether fe80::/64 or the fe80::/10 is the right prefix for >> link-local addresses. So I am not sure whether the below method is ok. > > The RFC seems pretty clear to me. fe80::/10 is reserved. At present only fe80::/64 is defined for link local. Which makes sense since a device connecting needs to know what the link local /64 is before it has any other information. > > https://tools.ietf.org/html/rfc4291 > > 2.5.6. Link-Local IPv6 Unicast Addresses > > > Link-Local addresses are for use on a single link. Link-Local > addresses have the following format: > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ Does this figure 'define' fe80::/64? All it says is that there is an fe80::/10 followed by 54 0 bits, and then a 64bit IID. At the risk of being called pedantic - are you sure it is not one's reading that interprets that text to mean that RFC4291 'defines' fe80::/64? And why are the 54 bits reset? Are they a waste? Alex > > Since I had someone configure "custom" link local addresses on a network using other subnets in fe80::/10 once upon a time, I also know that some devices will not work at all without manually and statically configuring them in the neighbor table, which is what we did until I figured out what was misconfigured and had them fix it. So in most instances, it would be unwise to configure anything else on routers. > > Scott > From nobody Tue Jun 6 05:48:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD49129413 for ; Tue, 6 Jun 2017 05:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VrJ9wf7eik7 for ; Tue, 6 Jun 2017 05:48:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3E127419 for ; Tue, 6 Jun 2017 05:48:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dIDu0-0000E7C; Tue, 6 Jun 2017 14:48:04 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Different sets of needs (Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00)) From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com In-reply-to: Your message of "Tue, 6 Jun 2017 17:52:12 +1000 ." Date: Tue, 06 Jun 2017 14:48:04 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 12:48:10 -0000 > If some of IPv4 addressing > practices are carried over to IPv6 at the edge of the network (e.g., > /120s on link-layers that have the capacity to support far more > hosts than that, or a /128 to a CPE), it may recreate the sorts of > IPv4 host addressing and addressing related problems that IPv6 was > meant to prevent. In my rather complex home network, at /120 prefix would be more than enough to number all interfaces that need addresses. Even in the next ten years that is very likely to be true. Is that a smart way to use the IPv6 address space, no. So what this draft does is create a huge mess of the IPv6 address architecture for very questionable benefits. And those benefits are not even articulated clearly in the draft. Adding an extra parameter to a protocol does not in general improve the protocol. In fact the opposite is true. Having a fixed boudary at 64 bits makes the system easy to explain and easy to troubleshoot. No need to waste extra cycles in trying to find out what crazy router announced a crazy prefix length. Of course the actual value '64' is derived from modified EUI-64 and with pseudo random IIDs we can just as well pick another value. But each bit we drop from the IID increases the chances of a collision. Address collisions are hard enough to deal with that you want to design for zero collisions, even in extremely big networks. Writing an RFC that requires implementations to support every possible IID length, even the ones that don't work in practice will only lead to extra confusion and the need for a new BCP that will tell operators how far they can go. From nobody Tue Jun 6 06:00:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356E6127136 for ; Tue, 6 Jun 2017 06:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5jA_pe8bQtw for ; Tue, 6 Jun 2017 06:00:11 -0700 (PDT) Received: from EMG5.irs.gov (emg5.irs.gov [IPv6:2610:30:4000:25::92]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E44E127B73 for ; Tue, 6 Jun 2017 06:00:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,306,1493697600"; d="scan'208";a="74249635" Received: from unknown (HELO mem0200vprelay3.is.irs.gov) ([10.207.43.148]) by mtb0120emg5.mcc.irs.gov with ESMTP; 06 Jun 2017 09:00:08 -0400 Received: from MTB0120PPEXB070.ds.irsnet.gov (mtb0120ppexb070.ds.irsnet.gov [10.207.136.43]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id v56D07Mr019523 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 08:00:08 -0500 Received: from MTB0120PPEXB060.ds.irsnet.gov (10.207.136.42) by MTB0120PPEXB070.ds.irsnet.gov (10.207.136.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 6 Jun 2017 09:00:06 -0400 Received: from MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969]) by MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969%19]) with mapi id 15.01.0845.034; Tue, 6 Jun 2017 09:00:06 -0400 From: Morizot Timothy S To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIwAuWEqAAAgIVAD//+6AgIAAQD9Q Date: Tue, 6 Jun 2017 13:00:06 +0000 Message-ID: <2c62066025d948a9b4867929374b2e0a@irs.gov> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.219.81.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 13:00:15 -0000 Tm90IHN1cmUgd2hhdCB0byBzYXkuIGZlOCAoaW4gaGV4KSBmb2xsb3dlZCBieSA1MiBiaW5hcnkg emVyb3MgKmlzKiBmZTgwOjovNjQuIFRoZXJlJ3Mgbm90aGluZyBhbWJpZ3VvdXMgYWJvdXQgaXQu IFRyYW5zbGF0ZWQgdG8gaGV4LCB0aGF0IHdvdWxkIGJlOiBmZTgwIDAwMDAgMDAwMCAwMDAwLiBJ dCdzIG5vdCBhbnkgcmFuZG9tIG5ldHdvcmsgcHJlZml4LiBJdCdzIHNwZWNpZmljYWxseSBhbmQg ZXhwbGljaXRseSBhbGwgemVyb3MuIEluIGEgcHJvcG9zZWQgc3RhbmRhcmQgUkZDLCBub3QgYW4g aW5mb3JtYXRpb25hbCBvbmUuIFNvbWV0aGluZyB0aGF0IHNwZWNpZmljIGluIGEgc3RhbmRhcmRz IGRvY3VtZW50ICppcyogYSBzcGVjaWZpY2F0aW9uLg0KDQpBbmQgYXMgSSBub3RlZCwgdGhlcmUg YXJlIGNlcnRhaW5seSBub24tcm91dGVyIGRldmljZXMgdGhhdCBpbXBsZW1lbnQgbGluayBsb2Nh bCBhcyBzcGVjaWZpZWQgYW5kIHdpbGwgbm90IHdvcmsgaWYgdGhlIHJvdXRlciBzcGVjaWZpZXMg YW55dGhpbmcgb3RoZXIgdGhhbiBmZTgwOjovNjQgZm9yIGxpbmsgbG9jYWwuIFByZXN1bWFibHkg dGhlIHdob2xlIC8xMCBpcyByZXNlcnZlZCB0byBhbGxvdyBmb3IgZnV0dXJlIGV4cGFuc2lvbiBv ZiB0aGUgc3RhbmRhcmQuIE9yIHBlcmhhcHMgdG8gYXZvaWQgY29uZnVzaW9uLiBGcmFua2x5LCBJ IGhhdmUgbm8gaWRlYSB3aHkgdGhlIHdob2xlIHRoaW5nIGlzIHJlc2VydmVkLiBCdXQgaW4gdGhl IGN1cnJlbnQgc3RhbmRhcmQsIHVuaWNhc3QgbGluayBsb2NhbCBpcyBmZTgwOjovNjQuDQoNClNj b3R0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kcmUgUGV0cmVz Y3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXks IEp1bmUgMDYsIDIwMTcgNzo0MSBBTQ0KVG86IE1vcml6b3QgVGltb3RoeSBTOyBpcHY2QGlldGYu b3JnDQpTdWJqZWN0OiBSZTogLzY0IGFuZCBBRVJPIGFkZHJlc3NlcyAoUkU6IGRyYWZ0LWJvdXJi YWtpLTZtYW4tY2xhc3NsZXNzLWlwdjYtMDApDQoNCg0KDQpMZSAwNi8wNi8yMDE3IMOgIDEyOjE5 LCBNb3Jpem90IFRpbW90aHkgUyBhIMOpY3JpdCA6DQo+IEFsZXhhbmRyZSBQZXRyZXNjdSB3cm90 ZToNCj4+IEkgYW0gbm90IHN1cmUgd2hldGhlciBmZTgwOjovNjQgb3IgdGhlIGZlODA6Oi8xMCBp cyB0aGUgcmlnaHQgcHJlZml4IGZvcg0KPj4gbGluay1sb2NhbCBhZGRyZXNzZXMuICBTbyBJIGFt IG5vdCBzdXJlIHdoZXRoZXIgdGhlIGJlbG93IG1ldGhvZCBpcyBvay4NCj4NCj4gVGhlIFJGQyBz ZWVtcyBwcmV0dHkgY2xlYXIgdG8gbWUuIGZlODA6Oi8xMCBpcyByZXNlcnZlZC4gQXQgcHJlc2Vu dCBvbmx5IGZlODA6Oi82NCBpcyBkZWZpbmVkIGZvciBsaW5rIGxvY2FsLiBXaGljaCBtYWtlcyBz ZW5zZSBzaW5jZSBhIGRldmljZSBjb25uZWN0aW5nIG5lZWRzIHRvIGtub3cgd2hhdCB0aGUgbGlu ayBsb2NhbCAvNjQgaXMgYmVmb3JlIGl0IGhhcyBhbnkgb3RoZXIgaW5mb3JtYXRpb24uDQo+DQo+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjkxDQo+DQo+IDIuNS42LiAgTGluay1M b2NhbCBJUHY2IFVuaWNhc3QgQWRkcmVzc2VzDQo+DQo+DQo+ICAgIExpbmstTG9jYWwgYWRkcmVz c2VzIGFyZSBmb3IgdXNlIG9uIGEgc2luZ2xlIGxpbmsuICBMaW5rLUxvY2FsDQo+ICAgIGFkZHJl c3NlcyBoYXZlIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KPg0KPiAgICB8ICAgMTAgICAgIHwNCj4g ICAgfCAgYml0cyAgICB8ICAgICAgICAgNTQgYml0cyAgICAgICAgIHwgICAgICAgICAgNjQgYml0 cyAgICAgICAgICAgfA0KPiAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgIHwxMTExMTExMDEwfCAgICAgICAg ICAgMCAgICAgICAgICAgICB8ICAgICAgIGludGVyZmFjZSBJRCAgICAgICAgIHwNCj4gICAgKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KDQpEb2VzIHRoaXMgZmlndXJlICdkZWZpbmUnIGZlODA6Oi82ND8NCg0KQWxsIGl0 IHNheXMgaXMgdGhhdCB0aGVyZSBpcyBhbiBmZTgwOjovMTAgZm9sbG93ZWQgYnkgNTQgMCBiaXRz LCBhbmQgDQp0aGVuIGEgNjRiaXQgSUlELg0KDQpBdCB0aGUgcmlzayBvZiBiZWluZyBjYWxsZWQg cGVkYW50aWMgLSBhcmUgeW91IHN1cmUgaXQgaXMgbm90IG9uZSdzIA0KcmVhZGluZyB0aGF0IGlu dGVycHJldHMgdGhhdCB0ZXh0IHRvIG1lYW4gdGhhdA0KUkZDNDI5MSAnZGVmaW5lcycgZmU4MDo6 LzY0Pw0KDQpBbmQgd2h5IGFyZSB0aGUgNTQgYml0cyByZXNldD8gIEFyZSB0aGV5IGEgd2FzdGU/ DQoNCkFsZXgNCg0KPg0KPiBTaW5jZSBJIGhhZCBzb21lb25lIGNvbmZpZ3VyZSAiY3VzdG9tIiBs aW5rIGxvY2FsIGFkZHJlc3NlcyBvbiBhIG5ldHdvcmsgdXNpbmcgb3RoZXIgc3VibmV0cyBpbiBm ZTgwOjovMTAgb25jZSB1cG9uIGEgdGltZSwgSSBhbHNvIGtub3cgdGhhdCBzb21lIGRldmljZXMg d2lsbCBub3Qgd29yayBhdCBhbGwgd2l0aG91dCBtYW51YWxseSBhbmQgc3RhdGljYWxseSBjb25m aWd1cmluZyB0aGVtIGluIHRoZSBuZWlnaGJvciB0YWJsZSwgd2hpY2ggaXMgd2hhdCB3ZSBkaWQg dW50aWwgSSBmaWd1cmVkIG91dCB3aGF0IHdhcyBtaXNjb25maWd1cmVkIGFuZCBoYWQgdGhlbSBm aXggaXQuIFNvIGluIG1vc3QgaW5zdGFuY2VzLCBpdCB3b3VsZCBiZSB1bndpc2UgdG8gY29uZmln dXJlIGFueXRoaW5nIGVsc2Ugb24gcm91dGVycy4NCj4NCj4gU2NvdHQNCj4NCg== From nobody Tue Jun 6 06:40:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91D128B51 for ; Tue, 6 Jun 2017 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOGyhuxzpZiv for ; Tue, 6 Jun 2017 06:40:52 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 E23DA124234 for ; Tue, 6 Jun 2017 06:40:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v56DensK012629; Tue, 6 Jun 2017 15:40:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 23586202104; Tue, 6 Jun 2017 15:40:49 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA15E202405; Tue, 6 Jun 2017 15:40:48 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v56DelqL017560; Tue, 6 Jun 2017 15:40:48 +0200 Subject: Re: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) To: Morizot Timothy S , "ipv6@ietf.org" References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> <2c62066025d948a9b4867929374b2e0a@irs.gov> From: Alexandre Petrescu Message-ID: Date: Tue, 6 Jun 2017 15:40:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2c62066025d948a9b4867929374b2e0a@irs.gov> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 13:40:54 -0000 Le 06/06/2017 à 15:00, Morizot Timothy S a écrit : > Not sure what to say. fe8 (in hex) followed by 52 binary zeros *is* > fe80::/64. Sounds logic but. Nothing in the figure says that the 52 zeros are part of the LL prefix fe80::/10, or part of some other subnet prefix within. Were some RFC to say literally: "fe80::/64 is the link-local prefix", then I would agree with you. But it would contradict itself saying earlier section 2.4 "Link-Local unicast FE80::/10". > There's nothing ambiguous about it. Translated to hex, that would > be: fe80 0000 0000 0000. It's not any random network prefix. It's > specifically and explicitly all zeros. fe80 0000 0000 0000 is not fe80::/10. > In a proposed standard RFC, not an informational one. Something that > specific in a standards document *is* a specification. Yes, it is an RFC on a Stds Track, and not INFORMATIONAL. It has more agreement behind it, and other things. This document defines IPv6 Architecture for the entire Internet, not just some link types. It _could_ be more appropriate to define fe80::/64 in an IPv6-over-foo RFC, and in a more non-ambiguous manner, with solid reasons on that particular link. > And as I noted, there are certainly non-router devices that implement > link local as specified YEs. > and will not work if the router specifies anything other than > fe80::/64 for link local. What in particular may not work? I think I can safely 'ifconfig add eth0 fe80::1/11'. > Presumably the whole /10 is reserved to allow for future expansion > of the standard. Which expansion can one imagine here? If fe80::/10 is reserved by IANA as 'link-local' and fe80::/64 is thought by many to be 'link-local' too - where is the place for expansion? fe80::/65 maybe? > Or perhaps to avoid confusion. The confusion is there: fe80::/10 is reserved yet fe80::/64 is thought by many to be defined. > Frankly, I have no idea why the whole thing is reserved. But in the > current standard, unicast link local is fe80::/64. I can understand your opinion. Alex > > Scott > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday, June 06, 2017 > 7:41 AM To: Morizot Timothy S; ipv6@ietf.org Subject: Re: /64 and > AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) > > > > Le 06/06/2017 à 12:19, Morizot Timothy S a écrit : >> Alexandre Petrescu wrote: >>> I am not sure whether fe80::/64 or the fe80::/10 is the right >>> prefix for link-local addresses. So I am not sure whether the >>> below method is ok. >> >> The RFC seems pretty clear to me. fe80::/10 is reserved. At present >> only fe80::/64 is defined for link local. Which makes sense since a >> device connecting needs to know what the link local /64 is before >> it has any other information. >> >> https://tools.ietf.org/html/rfc4291 >> >> 2.5.6. Link-Local IPv6 Unicast Addresses >> >> >> Link-Local addresses are for use on a single link. Link-Local >> addresses have the following format: >> >> | 10 | | bits | 54 bits | 64 >> bits | >> +----------+-------------------------+----------------------------+ >> >> >> >> >> >> |1111111010| 0 | interface ID | >> +----------+-------------------------+----------------------------+ > >> >> >> >> >> > Does this figure 'define' fe80::/64? > > All it says is that there is an fe80::/10 followed by 54 0 bits, and > then a 64bit IID. > > At the risk of being called pedantic - are you sure it is not one's > reading that interprets that text to mean that RFC4291 'defines' > fe80::/64? > > And why are the 54 bits reset? Are they a waste? > > Alex > >> >> Since I had someone configure "custom" link local addresses on a >> network using other subnets in fe80::/10 once upon a time, I also >> know that some devices will not work at all without manually and >> statically configuring them in the neighbor table, which is what we >> did until I figured out what was misconfigured and had them fix it. >> So in most instances, it would be unwise to configure anything else >> on routers. >> >> Scott >> From nobody Tue Jun 6 07:52:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D225012950A for ; Tue, 6 Jun 2017 07:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHdRmHRzClel for ; Tue, 6 Jun 2017 07:52:55 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BD2126D05 for ; Tue, 6 Jun 2017 07:52:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v56Eqs9A010418; Tue, 6 Jun 2017 07:52:54 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v56EqqKJ010375 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 6 Jun 2017 07:52:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 6 Jun 2017 07:52:51 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 6 Jun 2017 07:52:51 -0700 From: "Templin, Fred L" To: Tom Herbert CC: Tim Chown , Brian E Carpenter , 6man Subject: RE: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIwARYZ8AAAxi0HAAAkJRAAAQEWEA Date: Tue, 6 Jun 2017 14:52:51 +0000 Message-ID: <2ca19114eaa745c5a72e9c2e908f282b@XCH15-06-08.nw.nos.boeing.com> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <8333195fe502477e85f06cfd7895590b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:52:58 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDA1 LCAyMDE3IDU6MDMgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCj4gQ2M6IFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+OyBCcmlhbiBF IENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPjsgNm1hbiA8aXB2NkBpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IC82NCBhbmQgQUVSTyBhZGRyZXNzZXMgKFJFOiBkcmFmdC1i b3VyYmFraS02bWFuLWNsYXNzbGVzcy1pcHY2LTAwKQ0KPiANCj4gT24gTW9uLCBKdW4gNSwgMjAx NyBhdCAxMToxMyBBTSwgVGVtcGxpbiwgRnJlZCBMDQo+IDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPiB3cm90ZToNCj4gPiBIaSBUb20sDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29t XQ0KPiA+PiBTZW50OiBNb25kYXksIEp1bmUgMDUsIDIwMTcgMTA6MDQgQU0NCj4gPj4gVG86IFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gPj4gQ2M6IFRpbSBD aG93biA8VGltLkNob3duQGppc2MuYWMudWs+OyBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tPjsgNm1hbiA8aXB2NkBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDog UmU6IC82NCBhbmQgQUVSTyBhZGRyZXNzZXMgKFJFOiBkcmFmdC1ib3VyYmFraS02bWFuLWNsYXNz bGVzcy1pcHY2LTAwKQ0KPiA+Pg0KPiA+PiBPbiBNb24sIEp1biA1LCAyMDE3IGF0IDg6NDcgQU0s IFRlbXBsaW4sIEZyZWQgTA0KPiA+PiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6 DQo+ID4+ID4gSGksIG9uZSBleGFtcGxlIHdoZXJlIC82NCBpcyB2ZXJ5IHVzZWZ1bCBpcyBmb3Ig dGhlIGNvbnN0cnVjdGlvbiBvZiBBRVJPDQo+ID4+ID4gYWRkcmVzc2VzIGFzIGRvY3VtZW50ZWQg aW46DQo+ID4+ID4NCj4gPj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10ZW1wbGluLTZtYW4tYWVyb2FkZHIvDQo+ID4+ID4NCj4gPj4gPiBUaGUgZHJhZnQgaXMgdmVy eSBzaG9ydCwgYnV0IGhlcmUgYXJlIHRoZSBtYWluIHRocnVzdHM6DQo+ID4+ID4NCj4gPj4gPiAg ICAiQW4gQUVSTyBhZGRyZXNzIGlzIGFuIElQdjYgbGluay1sb2NhbCBhZGRyZXNzIHdpdGggYW4g aW50ZXJmYWNlDQo+ID4+ID4gICAgaWRlbnRpZmllciBiYXNlZCBvbiBhIHByZWZpeCB0aGF0IGhh cyBiZWVuIGRlbGVnYXRlZCB0byBhIG5vZGUgZm9yDQo+ID4+ID4gICAgaXRzIG93biBleGNsdXNp dmUgdXNlLiAgQUVSTyBhZGRyZXNzZXMgYmVnaW4gd2l0aCB0aGUgcHJlZml4DQo+ID4+ID4gICAg ZmU4MDo6LzY0IGFuZCBpbmNsdWRlIGluIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllciAoaS5lLiwg dGhlIGxvd2VyDQo+ID4+ID4gICAgYml0cykgYSA2NC1iaXQgcHJlZml4IHRha2VuIGZyb20gb25l IG9mIHRoZSBub2RlJ3MgZGVsZWdhdGVkDQo+ID4+ID4gICAgcHJlZml4ZXMuICBGb3IgZXhhbXBs ZSwgaWYgdGhlIG5vZGUgcmVjZWl2ZXMgdGhlIElQdjYgcHJlZml4Og0KPiA+PiA+DQo+ID4+ID4g ICAgICAgMjAwMTpkYjg6MTAwMDoyMDAwOjovNjQNCj4gPj4gPg0KPiA+PiA+ICAgIGl0IGNvbnN0 cnVjdHMgaXRzIGNvcnJlc3BvbmRpbmcgQUVSTyBhZGRyZXNzZXMgYXM6DQo+ID4+ID4NCj4gPj4g PiAgICAgICBmZTgwOjoyMDAxOmRiODoxMDAwOjIwMDAiDQo+ID4+ID4NCj4gPj4gPiAgICAiVGhl IEFFUk8gYWRkcmVzcyBpcyBpbnRlbmRlZCBmb3IgdXNlIGJ5IG1vYmlsZSBuZXR3b3JrcyB0aGF0 IGNvbXByaXNlDQo+ID4+ID4gICAgYSBtb2JpbGUgcm91dGVyIGFuZCBhIHRldGhlcmVkIG5ldHdv cmsgb2YgIkludGVybmV0IG9mIFRoaW5ncyINCj4gPj4gPiAgICBkZXZpY2VzIHRoYXQgdHJhdmVs IHRvZ2V0aGVyIHdpdGggdGhlIHJvdXRlciBhcyBhIHNpbmdsZSB1bml0LiAgVGhlDQo+ID4+ID4g ICAgbW9iaWxlIHJvdXRlciBhc3NpZ25zIHRoZSBBRVJPIGFkZHJlc3MgdG8gaXRzIHVwc3RyZWFt IGludGVyZmFjZSBvdmVyDQo+ID4+ID4gICAgd2hpY2ggaXQgcmVjZWl2ZXMgYSBwcmVmaXggZGVs ZWdhdGlvbiBmcm9tIGEgZGVsZWdhdGluZyByb3V0ZXIuICBUaGUNCj4gPj4gPiAgICBtYW5uZXIg Zm9yIHJlY2VpdmluZyB0aGUgZGVsZWdhdGVkIHByZWZpeCBjb3VsZCBiZSB0aHJvdWdoIHN0YXRp Yw0KPiA+PiA+ICAgIGNvbmZpZ3VyYXRpb24gb3Igc29tZSBhdXRvbWF0ZWQgcHJlZml4IGRlbGVn YXRpb24gc2VydmljZS4iDQo+ID4+ID4NCj4gPj4gPiBJIGZ1cnRoZXIgYmVsaWV2ZSB0aGlzIGxp bmstbG9jYWwgYWRkcmVzcyBmb3JtYXQgbWF5IHByb3ZlIHRvIGJlIHVzZWZ1bCBmb3INCj4gPj4g PiBhbnkgc2NlbmFyaW9zIHdoZXJlIGEgcHJlZml4IGRlbGVnYXRpb24gaXMgcmVjZWl2ZWQuDQo+ ID4+ID4NCj4gPj4NCj4gPj4gQ291bGRuJ3QgeW91IGRvIHRoaXMgc2FtZSB0cmljayB3aXRoIGFu eSBkZWxlZ2F0ZWQgcHJlZml4IHVwIHRvIDExOCBiaXRzIGxlbmd0aD8NCj4gPg0KPiA+IFZlcnkg Z29vZCBxdWVzdGlvbiwgc2luY2UgbGluay1sb2NhbCBwcmVmaXggaXMgdGVjaG5pY2FsbHkgZmU4 MDo6LzEwLiBCdXQsDQo+ID4gd2hhdCB3b3VsZCBpbXBsZW1lbnRhdGlvbnMgZG8gd2l0aCBhIGxp bmstbG9jYWwgdGhhdCBkb2Vzbid0IGJlZ2luIHdpdGgNCj4gPiBmZTgwOjovNjQ/DQo+ID4NCj4g UkZDMzUxMyBkZWZpbmVzIGxpbmsgYWRkcmVzcyB3aXRoIHplcm8gaW4gdGhlIDU0IGJpdHMgZm9s bG93aW5nIHRoZSAxMA0KPiBiaXQgcHJlZml4Lg0KDQpUaGF0IHNlZW1zIHRvIGJlIHN0aWxsIHRo ZSBjYXNlIGZvciBSRkM0MjkxIGFuZCBSRkM0MjkxKGJpcykuDQoNCj4gSSBkb3VidCBhbnkgaW1w bGVtZW50YXRpb24gd291bGQgY2FyZSBpZiB0aG9zZSBiaXRzDQo+IHdlcmVuJ3QgemVyb2VzLCBo b3BlZnVsbHkgaXQncyBqdXN0IHRyZWF0ZWQgYXMgYSAvMTAgSVAgYWRkcmVzcyB0aGF0DQo+IGNh biBiZSBjb25maWd1cmVkIGFuZCB1c2VkLg0KDQpBIHN0cmljdCBpbXBsZW1lbnRhdGlvbiBvZiBS RkM0MjkxL1JGQzQyOTEoYmlzKSB3b3VsZCBjYXJlLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwu dGVtcGxpbkBib2VpbmcuY29tDQoNCj4gVG9tDQo+IA0KPiA+IFRoYW5rcyAtIEZyZWQNCj4gPg0K PiA+PiBUb20NCj4gPj4NCj4gPj4gPiBUaGFua3MgaW4gYWR2YW5jZSBmb3IgY29tbWVudHMuDQo+ ID4+ID4NCj4gPj4gPiBGcmVkDQo+ID4+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+ PiA+DQo+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IGlw djYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW0gQ2hvd24N Cj4gPj4gPj4gU2VudDogTW9uZGF5LCBKdW5lIDA1LCAyMDE3IDg6MzQgQU0NCj4gPj4gPj4gVG86 IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+DQo+ID4+ID4+ IENjOiA2bWFuIDxpcHY2QGlldGYub3JnPg0KPiA+PiA+PiBTdWJqZWN0OiBSZTogZHJhZnQtYm91 cmJha2ktNm1hbi1jbGFzc2xlc3MtaXB2Ni0wMA0KPiA+PiA+Pg0KPiA+PiA+PiBIaSwNCj4gPj4g Pj4NCj4gPj4gPj4gPiBPbiAzIEp1biAyMDE3LCBhdCAyMjoxMiwgQnJpYW4gRSBDYXJwZW50ZXIg PGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+ID4+ID4NCj4gPj4gPj4g PiBPbiAwNC8wNi8yMDE3IDA1OjMyLCBSb2dlciBKw7hyZ2Vuc2VuIHdyb3RlOg0KPiA+PiA+PiA+ PiBPbiBGcmksIEp1biAyLCAyMDE3IGF0IDQ6MTEgUE0sIEpvYiBTbmlqZGVycyA8am9iQG50dC5u ZXQ+IHdyb3RlOg0KPiA+PiA+PiA+PiA8c25pcD4NCj4gPj4gPj4gPj4+IEFic3RyYWN0Og0KPiA+ PiA+PiA+Pj4gICBPdmVyIHRoZSBoaXN0b3J5IG9mIElQdjYsIHZhcmlvdXMgY2xhc3NmdWwgYWRk cmVzcyBtb2RlbHMgaGF2ZSBiZWVuDQo+ID4+ID4+ID4+PiAgIHByb3Bvc2VkLCBub25lIG9mIHdo aWNoIGhhcyB3aXRoc3Rvb2QgdGhlIHRlc3Qgb2YgdGltZS4gIFRoZSBsYXN0DQo+ID4+ID4+ID4+ PiAgIHJlbW5hbnQgb2YgSVB2NiBjbGFzc2Z1bCBhZGRyZXNzaW5nIGlzIGEgcmlnaWQgbmV0d29y ayBpbnRlcmZhY2UNCj4gPj4gPj4gPj4+ICAgaWRlbnRpZmllciBib3VuZGFyeSBhdCAvNjQuICBU aGlzIGRvY3VtZW50IHJlbW92ZXMgdGhlIGZpeGVkIHBvc2l0aW9uDQo+ID4+ID4+ID4+PiAgIG9m IHRoYXQgYm91bmRhcnkgZm9yIGludGVyZmFjZSBhZGRyZXNzaW5nLg0KPiA+PiA+PiA+Pg0KPiA+ PiA+PiA+PiB3aGF0IEkgZmluZCBvZGQgaXMgdGhhdCB3ZSBvdmVyIGFuZCBvdmVyIGFnYWluIGFy ZSBtb3JwaGluZyBJUHY2IGludG8gSVB2NA0KPiA+PiA+PiA+PiB3aXRoIGp1c3QgbW9yZSBJUCBh ZHJlc3Nlcy4uLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gVGhhdCBzaW1wbHkgaXNuJ3QgdHJ1ZS4g VGhlIGRyYWZ0IGRvZXNuJ3QgYWJvbGlzaCB0aGUgY29uY2VwdCBvZiAnaW50ZXJmYWNlDQo+ID4+ ID4+ID4gaWRlbnRpZmllcicsIHdoaWNoIGRvZXNuJ3QgZXhpc3QgaW4gSVB2NC4gSXQgZG9lc24n dCBhdHRhY2sgU0xBQUMuIEl0DQo+ID4+ID4+ID4gZG9lc24ndCBhdHRhY2sgSUxOUCBvciBkcmFm dC1oZXJiZXJ0LW52bzMtaWxhLiBJdCBkb2Vzbid0IGF0dGFjayB0aGUgY2hvaWNlDQo+ID4+ID4+ ID4gb2YgLzY0IGZvciBhbGwgSVB2Ni1vdmVyLWZvb3MgdG8gZGF0ZS4NCj4gPj4gPj4gPg0KPiA+ PiA+PiA+IEl0IGRvZXMgc2F5IHR3byB0aGluZ3MuDQo+ID4+ID4+ID4NCj4gPj4gPj4gPiAxLiBC Q1AxOTgNCj4gPj4gPj4gPiAyLiBuIGluIHRoZSBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZSBpcyBh IHBhcmFtZXRlci4NCj4gPj4gPj4NCj4gPj4gPj4gQW5kIGl0IHRoYXQgc2Vuc2UsIGl04oCZcyBm aW5lLCBpLmUuIC82NCBpcyBSRUNPTU1FTkRFRCwgYW5kIHVzZWQgZm9yIHRoZSB2YXJpb3VzIElQ djYtb3Zlci1mb29zIHRoYXQgQnJpYW4gbWVudGlvbmVkLCBidXQgYWxzbyBpdA0KPiA+PiBzZW5k cw0KPiA+PiA+PiBhIG1lc3NhZ2UgdG8gbm90IGhhcmRjb2RlIC82NC4NCj4gPj4gPj4NCj4gPj4g Pj4gVGhlIGRyYWZ0IGNvdWxkIGNpdGUgUkZDNzQyMSBhbmQgKGZvciB0aGUgcG9pbnQgYWJvdXQg YWRkcmVzcyBhdmFpbGFiaWxpdHkpIFJGQzc5MzQuDQo+ID4+ID4+DQo+ID4+ID4+IExpa2UgRGF2 aWQsIGF0IHRoZSB1bml2ZXJzaXR5IHdoZXJlIHdlIGRlcGxveWVkIElQdjYsIHdlIGRpZG7igJl0 IHRyeSB0byBsb2NrIGRvd24gYWRkcmVzc2VzIHRvIGhvc3RzOyByYXRoZXIgd2UgdXNlZCBTTk1Q LQ0KPiBiYXNlZA0KPiA+PiA+PiBwb2xsaW5nIG9mIG5ldHdvcmsgZGV2aWNlcyBmb3IgYWNjb3Vu dGFiaWxpdHkuIFdlIGFsc28gaGFkIDgwMi4xWCAodGhyb3VnaCBlZHVyb2FtKSBvbiBXaUZpLCBh bmQgSSBrbm93IG9mIHNvbWUgdW5pdmVyc2l0aWVzDQo+ID4+ID4+IGRlcGxveWluZyA4MDIuMVgg Zm9yIHdpcmVkIG5ldHdvcmtzIGFzIHdlbGwuIFRoZXJl4oCZcyBhbHNvIHRoZSBDaXNjbyBORCBz eXNsb2dnaW5nIGNhcGFiaWxpdHkgaWYgeW91IHVzZSB0aGVpciBwbGF0Zm9ybS4NCj4gPj4gPj4N Cj4gPj4gPj4gVGltDQo+ID4+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+PiA+PiBpcHY2QGlldGYub3JnDQo+ID4+ID4+IEFk bWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjYNCj4gPj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiA+ IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+PiA+IGlwdjZAaWV0Zi5v cmcNCj4gPj4gPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KDQo= From nobody Tue Jun 6 07:53:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55E129515 for ; Tue, 6 Jun 2017 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrFoAZksKreQ for ; Tue, 6 Jun 2017 07:53:18 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36263129A8F for ; Tue, 6 Jun 2017 07:53:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v56ErG7X011178; Tue, 6 Jun 2017 07:53:17 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v56Er68w011045 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 6 Jun 2017 07:53:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 6 Jun 2017 07:53:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 6 Jun 2017 07:53:05 -0700 From: "Templin, Fred L" To: Michael Richardson CC: 6man Subject: RE: draft-templlin-6man-aeroaddr Thread-Topic: draft-templlin-6man-aeroaddr Thread-Index: AQHS3kThU4/e1NUcP0q+n3y/e7rPeaIW2p6AgACvAICAAGENoA== Date: Tue, 6 Jun 2017 14:53:05 +0000 Message-ID: <35539747bae34a3cb53c196b56ec3147@XCH15-06-08.nw.nos.boeing.com> References: <4234.1496699042@obiwan.sandelman.ca> <8b4caaafb6fc4b9d8245600993bf1f44@XCH15-06-08.nw.nos.boeing.com> <30709.1496714315@obiwan.sandelman.ca> In-Reply-To: <30709.1496714315@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:53:20 -0000 Hi Michael, > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: Monday, June 05, 2017 6:59 PM > To: Templin, Fred L > Cc: 6man > Subject: Re: draft-templlin-6man-aeroaddr >=20 >=20 > Templin, Fred L wrote: > >> PPP links just make up random stuff, with the option that they > >> can keep it around across reboots. Or is the point to offload tha= t state > >> into the network? >=20 > > I am using it on NBMA links where a node first obtains a delegated > > prefix then next statelessly constructs an AERO address for itself. > > The AERO address then statelessly links IPv6 ND with IPv6 forwardin= g; > > if there is a neighbor cache entry with an AERO address that matche= s > > the packet's IPv6 destination address then there is no need to also > > look up the destination in the IPv6 forwarding table. >=20 > So you are taking advantage of the mapping to implicitely do the routing? Yes, since the routing information is available from the link-local address why not use it? > What kind of NBMA link is it? It is an NBMA link based on encapsulation without explicit tunnels. IP is seen as the link-layer for IP, and an ingress node can send encapsulated packets to any among possibly man egress nodes. The ingress node keeps a neighbor cache entry for each egress, indexed by the egress' AERO address. That said, this may be useful for any NBMA link type, and not just multipoint tunnels. > This could be useful for the ANIMA ACP, which is a mesh of IPsec (normall= y) > over LL tunnels. I think there may be many other uses - thanks for pointing this one out. Please feel free to forward a pointer to the document to anyone in that community who may be interested. Thanks - Fred fred.l.templin@boeing.com > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Tue Jun 6 08:01:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D62412944C for ; Tue, 6 Jun 2017 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV6VArLbANro for ; Tue, 6 Jun 2017 08:01:39 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123AD1293EC for ; Tue, 6 Jun 2017 08:01:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v56F1bLG058693; Tue, 6 Jun 2017 08:01:37 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v56F1QDF058518 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 6 Jun 2017 08:01:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 6 Jun 2017 08:01:25 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 6 Jun 2017 08:01:25 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , Morizot Timothy S , "ipv6@ietf.org" Subject: RE: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: /64 and AERO addresses (RE: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AdLeEuR3ZBv5AtZdTFakXXcngcrvIwA0oZ2AAADkloAABPPKgAAArGgAAAFrvYAAC//RMA== Date: Tue, 6 Jun 2017 15:01:25 +0000 Message-ID: <8990eb23bab34c4cb95cbd606c8f6e7b@XCH15-06-08.nw.nos.boeing.com> References: <6c0c2d222ad44cdab04bb94e68e6df65@XCH15-06-08.nw.nos.boeing.com> <6f9deb37-63ce-0f67-0ca6-71b2b1fcc53f@gmail.com> <2c62066025d948a9b4867929374b2e0a@irs.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:01:41 -0000 PiA+IEZyYW5rbHksIEkgaGF2ZSBubyBpZGVhIHdoeSB0aGUgd2hvbGUgdGhpbmcgaXMgcmVzZXJ2 ZWQuIEJ1dCBpbiB0aGUNCj4gPiBjdXJyZW50IHN0YW5kYXJkLCB1bmljYXN0IGxpbmsgbG9jYWwg aXMgZmU4MDo6LzY0Lg0KDQpJcyBSRkM0MjkxKGJpcykgc3RpbGwgb3BlbiBmb3IgZWRpdHM/DQoN ClRoYW5rcyAtIEZyZWQNCg0KDQo= From nobody Tue Jun 6 08:54:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5C1286D6 for ; Tue, 6 Jun 2017 08:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V16Wi4EFTfv for ; Tue, 6 Jun 2017 08:54:56 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 797AE129649 for <6man@ietf.org>; Tue, 6 Jun 2017 08:54:56 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id q97so56072007wrb.2 for <6man@ietf.org>; Tue, 06 Jun 2017 08:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PvZtgNNNhbvxezpPGRRlb1MjneTziFLisO0jB+OgtuI=; b=ZEkg5hCLTfG9GxGQiPTYaHjZOSyOPaYU1e/IApDc5ueGq7PB+iUovXhLJYc+BHAsyH ZDerwtw6Y1My/8jsOsWdCNk4fooQrzvRWNyF/SVy/tQmIfb9jzlmJXQr74m8nNOtw3XS sWiA4usWBb9H5HidocyXWcgm+7UcVdJYyZmfBsQtnVD77hpCHXbgH32s3J/Ug7lrHlbp GHNkZCUPf9BqE8+fxEjLiqEp2KdxpH2QhIt4AGFWyZRi74DOtEn+kFQWNCPIO5GOlTgF HBZW1hv/jDeeyIGLcpVYJ3zcQaXw3OTyYAUmcHd4kHbhFuGXeEVP8OKLXHXOInysjxAb sKcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PvZtgNNNhbvxezpPGRRlb1MjneTziFLisO0jB+OgtuI=; b=hI5nPcmaro0GMMXbXErnMxVmrpWGqP2UOOcESga3kUfzLHHU7thfbxcuqJ/2LK/LW+ /REa/vexbAhOEOmkCOwPn6Z+kA71MG7R3FGO+9o79PvpuRbEQYsYBUDXD9xb11LybUc5 0Ix6QHBdA8UnVFKO62SgIQ6ShYIJTG1XUVkR86b9WRZCb3/qd+KlLZPjmCwEZJefB8yV pRfpTkODrWqpiLHur2SyIKcZr+7XMXXZRLdM/JY7jCPwMLmdwmVd5fAqXeUxsa0eLLLT p3sGuFwJri2W9HVWUIbjGsXRo1coyyzftmZ4LU6DltdMDw/pqDOcUlGF5/YpQfp1D2NI 5lLA== X-Gm-Message-State: AODbwcB+qzykTHEEiGqlQTZyaKzLOsxlSoqa3JxhXr76U4o8dZ8Ekx3i yAxmtJF/+tO2fWlfpm7dXzPieS0AQz704ZZ5mQ== X-Received: by 10.223.183.32 with SMTP id l32mr10316958wre.115.1496764494572; Tue, 06 Jun 2017 08:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 08:54:54 -0700 (PDT) From: Tom Herbert Date: Tue, 6 Jun 2017 08:54:54 -0700 Message-ID: Subject: Identifier/locator split addressing and /64 To: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:54:58 -0000 Both RFC7421 and RFC7136 state that a motivation for the /64 is identfier/locator split addressing (like in ILNP). The motivation is valid, however assigning a /64 to UEs in a mobile network is not compatible with identifier/locator split. The reason is that the link of interest for IIDs is not inside the UE, but is logically in the network. The identifier in a mobile network needs to identify the device. In identifier/locator split, the IP address is split into a locator and identifier. Each are 64 bits (although Brian did point out that that could also be a parameter). Just like IIDs, identifiers must be unique within the subnet. In the case of a mobile network the link is an overlay network that is not physical, but none the less it is a type of link. So the properties of it being a link including those for IIDs on the link hold-- this make identifiers equivalent to IIDs by definition. The IPv6 address for identifier/locator split looks like: M bits for locator N bits for device identifier 128 - M - N bits for addresses within the device M is 64, and it seems straightforward to make N be 32 so we get 64 bits for locator 32 bits for device identifier 32 bits for addresses within the device Which implies /96 assignment to each UE. Thus the IID is constructed from a 32 bit number assigned to the device, and a 32 bit number assigned by the device. If assignments for both of these are randomized this provides 64 bits of entropy for security. Tom From nobody Tue Jun 6 09:02:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718E81292F5 for ; Tue, 6 Jun 2017 09:02:27 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63a1ly5nmo8w for ; Tue, 6 Jun 2017 09:02:25 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id EB962128990 for <6man@ietf.org>; Tue, 6 Jun 2017 09:02:25 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 06 Jun 2017 16:02:25 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 26C9BD788A; Tue, 6 Jun 2017 09:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=H4SnptHty9OfwBKueRlpmLMC5f8=; b= Obn+Iz89N9ycQJVbKZwkPPtDJ0Wd98ZIrs2YaclsIDR/bWHAeKfAHu4pfA6iUVim EmydfUvyQLYW2wXRKNS8CRN0vQEDCC+12S3o+F4kcegCdhPWhalwg8UDmFZg/A7Q sFttvvD293KtEIR9bWG4fadd7KlNcw6ZENZmTydP22w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=cze6lXletSXeA0S4hRyzTl+ S1ojhBXpIXcI5LpnBvTWDjmjJh24hMhaMdGe8/pJMHj7zFN50tJDyWtsF6gmPw6T E00CO+JL5o6A7w0Yoa8gl6FBqkJY2DtqIPTDMKCdCkqdjvQlGwcDvz1+xD7iHo9G elxRlhy+84aSImJGRmm0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E6F05D788D; Tue, 6 Jun 2017 09:02:24 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DFEEACDB8599; Tue, 6 Jun 2017 18:02:21 +0200 (CEST) From: otroan@employees.org Message-Id: <308B32F8-9EC9-4067-A396-8AB2067931F7@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_58E30B9D-DDDD-465D-871D-6422C6D2CA02"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Identifier/locator split addressing and /64 Date: Tue, 6 Jun 2017 18:02:20 +0200 In-Reply-To: Cc: 6man@ietf.org To: Tom Herbert References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:02:27 -0000 --Apple-Mail=_58E30B9D-DDDD-465D-871D-6422C6D2CA02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, > Both RFC7421 and RFC7136 state that a motivation for the /64 is > identfier/locator split addressing (like in ILNP). The motivation is > valid, however assigning a /64 to UEs in a mobile network is not > compatible with identifier/locator split. The reason is that the link > of interest for IIDs is not inside the UE, but is logically in the > network. The identifier in a mobile network needs to identify the > device. >=20 > In identifier/locator split, the IP address is split into a locator > and identifier. Each are 64 bits (although Brian did point out that > that could also be a parameter). Just like IIDs, identifiers must be > unique within the subnet. In the case of a mobile network the link is > an overlay network that is not physical, but none the less it is a > type of link. > So the properties of it being a link including those for IIDs on the > link hold-- this make identifiers equivalent to IIDs by definition. >=20 > The IPv6 address for identifier/locator split looks like: >=20 > M bits for locator > N bits for device identifier > 128 - M - N bits for addresses within the device >=20 > M is 64, and it seems straightforward to make N be 32 so we get >=20 > 64 bits for locator > 32 bits for device identifier > 32 bits for addresses within the device >=20 > Which implies /96 assignment to each UE. >=20 > Thus the IID is constructed from a 32 bit number assigned to the > device, and a 32 bit number assigned by the device. If assignments for > both of these are randomized this provides 64 bits of entropy for > security. Can you explain how this is different from a device getting multiple = 64-bit IIDs? Cheers, Ole --Apple-Mail=_58E30B9D-DDDD-465D-871D-6422C6D2CA02 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZNtINAAoJEL7aWKiYQt92UQkP/AgyZNBvZoUJogaMeqsHDnGz E1oQMREsZQZVkr+RaNna4nFvx4pHcjiFxXZO6H2HngbGqbarPc2ehKCGh3dBJuZn 4nh6TSM2Mxr2zQNGzOqKLIkWOr0eHLwkOUU7D6N5O3VHEtNIynfpAyqPTO5KJFvq nYyzlErhPWGsRKI0jDbPfSdbQv9OSYhM8zK/klSVFchfCWQM66jw91p+EQ0gk9u7 1z+ApieK+FBtdzfyCwFhzc9pTjQOETyUl8C0HfSepMK6HOns0Wpjj5fkjgOWgbFi /PYFGk1m16aAqD4WabJ5WbLDK0bvGuW22w77q2mDAOzeHER6RNPV1GYCqCy8l98W RjcKHr6Cz+0TZ4W3AIcFHPmcPmSiowiGnnAHIWD98bV+8jVHEfVMeeN8g+5rX9k9 V1X9vjlS54dX/mQkSw6ADmRDqLIKgj31og6F/+j/6hk+GMlxzmzaXml4hpgu3YUS fihGP/BNPr1vp3W0JqYBtgb/LlgksVdoo8WjxgDqOTnKWOstpqObv0WZsZqLw4It 1ovKDnFY77yMwxTf9775ndAKUiPNix8XpIMNMPeMQEvq/LRq+GI9ukXK445nOpeP xxIs693MbrOCUos1oRDa2UlUvqqcrR6Ak9cLPucu2ond64X+VON3zocRskHHaQ5t Tc2woF308hI5d4D1QbVc =4sAM -----END PGP SIGNATURE----- --Apple-Mail=_58E30B9D-DDDD-465D-871D-6422C6D2CA02-- From nobody Tue Jun 6 09:20:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BEE129AB0 for ; Tue, 6 Jun 2017 09:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl7nsrEJnIZH for ; Tue, 6 Jun 2017 09:20:35 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 0B13612947B for <6man@ietf.org>; Tue, 6 Jun 2017 09:20:35 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id v104so56495897wrb.0 for <6man@ietf.org>; Tue, 06 Jun 2017 09:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b4K2sCJ7MdXLahzRPL4/ZfGwYd0v8TeTiYDBtB+CMD4=; b=2FULubJxG0PS+2mVAAsvEmkuWZhgf8G8PIhhyd6Yg1isBvcoqV4Cgnn9RchRDDIRQG O9BtRixOgNCPIcTrJidwsydOqBJyCJJfhor9etw6oMDaTioMrtkNQ5O7LaRZDrL+EXqn Fpg7c2NoPg2TRSz7VWMFjYPhGikD/u52hcihmL/2+VHjuAJyv0bGtYSJTIwWVbd+VFDu pp19LL0LHqnAZ3vl4YLFQfcQINp2oKeTtL9ftzILpEn/jgDZ09bt5T8WRdXPb565X0mK eB9txOlw5n6x452BAWN0nmQhQYJkFiaY0XjqFEcMK7LnFbQzCg42soIKMaaKc63gIBt5 KUlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b4K2sCJ7MdXLahzRPL4/ZfGwYd0v8TeTiYDBtB+CMD4=; b=sVpEVw6sTUTJ5y1UJJZVpjnjVIKJDm4zsBF4iMqgdW+XN2fSkpZdskIu0vF/F+E22P +3HpprMEao9lT7iLEu/JOUb8ZgfySL0xqEOVyyfxX29qgP0WP4CsHH7koQLPmqzSGl91 fegrIKASJxwy0MylTTsgmAqL+vMYJXZ1IEXTdw6LwhCwnNaf8g2LNXyR0WLqAUFUz5C8 UglFLiti4ZD+f0CIKUnDqFE+mC9Xt/wt3czR0wyN4+Lsk8Uq955ut/5pS/sX2qVGCFss Ju4W7h4soUb4ool5XDq7mhLDFYzDJicxQBBKaEcg9mk+rUXeyLkQChQCXpbs5fzk3AUl GhYQ== X-Gm-Message-State: AODbwcDGbePLjmOk6UuZv8g8FrGgMrSYCkWtZpNZX3sqb2YaUrN9Za1B KkGmXOWzauYQYXpDIgt5CRgPiFRfLZ+dTxk5TQ== X-Received: by 10.223.128.80 with SMTP id 74mr21719054wrk.30.1496766033487; Tue, 06 Jun 2017 09:20:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 09:20:32 -0700 (PDT) In-Reply-To: <308B32F8-9EC9-4067-A396-8AB2067931F7@employees.org> References: <308B32F8-9EC9-4067-A396-8AB2067931F7@employees.org> From: Tom Herbert Date: Tue, 6 Jun 2017 09:20:32 -0700 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: Ole Troan Cc: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:20:36 -0000 On Tue, Jun 6, 2017 at 9:02 AM, wrote: > Tom, > >> Both RFC7421 and RFC7136 state that a motivation for the /64 is >> identfier/locator split addressing (like in ILNP). The motivation is >> valid, however assigning a /64 to UEs in a mobile network is not >> compatible with identifier/locator split. The reason is that the link >> of interest for IIDs is not inside the UE, but is logically in the >> network. The identifier in a mobile network needs to identify the >> device. >> >> In identifier/locator split, the IP address is split into a locator >> and identifier. Each are 64 bits (although Brian did point out that >> that could also be a parameter). Just like IIDs, identifiers must be >> unique within the subnet. In the case of a mobile network the link is >> an overlay network that is not physical, but none the less it is a >> type of link. >> So the properties of it being a link including those for IIDs on the >> link hold-- this make identifiers equivalent to IIDs by definition. >> >> The IPv6 address for identifier/locator split looks like: >> >> M bits for locator >> N bits for device identifier >> 128 - M - N bits for addresses within the device >> >> M is 64, and it seems straightforward to make N be 32 so we get >> >> 64 bits for locator >> 32 bits for device identifier >> 32 bits for addresses within the device >> >> Which implies /96 assignment to each UE. >> >> Thus the IID is constructed from a 32 bit number assigned to the >> device, and a 32 bit number assigned by the device. If assignments for >> both of these are randomized this provides 64 bits of entropy for >> security. > > Can you explain how this is different from a device getting multiple 64-bit IIDs? > Hi Ole, I'm not sure I understand the question, but each device is getting 2^32 64-bit IIDs in this scheme. Uniqueness of IIDs within the subnet is ensured by the device identifier. This conforms with RFC3513: "Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet prefix." Tom > Cheers, > Ole From nobody Tue Jun 6 09:34:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25807129ABD for ; Tue, 6 Jun 2017 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyjSZU9XkwB2 for ; Tue, 6 Jun 2017 09:34:45 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 70D20129AB5 for <6man@ietf.org>; Tue, 6 Jun 2017 09:34:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 592C35E0485; Tue, 6 Jun 2017 09:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496766885; bh=O2+L1+HW+XP735iGOnaSmuv6oOVkjWFUN+ZWcTLezR0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KdAFcmfHICCIh3JOyKZmSC+gOLY42gCWzvRbkT6rr1ehoHz8HbRGK949HxOVYD2x2 ls/ZsBVpw3iafsJqeLpySsCrsGkGmcF7xr8cbi/WTuVt1KvmaO516Y2fZQJLKA1gPP RxRdwf4R/YIyjgqKbxLiqCjoIOuzLc2NP0vLnMoo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 98BBC1C02AF; Tue, 6 Jun 2017 09:34:44 -0700 (PDT) Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert , 6man@ietf.org References: From: "Joel M. Halpern" Message-ID: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> Date: Tue, 6 Jun 2017 12:34:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:34:47 -0000 Tom, I do not follow your reasoning at all. I can not tell what you mean by "addressing within the device". Even in a data center, one might choose to treat the hypervisor as part of the network, and allocate a prefix to the hypervisor so it can assign a /64 locator to each device. Or you could assign separate /64s to each entitiy within the device from the network directly. Neither requires changing the IID space. For something that is a single device, like a UE< it is even simpler to allow the network to directly assign as many /64 as the device needs. Note that if the UE is serving as a router for other devices, then 1) that is not routing within the device 2) the space is likely small enough that routing on the full /128s works just fine You have made this assertion a couple of times now, and I can not figure out why you consider the change necessary. ILNP can work fine for mobile network UE. Yours, Joel On 6/6/17 11:54 AM, Tom Herbert wrote: > Both RFC7421 and RFC7136 state that a motivation for the /64 is > identfier/locator split addressing (like in ILNP). The motivation is > valid, however assigning a /64 to UEs in a mobile network is not > compatible with identifier/locator split. The reason is that the link > of interest for IIDs is not inside the UE, but is logically in the > network. The identifier in a mobile network needs to identify the > device. > > In identifier/locator split, the IP address is split into a locator > and identifier. Each are 64 bits (although Brian did point out that > that could also be a parameter). Just like IIDs, identifiers must be > unique within the subnet. In the case of a mobile network the link is > an overlay network that is not physical, but none the less it is a > type of link. > So the properties of it being a link including those for IIDs on the > link hold-- this make identifiers equivalent to IIDs by definition. > > The IPv6 address for identifier/locator split looks like: > > M bits for locator > N bits for device identifier > 128 - M - N bits for addresses within the device > > M is 64, and it seems straightforward to make N be 32 so we get > > 64 bits for locator > 32 bits for device identifier > 32 bits for addresses within the device > > Which implies /96 assignment to each UE. > > Thus the IID is constructed from a 32 bit number assigned to the > device, and a 32 bit number assigned by the device. If assignments for > both of these are randomized this provides 64 bits of entropy for > security. > > Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 6 10:33:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCD5129B47 for ; Tue, 6 Jun 2017 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ5C63mra2m6 for ; Tue, 6 Jun 2017 10:33:25 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 76951129B44 for <6man@ietf.org>; Tue, 6 Jun 2017 10:33:25 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id q97so57178882wrb.2 for <6man@ietf.org>; Tue, 06 Jun 2017 10:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lcWBHdkFA25GKQIgfZQ7tYPIt4a1ipjNETGh8y/qbzs=; b=yLiVMP7YLaFn3gya2IOJ+mP9668BlJQoF0Rot0LmysCg7TjEeQVKtXdYT1F/fPrfAq nLfuSDhUa7MZv7vnETOG+cOI0o8FyG9b0CZGXetDIEuXEoPcZh4XontPFBq8FPCmONbI g2O/Y+FpnrX9W8QI1nkvrRxW74iAtzR8GW8o2gZuLFDooiiTZGGMbgAqblDA07xQjvu8 RBCi7Oro8zyA931uAyVeQAu6zRN3sHdgMefVGw3Y+5PWQd7bo8nAfRoESRhJ99gHsJwC 0cWJQRMLUaLOfDcBQTlejlsExJ1BnbBWC+xQSgdE+vcjANhnZxDeIzlI9GyFCjcAuQB0 f5Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lcWBHdkFA25GKQIgfZQ7tYPIt4a1ipjNETGh8y/qbzs=; b=NTcu7xmzz2BRPvz2mRIhPvfTF4yuLSYeQifOfpksbO2r76unbKcAbTZ7rSCMNSsOCi bfI/1kOMiCmf81kK9OySsb25G2qzScvHy8bFkDz19BCpW4uaXXYQRa2vLSnNktFSLvq5 1DmCbEc4iVawALtzhZtXcIFo/pRXZqFmAGRsQ0NsoSFa1p40NO8wXM+QeLA4p0eALldB R+Mq7hZmXufQst2ZsbPW+/4WZN+HTBDh1VAYhcKM1M8c0m/0+GM6+HLwhRHzo+EAacoG Zls3kC0glcBFJqvYNOUziVhXELvMONQipGgINn/FL6+Ulv2T4whXWiX4GgYmgZ0t1uNj UJRQ== X-Gm-Message-State: AODbwcA4z32YWgmtJsm0x85wIm0y/ncSCCINTv6FbR786HljKWkuywr6 A6MHr8BCwI0fo6oytLOQFL6yRK0Mw9iN4CA= X-Received: by 10.223.128.80 with SMTP id 74mr21987808wrk.30.1496770403620; Tue, 06 Jun 2017 10:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 10:33:23 -0700 (PDT) In-Reply-To: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> From: Tom Herbert Date: Tue, 6 Jun 2017 10:33:23 -0700 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: "Joel M. Halpern" Cc: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 17:33:27 -0000 Hi Joel, On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern wrote: > Tom, I do not follow your reasoning at all. > I can not tell what you mean by "addressing within the device". Referring to the prefix delegated to the device. > Even in a data center, one might choose to treat the hypervisor as part of > the network, and allocate a prefix to the hypervisor so it can assign a /64 > locator to each device. Or you could assign separate /64s to each entitiy > within the device from the network directly. Neither requires changing the > IID space. > Right, we're not changing the IID space here. We're specifying which link (subnet) is the IID space relative to. > For something that is a single device, like a UE< it is even simpler to > allow the network to directly assign as many /64 as the device needs. > > Note that if the UE is serving as a router for other devices, then > 1) that is not routing within the device > 2) the space is likely small enough that routing on the full /128s works > just fine > > You have made this assertion a couple of times now, and I can not figure out > why you consider the change necessary. ILNP can work fine for mobile > network UE. It doesn't work if the UE is assigned a /64, that's my point. The device is the mobile node that needs to be reflected in the identifier and then the mapping in the network is mobile device (device identifier) to locator. The locator is the address of an attachment point (e.g. base station) in the network. The addresses covered by the prefix assigned to the device is not relevant in mobility since the whole prefix follows the device. So what we're really interested in is which mobile device is the packet being sent to and where is it in the mobile network. I'll give it a shot to show by example. Suppose we have a mobile network. Base stations have addresses in the form 2000:0:0:X:: where X is unique for each base station. UEs are assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. Consider a packet is sent to an address within a mobile node with external address 3000:0:0:123:0:0:0:1. Assume the device is attached to base station with address 2000:0:0:567::. In identifier/locator the top sixty-four bits of address are overwritten with the locator for forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet will reach the correct base station, but we've lost the address information for the device so the base station has no way to forward it on. Alternatively, assume the identifier is composed of a 32 bit device identifier and 32 bits delegated to UE. Now UEs are assigned /32 in the form 3000:0:0:0:0:Z::/32. Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty four bits are overwritten with a locator so the destination on the wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, and it can now be forwarded to the correct device that is identified by the 0:123 device identifier in the address. Hope that helps! Tom > > Yours, > Joel > > > On 6/6/17 11:54 AM, Tom Herbert wrote: >> >> Both RFC7421 and RFC7136 state that a motivation for the /64 is >> identfier/locator split addressing (like in ILNP). The motivation is >> valid, however assigning a /64 to UEs in a mobile network is not >> compatible with identifier/locator split. The reason is that the link >> of interest for IIDs is not inside the UE, but is logically in the >> network. The identifier in a mobile network needs to identify the >> device. >> >> In identifier/locator split, the IP address is split into a locator >> and identifier. Each are 64 bits (although Brian did point out that >> that could also be a parameter). Just like IIDs, identifiers must be >> unique within the subnet. In the case of a mobile network the link is >> an overlay network that is not physical, but none the less it is a >> type of link. >> So the properties of it being a link including those for IIDs on the >> link hold-- this make identifiers equivalent to IIDs by definition. >> >> The IPv6 address for identifier/locator split looks like: >> >> M bits for locator >> N bits for device identifier >> 128 - M - N bits for addresses within the device >> >> M is 64, and it seems straightforward to make N be 32 so we get >> >> 64 bits for locator >> 32 bits for device identifier >> 32 bits for addresses within the device >> >> Which implies /96 assignment to each UE. >> >> Thus the IID is constructed from a 32 bit number assigned to the >> device, and a 32 bit number assigned by the device. If assignments for >> both of these are randomized this provides 64 bits of entropy for >> security. >> >> Tom >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From nobody Tue Jun 6 11:55:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2838126CB6 for ; Tue, 6 Jun 2017 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyfcZ2NhRRUz for ; Tue, 6 Jun 2017 11:55:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 0DC7C1252BA for <6man@ietf.org>; Tue, 6 Jun 2017 11:55:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DE87A5E046B; Tue, 6 Jun 2017 11:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496775311; bh=A8pKPRqCyZ+36qcw2VhrRS2Pyq8svOTPOsM1zyP2o7o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qxfoCXM2fhz8vqJ2IBd0nSQKt2YTpapL3eORkxxu1dAv0KSqLD+yG0wibVBHk+R9X OQufgvHRTCYdU15Bn74nObnjochi0sd9JLMP9vi8EDNBbsUrDGb0QjYJhiemr2KLMs 2oQEjCwaypo/9+oiiuEttScI96ysRwOUJevI6Opo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 640641C02AF; Tue, 6 Jun 2017 11:55:10 -0700 (PDT) Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert Cc: 6man@ietf.org References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> Date: Tue, 6 Jun 2017 14:55:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 18:55:14 -0000 I have several problems with your description. 1) The address of the Base Station for purposes of communciating with the base station is irrelevant. 2) More importantly, in ILNP, the upper 64 bits are not "over-written". Rather, the sender fills in the correct 64 bits that will route the traffic to the right place to reach the UE. Thus, the modile operator can allocate the structure of the locators (within their allocated IPv6 address block) so as to enable the use of effective and scalable IP routing to reach the UE without over-writing anything. I presume it is accidental, but your description of ILNP does not match the RFCs, including the ones that discuss mobility and data center handling. Yours, Joel On 6/6/17 1:33 PM, Tom Herbert wrote: > Hi Joel, > > On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern wrote: >> Tom, I do not follow your reasoning at all. >> I can not tell what you mean by "addressing within the device". > > Referring to the prefix delegated to the device. > >> Even in a data center, one might choose to treat the hypervisor as part of >> the network, and allocate a prefix to the hypervisor so it can assign a /64 >> locator to each device. Or you could assign separate /64s to each entitiy >> within the device from the network directly. Neither requires changing the >> IID space. >> > Right, we're not changing the IID space here. We're specifying which > link (subnet) is the IID space relative to. > >> For something that is a single device, like a UE< it is even simpler to >> allow the network to directly assign as many /64 as the device needs. >> >> Note that if the UE is serving as a router for other devices, then >> 1) that is not routing within the device >> 2) the space is likely small enough that routing on the full /128s works >> just fine >> >> You have made this assertion a couple of times now, and I can not figure out >> why you consider the change necessary. ILNP can work fine for mobile >> network UE. > > It doesn't work if the UE is assigned a /64, that's my point. The > device is the mobile node that needs to be reflected in the identifier > and then the mapping in the network is mobile device (device > identifier) to locator. The locator is the address of an attachment > point (e.g. base station) in the network. The addresses covered by the > prefix assigned to the device is not relevant in mobility since the > whole prefix follows the device. So what we're really interested in is > which mobile device is the packet being sent to and where is it in the > mobile network. > > I'll give it a shot to show by example. > > Suppose we have a mobile network. Base stations have addresses in the > form 2000:0:0:X:: where X is unique for each base station. UEs are > assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. > > Consider a packet is sent to an address within a mobile node with > external address 3000:0:0:123:0:0:0:1. Assume the device is attached > to base station with address 2000:0:0:567::. In identifier/locator the > top sixty-four bits of address are overwritten with the locator for > forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet > will reach the correct base station, but we've lost the address > information for the device so the base station has no way to forward > it on. > > Alternatively, assume the identifier is composed of a 32 bit device > identifier and 32 bits delegated to UE. Now UEs are assigned /32 in > the form 3000:0:0:0:0:Z::/32. > > Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty > four bits are overwritten with a locator so the destination on the > wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, > and it can now be forwarded to the correct device that is identified > by the 0:123 device identifier in the address. > > Hope that helps! > > Tom > > > >> >> Yours, >> Joel >> >> >> On 6/6/17 11:54 AM, Tom Herbert wrote: >>> >>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>> identfier/locator split addressing (like in ILNP). The motivation is >>> valid, however assigning a /64 to UEs in a mobile network is not >>> compatible with identifier/locator split. The reason is that the link >>> of interest for IIDs is not inside the UE, but is logically in the >>> network. The identifier in a mobile network needs to identify the >>> device. >>> >>> In identifier/locator split, the IP address is split into a locator >>> and identifier. Each are 64 bits (although Brian did point out that >>> that could also be a parameter). Just like IIDs, identifiers must be >>> unique within the subnet. In the case of a mobile network the link is >>> an overlay network that is not physical, but none the less it is a >>> type of link. >>> So the properties of it being a link including those for IIDs on the >>> link hold-- this make identifiers equivalent to IIDs by definition. >>> >>> The IPv6 address for identifier/locator split looks like: >>> >>> M bits for locator >>> N bits for device identifier >>> 128 - M - N bits for addresses within the device >>> >>> M is 64, and it seems straightforward to make N be 32 so we get >>> >>> 64 bits for locator >>> 32 bits for device identifier >>> 32 bits for addresses within the device >>> >>> Which implies /96 assignment to each UE. >>> >>> Thus the IID is constructed from a 32 bit number assigned to the >>> device, and a 32 bit number assigned by the device. If assignments for >>> both of these are randomized this provides 64 bits of entropy for >>> security. >>> >>> Tom >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> From nobody Tue Jun 6 12:05:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD1B1275AB for ; Tue, 6 Jun 2017 12:05:43 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkm2L1CyL115 for ; Tue, 6 Jun 2017 12:05:42 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B50C127241 for ; Tue, 6 Jun 2017 12:05:42 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id a70so30531394pge.3 for ; Tue, 06 Jun 2017 12:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N9KwQhwgsburgBVAY5Q6CSE7kqs5Vw29POU1+AZHZc0=; b=JJi7F9i7EEDkANQrVSdMf3kiF4o3Lu0cZHiT7OEbcyR6p0yUCjIjG4YVa+qwik9ano KRYlUXiuwkamHsXAmHGYytyxCRZGzAHCe6mLB0iWhEhPGIxw/3Bn3lgEVLkcR1Ougmj+ VEsR2+F4UUOQDuelrIpmnNLDoxpBSO6kI0SJawpiCTW+TNL+PCZny0yBFtQRK+c8ySQu nCneSL0xJaRJbN89Mk65T3t0MCPlfQKEAhCFDshhn76rq59azck2RLXwSolFPnfA/HzY UYzNIKrSOgNU0ilXFHaBChXi2v+sFpD0/qPNx4LtfY7DB1ccwQKBVxezYQT9loSGTeMi Fb3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N9KwQhwgsburgBVAY5Q6CSE7kqs5Vw29POU1+AZHZc0=; b=YRJqAMS7gMSbriGgmTQyRTdans864VPFqjlIP3GzRGl0nD69e+zIU9f9r40O5puAJN RskLomYusRpdULBJUpAXwqOtkBw3CF0cmhKJO1Xzbj7MIdRbEZ2gsUhJXWqVqE79lV1N aK66TKD2b+5IkL7aEAkeSps6Yi3/LXlDbBYYOg+DQUsjP2WHOHcoVoccSZomfEJXGTB9 Y0uz1xAFBnbkibU8OZQD82aQYRoPMVag6/Z1vwkLdfEfYfNovNHii6B19lpGB2ErSfwR FZQFrSM8qSF1JIy3FYK34LsczcsxDZJgLRXnrM0IR05OPHKrAd5Tci1w8mGaxqJXSo5L ikgA== X-Gm-Message-State: AODbwcCNp+7ARWzeDz4dRr8LjFFw/qZPJz7NPygO6QmgPwrKIBoA6Zvz +ggmdqKlKGmNFh9J X-Received: by 10.99.165.78 with SMTP id r14mr6731396pgu.74.1496775941516; Tue, 06 Jun 2017 12:05:41 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:b852:7159:721:8e69? ([2620:0:10e7:10:b852:7159:721:8e69]) by smtp.gmail.com with ESMTPSA id h15sm65411094pfk.120.2017.06.06.12.05.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 12:05:40 -0700 (PDT) From: james woodyatt Message-Id: <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FE7CC3BE-0D52-463D-8606-1EEE4F486AE3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Tue, 6 Jun 2017 12:06:02 -0700 In-Reply-To: Cc: 6man To: Erik Kline References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:05:43 -0000 --Apple-Mail=_FE7CC3BE-0D52-463D-8606-1EEE4F486AE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 5, 2017, at 20:57, Erik Kline wrote: > On 6 June 2017 at 03:47, james woodyatt > wrote: >=20 > Now is as good a time as any to repeat that I=E2=80=99m working on = delivering *basically* this now. Not in ten years. Now. [=E2=80=A6]We = are already on the path to IPv6/NAT w/ address amplification. We had a = chance to stop it, and we blew it. It=E2=80=99s time to move on from = that mistake. >=20 > Consider ND proxy or application/CoAP proxying. p1. Power conservative ND Proxy isn=E2=80=99t possible with Thread=E2=84=A2= 1.1 (and earlier) networks. It may never be possible in future versions = of Thread=E2=84=A2. p2. Thread=E2=84=A2 is not an application layer. It is an IPv6 mesh = network layer. There is no single application layer to proxy. The war against IPv6/NAT is over. It=E2=80=99s time to go home and nurse = our wounds. --james woodyatt > --Apple-Mail=_FE7CC3BE-0D52-463D-8606-1EEE4F486AE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 5, 2017, at 20:57, Erik Kline <ek@google.com> = wrote:
On 6 = June 2017 at 03:47, james woodyatt <jhw@google.com> wrote:

Now is as good a time as any to = repeat that I=E2=80=99m working on delivering *basically* this now. Not = in ten years. Now. [=E2=80=A6]We are already on the path to IPv6/NAT w/ = address amplification. We had a chance to stop it, and we blew it. = It=E2=80=99s time to move on from that = mistake.

Consider ND proxy or application/CoAP = proxying.

p1. Power conservative ND Proxy isn=E2=80=99t = possible with Thread=E2=84=A2 1.1 (and earlier) networks. It may never = be possible in future versions of Thread=E2=84=A2.

p2. Thread=E2=84=A2 is not an application layer. = It is an IPv6 mesh network layer. There is no single application layer = to proxy.

The war against IPv6/NAT is over. It=E2=80=99s time to go = home and nurse our wounds.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_FE7CC3BE-0D52-463D-8606-1EEE4F486AE3-- From nobody Tue Jun 6 12:06:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF39127241 for ; Tue, 6 Jun 2017 12:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qogpu815itxx for ; Tue, 6 Jun 2017 12:06:09 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 563DB127871 for ; Tue, 6 Jun 2017 12:06:09 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id w1so141410529qtg.2 for ; Tue, 06 Jun 2017 12:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e/CasfB9GAQ4pE/OEWjdzfltbtXqdG+OGB8DjdjpHJg=; b=JRd2a0V4OtADoKjAk7gE4jDouQugaV1oP//uTLXAX0WQebCXjxHLZH2PtdkyjcpjOS WaJ3SogcKSl2i96bPIP3UKWZQqZHDahAcBf2155YewhASuZTXh8yFEPcT2kdcDYCx+FJ eJzlkp+gvrtl6SClGCrZ4Li+I67j2bkDnWpjhOE25UyCa3kkVunMb0PWOiQB8BlEwmbO Mn1H/bXp4RgIKs8CIDM+Z84V5tt3J466KvT7fsgB2j+sQz6yu1mFmHXbXa35POh+eSJ8 qTc8zCohnu1guYw8CUVZrXAD8QLNP6GL1iJYMDYFglRCPu3eEOJLOzRQH1D13sSwTNTs 8wsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e/CasfB9GAQ4pE/OEWjdzfltbtXqdG+OGB8DjdjpHJg=; b=oPbATvwPNTkS24HpOm/6OMsSgdtLWr7OB58cf0kYjpIC402Y7KF5DC7NdLhmHgqDhK Z/uk0t2Yx4rpKFodZDhLHe+PysIuwQ5njaxB+4ExV1dEMNVBji0V/YxoJOMqlsn2AQA/ 53Y+sqwH4Fhn95YiUMpBQXa2A2T9WnlRzA1U+0qNol7eW6fKLkNJuEeovO5G+Fr+qhP3 pz1tyaGMnMJg78MlbtVnWEduxE6vLu1R9ED0MyGcGcBS98dPjfUBtzikDKARyFd3qGzj 4hCsxaplXvCz+RNtdShcAREAF3a7by31isUQ/IBYLF/xqDbbFlrvoYSj6ZhGtPz4evwg lOZw== X-Gm-Message-State: AODbwcD9hyUgEk8FjR4TRP0gEmzGoaEN6YIL0mh3Bwl3ZrYlbuFpERWg GFHz236Q+/XJ8rft8ZRNMGXJs5kOa37SdKU= X-Received: by 10.237.47.228 with SMTP id m91mr3165271qtd.86.1496775968024; Tue, 06 Jun 2017 12:06:08 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Tue, 6 Jun 2017 12:06:07 -0700 (PDT) In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 6 Jun 2017 12:06:07 -0700 X-Google-Sender-Auth: Z2XqR-XUTuTBbPQdlebW--ct0Bo Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: IPv6 IPv6 List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:06:11 -0000 At Fri, 2 Jun 2017 16:11:12 +0200, Job Snijders wrote: > Please review the below. I've read draft-bourbaki-6man-classless-ipv6-00. First, I have some high level comments: - it's not clear to me exactly what this draft tries to propose. Brian (a coauthor) seems to indicate it just makes the length of interface identifiers dependent only on IPv6-over-foo specifications (and not on the addressing architecture spec). But, as I commented earlier the draft text reads to me as if it proposes more: the length of IID is now completely variable and subject to operator's choice (whether we have a "default length" or whether such a default is 64 is a different topic). When the intent of the draft is so unclear, and perhaps the intent even among coauthors is not consistent, it's nearly impossible to even understand the draft accurately, let alone say support or non-support. - somewhat related to the first bullet, this draft seems to be confused about the point I tried to clarify in my own individual draft, draft-jinmei-6man-prefix-clarify-00, even if it's referenced from this draft: The draft (perhaps unintentionally) conflates "on-link prefixes" and "(SLAAC) subnet prefixes". Depending on which kind of prefix it talks about, the draft could actually update an existing standard or be a mere clarification. For example, in Section 1 it states: [...] While link prefixes of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been successfully deployed for many years, glaring mismatches between a formal specification and long-standing field deployment practices are never wise, [...] This "link prefixes" is more likely to refer to on-link prefixes. But in that sense there's no "mismatch" between the specification and the deployment: on-link prefix length has already, and always been variable (but I know it's confusing, and that's one main reason why I wrote my own draft). (As a minor note, I realize the concept of on-link prefixes used in my draft exclusively focuses on prefixes in RA PIOs. But it's straightforward to extend the concept to manual configuration, and I believe even those who prefer keeping the /64 magic number for certain SLAAC subnet prefixes agree that on-link prefix length is already variable and it also applies to manual configuration). On the other hand, the 2nd and 3rd paragraphs of Section 4 clearly mean SLAAC subnet prefixes (by talking about interface identifiers). As I tried to explain in my draft, these two are independent. It's very confusing to see an introduction to topics about on-link prefixes and then recommendations about SLAAC subnet prefixes. So, I'd first like to request this draft be much more clearer on what it proposes. And, if it helps in doing so, be clearer on the difference between on-link and SLAAC subnet prefixes. If the proposal is only about one of them, just don't talk about the other, since discussing both would just increase confusion and introduce unnecessary controversy; if the proposal covers both types of prefixes, make sure which type of prefixes is intended in each specific context. And so it may be premature to talk about specific content of the draft, but I'll provide some comments on the current version of text anyway. - Section 1: the discussion in this section is confusing, misleading, and/or irrelevant. See the high-level comment above. - Section 2 [...] Therefore their length, previously fixed at 64 bits [RFC7136], [...] I don't think RFC7136 fixes "their (= interface IDs') length". At the very least fixing it doesn't seem to be the main goal of the RFC. If it intends to refer to a particular part of the RFC that I'm missing, it's better to include a specific section number. - Section 2 [...] Therefore their length, [...], is in fact a variably-sized parameter as explicitly acknowledged in Section 5.5.3(d) of [RFC4862] This sentence itself is true, but I suspect it's misleading in the context (i.e., stating this after referring to RFC7217/8064). What RFC4862 acknowledges is that the length of IID is a parameter of the link, but RFC7217 is actually a technique quite independent from specific link type. If this paragraph tries to say that now that we have the technique of RFC7217 and recommendation of RFC8064, IID length won't have to be a parameter of link type (and therefore not necessarily be 64 for Ethernet, for example), then I see it's worth discussing. But that's a new update to existing standards, not what RFC4862 is currently acknowledging. - Section 3 IPv6 unicast interfaces may use any subnet length up to 128 except for situations where an Internet Standard document may impose a particular length, for example Stateless Address Autoconfiguration (SLAAC) [RFC4862], [...]. RFC4862 does not (directly) impose a particular IID length. It just says the length is a parameter of the link type. If anything, what imposes a particular length is specific IPv6-over-foo specs, such as RFC2464. - Section 4 For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136]. This "prefix" is ambiguous. Please clarify whether it's an on-link prefix or SLAAC subnet prefix. Also, I don't think RFC7136 makes such a recommendation. At least such a recommendation is not the main topic of the RFC (see another bullet on Section 2 above). And, perhaps related to the second point, it's not clear to me whether this sentence tries to introduce a new recommendation or just intends to refer to an existing recommendation in other RFC(s). - Section 4 Nonetheless, there is no reason in theory why an IPv6 node should not operate with different interface identfier lengths on different physical interfaces. Thus, a correct implementation of SLAAC must in fact allow for any prefix length, with the value being a parameter per interface. This reads to me like an update to RFC4862. In RFC4862, the length of IID (which derives SLAAC subnet prefix length) is a parameter of link type, not of an individual interface. If this text intends to make an update to RFC4862, that's find as a proposal, but it should more explicitly say so. Also it should add RFC4862 to the "Update:" field of the draft header. - Section 5 This section is another place where this draft conflates on-link and SLAAC subnet prefixes: The first paragraph is mainly related to SLAAC subnet prefixes, while the second paragraph is about on-link prefixes. It's misleading to discuss these this way using the same "subnet" term, or one of them can be totally irrelevant depending on the actual intent of this draft's proposal (see the high level comment above). I actually see there's a subtle relationship between these two topics, however, since both prefixes are often the same in practice. But, if the draft really needs to talk about the subtlety it should do so more carefully (if one of the issues is irrelevant it's much simpler and less confusing to just omit it). -- JINMEI, Tatuya From nobody Tue Jun 6 12:21:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58A2128A32 for ; Tue, 6 Jun 2017 12:21:46 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGOb0S7-Zgom for ; Tue, 6 Jun 2017 12:21:45 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 409511242EA for ; Tue, 6 Jun 2017 12:21:45 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id a70so30652705pge.3 for ; Tue, 06 Jun 2017 12:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=JI8MsKw2FsfhjR7sRn71PR+0+e3WPOmIoO36PdIZV+I=; b=bnmB/MTiwumN3PahJVKl2SjRUgWva3P007UPuBrEleI32nUoAOdvuc7645J2jhiEI4 SXkLU5zALVLQiDiiCrskvSi5Ma5vnrYZYTt/d2gb4mSg0eonrH+Sw493/nC+viLhb7cp +yvc5UL8Th7rViI/wLpI9bGsRz2FIzt6eYGsysKacLuhxLut53XzBtdx9fPMU4IIlMYW wm6kCOHJuosZ2AEm/UoIccCtxo4hHtGlqotTj/hxHl3UNLwnmWpn9b9McJS3AFNvEpAb uZt5BU3XJK+O3KYbu9V1a4sKYnZzRJrw+xDO1i1/JwtBk1Tzz2eVcOyZDVlqM1oZIHfI KDhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=JI8MsKw2FsfhjR7sRn71PR+0+e3WPOmIoO36PdIZV+I=; b=O8swE8ToZPMMNjaA467QyRrhvP76hemaB0T57YCfqHoqSt5IQX7nF0gTYwkN3wSrIv Dwjnp+h8uWMVudc2IPxC6730+89RM81uqEV+jetL14NbKQS3TbvWUr+HUlkYa90V7Oyf CD2DBr6Uu4TdELwTP4U/CShAul4rXLtcup+VjQZR3ujvYz8gpvM6Dq7VtCJvuYxLG8yN mT9EZXpyKrPObvtSAHbFaR/4WkEICCLGFBI0uHNTidy0mzaI5iCwUgU/NMy3ZsKLHUD3 QgqXjNhixmKx8vm89D4ZBeqQEp6ySLI3daJfbPTgR8g9MUZR7R7pR/R4lJFSYML7eUEP DKGA== X-Gm-Message-State: AODbwcCstCXCJP60lFWwATvb5+byuG1rlUKTPmPSCV3LU20+/g5ViNkK eccp8QKzAYdAZE96spRrLg== X-Received: by 10.98.30.129 with SMTP id e123mr27801589pfe.240.1496776904542; Tue, 06 Jun 2017 12:21:44 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:b852:7159:721:8e69? ([2620:0:10e7:10:b852:7159:721:8e69]) by smtp.gmail.com with ESMTPSA id x30sm41344597pge.23.2017.06.06.12.21.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 12:21:43 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_12E05A0E-E020-45C8-9870-C9A5CBAC9190" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Tue, 6 Jun 2017 12:22:05 -0700 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> To: IPv6 IPv6 List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:21:47 -0000 --Apple-Mail=_12E05A0E-E020-45C8-9870-C9A5CBAC9190 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 6, 2017, at 12:06, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > ...be clearer on the difference between on-link and SLAAC subnet = prefixes. ... I=E2=80=99m with Mr. Jinmei on this point. I really can=E2=80=99t make = any sense of this draft because of how badly it conflates these two = different concepts. I may find what the draft really proposes to do = completely harmless. I may not. I can=E2=80=99t tell at this point. --james woodyatt > --Apple-Mail=_12E05A0E-E020-45C8-9870-C9A5CBAC9190 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 6, 2017, at 12:06, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = <jinmei@wide.ad.jp> wrote:

...be clearer on the difference between = on-link and SLAAC subnet prefixes. = ...

I=E2=80=99m with Mr. Jinmei on this = point. I really can=E2=80=99t make any sense of this draft because of = how badly it conflates these two different concepts. I may find what the = draft really proposes to do completely harmless. I may not. I can=E2=80=99= t tell at this point.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_12E05A0E-E020-45C8-9870-C9A5CBAC9190-- From nobody Tue Jun 6 13:05:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09C12009C for ; Tue, 6 Jun 2017 13:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg5LaEKyibbe for ; Tue, 6 Jun 2017 13:05:26 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A661205F0 for <6man@ietf.org>; Tue, 6 Jun 2017 13:05:25 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id n195so108053265wmg.1 for <6man@ietf.org>; Tue, 06 Jun 2017 13:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y+sDUJ0jvUI8g6JGjpF63n1Jt2TV5fMMV1wVzEDnP6c=; b=R3wR0rk/q8o4snplu/ws2yy2M7I6J4AodR4C7vEK07t7xT9P2kqwB4s9jCLoPlPeCM G12JjbF9b7X9OoXoByyRPxTo2O/X5gMV54R3t6u9Cug3bHasp9HsO8vAwWDDCh3jijnU H0CxFJjwJdotVZ0++V2eDvJJHUZBHzZrpYWW30+1qWL3tJ82/9LbmTu2F297Tn6tHUPb zuCYsfmXCT6uo+NxdVKfXObTYCj38heAdIr5htZ7tqc3Uxre6nrPtFyGxQLZFyzdABDi WtoxqHnoB7eRVNduR13ujOrX989Ohn8QE2XJdnBKBGab5T4X7Bq7QqavpclZTHNLi0rF nveQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y+sDUJ0jvUI8g6JGjpF63n1Jt2TV5fMMV1wVzEDnP6c=; b=sCk7iXVNOpU60tSMFVTAc0TXNaIhBMUIUHs0ee3bHcJCcV+JxOZOhw62KBur8G8Efd 3W6I1KO8w4Bwuma6LeA3kkM0VsSoAcKP9dR8NFl3wC7Uwti/tOQg2lrZ5lpOv9f7VSV2 DhVU9CKBA1BKjyXVA1C3XIINkKTlrHi6Ktn95j5XQG1i2uULhW63WyUg8V8CxM2/APSs /2meC41TuJwFg45SYby8BSLovqM+2TDXzBYCuH/5C20vlD/uAa78vZv4hZYkquZXRXdN KYU++DExSItnAKSCnuP4+4JG8b3jbyDq9N8LqFi6Qta3ASPTAwm4aTA/OHy57O7eElHC j2oQ== X-Gm-Message-State: AODbwcD53pzynReyS7c7TV+T07Lfgat8ZJGGNjvw2S03HkZwWpyERwYt +x7jjcp2GikQ7fCnjKT6aMAQG41Tve2s9MQ= X-Received: by 10.28.87.72 with SMTP id l69mr11995201wmb.111.1496779524017; Tue, 06 Jun 2017 13:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 13:05:23 -0700 (PDT) In-Reply-To: <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> From: Tom Herbert Date: Tue, 6 Jun 2017 13:05:23 -0700 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: "Joel M. Halpern" Cc: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:05:28 -0000 On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern wrote: > I have several problems with your description. > 1) The address of the Base Station for purposes of communciating with the > base station is irrelevant. > 2) More importantly, in ILNP, the upper 64 bits are not "over-written". > Rather, the sender fills in the correct 64 bits that will route the traffic > to the right place to reach the UE. Thus, the modile operator can allocate > the structure of the locators (within their allocated IPv6 address block) so > as to enable the use of effective and scalable IP routing to reach the UE > without over-writing anything. Can you provide concrete end to end example for this similar to mine. That is how an external host can reach an address in a UE that is moving around in a mobile network. > I presume it is accidental, but your description of ILNP does not match the > RFCs, including the ones that discuss mobility and data center handling. > I didn't say this was specifically ILNP. The description is consistent with ILA. Thanks, Tom > Yours, > Joel > > > On 6/6/17 1:33 PM, Tom Herbert wrote: >> >> Hi Joel, >> >> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >> wrote: >>> >>> Tom, I do not follow your reasoning at all. >>> I can not tell what you mean by "addressing within the device". >> >> >> Referring to the prefix delegated to the device. >> >>> Even in a data center, one might choose to treat the hypervisor as part >>> of >>> the network, and allocate a prefix to the hypervisor so it can assign a >>> /64 >>> locator to each device. Or you could assign separate /64s to each >>> entitiy >>> within the device from the network directly. Neither requires changing >>> the >>> IID space. >>> >> Right, we're not changing the IID space here. We're specifying which >> link (subnet) is the IID space relative to. >> >>> For something that is a single device, like a UE< it is even simpler to >>> allow the network to directly assign as many /64 as the device needs. >>> >>> Note that if the UE is serving as a router for other devices, then >>> 1) that is not routing within the device >>> 2) the space is likely small enough that routing on the full /128s works >>> just fine >>> >>> You have made this assertion a couple of times now, and I can not figure >>> out >>> why you consider the change necessary. ILNP can work fine for mobile >>> network UE. >> >> >> It doesn't work if the UE is assigned a /64, that's my point. The >> device is the mobile node that needs to be reflected in the identifier >> and then the mapping in the network is mobile device (device >> identifier) to locator. The locator is the address of an attachment >> point (e.g. base station) in the network. The addresses covered by the >> prefix assigned to the device is not relevant in mobility since the >> whole prefix follows the device. So what we're really interested in is >> which mobile device is the packet being sent to and where is it in the >> mobile network. >> >> I'll give it a shot to show by example. >> >> Suppose we have a mobile network. Base stations have addresses in the >> form 2000:0:0:X:: where X is unique for each base station. UEs are >> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >> >> Consider a packet is sent to an address within a mobile node with >> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >> to base station with address 2000:0:0:567::. In identifier/locator the >> top sixty-four bits of address are overwritten with the locator for >> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet >> will reach the correct base station, but we've lost the address >> information for the device so the base station has no way to forward >> it on. >> >> Alternatively, assume the identifier is composed of a 32 bit device >> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >> the form 3000:0:0:0:0:Z::/32. >> >> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty >> four bits are overwritten with a locator so the destination on the >> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >> and it can now be forwarded to the correct device that is identified >> by the 0:123 device identifier in the address. >> >> Hope that helps! >> >> Tom >> >> >> >>> >>> Yours, >>> Joel >>> >>> >>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>> >>>> >>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>> identfier/locator split addressing (like in ILNP). The motivation is >>>> valid, however assigning a /64 to UEs in a mobile network is not >>>> compatible with identifier/locator split. The reason is that the link >>>> of interest for IIDs is not inside the UE, but is logically in the >>>> network. The identifier in a mobile network needs to identify the >>>> device. >>>> >>>> In identifier/locator split, the IP address is split into a locator >>>> and identifier. Each are 64 bits (although Brian did point out that >>>> that could also be a parameter). Just like IIDs, identifiers must be >>>> unique within the subnet. In the case of a mobile network the link is >>>> an overlay network that is not physical, but none the less it is a >>>> type of link. >>>> So the properties of it being a link including those for IIDs on the >>>> link hold-- this make identifiers equivalent to IIDs by definition. >>>> >>>> The IPv6 address for identifier/locator split looks like: >>>> >>>> M bits for locator >>>> N bits for device identifier >>>> 128 - M - N bits for addresses within the device >>>> >>>> M is 64, and it seems straightforward to make N be 32 so we get >>>> >>>> 64 bits for locator >>>> 32 bits for device identifier >>>> 32 bits for addresses within the device >>>> >>>> Which implies /96 assignment to each UE. >>>> >>>> Thus the IID is constructed from a 32 bit number assigned to the >>>> device, and a 32 bit number assigned by the device. If assignments for >>>> both of these are randomized this provides 64 bits of entropy for >>>> security. >>>> >>>> Tom >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> > From nobody Tue Jun 6 13:27:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C670712762F for ; Tue, 6 Jun 2017 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGe0RrRxU2-B for ; Tue, 6 Jun 2017 13:27:46 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9254C12009C for ; Tue, 6 Jun 2017 13:27:46 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id f185so38164011pgc.0 for ; Tue, 06 Jun 2017 13:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hPZCZkE2r/3KEIOxZ6YBcTwRHrW1lPSXmQVZtwnAWqY=; b=Wea+DaxZMXRxXDWjj/srq7ntk3djPbB0c17y5mGAZj4h76hYi0wW3hVqAY29VLP/DQ e6R9SpcyXxOFR1/tQc2pKT7DyLaY6CiX5svYR0OSdS3reE2rv4hLIEBjFTscz2jOWntF /nwbGfpnJvSZCfjn/iRtcamlyOFrFtI8cGBq8xsT5FWrOk1SwKNKs5Hh4nFa2KmuVOlz mSlQeZWaawWsz+s1mXSlUuCuxKPbrE1FVDGRZkHbLf2wWOSOdKdO9cjUN+tnYki9ZHr7 4WReiOBu+E56RivXU8/J25OQpkFihb8y6vtqjKuexIZ7dggo5E5IDfdGzfW7azshzCkb 5AMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hPZCZkE2r/3KEIOxZ6YBcTwRHrW1lPSXmQVZtwnAWqY=; b=VPTjmZxPIw22jTP/XcFEk3Hv7wZ6Td2hSeSam0SkfdKsqBJaRFZMBWeNesjiCaMreo pptOFL+5XhV354jyGiDbLA6Ge0zGD3N4VRFh3Bc3XeO40jPo5LglXYFMsAJ8SM8StUJi wLVKYw1iyMX7w3z6/VJvlT1MmRIJ8SZsLH1jmNZe60Vu2P3tMn9ccVWvgRUEt10VbKJu PvJNe3dfSIDmuDTcSHiGEktohleUYS3oly/Qg44YGRCc9TPPY/e00Ad7rKFaDI3rqBMU GjAcXDI7LaGyWGZqxIzntav3TB/7lhS2E9DfnrCqnoyRRuuIcUI2l9oBYU2wSE5Obrqs Q/DQ== X-Gm-Message-State: AODbwcBAV2uIkcxosaWBm7oJvfK7iJ57x5c/OdpuPcqJDbXBJntLsH8h O+4An4kdDmqNUhFB+pU= X-Received: by 10.98.83.132 with SMTP id h126mr27846511pfb.214.1496780865831; Tue, 06 Jun 2017 13:27:45 -0700 (PDT) Received: from ?IPv6:2406:e007:40bc:1:28cc:dc4c:9703:6781? ([2406:e007:40bc:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 69sm21234158pft.41.2017.06.06.13.27.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 13:27:45 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 7 Jun 2017 08:27:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:27:51 -0000 Jinmei-san, Thanks for those careful comments. Can I just ask one question to be sure I understand: > The draft (perhaps unintentionally) conflates > "on-link prefixes" and "(SLAAC) subnet prefixes". Am I correct in thinking that this distinction *only* applies when SLAAC is in use? If the nodes on a link (including a point-to-point) are configured without use of SLAAC, surely there is only a "prefix", without distinction. Regards Brian Carpenter On 07/06/2017 07:06, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Fri, 2 Jun 2017 16:11:12 +0200, > Job Snijders wrote: >=20 >> Please review the below. >=20 > I've read draft-bourbaki-6man-classless-ipv6-00. >=20 > First, I have some high level comments: >=20 > - it's not clear to me exactly what this draft tries to propose. > Brian (a coauthor) seems to indicate it just makes the length of > interface identifiers dependent only on IPv6-over-foo specifications > (and not on the addressing architecture spec). But, as I commented > earlier the draft text reads to me as if it proposes more: the > length of IID is now completely variable and subject to operator's > choice (whether we have a "default length" or whether such a default > is 64 is a different topic). When the intent of the draft is so > unclear, and perhaps the intent even among coauthors is not > consistent, it's nearly impossible to even understand the draft > accurately, let alone say support or non-support. >=20 > - somewhat related to the first bullet, this draft seems to be > confused about the point I tried to clarify in my own individual > draft, draft-jinmei-6man-prefix-clarify-00, even if it's referenced > from this draft: The draft (perhaps unintentionally) conflates > "on-link prefixes" and "(SLAAC) subnet prefixes". Depending on > which kind of prefix it talks about, the draft could actually update > an existing standard or be a mere clarification. For example, in > Section 1 it states: >=20 > [...] While link prefixes > of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been > successfully deployed for many years, glaring mismatches between a > formal specification and long-standing field deployment practices ar= e > never wise, [...] >=20 > This "link prefixes" is more likely to refer to on-link prefixes. > But in that sense there's no "mismatch" between the specification > and the deployment: on-link prefix length has already, and always > been variable (but I know it's confusing, and that's one main reason > why I wrote my own draft). (As a minor note, I realize the concept > of on-link prefixes used in my draft exclusively focuses on prefixes > in RA PIOs. But it's straightforward to extend the concept to > manual configuration, and I believe even those who prefer keeping > the /64 magic number for certain SLAAC subnet prefixes agree that > on-link prefix length is already variable and it also applies to > manual configuration). >=20 > On the other hand, the 2nd and 3rd paragraphs of Section 4 clearly > mean SLAAC subnet prefixes (by talking about interface identifiers). > As I tried to explain in my draft, these two are independent. It's > very confusing to see an introduction to topics about on-link > prefixes and then recommendations about SLAAC subnet prefixes. >=20 > So, I'd first like to request this draft be much more clearer on what > it proposes. And, if it helps in doing so, be clearer on the > difference between on-link and SLAAC subnet prefixes. If the proposal > is only about one of them, just don't talk about the other, since > discussing both would just increase confusion and introduce > unnecessary controversy; if the proposal covers both types of > prefixes, make sure which type of prefixes is intended in each > specific context. >=20 > And so it may be premature to talk about specific content of the > draft, but I'll provide some comments on the current version of text > anyway. >=20 > - Section 1: the discussion in this section is confusing, misleading, > and/or irrelevant. See the high-level comment above. >=20 > - Section 2 >=20 > [...] Therefore their length, previously fixed > at 64 bits [RFC7136], [...] >=20 > I don't think RFC7136 fixes "their (=3D interface IDs') length". At > the very least fixing it doesn't seem to be the main goal of the > RFC. If it intends to refer to a particular part of the RFC that > I'm missing, it's better to include a specific section number. >=20 > - Section 2 >=20 > [...] Therefore their length, [...], > is in fact a variably-sized parameter as > explicitly acknowledged in Section 5.5.3(d) of [RFC4862] >=20 > This sentence itself is true, but I suspect it's misleading in the > context (i.e., stating this after referring to RFC7217/8064). What > RFC4862 acknowledges is that the length of IID is a parameter of the > link, but RFC7217 is actually a technique quite independent from > specific link type. If this paragraph tries to say that now that we > have the technique of RFC7217 and recommendation of RFC8064, IID > length won't have to be a parameter of link type (and therefore not > necessarily be 64 for Ethernet, for example), then I see it's worth > discussing. But that's a new update to existing standards, not what > RFC4862 is currently acknowledging. >=20 > - Section 3 >=20 > IPv6 unicast interfaces may use any subnet length up to 128 except > for situations where an Internet Standard document may impose a > particular length, for example Stateless Address Autoconfiguration > (SLAAC) [RFC4862], [...]. >=20 > RFC4862 does not (directly) impose a particular IID length. It just > says the length is a parameter of the link type. If anything, what > imposes a particular length is specific IPv6-over-foo specs, such as > RFC2464. >=20 > - Section 4 >=20 > For historical reasons, when a prefix is needed on a link, barring > other considerations, a /64 is recommended [RFC7136]. >=20 > This "prefix" is ambiguous. Please clarify whether it's an on-link > prefix or SLAAC subnet prefix. >=20 > Also, I don't think RFC7136 makes such a recommendation. At least > such a recommendation is not the main topic of the RFC (see another > bullet on Section 2 above). >=20 > And, perhaps related to the second point, it's not clear to me > whether this sentence tries to introduce a new recommendation or > just intends to refer to an existing recommendation in other RFC(s). >=20 > - Section 4 >=20 > Nonetheless, there is no reason in theory why an IPv6 node should no= t > operate with different interface identfier lengths on different > physical interfaces. Thus, a correct implementation of SLAAC must i= n > fact allow for any prefix length, with the value being a parameter > per interface. >=20 > This reads to me like an update to RFC4862. In RFC4862, the length > of IID (which derives SLAAC subnet prefix length) is a parameter of > link type, not of an individual interface. If this text intends to > make an update to RFC4862, that's find as a proposal, but it should > more explicitly say so. Also it should add RFC4862 to the "Update:" > field of the draft header. >=20 > - Section 5 >=20 > This section is another place where this draft conflates on-link and > SLAAC subnet prefixes: The first paragraph is mainly related to SLAAC= > subnet prefixes, while the second paragraph is about on-link > prefixes. It's misleading to discuss these this way using the same > "subnet" term, or one of them can be totally irrelevant depending on > the actual intent of this draft's proposal (see the high level > comment above). I actually see there's a subtle relationship > between these two topics, however, since both prefixes are often the > same in practice. But, if the draft really needs to talk about the > subtlety it should do so more carefully (if one of the issues is > irrelevant it's much simpler and less confusing to just omit it). >=20 > -- > JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Jun 6 13:34:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFD912762F for ; Tue, 6 Jun 2017 13:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u30llQgy9PVI for ; Tue, 6 Jun 2017 13:34:02 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468BA12009C for ; Tue, 6 Jun 2017 13:34:02 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id x63so3628073pff.3 for ; Tue, 06 Jun 2017 13:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PmQgivvXYENHyoyMBe7j/aA/mkZWM6hixQDhisIrfnY=; b=AYQHSxgcDrE6J3BAntas66wS5EQlCiRZy7LNp8EAqqpbMmeiym7QM2dfXMqmB6bzMg F6WQ9IoxWXSbtH9IyJyie6ZpSf5IsjwQDHAodb4EdZ2rvoZ+SDhpLPEFMn4hdemUI3jw 1ldCggxCRgBxhslBsyf9sVikcWnteMgyMcu2gGfBhbVyHna8OFKZ+cfCt3mEIpJ4WoIh I8s/0DmUar9RTep2MLXvOUmsFxIE6b/80ImFjIGgl8pg0khjj+KV6uctSMgEzsYKPDWf J/h1/2g9haHlUJWzyQfbMy7jSb5YPsfj0zP1wFVAzHP0sbT0A9aZMZYZkDze3CDoJ5f9 ufjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=PmQgivvXYENHyoyMBe7j/aA/mkZWM6hixQDhisIrfnY=; b=qivh1mgSlbYfpUuinjxijsWRTViZYN/+WfsucW8p0asxtxmhq0lB1L9vBDpO0h4bLn lSdGv8/Q7Hzxuq6AZsy0CxIQ9KgBzeOOrcjXlDt5P3iCEP5g3FtFMQoYCxnHUgQBaOIV CM6C2RgN+zYSMOiQdQpcGUsXdFhXvpfXk+17iuwHLgxwXREqHD+vQRFeN8y6XkO/Q4vO +QJ5HIPenqtWXjzlqyDlIyi/PA7zZTJXTf+lBP48biWMejCKzmFIpMLSLwqBBH0S1Z2z mrQ4m4ijZ+hfxzx5JU6pz/683hCP0gYvnqXTPDzuARs519Zapl5An8UNF4x0PgPdmoi+ U5fA== X-Gm-Message-State: AODbwcDzpoIo7nOOSozEu5fmmsmuR+hfdB7MdojjF/da6+jLcHd0W0Qr jnGxOHn4VfuUkmx/STI= X-Received: by 10.84.231.194 with SMTP id g2mr23269505pln.44.1496781241677; Tue, 06 Jun 2017 13:34:01 -0700 (PDT) Received: from ?IPv6:2406:e007:40bc:1:28cc:dc4c:9703:6781? ([2406:e007:40bc:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t13sm18950728pfg.122.2017.06.06.13.33.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 13:34:00 -0700 (PDT) Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <441d4cae-b0d6-2a06-4e16-9d0f14e1b814@gmail.com> Date: Wed, 7 Jun 2017 08:34:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:34:04 -0000 On 06/06/2017 16:40, Mark Smith wrote: > On 6 June 2017 at 11:22, Brian E Carpenter wrote: >> On 05/06/2017 21:53, Alexandre Petrescu wrote: ... >> Alexandre, >> >> I think that is what the draft says. Most of the discussion here has not >> been about what the draft says, but about what operators who don't read >> RFCs anyway might or might not do because they don't understand that IPv6 >> isn't IPv4+. > > If the goal of this document is to state that the IPv6 prefix length > and IID size is a parameter, then I think the title is incorrect. The > title would be better and more accurate if it was something like "IPv6 > prefix length (and IID size) is a parameter not a constant". Certainly BCP198 already establishes that IPv6 routing is classless. To that extent I agree with you. But, like it or not, there's another message: SLAAC is not compulsory. ILNP is not compulsory. DHCPv6 is not compulsory. AERO is not compulsory. And so on. So although the main focus is on "/64 is not magic", there is a bit more than that. However, point taken. Brian > > One the title of a document is accurate, I've found it easier to > determine what is in and out of scope for the document. With a title > of "IPv6 prefix length (and IID size) is a parameter not a constant", > I think the topics would at least be and be in this sort of order: > > > * Prefix length and IID size is a parameter > > - text and references describing why and where > > > * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) > > - text and references describing why, mostly a summary and reference to RFC7421 > > > * Possible consequences and considerations when choosing not to use 64 > > - privacy, security and operational implications to end-user hosts and > applications > - privacy, security and operational implications to infrastructure > - a specific consideration is the type and scope of reachability of > the address/prefix e.g., ND cache DoS less likely of a concern for a > ULA /64, because it isn't reachable over the Internet, and local > network users have a vested interest in the network being available > - summaries and refs to appropriate RFCs and sections of such as > RFC7707, RFC7721, RFC7421 section 4. > > > > > Regards, > Mark. > . > From nobody Tue Jun 6 13:38:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B471294C4 for ; Tue, 6 Jun 2017 13:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux3cGaVlBiyE for ; Tue, 6 Jun 2017 13:38:41 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 2E7F812894A for ; Tue, 6 Jun 2017 13:38:41 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id f185so38242613pgc.0 for ; Tue, 06 Jun 2017 13:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SnqEOqW2nEv71eTzVwtvEA8Yd/BfoI/B55UdY5+xzHc=; b=VWW7LVQtRi7eofaC0f4PUKslYZFDs3RKXKSzLx4ls/pBV8ztFtjGyK5N14B7KJtzPz OVwVCJXTd51UWdPFU+PHYAoixS15Qq8V2rgAeOxBPFbNC19OSA9o/R5bDTMBu4qbPiYT 4I431PXnUBTfAsBFcjFehYZl/ZFQ0OHkCkY6n65ag5cVfPMkMtdV3f4D3uhMTmMg1FkT DT2RMNWDy35V8ERgSIqedqc+UCO96X6AGl93aeHyDfzNGNtTQD/+wdaWVYu0/UfEVF3K 4m9H/FqSOLjr9jJjmSsEiOVJ6+7YbMK/M/wwh3iL+ODipqJXvrcOHuDOjmc1I8BD2SfC itcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=SnqEOqW2nEv71eTzVwtvEA8Yd/BfoI/B55UdY5+xzHc=; b=IEsNtPXjIS7+vvMiHmVVYGCINtEe+USsNY2prCI8nGcJsfhxaNxXHlMLch8uofd6mr gazHbvM8Wv6n+EUDMSaydCOHXEIXxsqjJ7Xy3KaGSpZ9Tg3WdLSZMPdeuJn47cKcR4OP 3VpSnRSuN/ls1ET1oOtfM60TJodFs3wU3m0V2hdp1uFNkl99vxCDe4j9fulfTTI20/F5 EZQ2N+m6x5iTcQs2GjqxqoWYdZEv6cQR0v+B6cV0Q2cNWP+mA4Vu5QfQGSz5BWU0CMPQ NIq1x8s+i8zG4RmvO7oMTrsKOINerAlB4MBsAM6rjZ1euVqWVj2kAEx9oThi1Y3GGxF/ MPvg== X-Gm-Message-State: AODbwcCv8haH3Hh8E+EJkdDM9hTIEvffHEFyuENUMPKp8dzzwKKuzfbB Xb5xlG9U2sk9DevnnhM= X-Received: by 10.98.34.8 with SMTP id i8mr15024292pfi.194.1496781520569; Tue, 06 Jun 2017 13:38:40 -0700 (PDT) Received: from ?IPv6:2406:e007:40bc:1:28cc:dc4c:9703:6781? ([2406:e007:40bc:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 69sm20130156pfy.119.2017.06.06.13.38.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 13:38:39 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Erik Kline Cc: 6man References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> Date: Wed, 7 Jun 2017 08:38:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:38:43 -0000 Erik, > The only thing meaningfully affected by removing 64bit IIDs... But that is exactly what the draft does *not* do. Nobody would change a single instruction in existing code as a result of this draft. (I agree with you that some O/S stacks may need fixing, but they already need fixing.) Regards Brian On 06/06/2017 16:26, Erik Kline wrote: > On 6 June 2017 at 07:25, Brian E Carpenter > wrote: > >> On 05/06/2017 19:45, Lorenzo Colitti wrote: >>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> None of that is the point. The point is to establish >>>> that routing is classless >>> >>> >>> Routing is already classless because BCP 198. >>> >>> >>>> and /64 is a parameter of specific addressing schemes. >>>> >>> >>> It *is* a parameter. The parameter's value is 64 for all unicast >> addresses >>> except those starting with 000. >> >> The parameter's *current* value, yes. But should we really be fixing >> the value of the parameter once and for all in the addressing architecture? >> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >> assumes? >> > > Because I doubt there is any good argument about things specific to the Foo > layer for having something shorter than a 64 when 64 gets you many so nice > guarantees for randomness, security and non-collision. > > This document does not include a problem statement -- it doesn't say what > problem exists that need solving. > > If all this is about being able to execute the OS-specific equivalent of > "ifconfig eth0 add 2001:db8::1/123" then I think that should absolutely > work fine. We should file bugs to get OS tools to understand what this > actually means. > > That, however, is completely orthogonal to 64bit IIDs. The 64bit boundary > pretty much only has meaning in a SLAAC context. Not doing SLAAC? 64bit > IIDs don't really affect to you then. If OS's make assumptions that there > must be some 2001:db8::/64 route when in fact 2001:db8::1/123 was specified > then that's an obvious error. IMHO, if /n isn't specified: use n=64 and if > /n is specified then use /n. Seems simple enough. You can put a /123 PIO > in an RA so why not on a command line. > > This document however burns down the whole house for the sake of lighting a > candle that was in fact already lit. > > The only thing meaningfully affected by removing 64bit IIDs is removal of > the last backstop that ensures network operators and users alike share -- > however unequally -- the benefits of IPv6 and it permanently demotes IPv6 > to little more than 128bit IPv4 with quaint, warty rules about fragments > and extension headers. > From nobody Tue Jun 6 13:44:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BB7129537 for ; Tue, 6 Jun 2017 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI0lGTShoKIR for ; Tue, 6 Jun 2017 13:44:25 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 8CA6A128CDB for <6man@ietf.org>; Tue, 6 Jun 2017 13:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 724781C003B; Tue, 6 Jun 2017 13:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496781865; bh=db7bPPEvaAcaO6ZufkkHTCU09gGDLYgltjRLpPLPI7s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JSRvtl0mmKJxG8WaendQr1burTUSpNFil1K/jPKd8vJFStPwgxXqfakKd6XgWN6bN OUFJ6YVXEHurh6HV2v+EwzFVzhS2htxC1HVJnKVp+km9tg5A4kcOyTqCAJVeCq+7MM V9bGEObV7RvbHqA2GrhbprvFWGsbFopfmjRQBLT0= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A45645E048D; Tue, 6 Jun 2017 13:44:24 -0700 (PDT) Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert Cc: 6man@ietf.org References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> Date: Tue, 6 Jun 2017 16:44:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:44:28 -0000 If what you are now saying Tom is that ILA would work better with a different address arrangement, I guess you would know better than I. From what I had seen, it seemed likely that if ILA will work for mobiles at all, it will work with the current /64 boundary. But your invention, your judgment. As for ILNP, if you want to understand how it works, in general, for data centers, or for mobility, I suggest reading the RFCs. Any paraphrase I provided in a short email would probably be a disservice both to ILNP and to the members of this list. Yours, Joel On 6/6/17 4:05 PM, Tom Herbert wrote: > On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern wrote: >> I have several problems with your description. >> 1) The address of the Base Station for purposes of communciating with the >> base station is irrelevant. >> 2) More importantly, in ILNP, the upper 64 bits are not "over-written". >> Rather, the sender fills in the correct 64 bits that will route the traffic >> to the right place to reach the UE. Thus, the modile operator can allocate >> the structure of the locators (within their allocated IPv6 address block) so >> as to enable the use of effective and scalable IP routing to reach the UE >> without over-writing anything. > > Can you provide concrete end to end example for this similar to mine. > That is how an external host can reach an address in a UE that is > moving around in a mobile network. > >> I presume it is accidental, but your description of ILNP does not match the >> RFCs, including the ones that discuss mobility and data center handling. >> > I didn't say this was specifically ILNP. The description is consistent with ILA. > > Thanks, > Tom > >> Yours, >> Joel >> >> >> On 6/6/17 1:33 PM, Tom Herbert wrote: >>> >>> Hi Joel, >>> >>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>> wrote: >>>> >>>> Tom, I do not follow your reasoning at all. >>>> I can not tell what you mean by "addressing within the device". >>> >>> >>> Referring to the prefix delegated to the device. >>> >>>> Even in a data center, one might choose to treat the hypervisor as part >>>> of >>>> the network, and allocate a prefix to the hypervisor so it can assign a >>>> /64 >>>> locator to each device. Or you could assign separate /64s to each >>>> entitiy >>>> within the device from the network directly. Neither requires changing >>>> the >>>> IID space. >>>> >>> Right, we're not changing the IID space here. We're specifying which >>> link (subnet) is the IID space relative to. >>> >>>> For something that is a single device, like a UE< it is even simpler to >>>> allow the network to directly assign as many /64 as the device needs. >>>> >>>> Note that if the UE is serving as a router for other devices, then >>>> 1) that is not routing within the device >>>> 2) the space is likely small enough that routing on the full /128s works >>>> just fine >>>> >>>> You have made this assertion a couple of times now, and I can not figure >>>> out >>>> why you consider the change necessary. ILNP can work fine for mobile >>>> network UE. >>> >>> >>> It doesn't work if the UE is assigned a /64, that's my point. The >>> device is the mobile node that needs to be reflected in the identifier >>> and then the mapping in the network is mobile device (device >>> identifier) to locator. The locator is the address of an attachment >>> point (e.g. base station) in the network. The addresses covered by the >>> prefix assigned to the device is not relevant in mobility since the >>> whole prefix follows the device. So what we're really interested in is >>> which mobile device is the packet being sent to and where is it in the >>> mobile network. >>> >>> I'll give it a shot to show by example. >>> >>> Suppose we have a mobile network. Base stations have addresses in the >>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>> >>> Consider a packet is sent to an address within a mobile node with >>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>> to base station with address 2000:0:0:567::. In identifier/locator the >>> top sixty-four bits of address are overwritten with the locator for >>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet >>> will reach the correct base station, but we've lost the address >>> information for the device so the base station has no way to forward >>> it on. >>> >>> Alternatively, assume the identifier is composed of a 32 bit device >>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>> the form 3000:0:0:0:0:Z::/32. >>> >>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty >>> four bits are overwritten with a locator so the destination on the >>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>> and it can now be forwarded to the correct device that is identified >>> by the 0:123 device identifier in the address. >>> >>> Hope that helps! >>> >>> Tom >>> >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>> >>>>> >>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>> identfier/locator split addressing (like in ILNP). The motivation is >>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>> compatible with identifier/locator split. The reason is that the link >>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>> network. The identifier in a mobile network needs to identify the >>>>> device. >>>>> >>>>> In identifier/locator split, the IP address is split into a locator >>>>> and identifier. Each are 64 bits (although Brian did point out that >>>>> that could also be a parameter). Just like IIDs, identifiers must be >>>>> unique within the subnet. In the case of a mobile network the link is >>>>> an overlay network that is not physical, but none the less it is a >>>>> type of link. >>>>> So the properties of it being a link including those for IIDs on the >>>>> link hold-- this make identifiers equivalent to IIDs by definition. >>>>> >>>>> The IPv6 address for identifier/locator split looks like: >>>>> >>>>> M bits for locator >>>>> N bits for device identifier >>>>> 128 - M - N bits for addresses within the device >>>>> >>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>> >>>>> 64 bits for locator >>>>> 32 bits for device identifier >>>>> 32 bits for addresses within the device >>>>> >>>>> Which implies /96 assignment to each UE. >>>>> >>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>> device, and a 32 bit number assigned by the device. If assignments for >>>>> both of these are randomized this provides 64 bits of entropy for >>>>> security. >>>>> >>>>> Tom >>>>> >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>> >> From nobody Tue Jun 6 13:49:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE001294E2 for ; Tue, 6 Jun 2017 13:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfBnAUnznMqo for ; Tue, 6 Jun 2017 13:49:06 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 489D9128C84 for ; Tue, 6 Jun 2017 13:49:06 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id k71so5662971pgd.2 for ; Tue, 06 Jun 2017 13:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xo93Dvj3bZ8lKt20vDF4eCxPcd5mN6IZyPTpnprMFw8=; b=Mr/A9zVQTHu8OqhU+x41+SKPjE4UTd/suygZGlSxnpx+D+Dv/QMzCXMRHCDMjizSyK jKQ6sPZlov1ZfD/LCBnWtUtK3K8DpZwcfhXjlMIfZgyUmcjD+BBmKrGFlW+IQMYjp/87 QtUu62/sJyoA0O8iYstZrLYb02XDF5MU8I+lWH4bjKeNjRj9pSDf73TTK8BbBWx2NZe8 p3bx/XvjMAAel9srFmkmb7nHP/SbO57w199B8kIW5CHYduvtgBnt94PRjkzfOvsHHwLa 6CfIEM/fPvIIcXOxckq8f8M5EKD9MWME7qlsWpQebOIQmnxcrLNWain4j7rYXsSsGnvj V5jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=xo93Dvj3bZ8lKt20vDF4eCxPcd5mN6IZyPTpnprMFw8=; b=trqcmDZ+DQGHc9EKjh8FsQLSwlmu8tnPbFaUZlkj7Cv46jVPkoH/6YmYCTx6Ap3il2 zLhd+87f+3zbu3FNh7jPs81/tjKViF0I0oZeFBo2wu5UW6MjFiWlWjL/e/YnDOfSTudq rZd7p1OclzJSChOjq0fK471N3BmVHkXMRDLavN8psqrScZJKwkIJg5OYZ6wGsh14szuw IM7GxRdHsn1teOCve+lew+4Fm6mF8I8eU3ctGbKQJZhNjdfamRZeabl4eKhKt540AZXZ HtgxsGJAUIi4WfhGmVNA349uslkmI3nzKlGIe0nDInFRSbskUnzdEvgDjCQ1SR8M32Ex hUAw== X-Gm-Message-State: AODbwcDq88gxEyLOYG78Y14B7wrys3A4LtHnzCogUNCm7bQZyXwLmCYR dDzf9fLnQCOP2NxkI3I= X-Received: by 10.84.142.129 with SMTP id 1mr23091036plx.84.1496782145678; Tue, 06 Jun 2017 13:49:05 -0700 (PDT) Received: from ?IPv6:2406:e007:40bc:1:28cc:dc4c:9703:6781? ([2406:e007:40bc:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g86sm63031249pfe.116.2017.06.06.13.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 13:49:05 -0700 (PDT) Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti Cc: 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <3444b786-12b2-10bd-4b38-92ff80410a57@gmail.com> Date: Wed, 7 Jun 2017 08:49:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:49:08 -0000 On 06/06/2017 17:15, Lorenzo Colitti wrote: > On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith wrote: > >> One the title of a document is accurate, I've found it easier to >> determine what is in and out of scope for the document. With a title >> of "IPv6 prefix length (and IID size) is a parameter not a constant", >> I think the topics would at least be and be in this sort of order >> > > I think you forgot that if you want to run non-64-bit IIDs on any > currently-defined link type you need to deprecate all the IPv6-over-foo > documents. Remember, Job's original motivation for this draft was "I want > to assign a /123 in my network", and that is not just a violation of RFC > 4291, it's a violation of RFC 2464 as well. I think his implied goal is "I want to assign a /123 in my network and not run SLAAC" It's not something I'd want to do, since running SLAAC is so much easier, but it doesn't seem like the end of the world to me. The hosts will still have globally routable /128s. Brian > To be clear, I still think this document is a bad idea. I still see no > reason for us to do this, and lots of reasons why we shouldn't. > From nobody Tue Jun 6 13:59:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28D1294E2 for ; Tue, 6 Jun 2017 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzGhokkIEx2A for ; Tue, 6 Jun 2017 13:59:48 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4251200B9 for ; Tue, 6 Jun 2017 13:59:48 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 83so44222537pfr.0 for ; Tue, 06 Jun 2017 13:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zbizIj9bJEeZGfsVY51ePhL42nbplApv7yfs4dH7LpE=; b=n+ECtuCYX8ycQPzNg3UzxH5NhzCrikarfpyeq/f/6aGJyUpKQkpJYYRcQZ5Kz9kfgd yaHAYfuAI04Nc4IWhnf+9RSXe9ozKEms9k0RwbDouHa6931rBaQX+XI8IMw5mSgj4hUX LduBXoNXa0OPtDZcvNniPSDohbOULL+WK3pnTY/8DkqdcqPw/TAh5V/4zpWMtOL/W/RL fJAtE4fkH6cJju57jmAW3FZuF8FMKUt3RlQmLoHCZvNaAKwifhip6eVmxFnXRSW27BSu J+MmdQu0fgGBA5UFyy6zZcYcxotbHysEEjQphrEyfQUVQrQHeT4hAGA+PlgJTR9xbuL4 62SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zbizIj9bJEeZGfsVY51ePhL42nbplApv7yfs4dH7LpE=; b=tr3ppr30NQEBHjmevye4NSoFmRlY6ZqURNsO/qSO26sbt+BUTtJYrc64cKtRXO4owP NfWoiuB6d7VC8C7+H8lphrTqMr4aystT/P33CP7spNHxyyj5Le6vuG/HnrKdH+zIXN9W BXs1MkkmSALWFo+K+TuTekKxxS8w/RgnKIejdi3vOn2p61E8aV/iTZ5VN4+aL7NNSRfb Derrwim2+6YCbqc6HI+7bYwDUbWBAOEjCBFQm8ehw8fXn6dQGn5Xw2plPLJfN/CIxmeI CF7kIiJUo5SBiP+iqqMMnlN+v861pZDQsu43nH1XALNSGCoWNUl6ismjHinyBMNkMC+y Jixw== X-Gm-Message-State: AODbwcDQqrBfGCPhH/6YD1DpdezxpT5254OwZ5pm+D6nfRpRJ7O56/Be Z85wr7pPPXEZu1yv X-Received: by 10.84.237.2 with SMTP id s2mr23381945plk.176.1496782787753; Tue, 06 Jun 2017 13:59:47 -0700 (PDT) Received: from ?IPv6:2406:e007:40bc:1:28cc:dc4c:9703:6781? ([2406:e007:40bc:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e124sm65015055pfc.64.2017.06.06.13.59.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 13:59:47 -0700 (PDT) Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti , Mark Smith Cc: 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 7 Jun 2017 08:59:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:59:50 -0000 On 06/06/2017 17:42, Lorenzo Colitti wrote: > On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith wrote: > >> * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) >> > > As an host implementer, I strongly object to this. > > In practice (if you ignore the will-never-be-used space in ::/3), the > current state of affairs is that the parameter value MUST be 64. That means > that an implementation that is compliant with IETF best practices can > simply not work when the value is not 64. On this, I tend to agree with Lorenzo. The ipv6-over-foo document needs to say that the IID length MUST be N (and for all existing foo, N=64). Otherwise, we can't guarantee out-of-the-box interoperability of foo interfaces. But I want the architectural statement to be that every ipv6-over-foo document MUST specify N and that the RECOMMENDED value of N is 64. That covers SLAAC. What the current draft also recognises is that other addressing schemes (ILNP etc) also need to define N. But we need to put the definition of N where it belongs, which is in those documents defining addressing schemes. Frankly I'd rather we say all that in 4291bis than in a separate draft. But since 4291bis floundered, there's a separate draft. > Saying that the value MAY be larger than 64 is bad for host users for all > the reasons written in RFC 7934. I don't think we should support this on > general purpose hosts because we as the users of those hosts will all > suffer from the reduced functionality and decreased efficiency that that > brings. Again, I actually agree to the extent that it should be NOT RECOMMENDED. Brian From nobody Tue Jun 6 14:03:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250301200B9 for ; Tue, 6 Jun 2017 14:03:38 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zytOi2QtF_L for ; Tue, 6 Jun 2017 14:03:36 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A47AD129527 for ; Tue, 6 Jun 2017 14:03:36 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 06 Jun 2017 21:03:36 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 60D30D788D; Tue, 6 Jun 2017 14:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=YvKUsKjF1o7bBwMwYIiM4Ftqkx8=; b= MfrrcWIZ5X1P7cHMK6CFyO7ogKl7bZABrSRTJd47cUmNEYHh8Qs711poMOXdRDH+ kaO1hiCompH7sHekLjLeAAckHnHknC2rx6QlbWD6B4/T51ZuFHVG/IE9CNye8Nqo zLnBLQACRP0+tdbRxwOYqbWEoQ/o5jZXIKoTXpvVnFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=kQ2ynOIYoSSiqCNyy0YPoHk vLAln1n6uw6Yf2NjA1J+htEGYH54uKrLKzci3Fk7iIpW+W36HZo3xuHAkND4ZzeX AXNKTNdIsjQmkyeXraYocj0ArPIPxXkfurpdU6MeHchyQD956/vaTu4VYtw9QZdI gZXvj2irZHuMIBd2wucY= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 2D514D788B; Tue, 6 Jun 2017 14:03:36 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A8EEECDFA1AF; Tue, 6 Jun 2017 23:03:34 +0200 (CEST) From: otroan@employees.org Message-Id: <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_06BCE1B8-C2B1-4F94-900A-64D60055BB8B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Tue, 6 Jun 2017 23:03:33 +0200 In-Reply-To: <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> Cc: Erik Kline , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 21:03:38 -0000 --Apple-Mail=_06BCE1B8-C2B1-4F94-900A-64D60055BB8B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >> The only thing meaningfully affected by removing 64bit IIDs... > > But that is exactly what the draft does *not* do. Nobody would > change a single instruction in existing code as a result of this > draft. (I agree with you that some O/S stacks may need fixing, but > they already need fixing.) is this draft exactly: IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198]. Interface Identifiers should be 64 bit long except when the addresses are manually configured, or by exceptions defined in standards track documents. For example, [RFC6164] standardises 127 bit prefixes on inter-router point-to-point links. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421] ? Ole --Apple-Mail=_06BCE1B8-C2B1-4F94-900A-64D60055BB8B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZNximAAoJEL7aWKiYQt929bcQAIT644gm55goC6e1rubTuM6O e8vdZAFdle6xnOYJ6Kmc6D1Tqa6d+F6BhK9XfM636+uWiAWlkV0WGsgSkgqqr34F 2QGMF+qpFkdKCCqDOKXsv3KZadeuc5JzmhwILPnu2VE1rKQUl36jIT4NOSvKpJ8g t9fB1Z9AuAEXdhVW5O5hrHoXwzELobvEScU1jGdJU7WyLTrAv8DWtHaES7EHsPs3 kwxF3p4+9zRNTFvu4xh5vpifSTC68OzNA1uIaUeFpvnNWBCFcc6ZNvvJ0UhmFz/9 OKUOP8cYXgR7uJw6fZd4uigZkYYIGYgOY2oEtW0TV6NRX3DPc5H+NUInD9DoOV7t VCHZWzCakpNerwTCHcP8ktCLs5caoxYgR1mRCYimTG+QtmTS0o4m9618Sw8L3A6/ 9d+9XUpJ16lIk6ynDIuB4joMPuqMTOiuXKtaZEZG+5+c1RswxD5gVi87/WjB89iJ S3sp/XO0kYabJeUlWHgyoqeEx7qN5Noy97yMInTwhFZQ3mQqtCuD2Sgr9W3PQ8lK pj/DKX23WgaL8C/QAKlVt+eUwm1njjQZtgXS/40d8kkdfHaZZGX+qI9U3CaxbkC5 QbW6tTmRLX8zvRclCapKV0WODga8ZHgf9NVswcjyINbG0uWyYTvbrlz2YZZ+IOgB xpxkuJZujlu2GcxJAQqK =e+xG -----END PGP SIGNATURE----- --Apple-Mail=_06BCE1B8-C2B1-4F94-900A-64D60055BB8B-- From nobody Tue Jun 6 14:07:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BD0129537 for ; Tue, 6 Jun 2017 14:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2-chf5g5aRU for ; Tue, 6 Jun 2017 14:07:27 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C071128BB6 for ; Tue, 6 Jun 2017 14:07:27 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id a70so31429260pge.3 for ; Tue, 06 Jun 2017 14:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=fDOt+RD4fz+HXHU9V8ULb4B2j+0GsFuvOyjG1S2yh88=; b=qCgiSDxP7LM4e0BiallZ64/rIubx1W5M7iCovegCMlrsop0dxNeNPBqzKia6IfmRMl SOx7XVfg8JLKwdqIYcOf3hcoqpgq1tAP2sFmWGZvq7AZRJMAM3g/Vinrtaj0/XwaPsD8 QAmAKu894utvbnmrJhOMuY8MJkVfch2/OchcC3+8CujtLs0vdXQPfaQwHy6apVJcqstf rfzFwCBgXqKE1jKY/wZmJIeeeZZB5wpKdSNodsA0uNSJhnMhl8mS+CY1SsAY0cXZERq+ 8nQC3Rpxp8uYpvFfbadhc6iU29E/69vo0KL0e81ij1VW8HeuO/5VGm7YCiwb/8XmAoB0 X+Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=fDOt+RD4fz+HXHU9V8ULb4B2j+0GsFuvOyjG1S2yh88=; b=GUmlRSDlXVxZnZa6vmBk5Rv6btvTtiDxJetv5Ev+X1Y9QAIEPnjU+Qe6VrU61dd13X QJ+USuLHvyHwxQX9SSQyDdCrUj7hZD2gf0JEiGmEiTy8j7je3DMn4w4qaqylVX/fbS2o WyR/sXon7F2mTohGBx/qP+m0Y4A8wvgyBss94gs5H+E2vJpHdOjaLsc+qZKM36i5aSbE LmRXDyqEKyKHswg6CzrGigXbyEeVwVoJAqYNtF1TCbkPS9kR0lHwi9C6Ng2WT3A9bh0J +8TIx0nhmCv8TtSgY0vzE3wYaCm7/H1W2SCc9S0BR9NZLkA73FOnr7cRSERH6VBwqZNi 7/NQ== X-Gm-Message-State: AODbwcB2j+h6EiFI1+NSUSPRkMKOnDuZoGWrXwOJFTyF2I5rrWAVxMv2 NqzPebaIx5z69TpLDJfW2g== X-Received: by 10.99.99.193 with SMTP id x184mr28623044pgb.14.1496783246712; Tue, 06 Jun 2017 14:07:26 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:b852:7159:721:8e69? ([2620:0:10e7:10:b852:7159:721:8e69]) by smtp.gmail.com with ESMTPSA id h84sm68412094pfh.45.2017.06.06.14.07.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 14:07:25 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Tue, 6 Jun 2017 14:07:24 -0700 References: To: 6man WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 21:07:29 -0000 On Jun 5, 2017, at 22:15, Lorenzo Colitti wrote: >=20 > Remember, Job's original motivation for this draft was "I want to = assign a /123 in my network", and that is not just a violation of RFC = 4291, it's a violation of RFC 2464 as well. I don=E2=80=99t know Job=E2=80=99s original motivation, but the phrase = =E2=80=9Cserious operational problems=E2=80=9D does appear near the end = of =C2=A71 Introduction, although it doesn=E2=80=99t describe what those = problems may or may not be. It would be helpful to have a more = explanatory problem statement. The authors also conclude the introduction with this: >> This document also clarifies that IPv6 routing subnets may be of any = length up to 128. I=E2=80=99d like to assume that s/subnets/prefixes/ should be applied = here, but that=E2=80=99s kinda funny because there is no real = controversy here or anywhere else that I can see over the question of = what the IPv6 standards say about the lengths of routing prefixes, = including the on-link routing prefixes used in Neighbor Discovery. The = controversy in the context of I-D.ietf-6man-rfc4291bis was entirely = about clarifying what the standard says about the lengths of subnet = prefixes for address assignment, and not anything to do with routing. Until this draft is revised to clear up the confusion between on-link = routing prefixes and address assignment =E2=80=9Csubnet=E2=80=9D = prefixes, I=E2=80=99m not sure what the original motivation for this = draft could be. It=E2=80=99s curious that the draft explicitly cites and = recommends reviewing I-D.jinmei-6man-prefix-clarify, then it proceeds to = disregard completely the carefully drawn distinction and clarification = that document was written to provide. I really don=E2=80=99t know what = to make of that. --james woodyatt From nobody Tue Jun 6 14:49:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCCA1271FD for ; Tue, 6 Jun 2017 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVIHSj6K4ZLO for ; Tue, 6 Jun 2017 14:49:48 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 020A1128BB6 for ; Tue, 6 Jun 2017 14:49:47 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id w1so145954733qtg.2 for ; Tue, 06 Jun 2017 14:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fgz8CYSPM3Fcmztdd3VwKvPbyucwOkvdOZygU1vrWZc=; b=f2OpeeOmu7DANZw6pNc/eFNzzFRL8JYqm7aw8fGX3omHwrNCYs2ihZeNr9YWLf7XRE ZC1fPkdhi7Axf6enAzvkeLXsoz+euNmee4aJ4JW1LZIws4442ZlBSIkff0x9NjcUtUSe ac89BCTjgh4L1jUoVReUpsM4u7FZW9rIL4qGJwPthBOW1kcSMCkOb/+H201tnZY5J5nB QoouRdkVJbrv8x5R/mDWE4TRso0Brm77h6fpdwb7N4wSU7qTBQ0sk3jU70q8M3pAVwOK jPoH2Tb3QJrnB3WFOWpm3I95yFKHz9n6iA9kc2YYQPuGr6qNYJPAAPdmt10Sb5oissJl gejQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fgz8CYSPM3Fcmztdd3VwKvPbyucwOkvdOZygU1vrWZc=; b=uUYcoygmbKVgKsQA4LynPTe1wis7BXBlpEHE4NCfZuuN5kT+NJxLm/ncKVoZyXN1bR iAbMRMraREgeX3o6VfuhGajjrxkybFvi6ijIcX3gmff5SxKPIhrFm2juMXVsNNA2spo6 V4kIJ5IlhQGnCaSrDYjyK6M5AvqwL57hfvrTFLEoo/DOl4+lcEyxTV4WtThZB7zVYVu/ CDV39uuHBHq9K1C+Qb2hta5BZaxr5VwxiQhvw48H5XI74yhXecMD/PmQBdMkLhx5iyki d7kvMJPE8qcY4kagP8mVu899X2DJcIiM82emme+tVu34/Uxw+XY1Wy2K2tHiXrFULK76 6vzg== X-Gm-Message-State: AODbwcDrbQokfcGuL9kKGd/G0/lUto5BmSiG6FaUenYAUAJAX+Lni+ae kr447KSXuLwPRRgxy7SCb1NbQixEkQ== X-Received: by 10.200.44.186 with SMTP id 55mr33919732qtw.173.1496785786838; Tue, 06 Jun 2017 14:49:46 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Tue, 6 Jun 2017 14:49:46 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 6 Jun 2017 14:49:46 -0700 X-Google-Sender-Auth: 2yIc19F2w5GXzYwDmCcQwS-iVLY Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 21:49:50 -0000 At Wed, 7 Jun 2017 08:27:45 +1200, Brian E Carpenter wrote: > Thanks for those careful comments. Can I just ask one question to be > sure I understand: > > > The draft (perhaps unintentionally) conflates > > "on-link prefixes" and "(SLAAC) subnet prefixes". > > Am I correct in thinking that this distinction *only* > applies when SLAAC is in use? This is indeed a subtle point and I intentionally didn't go into it in my comments to avoid introducing further confusion (so I'm glad you asked it separately). As it's subtle I'm not sure if I can explain it well, but let me try...(and therefore it can't be a simple answer like "yes, you're right" or "no, it's not correct"). First, an "on-link prefix" is only about on-link determination in the Neighbor Discovery protocol. It's independent from SLAAC or any other way to configure addresses. In that sense, the separation between on-link prefix and (SLAAC) subnet prefix always applies, whether or not SLAAC is in use. So the answer to the above question would be "no, you're not correct". Secondly, "SLAAC subnet prefix" is by definition only meaningful when SLAAC is in use. In that sense, "this distinction only applies when SLAAC is in use" obviously. But in this context we should actually extend it and only consider "subnet prefix". Purely from the addressing architecture point of view, a subnet prefix could be defined as the leading bits of an IPv6 address immediately followed by the interface identifier. This definition has no conflict with the definition of "SLAAC subnet prefix" as introduced in draft-jinmei-6man-prefix-clarify-00 (where it's defined as a prefix advertised in an RA PIO with A flag on, and its only use is for SLAAC, and in SLAAC this prefix is immediately followed by the interface identifier). With this extended definition, the question is whether "on-link prefix" is distinct from "subnet prefix" only when SLAAC is in use. Admittedly I don't think an existing standard document answers this question. But IMO the answer is still "no". That's simply because the concept of "on-link" prefix is independent from how an address is configured at all, as explained two paragraphs above. And then: > If the nodes on a link > (including a point-to-point) are configured without use > of SLAAC, surely there is only a "prefix", without > distinction. (again in my understanding/opinion), no, an on-link prefix is still different from a subnet prefix in this case (they can happen to be the same, but don't have to be so). Now, another related subtle point is that if we accept this separation, the "subnet prefix" for an address configured without SLAAC is almost meaningless except in the formal definition of the addressing architecture: a host uses an on-link prefix for on-link determination, and uses the full 128 bits to identify L3 end points. It doesn't matter for the host which part of the address is the subnet prefix and which part is the interface identifier. To this end, your original question: > Am I correct in thinking that this distinction *only* > applies when SLAAC is in use? could also be answered with "yes" since in this case only the "on-link prefix" matters in practice. Does this answer your question? -- JINMEI, Tatuya From nobody Tue Jun 6 15:14:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D46B12700F for ; Tue, 6 Jun 2017 15:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTqpiCK9tFha for ; Tue, 6 Jun 2017 15:14:43 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8557126E01 for ; Tue, 6 Jun 2017 15:14:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id CC2D4964 for ; Tue, 6 Jun 2017 22:14:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osoeNckiN-Zz for ; Tue, 6 Jun 2017 17:14:42 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 89E8A989 for ; Tue, 6 Jun 2017 17:14:42 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id n38so42789009uai.1 for ; Tue, 06 Jun 2017 15:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rbQTzzG2nlpdgzdIi+ogqqtHYI+Zh1Yq/eTI71wXMos=; b=G0Gy4ezPeA47PW5cD4pkohjIxak/r76WJtYr3AgCZ1txQxsoqlEPB8OWpOARGcXQiz v7GxeJpa9QkplZ9+hMo4u+472SPaYI3rLdwLllEP7J83LoaCgMc0TgAnYUkulZAdwlmg Qn9XdIbYjA40y054CKsXWdm8iGZ0YASithng1ob1s/sAOQWhvBbSqR8JkaReVhG0amce xLW7BDTTdSzYdgwoEuhUPCsVeP7y/x0FqLqxT3H9IbQ8epVa0DegtW5MTRicENYJo1v7 hLNK8/HNx2z3yNGIHfBcMnWTCGuLUIME2gJkF4ylxP+Se27BRVYpMYgO6iV5G6LNz+No IWug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rbQTzzG2nlpdgzdIi+ogqqtHYI+Zh1Yq/eTI71wXMos=; b=RsqwTPufV2RxxIY/rZvB7x9DN71fu6Gd14t41tEOD81lst+o7vIMi4Ybds8W0VxDv5 qoEoxaCXGl5Ihcvfo9s82Plhvr04NYGCmpYFMRhFpBJmJI1oeC5wvjWp1rhymIidahNb XBjSwu6oukY07AGCmCVlW54xoEMQWsIWxJVUUSH1dT/3ta3TS8HY1M+nB8tB9nPAqWQU 0G04DyuwtSJwY+N74p8Zgkg0yVMD/eyssESucpwIxeXCTlsihlVE+BGB5qjZsYRxa12c 5Daaz1/M22hDPGOUGo+b0Wk5GI26XyNjhf0cWAwWy6ZlW+IZk4ScdaIo780D/pz10y8+ Wcew== X-Gm-Message-State: AODbwcDyWRQN9jAieNr3J3+j8lUkwS7ff6p6v/m4eCrpmd0z+N9CPk4L KG84ElBmCX6o/737lmA4TMHYreskyyqaXN6So4V52ZEodkON1kSpYdnycXpuGyuKrfFkurlch9k 2hrzhITmKKjKBDbo= X-Received: by 10.31.197.5 with SMTP id v5mr12333398vkf.129.1496787281748; Tue, 06 Jun 2017 15:14:41 -0700 (PDT) X-Received: by 10.31.197.5 with SMTP id v5mr12333376vkf.129.1496787281095; Tue, 06 Jun 2017 15:14:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Tue, 6 Jun 2017 15:14:40 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Tue, 6 Jun 2017 17:14:40 -0500 Message-ID: Subject: Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00) To: Brian E Carpenter Cc: Lorenzo Colitti , Mark Smith , 6man WG Content-Type: multipart/alternative; boundary="001a114e6cc431c628055151f2b5" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:14:46 -0000 --001a114e6cc431c628055151f2b5 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 3:59 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 06/06/2017 17:42, Lorenzo Colitti wrote: > > On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith > wrote: > > > >> * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119) > >> > > > > As an host implementer, I strongly object to this. > > > > In practice (if you ignore the will-never-be-used space in ::/3), the > > current state of affairs is that the parameter value MUST be 64. That > means > > that an implementation that is compliant with IETF best practices can > > simply not work when the value is not 64. > > On this, I tend to agree with Lorenzo. The ipv6-over-foo document needs > to say that the IID length MUST be N (and for all existing foo, N=64). > Otherwise, we can't guarantee out-of-the-box interoperability of > foo interfaces. > > But I want the architectural statement to be that every ipv6-over-foo > document MUST specify N and that the RECOMMENDED value of N is 64. > > That covers SLAAC. What the current draft also recognises is that other > addressing schemes (ILNP etc) also need to define N. But we need to > put the definition of N where it belongs, which is in those documents > defining addressing schemes. > I'd be fine with this except for we need something for manual (AKA static) configuration, as distinguished from SLAAC or other automatic addressing schemes you are talking about above. I'll note, all implementations of IPv6 that I'm aware of that allow manual configuration of the address, also allow any prefix length to be specified manually. If no prefix length is specified I believe many default to /64. I'd also be fine with something like; the manual configuration of prefix lengths other than /64, or /127 for point-to-point router links [RFC6164], is NOT RECOMMENDED. But that still leaves room for consenting adults to manually configure other prefix lengths when they have a specific reasons to do so, which I also think is one of the goals of this draft. I believe there are some implementations of IPv6 that don't allow manual configuration, but I don't believe manual configuration is a required IPv6 feature, so that isn't a problem. > Frankly I'd rather we say all that in 4291bis than in a separate draft. > But since 4291bis floundered, there's a separate draft. > +1, but maybe we can find some consensus through this draft, and not bother to advance it to RFC and just return to work on 4291bis and advance it. > > Saying that the value MAY be larger than 64 is bad for host users for all > > the reasons written in RFC 7934. I don't think we should support this on > > general purpose hosts because we as the users of those hosts will all > > suffer from the reduced functionality and decreased efficiency that that > > brings. > > Again, I actually agree to the extent that it should be NOT RECOMMENDED. > +1 > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114e6cc431c628055151f2b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 3:59 PM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
On 06/06/2017 17:42, Lorenzo Colitti wrote:
> On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>
>> * The parameter's default value SHOULD be 64 ("SHOULD&quo= t; per RFC2119)
>>
>
> As an host implementer, I strongly object to this.
>
> In practice (if you ignore the will-never-be-used space in ::/3), the<= br> > current state of affairs is that the parameter value MUST be 64. That = means
> that an implementation that is compliant with IETF best practices can<= br> > simply not work when the value is not 64.

On this, I tend to agree with Lorenzo. The ipv6-over-foo document needs
to say that the IID length MUST be N (and for all existing foo, N=3D64). Otherwise, we can't guarantee out-of-the-box interoperability of
foo interfaces.

But I want the architectural statement to be that every ipv6-over-foo
document MUST specify N and that the RECOMMENDED value of N is 64.

That covers SLAAC. What the current draft also recognises is that other
addressing schemes (ILNP etc) also need to define N. But we need to
put the definition of N where it belongs, which is in those documents
defining addressing schemes.

I'd be= fine with this except for we need something for manual (AKA static) config= uration, as distinguished from SLAAC or other automatic addressing schemes = you are talking about above.=C2=A0 I'll note, all implementations of IP= v6 that I'm aware of that allow manual configuration of the address, al= so allow any prefix length to be specified manually.=C2=A0 If no prefix len= gth is specified I believe many default to /64. =C2=A0

=
I'd also be fine with something like; the manual configuration of = prefix lengths other than /64, or /127 for point-to-point router links [RFC= 6164], is NOT RECOMMENDED.=C2=A0 But that still leaves room for consenting = adults to manually configure other prefix lengths when they have a specific= reasons to do so, which I also think is one of the goals of this draft.

I believe there are some implementations of IPv6 tha= t don't allow manual configuration, but I don't believe manual conf= iguration is a required IPv6 feature, so that isn't a problem.=C2=A0
=C2=A0
Frankly I'd rather we say all that in 4291bis than in a separate draft.=
But since 4291bis floundered, there's a separate draft.

+1, but maybe we can find some consensus through this = draft, and not bother to advance it to RFC and just return to work on 4291b= is and advance it.
=C2=A0
> Saying that the value MAY be larger than 64 is bad for host users for = all
> the reasons written in RFC 7934. I don't think we should support t= his on
> general purpose hosts because we as the users of those hosts will all<= br> > suffer from the reduced functionality and decreased efficiency that th= at
> brings.

Again, I actually agree to the extent that it should be NOT RECOMMENDED.

+1
=C2=A0
=C2=A0 =C2=A0 Brian

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114e6cc431c628055151f2b5-- From nobody Tue Jun 6 15:18:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC67F1293F5 for ; Tue, 6 Jun 2017 15:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Ebm-SuWufJ for ; Tue, 6 Jun 2017 15:18:23 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 B26C9126D45 for ; Tue, 6 Jun 2017 15:18:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 70C6A290 for ; Tue, 6 Jun 2017 22:18:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybPZzYYgRdLH for ; Tue, 6 Jun 2017 17:18:22 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 42CF22BC for ; Tue, 6 Jun 2017 17:18:22 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id f19so38081857uab.9 for ; Tue, 06 Jun 2017 15:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ikt78HxWBGl/kz5N6pGcFdwvnMZy89G2UVMnPuS1d40=; b=NgdnlW/KhtcZtYDBsM0ppL/g1r0pCAz1oLl/hBQZKcBn1i9tGR8rzPMvhGy+AmVX+E eEdBhCkTD0FARGRfukC6oEEvn1kvo1yJLbCiPWV6Fv7QRP6NwKFXm6GLYhKBrNZ8M984 vCJG0FDxcg2QBaUo4aCFWtM7ablOm3AYPoDR//lMWGbd3EdzOBCdusSyvtCnfsnxfmV+ 8Pyv1NcHtcAOJQWkvxZ0j+iZsTsl/0s0zIGmvq58uHv1HM8xMvIy2rBRlOuvTjCNwjdK W7ZGWm1RpDK03RmiBNlIOAWQOsZu2oFJHdxmKUsflgOvLkdQ7hcJd5Gq6v8awzNTtWnX dXHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ikt78HxWBGl/kz5N6pGcFdwvnMZy89G2UVMnPuS1d40=; b=t/Zh0+3SLHvzsLFyroVRlgF7LaoMa1LkezxFEH//hRAggKZv2v8JBl7Nfea72JhEis zxQSvprQtMpLyJCEXy1Q2dyS0tbwSV08yUDoLWJWN1Wxb41ppo8SyS6BB5kQqbjcUKs+ X1i5LjVKlPrPNJp7uV2lrf6aiySS/J2x+WhkucVlNd1fV1IqZWnAQzNIVxnNvzCNJ1Nd UbJirQy3xTZ2b4opxqsKiXyVwZ5ZHWAyw6H88DUaDD5QE4AKwdj5VRssGDZWJa/hVKQw ii6ZL6htY1iHN83jRFdPBgz5VTnl+QaXoW985e2oS5X9aMH90ydcMV+LEQW2McyYCttm ohgg== X-Gm-Message-State: AODbwcD/RU5I6lbQtYvEPMMTyGAH9Iw9ilF5Om0DwYoChXJ2e6A5LaSX tV8N3ZRGXGbTsQGeLjMoa5zJwMVJeLINeBihvSc5RV04+wAszOv5saFo4cKCnpIz4XVBqjpqwYT gNalK9EbNG7CyFxQ= X-Received: by 10.159.34.207 with SMTP id 73mr9262171uan.131.1496787501406; Tue, 06 Jun 2017 15:18:21 -0700 (PDT) X-Received: by 10.159.34.207 with SMTP id 73mr9262162uan.131.1496787501259; Tue, 06 Jun 2017 15:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Tue, 6 Jun 2017 15:18:20 -0700 (PDT) In-Reply-To: <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: David Farmer Date: Tue, 6 Jun 2017 17:18:20 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Ole Troan Cc: Brian E Carpenter , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="94eb2c04ca4e51409d055151ff8d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:18:25 -0000 --94eb2c04ca4e51409d055151ff8d Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 4:03 PM, wrote: > >> The only thing meaningfully affected by removing 64bit IIDs... > > > > But that is exactly what the draft does *not* do. Nobody would > > change a single instruction in existing code as a result of this > > draft. (I agree with you that some O/S stacks may need fixing, but > > they already need fixing.) > > is this draft exactly: > > IPv6 unicast routing is based on prefixes of any valid length up to > 128 [BCP198]. Interface Identifiers should be 64 bit long except > when the addresses are manually configured, or by exceptions defined > in standards track documents. For example, [RFC6164] standardises > 127 bit prefixes on inter-router point-to-point links. The rationale > for using 64 bit Interface Identifiers can be found in [RFC7421] > > I'd be cool with that! +1 -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c04ca4e51409d055151ff8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 4:03 PM, <otroan@employees.org> wrote:
>> The only thing meaning= fully affected by removing 64bit IIDs...
>
> But that is exactly what the draft does *not* do. Nobody would
> change a single instruction in existing code as a result of this
> draft. (I agree with you that some O/S stacks may need fixing, but
> they already need fixing.)

is this draft exactly:

=C2=A0 =C2=A0IPv6 unicast routing is based on prefixes of any valid length = up to
=C2=A0 =C2=A0128 [BCP198].=C2=A0 Interface Identifiers should be 64 bit lon= g except
=C2=A0 =C2=A0when the addresses are manually configured, or by exceptions d= efined
=C2=A0 =C2=A0in standards track documents.=C2=A0 For example, [RFC6164] sta= ndardises
=C2=A0 =C2=A0127 bit prefixes on inter-router point-to-point links.=C2=A0 T= he rationale
=C2=A0 =C2=A0for using 64 bit Interface Identifiers can be found in [RFC742= 1]


I'd be cool with that! +1

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Email:fa= rmer@umn.edu
Networking & Telecommunication Services
Office o= f Information Technology
University of Minnesota=C2=A0=C2=A0
2218 Un= iversity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapol= is, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c04ca4e51409d055151ff8d-- From nobody Tue Jun 6 16:06:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC41273E2 for ; Tue, 6 Jun 2017 16:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj7bIAHa18MJ for ; Tue, 6 Jun 2017 16:06:43 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC97126B71 for <6man@ietf.org>; Tue, 6 Jun 2017 16:06:43 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 83so45102935pfr.0 for <6man@ietf.org>; Tue, 06 Jun 2017 16:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=2ac5iCWEMLNIl5ZV5Yq5hnAAUqPvWOEAVvxg3lQFGog=; b=vRPKlHJL1vZhan5MP907DJrOyCypppHFIkmBnc0hhOzYmNrJ0+y8XxKCUpG5dBsPQY o5gqlhCtACeuuldsBCPPq7AadPqnVpoviUQs5zWJuZCoVZh23xsBv/vKYTpMB13IPKMb 19Q1vRsfGBDyUqeOrSdWdPXbMQioT3mUCKbNK3RC8ICPFZ+l72nCvKvbyDq0xzb196cA ppPyS7hbufnT+Jd6/4e9oLIzChyFaLBBRo3y2CQEhWCFt8giFxaptPW+M3RnyNyNOLze 1bkeY9BO7HkOMTe0seTYU1e/F2wswDns5lQcPynO0cerMWiFYt6HYTOmseIDqYWNidnz aMOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=2ac5iCWEMLNIl5ZV5Yq5hnAAUqPvWOEAVvxg3lQFGog=; b=nUWyudtDqv1+lndQJFHaw8+c0uxfDzhnDN+A+mzg26i6jVBO2jGbCniVxWqykU6e0F YAwkwnT8jTWveyDto7KVsaLtA+jnXWqL17Z/eXmJF8Dl6o9HyqEKybQLGCYDUI3uwB2O kNPwb8ORtFnSvNE3rVA5aanRKaVL9M5zMUndmP/5iM9BvkgN+sBAbsuauijjrKd6Q83x 4uVH+tT/T9dPTnS++ALB52+Wrk/fFjS9hXi7ejQ/3mxf/flRWcxePOSTx+ZHMOakYFe/ PTC6FWmIrjenMstdQw4syhDyeKkdg30/Tpcp1rA0vEQg5ZpTzsFGHPgkkugYoiM680mz U+Ag== X-Gm-Message-State: AODbwcAkdQBUNhvYN3+ME1IK/SIuFfSbCzYPsJkgrO3gJUBbuDz038Xy TPnYEpRRTQyfTGdCFgx7+Q== X-Received: by 10.98.145.26 with SMTP id l26mr28225998pfe.36.1496790402231; Tue, 06 Jun 2017 16:06:42 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:e8f1:52b3:561c:ee65? ([2620:0:10e7:10:e8f1:52b3:561c:ee65]) by smtp.gmail.com with ESMTPSA id k11sm23700089pfj.48.2017.06.06.16.06.41 for <6man@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 16:06:41 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Tue, 6 Jun 2017 16:06:40 -0700 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> To: 6man@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:06:45 -0000 On Jun 6, 2017, at 14:49, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > With this extended definition, the question is whether "on-link > prefix" is distinct from "subnet prefix" only when SLAAC is in use. > Admittedly I don't think an existing standard document answers this > question. [=E2=80=A6] I would say that IPv6 Subnet Model [RFC5942] = clearly answers this question. The answer is no: they are always distinct. See =C2=A71 Introduction, = where it says, "The behavior of IPv6 as specified in Neighbor Discovery = (ND) [RFC4861] is quite different. The on-link determination is separate = from the address assignment," and further refinement in =C2=A74 Host = Rules, p1. where it says this: "The assignment of an IPv6 address -- = whether through IPv6 stateless address autoconfiguration [RFC4862], = DHCPv6 [RFC3315], or manual configuration -- MUST NOT implicitly cause a = prefix derived from that address to be treated as on-link and added to = the Prefix List." > [=E2=80=A6] But IMO the answer is still "no". That's simply because = the concept of "on-link" prefix is independent from how an address is = configured at all, as explained two paragraphs above. I think it=E2=80=99s not just a matter of opinion. I think the standards = track documents are clear on this point. --james woodyatt From nobody Tue Jun 6 16:10:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0776F1273E2 for ; Tue, 6 Jun 2017 16:10:41 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk8EL31QnMlZ for ; Tue, 6 Jun 2017 16:10:39 -0700 (PDT) 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 9269F126557 for ; Tue, 6 Jun 2017 16:10:39 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id p85so87329418vkd.3 for ; Tue, 06 Jun 2017 16:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=plvRemwWaeY0PKq8/V2juNzx8tPs2p5ZZZWhEhvhyvc=; b=dzPEBvU5eD7pMNNyQnebqeJFB+34Yh4BRN5yXHRa0PfYPjLngnwcrSZpIDqET4lGNY 7az6LxUqci6QQMR49Ho/Iwn7Q6zP4vv7BFdu3J4y4WYy3FvlMgoSvApGBI8DLlijCD7q 0XhGm4HWJH6GgaMRAO5gO6288A5G39LDkD6//xFOZZuXKFx36UEoGOUvh4VRdsjle32j WruZ9ke+PyLsv6PjB9O5mzSoVRIQc99kHFy0v06jVjGgeWcmT6fAw4AHmF5mSyjMlp3c 6N1R1crMo7Mqg06qhgSqbNKCfU8uMaMKgm1ZQjGZzSgMsuoGtCWzTvWpQf2pP4WzysUa PNOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=plvRemwWaeY0PKq8/V2juNzx8tPs2p5ZZZWhEhvhyvc=; b=tqMSgeZ98cRsLtuy+smpHIt7kOJob90BjQISgRiaiX3hF/vAnsmWx7jf2X8V4xp7vH 5ctLuXyMDgQAhUUnlRR+AXInZi8hlHjnVB0Zh2DempX/SWIiQjdu5f1d4h2wPi0m3Puh mLdQ+XtfDAFkHcedG3MUZEEJd+/i6a5ZCjUNOaV8E0F40wYE6sfmNWz3KgvVayxCkT8V rh/GO86UbGUhwvLvHO13DTIFb3Q3CKv/A8qtGvspBMj3DmHWhuMW65i12zNBwbMkPUnX j6dNh+0rDJf4HTCGIG6YRWMgLq4Z+V92n3w5BbWOjPTDE77LFqbEmmJFBVrqEPA8QMMZ hKYQ== X-Gm-Message-State: AODbwcDQnmH7E8h4QELiqtYng6aHjWYRPnkHMGgExS+phI50HCSO20Gp y06T20JGXXTbV92gI320QI5GLM0YRUQw X-Received: by 10.31.158.195 with SMTP id h186mr14585441vke.30.1496790638545; Tue, 06 Jun 2017 16:10:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Tue, 6 Jun 2017 16:10:08 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 7 Jun 2017 09:10:08 +1000 Message-ID: Subject: Re: Different sets of needs (Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00)) To: Philip Homburg Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:10:41 -0000 On 6 June 2017 at 22:48, Philip Homburg wrote: >> If some of IPv4 addressing >> practices are carried over to IPv6 at the edge of the network (e.g., >> /120s on link-layers that have the capacity to support far more >> hosts than that, or a /128 to a CPE), it may recreate the sorts of >> IPv4 host addressing and addressing related problems that IPv6 was >> meant to prevent. > > In my rather complex home network, at /120 prefix would be more than enough > to number all interfaces that need addresses. Even in the next ten years > that is very likely to be true. I wouldn't want to be so sure about that. That's assuming 1:1 host:address, and we have a BCP saying not to make that assumption. Host Address Availability Recommendations https://tools.ietf.org/html/rfc7934 > > Is that a smart way to use the IPv6 address space, no. > > So what this draft does is create a huge mess of the IPv6 address architecture > for very questionable benefits. And those benefits are not even articulated > clearly in the draft. > > Adding an extra parameter to a protocol does not in general improve the > protocol. In fact the opposite is true. Having a fixed boudary at 64 bits > makes the system easy to explain and easy to troubleshoot. No need to > waste extra cycles in trying to find out what crazy router announced a > crazy prefix length. > > Of course the actual value '64' is derived from modified EUI-64 and with > pseudo random IIDs we can just as well pick another value. But each bit we > drop from the IID increases the chances of a collision. Address collisions > are hard enough to deal with that you want to design for zero collisions, > even in extremely big networks. > > Writing an RFC that requires implementations to support every possible > IID length, even the ones that don't work in practice will only lead to > extra confusion and the need for a new BCP that will tell operators how far > they can go. > > From nobody Tue Jun 6 16:24:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22704126557 for ; Tue, 6 Jun 2017 16:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJyE4GkgNgvP for ; Tue, 6 Jun 2017 16:24:15 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 B7D38126579 for ; Tue, 6 Jun 2017 16:24:15 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id a70so32326042pge.3 for ; Tue, 06 Jun 2017 16:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TarwgvC+AK5gYBcFZoRaPxkbd2PCCrYJPdPB1mR4jNQ=; b=t6A9ZnHTQkPk3aaaROpYmTGG1TshVOD9vcrXihfx1WWeqQtQidwJ9zqkvzflaK2avr vLs1+q3B0yKnqezXXIZ846Dr71RM0qXvpOArC7bDBwSP2exrSpeWDp319FygIRSoONTh tZpfsQPk7ibHqZfX8IaNH+vEHjMcrMTp7h7hsnDVZgHI9RtOcJgK6d2sgfHo96U6tSZM ouGktxKtTA9Dgepz/wGwiYfsPckw0ijWeJpLVrQJWde5P0iBiOH/pHD8Fl4zOlWRvhbo WdH62VAD8QX/aHZu5HjoKCaiF9uqgPCKYp8aDSGx7b0UXUzKYHRO+jLV81pjjka7rwPH JpvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TarwgvC+AK5gYBcFZoRaPxkbd2PCCrYJPdPB1mR4jNQ=; b=LvBvlxvJBREzprW35hjudGpjy09nCgZoLIWhVwksIEy7AQ5NLBpOCoAmIWnKRzVHIL f42xVaxbMq9R5dy/lak/9qWZ3pocR4rqgC+kUbnVzH1D1tLzqEZfDknxrSxgfYgmOFkl FekHOEXsyyzttTVbCMK6wVMdehws2QGsVri5qeS/D5dr70s0ypSsc8v6YQNC1iP7bvR6 DtIXq1vhEHPK3SZC6ewuu+iEfE28tKMp5ldlgS9txtMEtoYv44gvMXP/U09w8S96RZ2K Bfep+8TvWwejmWa+JLnfaR1FFrbKLVZ+utEypq9X79fLOk38oxjgtIA1KImxSYVA4iFc QGTg== X-Gm-Message-State: AODbwcBm3fdGuCI33qup2zN245DSoeYJsTHxrJXTkt1q1AUhNyuoC3BY nbEsJl+QVx4sBsn8 X-Received: by 10.84.229.14 with SMTP id b14mr24350810plk.14.1496791455154; Tue, 06 Jun 2017 16:24:15 -0700 (PDT) Received: from [130.216.38.7] (sc-cs-316051.cs.auckland.ac.nz. [130.216.38.7]) by smtp.gmail.com with ESMTPSA id b1sm24638843pfl.70.2017.06.06.16.24.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 16:24:14 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Ca By , Philip Homburg , IETF IPv6 Mailing List References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> Date: Wed, 7 Jun 2017 11:24:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:24:17 -0000 On 06/06/2017 19:48, Lorenzo Colitti wrote: > On Tue, Jun 6, 2017 at 7:25 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> The parameter's *current* value, yes. But should we really be fixing >> the value of the parameter once and for all in the addressing architecture? >> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >> assumes? >> > > If that is the authors' goal, then what the draft should say is that the > IID length is 64 unless otherwise specified by an IPv6-over-foo layer. As Ole quoted, it says: "Interface Identifiers should be 64 bit long except when the addresses are manually configured, or by exceptions defined in standards track documents." Maybe there are too many other words? > That is not what the draft says today. The difference is the "manually configured" option. I don't see how we can forbid that. Brian > > I also suspect it's not the authors' goal. At least Randy and Job have > clearly stated that what they want to do is run non-/64 prefixes on today's > links (Ethernet, maybe wifi), not on some future link layer. > From nobody Tue Jun 6 16:27:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D837126579 for ; Tue, 6 Jun 2017 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUrOLLm0Q8KX for ; Tue, 6 Jun 2017 16:27:55 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615E812704B for ; Tue, 6 Jun 2017 16:27:55 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id k71so6719273pgd.2 for ; Tue, 06 Jun 2017 16:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UuoF3L8MdBK5+DDLVNfswYlMpPngXEf3h43aXVddFog=; b=fK46XnGPBN7/2kRQVowN7JZ6UqfRxroOOaJ1A6agEM81v0XJTCt4RYz3YlR484Dwbo vk3PXzvZJ0dZBiOiTMS3/rjdRMCygE63Ow8wzKfmyN8QEqOvvjWLH488CowB+IcGxFx9 Ayc/M/rc5csNBXVHWGsJdyGJbwTHKsbNu/QK61HmA0o+6YdMqX+25ONSB/4y+65E/Z3v OWUIAN0J644I2ehQe3uEU2RGdNp6Txsb4EAzX/XcOjn6CYyMPQY6u15BiUjPERXWjdeS Al7lahpnx2lqdAcPnRt+9x0IPQC351CubC/yQhmxZvm9ufyQJxgY6gqdMg9CdOFrank7 MiOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UuoF3L8MdBK5+DDLVNfswYlMpPngXEf3h43aXVddFog=; b=FC2dQgJmI/ob+gt9+0mPHOq+nH3dxcDbIB+1ZIF1NKVzeC1UEKk+sxiQUyGjWRmUkO kIJguoMvsznaAXrGavyo0tu7mRnesXEKM3Pu0npXyDJLUmvRjIx2Cwrlt1rwqH5sdxe3 a3oVAvOFBth/Ul8zBNj+JI0fPocOhV1lGeGe6q/OCVD33bLyD/5VlKEncHN1gzPVI1vV nuWGdMMPysR7A6z0Sbw+uQck3WeCm+nc4jB9ToqKMyxU+EDCazkKFIjQpnATHGsHuMbR ub+Sm+9tN9UKLr+NbKYvgy6Meua7UJkCPt3GL0O2sTBZySkWb6yM6wDdyWuaE4tBWkiD gVmA== X-Gm-Message-State: AODbwcCl+jFm3yY5+IxRk9rBM7BI50AKLhTeqCBpoxhhurciupVXwm4W d8ojNCZpwOV8ac0t X-Received: by 10.84.138.131 with SMTP id 3mr24967441plp.38.1496791674893; Tue, 06 Jun 2017 16:27:54 -0700 (PDT) Received: from [130.216.38.7] (sc-cs-316051.cs.auckland.ac.nz. [130.216.38.7]) by smtp.gmail.com with ESMTPSA id f71sm65963386pfd.98.2017.06.06.16.27.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 16:27:54 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org Cc: Erik Kline , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 7 Jun 2017 11:27:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:27:57 -0000 On 07/06/2017 09:03, otroan@employees.org wrote: >>> The only thing meaningfully affected by removing 64bit IIDs... >> >> But that is exactly what the draft does *not* do. Nobody would >> change a single instruction in existing code as a result of this >> draft. (I agree with you that some O/S stacks may need fixing, but >> they already need fixing.) > > is this draft exactly: > > IPv6 unicast routing is based on prefixes of any valid length up to > 128 [BCP198]. Interface Identifiers should be 64 bit long except > when the addresses are manually configured, or by exceptions defined > in standards track documents. For example, [RFC6164] standardises > 127 bit prefixes on inter-router point-to-point links. The rationale > for using 64 bit Interface Identifiers can be found in [RFC7421] > > ? Yes. Put those words in 4291bis and I will be very happy. Oh ;-). Brian > > Ole > From nobody Tue Jun 6 16:30:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB12D128B8F for ; Tue, 6 Jun 2017 16:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j6QBxn4g79p for ; Tue, 6 Jun 2017 16:30:24 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 C3B70126579 for ; Tue, 6 Jun 2017 16:30:24 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id v18so29822235pgb.1 for ; Tue, 06 Jun 2017 16:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UlImqTh6t721yY6aXX8asq6avTUeCgur5sPY9YDKZRw=; b=VSYryqVl7/5i4HMwWSR6MyFPGLbFw36IPJgxriORt2Wuy/J1uUrN1K4LvdqTUD8Gk1 MOGKXe2wZ4oSFy8tnqPtoG7HPVV1wK2cAY5l5SEmrO0K9YNFvt95B9d+a5uJM9i9wOtQ TajGTDeaJcTfVqpd1WDr/+a42VYMB5xTtUuGOoZPH9vojUqd7Lc7ybJyxCmHL4Jbx+/1 bL8hgDVuMfr81LbgkDaBBhdsBxnYkN75OrUeStKu9+sJCx+tW+ASOJ8ZNIoKWPgzTidd c8OWQziVn8nkOVzLcJd34VamKX8Eru6WLVXFCeijeXE8QJQyUEzbdnE57522BFi2c7M+ yPpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UlImqTh6t721yY6aXX8asq6avTUeCgur5sPY9YDKZRw=; b=mGCH9ghFwxi144htPcaIY6qsAgPlSFmQZF69ufeXsDlu+2hted464wIa62amuLT6WA W/agIhOycyEJ4i7do8a7Iks6Uod/82KiaaSXyihSdMgns+2BJk42Fhg/WqzvM5GxseUk 5kQ6wc9Qlszt7BtlvN+qiwdmiCh9KaVI3H0MllBoaAjM6bbpwDKUfYW4DiqIqC4611Sm tleorgjqPHUevZkHDM9h+oqQsnrWvjyw1x+UiN7Q9OKH8Fn3auS+CvMfSCqKjNSRlg/N omiHPtxHThPk3cheC49hMZNQ/7StOR20j6ZNvt4T9dX/wz1IWnQPOk/uhyQGA2BJBQi8 mPmQ== X-Gm-Message-State: AODbwcAc2J2E9gPdNocVEKUm2Dciu9cDpAIkGqQfWzACIeIJMl9M1pKz kkks3Me5PS3LCCGH X-Received: by 10.84.225.5 with SMTP id t5mr24030124plj.238.1496791824209; Tue, 06 Jun 2017 16:30:24 -0700 (PDT) Received: from [130.216.38.7] (sc-cs-316051.cs.auckland.ac.nz. [130.216.38.7]) by smtp.gmail.com with ESMTPSA id v62sm15782569pfb.124.2017.06.06.16.30.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 16:30:23 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Ca By , Philip Homburg , IETF IPv6 Mailing List References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <864b8f70-c179-a501-8f4f-96f786beb774@gmail.com> Date: Wed, 7 Jun 2017 11:30:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:30:27 -0000 Just to be clear... On 07/06/2017 11:24, Brian E Carpenter wrote: > On 06/06/2017 19:48, Lorenzo Colitti wrote: >> On Tue, Jun 6, 2017 at 7:25 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> The parameter's *current* value, yes. But should we really be fixing >>> the value of the parameter once and for all in the addressing architecture? >>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >>> assumes? >>> >> >> If that is the authors' goal, then what the draft should say is that the >> IID length is 64 unless otherwise specified by an IPv6-over-foo layer. > > As Ole quoted, it says: I meant that it says this in a too complicated way, not in those exact words. > "Interface Identifiers should be 64 bit long except > when the addresses are manually configured, or by exceptions defined > in standards track documents." > > Maybe there are too many other words? > >> That is not what the draft says today. > > The difference is the "manually configured" option. I don't see > how we can forbid that. > > Brian > >> >> I also suspect it's not the authors' goal. At least Randy and Job have >> clearly stated that what they want to do is run non-/64 prefixes on today's >> links (Ethernet, maybe wifi), not on some future link layer. >> From nobody Tue Jun 6 16:30:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F3A128961 for ; Tue, 6 Jun 2017 16:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zbRfYltrkSE for ; Tue, 6 Jun 2017 16:30:45 -0700 (PDT) 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 323EB128B93 for ; Tue, 6 Jun 2017 16:30:43 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m7so30701929wmg.0 for ; Tue, 06 Jun 2017 16:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O16n3twiAaogl6Cjov26rWjoXN+rGerhbrn2MeyQfFw=; b=CSlGEpLWHxIKfubgybz49UxR5JAOJviAB1Z85p0SAs0l1XsDolMb6RphkkY1krXhGU GhuHBbLcM3kBtJ5rTNEIA5WRsFt4g9oweKyiExS9Fl3MZk5J7kqpczB1toIg2pISMxOq auadCWHBgs9hPe9pYTuTKTWYqzUXlR6EylMEbnIP8BUWLjjICj9ln2QSMJHpjVi4TLst w5ZITVz3VoqEb5tjGWeGEUZHvr9tFgfONy1I7BejMp70zz2TpoqUe4GTkDV3jNJ/X70J 26o4jhyF0gpBTXFxgklJbl+FyxCDHIpsm2tzOIfVz03ejizNFINZHYuiVE69w64TVZ0q Y+vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O16n3twiAaogl6Cjov26rWjoXN+rGerhbrn2MeyQfFw=; b=N0FYBM/eq+lk0ar7jGDYNLccLowKkvguwfSRPbB662mmMEfguFXyAn6H2RU1bIH+dU YryLULa8DfHROsHGQMe6lRs7ZPHb7U1X6lFaZPxYaybUmN452Clj8jtAGILpviUcq7mq aFAQKETmO2vuJWfKCsirXz4p98VobVXOMhCepLi42119jjuDlzJO4HwteXNzG+OY/48L XZzYMXL1QRhCC4p9PrsO7FafzNhsxCbxBnmJtZNy01Vo7bZk4ii77uxD+kZH3XVYfhr4 3gbWBbUVEr1ltAaQdlXjHizzWD38TkVmB811sOdyIV+YqFvFSlHtX1Ujqi4ARjlndIzY P+LA== X-Gm-Message-State: AODbwcAhGsC1DOWu90afybxFdaHAbFajpz/CUuToxV38ZDi3ditGnGMg AfFT+8CIrImyLgeOeymWqCrhugZj/KVL X-Received: by 10.28.54.13 with SMTP id d13mr7044064wma.124.1496791841605; Tue, 06 Jun 2017 16:30:41 -0700 (PDT) MIME-Version: 1.0 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> In-Reply-To: From: Job Snijders Date: Tue, 06 Jun 2017 23:30:30 +0000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , otroan@employees.org Cc: 6man WG , Erik Kline Content-Type: multipart/alternative; boundary="001a1143678e05a703055153025b" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:30:48 -0000 --001a1143678e05a703055153025b Content-Type: text/plain; charset="UTF-8" On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter wrote: > On 07/06/2017 09:03, otroan@employees.org wrote: > >>> The only thing meaningfully affected by removing 64bit IIDs... > >> > >> But that is exactly what the draft does *not* do. Nobody would > >> change a single instruction in existing code as a result of this > >> draft. (I agree with you that some O/S stacks may need fixing, but > >> they already need fixing.) > > > > is this draft exactly: > > > > IPv6 unicast routing is based on prefixes of any valid length up to > > 128 [BCP198]. Interface Identifiers should be 64 bit long except > > when the addresses are manually configured, or by exceptions defined > > in standards track documents. For example, [RFC6164] standardises > > 127 bit prefixes on inter-router point-to-point links. The rationale > > for using 64 bit Interface Identifiers can be found in [RFC7421] > > > > ? > > Yes. Put those words in 4291bis and I will be very happy. Oh ;-). I recall a small but vocal group arguing fiercely against that text adjustment, so here we are. Kind regards, Job --001a1143678e05a703055153025b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 07/06/2017 09:03, otroan@employees.or= g wrote:
>>> The only thing meaningfully affected by removing 64bit IIDs...=
>>
>> But that is exactly what the draft does *not* do. Nobody would
>> change a single instruction in existing code as a result of this >> draft. (I agree with you that some O/S stacks may need fixing, but=
>> they already need fixing.)
>
> is this draft exactly:
>
>=C2=A0 =C2=A0 IPv6 unicast routing is based on prefixes of any valid le= ngth up to
>=C2=A0 =C2=A0 128 [BCP198].=C2=A0 Interface Identifiers should be 64 bi= t long except
>=C2=A0 =C2=A0 when the addresses are manually configured, or by excepti= ons defined
>=C2=A0 =C2=A0 in standards track documents.=C2=A0 For example, [RFC6164= ] standardises
>=C2=A0 =C2=A0 127 bit prefixes on inter-router point-to-point links.=C2= =A0 The rationale
>=C2=A0 =C2=A0 for using 64 bit Interface Identifiers can be found in [R= FC7421]
>
> ?

Yes. Put those words in 4291bis and I will be very happy. Oh ;-).


I recall a small but vocal group argu= ing fiercely against that text adjustment, so here we are.=C2=A0
=
Kind regards,

Job

--001a1143678e05a703055153025b-- From nobody Tue Jun 6 18:14:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5374129503 for ; Tue, 6 Jun 2017 18:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf6l_3M2U4b8 for ; Tue, 6 Jun 2017 18:14:23 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 55A591294E7 for ; Tue, 6 Jun 2017 18:14:23 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id u19so90242947qta.3 for ; Tue, 06 Jun 2017 18:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+Uxiod5QW+czwZXe5OYHRNpL2VJR/fPx1pjhYyDddTw=; b=H1iqY03I1a2MDozLJqUttdF1ymljC6/hdJ//rmsWRuPzasFb5vv6rIx/84cPJyWCiO fmeDecU+PG4msVVzaGKHLfLFgB98RG8HU3g+N9uhGLWENL8y+AfT5HGycsH/c+cWVGE5 7vu7XXw9wzTtYyCCIYN3AJVWySvYQcYiZnmcOjpGZO9WgI1pl3YwyWVY7lV2Q615OGMw G505MKbuzy31au6orih63tVug7GWcvAbzR/lOHOMDxNEb8iMqm5R1VMrVME2AbXIOGA0 Zt5uAPgjniZR0j0jd/nf1+yPkQZu2ARybqlDrZAmefaMub/DpvQzI1P1cFLzBZzYz7c/ EmFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+Uxiod5QW+czwZXe5OYHRNpL2VJR/fPx1pjhYyDddTw=; b=DlftX3bozJNp/rmVBqjHSXB5E5utXvHVwL5FQNKP83S/Wl0LaMrt3wMGmzZ/0sCRKY L5+ydS52zBx4OvKn5brFbEJitZlvADc+Cr0l+vKUfI9Jl8WHc3vBMFGlfe25d6a+66Cx 4H7gMruknai43Vq1cOvU1PvwiQ8UGp/fjmAUdYXh9aRpf8648MYBgIrAMa6yss8ifSxS yDKGufkQCmac8lMcMcEwmAwiNPS3310j5rsPznRwQqbZR7nHNOffO65Dqpr4iAZGukji FjTVXwAzTQcyUSJFYVhjKyiwU80ACssPwHj8WLyT6SLVr4ls7bKQs7IAxXMD3iztXsHW u5jQ== X-Gm-Message-State: AKS2vOwDWU1LVfmIqHqTBieaQl+nXBCbH/veHq4uKSqtVhWFctjRUkkV vpcZl29d81c+xLXzMFERcnclKt+yPw== X-Received: by 10.200.8.169 with SMTP id v38mr30996492qth.213.1496798062356; Tue, 06 Jun 2017 18:14:22 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Tue, 6 Jun 2017 18:14:21 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 6 Jun 2017 18:14:21 -0700 X-Google-Sender-Auth: 9iuk6b85cLVitBgY0ICFVDxhv8Y Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: Brian E Carpenter , Ole Troan , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:14:25 -0000 At Tue, 06 Jun 2017 23:30:30 +0000, Job Snijders wrote: > > >> But that is exactly what the draft does *not* do. Nobody would > > >> change a single instruction in existing code as a result of this > > >> draft. (I agree with you that some O/S stacks may need fixing, but > > >> they already need fixing.) > > > > > > is this draft exactly: > > > > > > IPv6 unicast routing is based on prefixes of any valid length up to > > > 128 [BCP198]. Interface Identifiers should be 64 bit long except > > > when the addresses are manually configured, or by exceptions defined > > > in standards track documents. For example, [RFC6164] standardises > > > 127 bit prefixes on inter-router point-to-point links. The rationale > > > for using 64 bit Interface Identifiers can be found in [RFC7421] > > > > > > ? > > > > Yes. Put those words in 4291bis and I will be very happy. Oh ;-). > > I recall a small but vocal group arguing fiercely against that text > adjustment, so here we are. As several people including myself have already pointed out, it's very hard for ordinary readers to understand that's really what draft-bourbaki-6man-classless-ipv6-00 tries to propose. It will have to be heavily revised to convey that message. As for the above text, my recollection is that some people (I don't know if that was a small group, btw - to me both groups looked equally vocal and equally small/large) were against one specific point in text like the above one: - "should be 64" instead of "must be 64" (but in my understanding they were/are okay with "except when the addresses are manually configured") It's also not clear to me whether the real intent of draft-bourbaki-6man-classless-ipv6-00 includes the subtle (but seemingly very important for those who were "fiercely against" it) change from "must" to "should". I guess if the authors of 6man-classless-ipv6 are actually also happy/okay with this one: IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198]. Interface Identifiers must be 64 bit long except when the addresses are manually configured, or by exceptions defined in standards track documents. For example, [RFC6164] standardises 127 bit prefixes on inter-router point-to-point links. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421] then there will be no dispute or further time wasting (we'll still need to decide what to do with the magic leading bits of 000 in terms of the interface identifier length, but if we can agree at this level this will be a relatively minor point to address). -- JINMEI, Tatuya From nobody Tue Jun 6 18:23:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85571129557 for ; Tue, 6 Jun 2017 18:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKCJ9o4OiM9J for ; Tue, 6 Jun 2017 18:23:31 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83A412953F for ; Tue, 6 Jun 2017 18:23:31 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id g66so29877907vki.1 for ; Tue, 06 Jun 2017 18:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=H072A26gE2LcCJQ2S+geCJrzX2Ddmqr+UhpN4/nqOjw=; b=FkHTX489FQOiDT6xOqAUbclOkGIneOfor7HGoJY5n6xJ808jRBbJEIXLK23oRIy37F wpEQ+hHerjkrORAzGSBIK00rT9K/9qJpsYhFfbkbUN0RAjzJBqIJwShShcyyo/BWCVRr k8AuFmOGOjteAlTA/VJPLUj1V4w6U9tFNe9gNx0dYeLdctmYOiwsYd4aIwqS6iQz7PUM 7U1xaeXkQvBj6uDayKTBMfUy/QNGds7bGuguRjHwqlT7N/D9kP5kMbG3dcXE3COHcloK lehtU1vC3zasSnOBtQT5R4XfgEjM/tKjjHWigl3cRi1QH8EH7o1MgNB4R1PjKVFe7VPg FmUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=H072A26gE2LcCJQ2S+geCJrzX2Ddmqr+UhpN4/nqOjw=; b=cDG1qLd3Ob9Af17ZflkGssQDaRgQMixxE8DVoSOiLNFbup4NUmFJoLH5+RBYMDS+OX YVfZZj5m8L77/z1YsT50VcZy3U15EQpb4wN2MZ57ayvIcrow3tBYePs+u7ghlL7ndHdD Y9E5tb8jUDZDyP8e2VSFiy1kXNMMqyq+tH29okj+RQex3q9eCyKCAWDwZpFjhifvSlPO FZbViX7JD5DzlFJfLOMcLonj8t9/G1xtCBWZ4k/3dMiNudNmwFptXFjeJE36JRHbLkeB FnaFkYfrEt5zckpkFsRShKB3w4LpVmpwe5QpZ03AAcaSuI1f+LGbOXdmpxQWVlLSUdtw mmnQ== X-Gm-Message-State: AODbwcCwTfSFj41pdZQ/wwRVhEZtYmsqcQIk4YQ7n96KNDHTQbJjA4My MwP6nz3WxYh9B+o0scEI0ClVPijGuA== X-Received: by 10.31.132.74 with SMTP id g71mr15163712vkd.93.1496798610601; Tue, 06 Jun 2017 18:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.86.29 with HTTP; Tue, 6 Jun 2017 18:23:00 -0700 (PDT) From: Mark Smith Date: Wed, 7 Jun 2017 11:23:00 +1000 Message-ID: Subject: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Job Snijders Cc: Brian E Carpenter , Ole Troan , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:23:33 -0000 On 7 June 2017 at 09:30, Job Snijders wrote: > On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter > wrote: >> >> > >> > is this draft exactly: >> > >> > IPv6 unicast routing is based on prefixes of any valid length up to >> > 128 [BCP198]. Interface Identifiers should be 64 bit long except >> > when the addresses are manually configured, or by exceptions defined >> > in standards track documents. For example, [RFC6164] standardises >> > 127 bit prefixes on inter-router point-to-point links. The rationale >> > for using 64 bit Interface Identifiers can be found in [RFC7421] >> > >> > ? >> >> Yes. Put those words in 4291bis and I will be very happy. Oh ;-). > "Interface Identifiers should be 64 bit long except when the addresses are manually configured, or by exceptions defined in standards track documents." That doesn't mention that security and privacy properties of addresses will be compromised if the manually configured addresses are from a small prefix. Security and privacy properties of addresses are independent of the method used to configure them. Addresses configured via SLAAC, DHCPv6 or manual configuration from within a small prefix/address range all lose privacy and security properties and value. Job and others might say those privacy and security properties of large addresses is only useful to hosts, not infrastructure such as routers. I disagree. Large addresses can be of value in infrastructure addressing too. If a network operator wants to significantly mitigate if not prevent an attack such as a BGP listener TCP SYN attack from the Internet, they can hide the router's interface address somewhere inside a /64 so that the attacker can't find it via unsolicited inbound probing. If the attacker decides to persist, they'll have to resort to other methods to discover the device that are or can be made more costly. If a network operator's router vendor supports RFC7217 for interface addresses, they get that security advantage of large addresses by default when they add the /64 to the interface. Router interfaces are one of the motivations for RFC7217 being able to use the interface ifIndex value for the Net_Iface parameter (Appendix A) - the comment about ifIndexes being enabled to be consistent across network interface changes was my suggestion, and the use case in my mind was router interface module swaps. It is self evident that a packet that cannot reach a device cannot be used to attack the device. Perhaps those who commented during rfc4291bis last call and who may not have seen the WG's addressing privacy and security discussions over the last 4 years haven't realised that many more addressing bits can provide more capability and value than just the ability to connect more hosts. Regards, Mark. From nobody Tue Jun 6 19:32:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172F4129B02 for ; Tue, 6 Jun 2017 19:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_dZn3KyfBj0 for ; Tue, 6 Jun 2017 19:32:53 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 E2D6A126DFB for <6man@ietf.org>; Tue, 6 Jun 2017 19:32:52 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id v104so154021wrb.0 for <6man@ietf.org>; Tue, 06 Jun 2017 19:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rDK/cOMnaNlgvGuvg0APwVXIdzLhdPuBQga0j53pi2E=; b=TX+iEfrx2IwcrEIQb5c2Is66u4YA1P0HMT3YXrpv7PjMhfoU2kLWF8uyQUTwwiW4Zl Hr0Ot+en60rgIevdnEffX5aBmJ5dIAk5NKopJaVGddIn+bY37+dUn2GCE7GP665nItWB cO9vcsa+ZnBCz5JAQBSJXa0PPkzct0fT+IlK8zEnZj4i2hw5T0CzOq4Is/xkuA9uY7Jk QIigzslr/c11iJ5Jx9ilQRbF2orZgtTJiuAHWLHNcvW7Qr3XLCIgC+UFKiCCeLVUA8qW GFZMOpfYrOg7aRiyCCiunDScp0NSf8f04pk//RW9aNW/7C2jr2nRjIv8+Iv4o2CvMV0x eCMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rDK/cOMnaNlgvGuvg0APwVXIdzLhdPuBQga0j53pi2E=; b=BR0h0bIYiC1ix2Cbg4qJPDH/mTb7oz5s84jzxj8eaiT9uZUHpTXv3TdnR3zTxvfMSf 2EKJe53xrJljOg4b0jbVPFwE7CNkCtp+OXgdQ3g7HmIEkIlGhstanIXqQz79vm+gaaGU Og3W2pB7Ng7qGiByZi7m1mFFMBTOLsY5QxlAHo/gL7oU3JJp1Lm48c1MANOGr0nItKoi vW7na1qOJ0iV3RAl9MwvOYmpMCzSs5/kJEhJNCv+80Gs57cFVB5Fxl+9wPrBH7lV4k9T PnnL8sCk9wVoUhikzsycyOLp090uFOeUBlBLeanipjzv0qN0BbNQ3fnLHON4DXD6/Qhq /3lQ== X-Gm-Message-State: AODbwcDAcqt9qeFKHo7a1NxHNNyWZAstm3iO7QfilSRkBxHxTaCWD19a chJxV6avp0UWOHrZ9T4TNtu8oo2QhNRV X-Received: by 10.223.183.32 with SMTP id l32mr11688188wre.115.1496802771265; Tue, 06 Jun 2017 19:32:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 19:32:50 -0700 (PDT) In-Reply-To: <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> From: Tom Herbert Date: Tue, 6 Jun 2017 19:32:50 -0700 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: "Joel M. Halpern" Cc: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 02:32:55 -0000 On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern wrote: > If what you are now saying Tom is that ILA would work better with a > different address arrangement, I guess you would know better than I. From > what I had seen, it seemed likely that if ILA will work for mobiles at all, > it will work with the current /64 boundary. But your invention, your > judgment. > > As for ILNP, if you want to understand how it works, in general, for data > centers, or for mobility, I suggest reading the RFCs. Any paraphrase I > provided in a short email would probably be a disservice both to ILNP and to > the members of this list. > Joel, I did read the drafts and that is what I base my conclusions on. Section 6 of RFC6740 on mobility indicates that a mobile host has a unique identifier, so if each host is already being assigned a /64 there is no room left for the host identifier. Section 6.3 about network mobility indicates that each host in the network is individually mobile which is even more of a problem. This is pertinent to the discussion on /64 addressing since in several RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) split for mobility. Tom > Yours, > Joel > > > On 6/6/17 4:05 PM, Tom Herbert wrote: >> >> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern >> wrote: >>> >>> I have several problems with your description. >>> 1) The address of the Base Station for purposes of communciating with the >>> base station is irrelevant. >>> 2) More importantly, in ILNP, the upper 64 bits are not "over-written". >>> Rather, the sender fills in the correct 64 bits that will route the >>> traffic >>> to the right place to reach the UE. Thus, the modile operator can >>> allocate >>> the structure of the locators (within their allocated IPv6 address block) >>> so >>> as to enable the use of effective and scalable IP routing to reach the UE >>> without over-writing anything. >> >> >> Can you provide concrete end to end example for this similar to mine. >> That is how an external host can reach an address in a UE that is >> moving around in a mobile network. >> >>> I presume it is accidental, but your description of ILNP does not match >>> the >>> RFCs, including the ones that discuss mobility and data center handling. >>> >> I didn't say this was specifically ILNP. The description is consistent >> with ILA. >> >> Thanks, >> Tom >> >>> Yours, >>> Joel >>> >>> >>> On 6/6/17 1:33 PM, Tom Herbert wrote: >>>> >>>> >>>> Hi Joel, >>>> >>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> Tom, I do not follow your reasoning at all. >>>>> I can not tell what you mean by "addressing within the device". >>>> >>>> >>>> >>>> Referring to the prefix delegated to the device. >>>> >>>>> Even in a data center, one might choose to treat the hypervisor as part >>>>> of >>>>> the network, and allocate a prefix to the hypervisor so it can assign a >>>>> /64 >>>>> locator to each device. Or you could assign separate /64s to each >>>>> entitiy >>>>> within the device from the network directly. Neither requires changing >>>>> the >>>>> IID space. >>>>> >>>> Right, we're not changing the IID space here. We're specifying which >>>> link (subnet) is the IID space relative to. >>>> >>>>> For something that is a single device, like a UE< it is even simpler to >>>>> allow the network to directly assign as many /64 as the device needs. >>>>> >>>>> Note that if the UE is serving as a router for other devices, then >>>>> 1) that is not routing within the device >>>>> 2) the space is likely small enough that routing on the full /128s >>>>> works >>>>> just fine >>>>> >>>>> You have made this assertion a couple of times now, and I can not >>>>> figure >>>>> out >>>>> why you consider the change necessary. ILNP can work fine for mobile >>>>> network UE. >>>> >>>> >>>> >>>> It doesn't work if the UE is assigned a /64, that's my point. The >>>> device is the mobile node that needs to be reflected in the identifier >>>> and then the mapping in the network is mobile device (device >>>> identifier) to locator. The locator is the address of an attachment >>>> point (e.g. base station) in the network. The addresses covered by the >>>> prefix assigned to the device is not relevant in mobility since the >>>> whole prefix follows the device. So what we're really interested in is >>>> which mobile device is the packet being sent to and where is it in the >>>> mobile network. >>>> >>>> I'll give it a shot to show by example. >>>> >>>> Suppose we have a mobile network. Base stations have addresses in the >>>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>>> >>>> Consider a packet is sent to an address within a mobile node with >>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>>> to base station with address 2000:0:0:567::. In identifier/locator the >>>> top sixty-four bits of address are overwritten with the locator for >>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet >>>> will reach the correct base station, but we've lost the address >>>> information for the device so the base station has no way to forward >>>> it on. >>>> >>>> Alternatively, assume the identifier is composed of a 32 bit device >>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>>> the form 3000:0:0:0:0:Z::/32. >>>> >>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty >>>> four bits are overwritten with a locator so the destination on the >>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>>> and it can now be forwarded to the correct device that is identified >>>> by the 0:123 device identifier in the address. >>>> >>>> Hope that helps! >>>> >>>> Tom >>>> >>>> >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>>> >>>>>> >>>>>> >>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>>> identfier/locator split addressing (like in ILNP). The motivation is >>>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>>> compatible with identifier/locator split. The reason is that the link >>>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>>> network. The identifier in a mobile network needs to identify the >>>>>> device. >>>>>> >>>>>> In identifier/locator split, the IP address is split into a locator >>>>>> and identifier. Each are 64 bits (although Brian did point out that >>>>>> that could also be a parameter). Just like IIDs, identifiers must be >>>>>> unique within the subnet. In the case of a mobile network the link is >>>>>> an overlay network that is not physical, but none the less it is a >>>>>> type of link. >>>>>> So the properties of it being a link including those for IIDs on the >>>>>> link hold-- this make identifiers equivalent to IIDs by definition. >>>>>> >>>>>> The IPv6 address for identifier/locator split looks like: >>>>>> >>>>>> M bits for locator >>>>>> N bits for device identifier >>>>>> 128 - M - N bits for addresses within the device >>>>>> >>>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>>> >>>>>> 64 bits for locator >>>>>> 32 bits for device identifier >>>>>> 32 bits for addresses within the device >>>>>> >>>>>> Which implies /96 assignment to each UE. >>>>>> >>>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>>> device, and a 32 bit number assigned by the device. If assignments for >>>>>> both of these are randomized this provides 64 bits of entropy for >>>>>> security. >>>>>> >>>>>> Tom >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>>> >>>>> >>> > From nobody Tue Jun 6 19:40:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B792129AC6 for ; Tue, 6 Jun 2017 19:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux7WhdJlz50m for ; Tue, 6 Jun 2017 19:40:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 697B1129401 for <6man@ietf.org>; Tue, 6 Jun 2017 19:40:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5038A5698D3; Tue, 6 Jun 2017 19:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496803238; bh=TuHX/t8SAOvmJunp4u3EnL5eurnU+tjJSJ+l8VA2dqY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Nfmaua2km/3F8iF0hi3vPnUpwRmFp3koe+hJd+xXP/9wvOFGfRWyzWnbZM54M6XIX bG6zO4aKIVbggObmb9x+aDgJdCo5Wy9QvPp+miKsuo5dAqW9x6b2n7NrphzJrPzkks u9IS+tPtugGYh39WzMkand80VISluUzT7yO4OVyA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 856DA1C043D; Tue, 6 Jun 2017 19:40:37 -0700 (PDT) Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert Cc: 6man@ietf.org References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <8c9874cd-9dde-936e-2c39-8f488cb5fb2c@joelhalpern.com> Date: Tue, 6 Jun 2017 22:40:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 02:40:40 -0000 In ILNP, the Unique Identifier for the host is used as the lower 64 bits of the IPv6 address, while the locator is the upper 64 bits. This was specifically designed with the 64 bit boundary in mind, and works for fixed and mobile hosts. You say that the boundary causes problems for ILA. I believe you. Having worked through multiple cases, it does not cause any problems for the ILNP. Yours, Joel On 6/6/17 10:32 PM, Tom Herbert wrote: > On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern wrote: >> If what you are now saying Tom is that ILA would work better with a >> different address arrangement, I guess you would know better than I. From >> what I had seen, it seemed likely that if ILA will work for mobiles at all, >> it will work with the current /64 boundary. But your invention, your >> judgment. >> >> As for ILNP, if you want to understand how it works, in general, for data >> centers, or for mobility, I suggest reading the RFCs. Any paraphrase I >> provided in a short email would probably be a disservice both to ILNP and to >> the members of this list. >> > Joel, > > I did read the drafts and that is what I base my conclusions on. > Section 6 of RFC6740 on mobility indicates that a mobile host has a > unique identifier, so if each host is already being assigned a /64 > there is no room left for the host identifier. Section 6.3 about > network mobility indicates that each host in the network is > individually mobile which is even more of a problem. > > This is pertinent to the discussion on /64 addressing since in several > RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 > to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) > split for mobility. > > Tom > >> Yours, >> Joel >> >> >> On 6/6/17 4:05 PM, Tom Herbert wrote: >>> >>> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern >>> wrote: >>>> >>>> I have several problems with your description. >>>> 1) The address of the Base Station for purposes of communciating with the >>>> base station is irrelevant. >>>> 2) More importantly, in ILNP, the upper 64 bits are not "over-written". >>>> Rather, the sender fills in the correct 64 bits that will route the >>>> traffic >>>> to the right place to reach the UE. Thus, the modile operator can >>>> allocate >>>> the structure of the locators (within their allocated IPv6 address block) >>>> so >>>> as to enable the use of effective and scalable IP routing to reach the UE >>>> without over-writing anything. >>> >>> >>> Can you provide concrete end to end example for this similar to mine. >>> That is how an external host can reach an address in a UE that is >>> moving around in a mobile network. >>> >>>> I presume it is accidental, but your description of ILNP does not match >>>> the >>>> RFCs, including the ones that discuss mobility and data center handling. >>>> >>> I didn't say this was specifically ILNP. The description is consistent >>> with ILA. >>> >>> Thanks, >>> Tom >>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 6/6/17 1:33 PM, Tom Herbert wrote: >>>>> >>>>> >>>>> Hi Joel, >>>>> >>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>>>> wrote: >>>>>> >>>>>> >>>>>> Tom, I do not follow your reasoning at all. >>>>>> I can not tell what you mean by "addressing within the device". >>>>> >>>>> >>>>> >>>>> Referring to the prefix delegated to the device. >>>>> >>>>>> Even in a data center, one might choose to treat the hypervisor as part >>>>>> of >>>>>> the network, and allocate a prefix to the hypervisor so it can assign a >>>>>> /64 >>>>>> locator to each device. Or you could assign separate /64s to each >>>>>> entitiy >>>>>> within the device from the network directly. Neither requires changing >>>>>> the >>>>>> IID space. >>>>>> >>>>> Right, we're not changing the IID space here. We're specifying which >>>>> link (subnet) is the IID space relative to. >>>>> >>>>>> For something that is a single device, like a UE< it is even simpler to >>>>>> allow the network to directly assign as many /64 as the device needs. >>>>>> >>>>>> Note that if the UE is serving as a router for other devices, then >>>>>> 1) that is not routing within the device >>>>>> 2) the space is likely small enough that routing on the full /128s >>>>>> works >>>>>> just fine >>>>>> >>>>>> You have made this assertion a couple of times now, and I can not >>>>>> figure >>>>>> out >>>>>> why you consider the change necessary. ILNP can work fine for mobile >>>>>> network UE. >>>>> >>>>> >>>>> >>>>> It doesn't work if the UE is assigned a /64, that's my point. The >>>>> device is the mobile node that needs to be reflected in the identifier >>>>> and then the mapping in the network is mobile device (device >>>>> identifier) to locator. The locator is the address of an attachment >>>>> point (e.g. base station) in the network. The addresses covered by the >>>>> prefix assigned to the device is not relevant in mobility since the >>>>> whole prefix follows the device. So what we're really interested in is >>>>> which mobile device is the packet being sent to and where is it in the >>>>> mobile network. >>>>> >>>>> I'll give it a shot to show by example. >>>>> >>>>> Suppose we have a mobile network. Base stations have addresses in the >>>>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>>>> >>>>> Consider a packet is sent to an address within a mobile node with >>>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>>>> to base station with address 2000:0:0:567::. In identifier/locator the >>>>> top sixty-four bits of address are overwritten with the locator for >>>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet >>>>> will reach the correct base station, but we've lost the address >>>>> information for the device so the base station has no way to forward >>>>> it on. >>>>> >>>>> Alternatively, assume the identifier is composed of a 32 bit device >>>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>>>> the form 3000:0:0:0:0:Z::/32. >>>>> >>>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty >>>>> four bits are overwritten with a locator so the destination on the >>>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>>>> and it can now be forwarded to the correct device that is identified >>>>> by the 0:123 device identifier in the address. >>>>> >>>>> Hope that helps! >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>>>> identfier/locator split addressing (like in ILNP). The motivation is >>>>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>>>> compatible with identifier/locator split. The reason is that the link >>>>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>>>> network. The identifier in a mobile network needs to identify the >>>>>>> device. >>>>>>> >>>>>>> In identifier/locator split, the IP address is split into a locator >>>>>>> and identifier. Each are 64 bits (although Brian did point out that >>>>>>> that could also be a parameter). Just like IIDs, identifiers must be >>>>>>> unique within the subnet. In the case of a mobile network the link is >>>>>>> an overlay network that is not physical, but none the less it is a >>>>>>> type of link. >>>>>>> So the properties of it being a link including those for IIDs on the >>>>>>> link hold-- this make identifiers equivalent to IIDs by definition. >>>>>>> >>>>>>> The IPv6 address for identifier/locator split looks like: >>>>>>> >>>>>>> M bits for locator >>>>>>> N bits for device identifier >>>>>>> 128 - M - N bits for addresses within the device >>>>>>> >>>>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>>>> >>>>>>> 64 bits for locator >>>>>>> 32 bits for device identifier >>>>>>> 32 bits for addresses within the device >>>>>>> >>>>>>> Which implies /96 assignment to each UE. >>>>>>> >>>>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>>>> device, and a 32 bit number assigned by the device. If assignments for >>>>>>> both of these are randomized this provides 64 bits of entropy for >>>>>>> security. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>>>> >>>>>> >>>> >> From nobody Tue Jun 6 19:57:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1115128B8F for ; Tue, 6 Jun 2017 19:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGcXsyjk-Hzf for ; Tue, 6 Jun 2017 19:57:50 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570B61273E2 for <6man@ietf.org>; Tue, 6 Jun 2017 19:57:50 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id 141so223559ywe.2 for <6man@ietf.org>; Tue, 06 Jun 2017 19:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H5D5EdEnClqsHALoVRn+8mhFBV9/xbxUHQSSTVjKjFo=; b=W7DeStJN8q8YIJ+iuwRhjPTQ0iq9cgl0OsoSqbb8LHaqElZYiEdgyrmX3BSik0m0+C h4eE9iaU7LL+5En5U37yK0GFfemS0gn855NzYvrWvEQbPTuufTco72OtJdW+nnqq5tak GKRRPCkpKXhMEsNMc6lLUU1ZpuiICy3f2nkI4PbNvJhorcrJCn309A8T9U0QRoQTdeB4 A7/Mo7Ga1PZoB58mWDaYydYeKq3mIoz1gWkk2ehOfgZWrMJr1La18LqkKefJ5AvvOU+z V4Q0A1aHVNEx7omZhWigEl5VVQROVV5m7Vyv4lwsALvfi+qNmVqIdjW1x69Y7D3El05J rfWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H5D5EdEnClqsHALoVRn+8mhFBV9/xbxUHQSSTVjKjFo=; b=Rz1SPm8KRJNuZorevoLqOkeASQIzVlF5Go7Y3hYtYPt+5QSPF5Plp1l/R6oQG3PXpK Iw3ZaJzyiyy7KHuJHt7jLmmjfRYn4nlR//0x8cPQ3DKBVSa+m7DDdoPZ5SwBXDkBqAbX JXhVXO6h3/7BtQZxk+W/uladdjwfceatZwuK5WJCaStmO2ihHokdXPsmfKtaFxTRKmm8 nHSobPZ2sOZ9O0zdq9yTe/TU/biG8p1MFkEvR/Ot3dPsVc1a30eWKHN2+KrQckidmQQg CSWhWF6bDXiKUtnzKnI+5cbVgZSmd3TP58pQwQexrOPr7UClE07OeNQvsUtAwoFUg5Ls HsgA== X-Gm-Message-State: AODbwcDv/5MTnmdZz4R4xs33KahILdO3UO1ZvsG0n7agCkEgOSWHby1y LSHAa5W68zRl8XdKiMRQHraNe8gGEx4x X-Received: by 10.129.76.17 with SMTP id z17mr5554999ywa.42.1496804269374; Tue, 06 Jun 2017 19:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Tue, 6 Jun 2017 19:57:28 -0700 (PDT) In-Reply-To: References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> From: Erik Kline Date: Wed, 7 Jun 2017 11:57:28 +0900 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert Cc: "Joel M. Halpern" , 6man <6man@ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f2bdcccfdfd055155e6f8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 02:57:55 -0000 --001a113f2bdcccfdfd055155e6f8 Content-Type: multipart/alternative; boundary="001a113f2bdcc69e46055155e627" --001a113f2bdcc69e46055155e627 Content-Type: text/plain; charset="UTF-8" On 7 June 2017 at 11:32, Tom Herbert wrote: > On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern > wrote: > > If what you are now saying Tom is that ILA would work better with a > > different address arrangement, I guess you would know better than I. From > > what I had seen, it seemed likely that if ILA will work for mobiles at > all, > > it will work with the current /64 boundary. But your invention, your > > judgment. > > > > As for ILNP, if you want to understand how it works, in general, for data > > centers, or for mobility, I suggest reading the RFCs. Any paraphrase I > > provided in a short email would probably be a disservice both to ILNP > and to > > the members of this list. > > > Joel, > > I did read the drafts and that is what I base my conclusions on. > Section 6 of RFC6740 on mobility indicates that a mobile host has a > unique identifier, so if each host is already being assigned a /64 > there is no room left for the host identifier. Section 6.3 about > network mobility indicates that each host in the network is > individually mobile which is even more of a problem. > > This is pertinent to the discussion on /64 addressing since in several > RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 > to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) > split for mobility. Not really. The identifier assigned by the 3GPP network is basically what the modem uses. In practice, it's just 1 address that's reserved. In practice you want to have a function that does a double check of any new identifier to make sure it's not in use. If an implementation randomly generates the same identifier already assigned this will just be a collision. I don't think there's any issue here. Tom > > > Yours, > > Joel > > > > > > On 6/6/17 4:05 PM, Tom Herbert wrote: > >> > >> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern > >> wrote: > >>> > >>> I have several problems with your description. > >>> 1) The address of the Base Station for purposes of communciating with > the > >>> base station is irrelevant. > >>> 2) More importantly, in ILNP, the upper 64 bits are not "over-written". > >>> Rather, the sender fills in the correct 64 bits that will route the > >>> traffic > >>> to the right place to reach the UE. Thus, the modile operator can > >>> allocate > >>> the structure of the locators (within their allocated IPv6 address > block) > >>> so > >>> as to enable the use of effective and scalable IP routing to reach the > UE > >>> without over-writing anything. > >> > >> > >> Can you provide concrete end to end example for this similar to mine. > >> That is how an external host can reach an address in a UE that is > >> moving around in a mobile network. > >> > >>> I presume it is accidental, but your description of ILNP does not match > >>> the > >>> RFCs, including the ones that discuss mobility and data center > handling. > >>> > >> I didn't say this was specifically ILNP. The description is consistent > >> with ILA. > >> > >> Thanks, > >> Tom > >> > >>> Yours, > >>> Joel > >>> > >>> > >>> On 6/6/17 1:33 PM, Tom Herbert wrote: > >>>> > >>>> > >>>> Hi Joel, > >>>> > >>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern > >>>> wrote: > >>>>> > >>>>> > >>>>> Tom, I do not follow your reasoning at all. > >>>>> I can not tell what you mean by "addressing within the device". > >>>> > >>>> > >>>> > >>>> Referring to the prefix delegated to the device. > >>>> > >>>>> Even in a data center, one might choose to treat the hypervisor as > part > >>>>> of > >>>>> the network, and allocate a prefix to the hypervisor so it can > assign a > >>>>> /64 > >>>>> locator to each device. Or you could assign separate /64s to each > >>>>> entitiy > >>>>> within the device from the network directly. Neither requires > changing > >>>>> the > >>>>> IID space. > >>>>> > >>>> Right, we're not changing the IID space here. We're specifying which > >>>> link (subnet) is the IID space relative to. > >>>> > >>>>> For something that is a single device, like a UE< it is even simpler > to > >>>>> allow the network to directly assign as many /64 as the device needs. > >>>>> > >>>>> Note that if the UE is serving as a router for other devices, then > >>>>> 1) that is not routing within the device > >>>>> 2) the space is likely small enough that routing on the full /128s > >>>>> works > >>>>> just fine > >>>>> > >>>>> You have made this assertion a couple of times now, and I can not > >>>>> figure > >>>>> out > >>>>> why you consider the change necessary. ILNP can work fine for mobile > >>>>> network UE. > >>>> > >>>> > >>>> > >>>> It doesn't work if the UE is assigned a /64, that's my point. The > >>>> device is the mobile node that needs to be reflected in the identifier > >>>> and then the mapping in the network is mobile device (device > >>>> identifier) to locator. The locator is the address of an attachment > >>>> point (e.g. base station) in the network. The addresses covered by the > >>>> prefix assigned to the device is not relevant in mobility since the > >>>> whole prefix follows the device. So what we're really interested in is > >>>> which mobile device is the packet being sent to and where is it in the > >>>> mobile network. > >>>> > >>>> I'll give it a shot to show by example. > >>>> > >>>> Suppose we have a mobile network. Base stations have addresses in the > >>>> form 2000:0:0:X:: where X is unique for each base station. UEs are > >>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. > >>>> > >>>> Consider a packet is sent to an address within a mobile node with > >>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached > >>>> to base station with address 2000:0:0:567::. In identifier/locator the > >>>> top sixty-four bits of address are overwritten with the locator for > >>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet > >>>> will reach the correct base station, but we've lost the address > >>>> information for the device so the base station has no way to forward > >>>> it on. > >>>> > >>>> Alternatively, assume the identifier is composed of a 32 bit device > >>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in > >>>> the form 3000:0:0:0:0:Z::/32. > >>>> > >>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty > >>>> four bits are overwritten with a locator so the destination on the > >>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, > >>>> and it can now be forwarded to the correct device that is identified > >>>> by the 0:123 device identifier in the address. > >>>> > >>>> Hope that helps! > >>>> > >>>> Tom > >>>> > >>>> > >>>> > >>>>> > >>>>> Yours, > >>>>> Joel > >>>>> > >>>>> > >>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is > >>>>>> identfier/locator split addressing (like in ILNP). The motivation is > >>>>>> valid, however assigning a /64 to UEs in a mobile network is not > >>>>>> compatible with identifier/locator split. The reason is that the > link > >>>>>> of interest for IIDs is not inside the UE, but is logically in the > >>>>>> network. The identifier in a mobile network needs to identify the > >>>>>> device. > >>>>>> > >>>>>> In identifier/locator split, the IP address is split into a locator > >>>>>> and identifier. Each are 64 bits (although Brian did point out that > >>>>>> that could also be a parameter). Just like IIDs, identifiers must be > >>>>>> unique within the subnet. In the case of a mobile network the link > is > >>>>>> an overlay network that is not physical, but none the less it is a > >>>>>> type of link. > >>>>>> So the properties of it being a link including those for IIDs on the > >>>>>> link hold-- this make identifiers equivalent to IIDs by definition. > >>>>>> > >>>>>> The IPv6 address for identifier/locator split looks like: > >>>>>> > >>>>>> M bits for locator > >>>>>> N bits for device identifier > >>>>>> 128 - M - N bits for addresses within the device > >>>>>> > >>>>>> M is 64, and it seems straightforward to make N be 32 so we get > >>>>>> > >>>>>> 64 bits for locator > >>>>>> 32 bits for device identifier > >>>>>> 32 bits for addresses within the device > >>>>>> > >>>>>> Which implies /96 assignment to each UE. > >>>>>> > >>>>>> Thus the IID is constructed from a 32 bit number assigned to the > >>>>>> device, and a 32 bit number assigned by the device. If assignments > for > >>>>>> both of these are randomized this provides 64 bits of entropy for > >>>>>> security. > >>>>>> > >>>>>> Tom > >>>>>> > >>>>>> ------------------------------------------------------------ > -------- > >>>>>> IETF IPv6 working group mailing list > >>>>>> ipv6@ietf.org > >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>>> ------------------------------------------------------------ > -------- > >>>>>> > >>>>> > >>> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113f2bdcc69e46055155e627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 7 June 2017 at 11:32, Tom Herbert <tom@herbertland.com> wrote:
On Tue, Jun = 6, 2017 at 1:44 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> If what you are now saying Tom is that ILA would work better with a > different address arrangement, I guess you would know better than I. F= rom
> what I had seen, it seemed likely that if ILA will work for mobiles at= all,
> it will work with the current /64 boundary.=C2=A0 But your invention, = your
> judgment.
>
> As for ILNP, if you want to understand how it works, in general, for d= ata
> centers, or for mobility, I suggest reading the RFCs.=C2=A0 Any paraph= rase I
> provided in a short email would probably be a disservice both to ILNP = and to
> the members of this list.
>
Joel,

I did read the drafts and that is what I base my conclusions on.
Section 6 of RFC6740 on mobility indicates that a mobile host has a
unique identifier, so if each host is already being assigned a /64
there is no room left for the host identifier. Section 6.3 about
network mobility indicates that each host in the network is
individually mobile which is even more of a problem.

This is pertinent to the discussion on /64 addressing since in several
RFCs a motivation for that is ILNP or ILA. I claim that assigning /64
to UEs prevents using ILNP, ILA, or any identifier/locator (64/64)
split for mobility.

Not really.=C2=A0 The i= dentifier assigned by the 3GPP network is basically what the modem uses.=C2= =A0 In practice, it's just 1 address that's reserved.=C2=A0 In prac= tice you want to have a function that does a double check of any new identi= fier to make sure it's not in use.=C2=A0 If an implementation randomly = generates the same identifier already assigned this will just be a collisio= n.

I don't think there's any issue here.

Tom

> Yours,
> Joel
>
>
> On 6/6/17 4:05 PM, Tom Herbert wrote:
>>
>> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern <jmh@joelhalpern.com>
>> wrote:
>>>
>>> I have several problems with your description.
>>> 1) The address of the Base Station for purposes of communciati= ng with the
>>> base station is irrelevant.
>>> 2) More importantly, in ILNP, the upper 64 bits are not "= over-written".
>>> Rather, the sender fills in the correct 64 bits that will rout= e the
>>> traffic
>>> to the right place to reach the UE. Thus, the modile operator = can
>>> allocate
>>> the structure of the locators (within their allocated IPv6 add= ress block)
>>> so
>>> as to enable the use of effective and scalable IP routing to r= each the UE
>>> without over-writing anything.
>>
>>
>> Can you provide concrete end to end example for this similar to mi= ne.
>> That is how an external host can reach an address in a UE that is<= br> >> moving around in a mobile network.
>>
>>> I presume it is accidental, but your description of ILNP does = not match
>>> the
>>> RFCs, including the ones that discuss mobility and data center= handling.
>>>
>> I didn't say this was specifically ILNP. The description is co= nsistent
>> with ILA.
>>
>> Thanks,
>> Tom
>>
>>> Yours,
>>> Joel
>>>
>>>
>>> On 6/6/17 1:33 PM, Tom Herbert wrote:
>>>>
>>>>
>>>> Hi Joel,
>>>>
>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern <jmh@joelhalpern.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Tom, I do not follow your reasoning at all.
>>>>> I can not tell what you mean by "addressing withi= n the device".
>>>>
>>>>
>>>>
>>>> Referring to the prefix delegated to the device.
>>>>
>>>>> Even in a data center, one might choose to treat the h= ypervisor as part
>>>>> of
>>>>> the network, and allocate a prefix to the hypervisor s= o it can assign a
>>>>> /64
>>>>> locator to each device.=C2=A0 Or you could assign sepa= rate /64s to each
>>>>> entitiy
>>>>> within the device from the network directly.=C2=A0 Nei= ther requires changing
>>>>> the
>>>>> IID space.
>>>>>
>>>> Right, we're not changing the IID space here. We'r= e specifying which
>>>> link (subnet) is the IID space relative to.
>>>>
>>>>> For something that is a single device, like a UE< i= t is even simpler to
>>>>> allow the network to directly assign as many /64 as th= e device needs.
>>>>>
>>>>> Note that if the UE is serving as a router for other d= evices, then
>>>>> 1) that is not routing within the device
>>>>> 2) the space is likely small enough that routing on th= e full /128s
>>>>> works
>>>>> just fine
>>>>>
>>>>> You have made this assertion a couple of times now, an= d I can not
>>>>> figure
>>>>> out
>>>>> why you consider the change necessary.=C2=A0 ILNP can = work fine for mobile
>>>>> network UE.
>>>>
>>>>
>>>>
>>>> It doesn't work if the UE is assigned a /64, that'= s my point. The
>>>> device is the mobile node that needs to be reflected in th= e identifier
>>>> and then the mapping in the network is mobile device (devi= ce
>>>> identifier) to locator. The locator is the address of an a= ttachment
>>>> point (e.g. base station) in the network. The addresses co= vered by the
>>>> prefix assigned to the device is not relevant in mobility = since the
>>>> whole prefix follows the device. So what we're really = interested in is
>>>> which mobile device is the packet being sent to and where = is it in the
>>>> mobile network.
>>>>
>>>> I'll give it a shot to show by example.
>>>>
>>>> Suppose we have a mobile network. Base stations have addre= sses in the
>>>> form 2000:0:0:X:: where X is unique for each base station.= UEs are
>>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses= the UE.
>>>>
>>>> Consider a packet is sent to an address within a mobile no= de with
>>>> external address 3000:0:0:123:0:0:0:1. Assume the device i= s attached
>>>> to base station with address 2000:0:0:567::. In identifier= /locator the
>>>> top sixty-four bits of address are overwritten with the lo= cator for
>>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1= . The packet
>>>> will reach the correct base station, but we've lost th= e address
>>>> information for the device so the base station has no way = to forward
>>>> it on.
>>>>
>>>> Alternatively, assume the identifier is composed of a 32 b= it device
>>>> identifier and 32 bits delegated to UE. Now UEs are assign= ed /32 in
>>>> the form 3000:0:0:0:0:Z::/32.
>>>>
>>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again t= he top sixty
>>>> four bits are overwritten with a locator so the destinatio= n on the
>>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the bas= e station,
>>>> and it can now be forwarded to the correct device that is = identified
>>>> by the 0:123 device identifier in the address.
>>>>
>>>> Hope that helps!
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>>
>>>>> On 6/6/17 11:54 AM, Tom Herbert wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Both RFC7421 and RFC7136 state that a motivation f= or the /64 is
>>>>>> identfier/locator split addressing (like in ILNP).= The motivation is
>>>>>> valid, however assigning a /64 to UEs in a mobile = network is not
>>>>>> compatible with identifier/locator split. The reas= on is that the link
>>>>>> of interest for IIDs is not inside the UE, but is = logically in the
>>>>>> network. The identifier in a mobile network needs = to identify the
>>>>>> device.
>>>>>>
>>>>>> In identifier/locator split, the IP address is spl= it into a locator
>>>>>> and identifier. Each are 64 bits (although Brian d= id point out that
>>>>>> that could also be a parameter). Just like IIDs, i= dentifiers must be
>>>>>> unique within the subnet. In the case of a mobile = network the link is
>>>>>> an overlay network that is not physical, but none = the less it is a
>>>>>> type of link.
>>>>>> So the properties of it being a link including tho= se for IIDs on the
>>>>>> link hold-- this make identifiers equivalent to II= Ds by definition.
>>>>>>
>>>>>> The IPv6 address for identifier/locator split look= s like:
>>>>>>
>>>>>> M bits for locator
>>>>>> N bits for device identifier
>>>>>> 128 - M - N bits for addresses within the device >>>>>>
>>>>>> M is 64, and it seems straightforward to make N be= 32 so we get
>>>>>>
>>>>>> 64 bits for locator
>>>>>> 32 bits for device identifier
>>>>>> 32 bits for addresses within the device
>>>>>>
>>>>>> Which implies /96 assignment to each UE.
>>>>>>
>>>>>> Thus the IID is constructed from a 32 bit number a= ssigned to the
>>>>>> device, and a 32 bit number assigned by the device= . If assignments for
>>>>>> both of these are randomized this provides 64 bits= of entropy for
>>>>>> security.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> ---------------------------------------------= -----------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org=
>>>>>> Administrative Requests: https://= www.ietf.org/mailman/listinfo/ipv6
>>>>>> ---------------------------------------------= -----------------------
>>>>>>
>>>>>
>>>
>

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

--001a113f2bdcc69e46055155e627-- --001a113f2bdcccfdfd055155e6f8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgrnQvHqrYONMXBNIkH8GvcVKblUp1JRnB VjGNn7UcFtQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjA3 MDI1NzQ5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAB0pL0nF+JXDOQIeB5AwXQnQQYJ+EryS0Lj3Naqo6QZL5yaoMw4g TGmL8EpZZZXd7mphJuXirHfuVK2rngkPqXezhZdO8BDlepiYP1SL8knQQL3wyNJeSmNYziM7C1yJ 5vifFB6ylGAACEn5VyliuOtDW+7UIq7P+K/TV2udBGmmLbdoylPLiU83zTuj0NaSjdbEkjJnzL2x 7k6RPKpVnayIQ99DxGR5PHVDyATQfHzdcq+xvbOS5oxx8lat0J0+R3YylANsPDobhXILzdFR2d5I trBVVSKvmtNvW9MYj8QtxWO6FM6h2of8wQEC9/gQw6fqS0uSPVETNuNtlLPfIok= --001a113f2bdcccfdfd055155e6f8-- From nobody Tue Jun 6 20:05:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D69F129B37 for ; Tue, 6 Jun 2017 20:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrdJ_p8vKcgW for ; Tue, 6 Jun 2017 20:05:15 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 AA293129B1E for <6man@ietf.org>; Tue, 6 Jun 2017 20:05:14 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id v104so305585wrb.0 for <6man@ietf.org>; Tue, 06 Jun 2017 20:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aCjQhOG0kyMJxOGbFkTRFW8MSFoZSNAp7Y0KZWTab6k=; b=gL4R/viAiNLcFErQPc8eExjO0JZhqRrTAOjbTkLgJx8DYxi0889oYs88qv4xWUcgaF THl4x3Jg1LFC55/mSYo27nwizQFuxMS6LTHMt8GaYGznBCxzapnePdW4PX+LHnxlAa7P 01W5JYAE3D8cOghRWpwNOROMHYv1l+fLbLhBjpaFbh/hdcYv6Hvsyca8VoDbLGgODfAg ow6NWuK8HSpZKYZoAmPFaaxVCl6r1mOADDCd/OIzLHb9Darz8/W+iN84KM8Ld8+koyq5 FZc458Ya7S4CPtXvMuGbLdlFI6YjveR7NFv7s/Ma6yXf9VbVrU903Su27gEsfY2/JABJ HXHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aCjQhOG0kyMJxOGbFkTRFW8MSFoZSNAp7Y0KZWTab6k=; b=a0fw193mRZoUYBMVR6UA0RGy6FSzccNC4p2pv8MzlqmVOz8sSZxKhlzKndZRpNgC5x vZMoZBdHOgHJFLzIutSSNC/XXImrVYDpoehVx6M+jzHQvWwgHxeHSoJbiJbarevrE6zG P1JD8GPv4wFLsXnns13mT6coaQD2jC0tDxzg19+YXBf3GN/IXnpCBlbLMd4Qv+E30/+H v50/EVad9mFx4GsWliOOJcO7aBkg5Zp1mzFrp/KUQrWyDm3lSmXE70ny+gyVCPGYUq6x qe9BnHwVxBZantUh8XB3RoM3lZKYpDF6yeVKf+1XoFI1/6fuosl4RS4Dv3708Debt14b sSXQ== X-Gm-Message-State: AODbwcCKH/8RF93UlcN/QhU5q6BTEMmUabNyi50xv2OAS8mS6lRziARf q3rZGj8Buzr4C8h/LEDD6u9zHnKCxR9tO70= X-Received: by 10.223.128.80 with SMTP id 74mr23401639wrk.30.1496804712624; Tue, 06 Jun 2017 20:05:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 20:05:11 -0700 (PDT) In-Reply-To: <8c9874cd-9dde-936e-2c39-8f488cb5fb2c@joelhalpern.com> References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> <8c9874cd-9dde-936e-2c39-8f488cb5fb2c@joelhalpern.com> From: Tom Herbert Date: Tue, 6 Jun 2017 20:05:11 -0700 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: "Joel M. Halpern" Cc: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:05:17 -0000 On Tue, Jun 6, 2017 at 7:40 PM, Joel M. Halpern wrote: > In ILNP, the Unique Identifier for the host is used as the lower 64 bits of > the IPv6 address, while the locator is the upper 64 bits. > This was specifically designed with the 64 bit boundary in mind, and works > for fixed and mobile hosts. > > You say that the boundary causes problems for ILA. I believe you. Having > worked through multiple cases, it does not cause any problems for the ILNP. > Great. Then I ask again "Can you provide concrete end to end example for this similar to mine?". This would be most helpful. Thanks, Tom > Yours, > Joel > > > On 6/6/17 10:32 PM, Tom Herbert wrote: >> >> On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern >> wrote: >>> >>> If what you are now saying Tom is that ILA would work better with a >>> different address arrangement, I guess you would know better than I. From >>> what I had seen, it seemed likely that if ILA will work for mobiles at >>> all, >>> it will work with the current /64 boundary. But your invention, your >>> judgment. >>> >>> As for ILNP, if you want to understand how it works, in general, for data >>> centers, or for mobility, I suggest reading the RFCs. Any paraphrase I >>> provided in a short email would probably be a disservice both to ILNP and >>> to >>> the members of this list. >>> >> Joel, >> >> I did read the drafts and that is what I base my conclusions on. >> Section 6 of RFC6740 on mobility indicates that a mobile host has a >> unique identifier, so if each host is already being assigned a /64 >> there is no room left for the host identifier. Section 6.3 about >> network mobility indicates that each host in the network is >> individually mobile which is even more of a problem. >> >> This is pertinent to the discussion on /64 addressing since in several >> RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 >> to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) >> split for mobility. >> >> Tom >> >>> Yours, >>> Joel >>> >>> >>> On 6/6/17 4:05 PM, Tom Herbert wrote: >>>> >>>> >>>> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> I have several problems with your description. >>>>> 1) The address of the Base Station for purposes of communciating with >>>>> the >>>>> base station is irrelevant. >>>>> 2) More importantly, in ILNP, the upper 64 bits are not "over-written". >>>>> Rather, the sender fills in the correct 64 bits that will route the >>>>> traffic >>>>> to the right place to reach the UE. Thus, the modile operator can >>>>> allocate >>>>> the structure of the locators (within their allocated IPv6 address >>>>> block) >>>>> so >>>>> as to enable the use of effective and scalable IP routing to reach the >>>>> UE >>>>> without over-writing anything. >>>> >>>> >>>> >>>> Can you provide concrete end to end example for this similar to mine. >>>> That is how an external host can reach an address in a UE that is >>>> moving around in a mobile network. >>>> >>>>> I presume it is accidental, but your description of ILNP does not match >>>>> the >>>>> RFCs, including the ones that discuss mobility and data center >>>>> handling. >>>>> >>>> I didn't say this was specifically ILNP. The description is consistent >>>> with ILA. >>>> >>>> Thanks, >>>> Tom >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 6/6/17 1:33 PM, Tom Herbert wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Joel, >>>>>> >>>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Tom, I do not follow your reasoning at all. >>>>>>> I can not tell what you mean by "addressing within the device". >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Referring to the prefix delegated to the device. >>>>>> >>>>>>> Even in a data center, one might choose to treat the hypervisor as >>>>>>> part >>>>>>> of >>>>>>> the network, and allocate a prefix to the hypervisor so it can assign >>>>>>> a >>>>>>> /64 >>>>>>> locator to each device. Or you could assign separate /64s to each >>>>>>> entitiy >>>>>>> within the device from the network directly. Neither requires >>>>>>> changing >>>>>>> the >>>>>>> IID space. >>>>>>> >>>>>> Right, we're not changing the IID space here. We're specifying which >>>>>> link (subnet) is the IID space relative to. >>>>>> >>>>>>> For something that is a single device, like a UE< it is even simpler >>>>>>> to >>>>>>> allow the network to directly assign as many /64 as the device needs. >>>>>>> >>>>>>> Note that if the UE is serving as a router for other devices, then >>>>>>> 1) that is not routing within the device >>>>>>> 2) the space is likely small enough that routing on the full /128s >>>>>>> works >>>>>>> just fine >>>>>>> >>>>>>> You have made this assertion a couple of times now, and I can not >>>>>>> figure >>>>>>> out >>>>>>> why you consider the change necessary. ILNP can work fine for mobile >>>>>>> network UE. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It doesn't work if the UE is assigned a /64, that's my point. The >>>>>> device is the mobile node that needs to be reflected in the identifier >>>>>> and then the mapping in the network is mobile device (device >>>>>> identifier) to locator. The locator is the address of an attachment >>>>>> point (e.g. base station) in the network. The addresses covered by the >>>>>> prefix assigned to the device is not relevant in mobility since the >>>>>> whole prefix follows the device. So what we're really interested in is >>>>>> which mobile device is the packet being sent to and where is it in the >>>>>> mobile network. >>>>>> >>>>>> I'll give it a shot to show by example. >>>>>> >>>>>> Suppose we have a mobile network. Base stations have addresses in the >>>>>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>>>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>>>>> >>>>>> Consider a packet is sent to an address within a mobile node with >>>>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>>>>> to base station with address 2000:0:0:567::. In identifier/locator the >>>>>> top sixty-four bits of address are overwritten with the locator for >>>>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet >>>>>> will reach the correct base station, but we've lost the address >>>>>> information for the device so the base station has no way to forward >>>>>> it on. >>>>>> >>>>>> Alternatively, assume the identifier is composed of a 32 bit device >>>>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>>>>> the form 3000:0:0:0:0:Z::/32. >>>>>> >>>>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty >>>>>> four bits are overwritten with a locator so the destination on the >>>>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>>>>> and it can now be forwarded to the correct device that is identified >>>>>> by the 0:123 device identifier in the address. >>>>>> >>>>>> Hope that helps! >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> >>>>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>>>>> identfier/locator split addressing (like in ILNP). The motivation is >>>>>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>>>>> compatible with identifier/locator split. The reason is that the >>>>>>>> link >>>>>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>>>>> network. The identifier in a mobile network needs to identify the >>>>>>>> device. >>>>>>>> >>>>>>>> In identifier/locator split, the IP address is split into a locator >>>>>>>> and identifier. Each are 64 bits (although Brian did point out that >>>>>>>> that could also be a parameter). Just like IIDs, identifiers must be >>>>>>>> unique within the subnet. In the case of a mobile network the link >>>>>>>> is >>>>>>>> an overlay network that is not physical, but none the less it is a >>>>>>>> type of link. >>>>>>>> So the properties of it being a link including those for IIDs on the >>>>>>>> link hold-- this make identifiers equivalent to IIDs by definition. >>>>>>>> >>>>>>>> The IPv6 address for identifier/locator split looks like: >>>>>>>> >>>>>>>> M bits for locator >>>>>>>> N bits for device identifier >>>>>>>> 128 - M - N bits for addresses within the device >>>>>>>> >>>>>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>>>>> >>>>>>>> 64 bits for locator >>>>>>>> 32 bits for device identifier >>>>>>>> 32 bits for addresses within the device >>>>>>>> >>>>>>>> Which implies /96 assignment to each UE. >>>>>>>> >>>>>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>>>>> device, and a 32 bit number assigned by the device. If assignments >>>>>>>> for >>>>>>>> both of these are randomized this provides 64 bits of entropy for >>>>>>>> security. >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> -------------------------------------------------------------------- >>>>>>>> IETF IPv6 working group mailing list >>>>>>>> ipv6@ietf.org >>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> -------------------------------------------------------------------- >>>>>>>> >>>>>>> >>>>> >>> > From nobody Tue Jun 6 20:18:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6D129B74 for ; Tue, 6 Jun 2017 20:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFTAykGs_L4Y for ; Tue, 6 Jun 2017 20:18:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 199BD129B5F for <6man@ietf.org>; Tue, 6 Jun 2017 20:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 060D5569FCB; Tue, 6 Jun 2017 20:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496805491; bh=zO2IKSJgRReGo1Oc4nDTPElKRl+PdkVybtEvfzZMcRY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nZjt7TrbV+k0HWJpxusrrRWeKi652puqKuBamHHJZMzMqthJbVZVRXA4vOhWAeM+u ZpKiaYfU4kvkdz7hxjY7O69n3fjAZEUy8aTIPY/LNXIj4m4zkSB0ZJUIs2Um5Uyiiz uQLfYa5oxoKliIDd46WR1rQJkQ2AcuGKFJO4rx3Y= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 554701C02AF; Tue, 6 Jun 2017 20:18:10 -0700 (PDT) Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert Cc: 6man@ietf.org References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> <8c9874cd-9dde-936e-2c39-8f488cb5fb2c@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <2bddb55c-3aa5-cd0c-e1b7-3ebc4c84bf86@joelhalpern.com> Date: Tue, 6 Jun 2017 23:18:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:18:14 -0000 I am really not sure what example you want, but I will try. Suppose that each eNodeB is expected to support up to 1000 simultaneous UEs. (I have not checked whether that is the right number, but we can use it for working an example. Then the operator takes his block (say XXX::/32) And he assigns 11 or 12 bits of space to each eNodeB. He assigns the block to the eNODEB acording to his addressing plan so that one can easily route to it. So one eNodeB might be allocated XXXYZQ/52, and another might get XXXLMN/52, etc. Where the portion after the XXX is allocated according to the topological placement of the eNodeB in the operators network. The eNodeB then assigns /64 locators from its block to each UE. (IN practice, due to th4e way mobile network work, the assignments are done in a more complicate fashion, but they still simply come out of the block associated with each eNodeB. Node that these blocks have nothing formally to do with the address assigned to the eNodeB, although due to simplicity of forwarding one might assign eNodeB local addresses from the same blocks. Or one might segregate for reasons of address isolation. ILNP does not care. The point is that the UE uses the combination of assigned locator and created identifier for its IPV6 communication. And when the UE moves, it sends the ICMP updates to its correspondents. Beyond that we are getting into operational practices for mobile operators, which are not the topic of this discussion. Yours, Joel On 6/6/17 11:05 PM, Tom Herbert wrote: > On Tue, Jun 6, 2017 at 7:40 PM, Joel M. Halpern wrote: >> In ILNP, the Unique Identifier for the host is used as the lower 64 bits of >> the IPv6 address, while the locator is the upper 64 bits. >> This was specifically designed with the 64 bit boundary in mind, and works >> for fixed and mobile hosts. >> >> You say that the boundary causes problems for ILA. I believe you. Having >> worked through multiple cases, it does not cause any problems for the ILNP. >> > Great. Then I ask again "Can you provide concrete end to end example > for this similar to mine?". This would be most helpful. > > Thanks, > Tom > >> Yours, >> Joel >> >> >> On 6/6/17 10:32 PM, Tom Herbert wrote: >>> >>> On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern >>> wrote: >>>> >>>> If what you are now saying Tom is that ILA would work better with a >>>> different address arrangement, I guess you would know better than I. From >>>> what I had seen, it seemed likely that if ILA will work for mobiles at >>>> all, >>>> it will work with the current /64 boundary. But your invention, your >>>> judgment. >>>> >>>> As for ILNP, if you want to understand how it works, in general, for data >>>> centers, or for mobility, I suggest reading the RFCs. Any paraphrase I >>>> provided in a short email would probably be a disservice both to ILNP and >>>> to >>>> the members of this list. >>>> >>> Joel, >>> >>> I did read the drafts and that is what I base my conclusions on. >>> Section 6 of RFC6740 on mobility indicates that a mobile host has a >>> unique identifier, so if each host is already being assigned a /64 >>> there is no room left for the host identifier. Section 6.3 about >>> network mobility indicates that each host in the network is >>> individually mobile which is even more of a problem. >>> >>> This is pertinent to the discussion on /64 addressing since in several >>> RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 >>> to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) >>> split for mobility. >>> >>> Tom >>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 6/6/17 4:05 PM, Tom Herbert wrote: >>>>> >>>>> >>>>> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern >>>>> wrote: >>>>>> >>>>>> >>>>>> I have several problems with your description. >>>>>> 1) The address of the Base Station for purposes of communciating with >>>>>> the >>>>>> base station is irrelevant. >>>>>> 2) More importantly, in ILNP, the upper 64 bits are not "over-written". >>>>>> Rather, the sender fills in the correct 64 bits that will route the >>>>>> traffic >>>>>> to the right place to reach the UE. Thus, the modile operator can >>>>>> allocate >>>>>> the structure of the locators (within their allocated IPv6 address >>>>>> block) >>>>>> so >>>>>> as to enable the use of effective and scalable IP routing to reach the >>>>>> UE >>>>>> without over-writing anything. >>>>> >>>>> >>>>> >>>>> Can you provide concrete end to end example for this similar to mine. >>>>> That is how an external host can reach an address in a UE that is >>>>> moving around in a mobile network. >>>>> >>>>>> I presume it is accidental, but your description of ILNP does not match >>>>>> the >>>>>> RFCs, including the ones that discuss mobility and data center >>>>>> handling. >>>>>> >>>>> I didn't say this was specifically ILNP. The description is consistent >>>>> with ILA. >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 6/6/17 1:33 PM, Tom Herbert wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Joel, >>>>>>> >>>>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Tom, I do not follow your reasoning at all. >>>>>>>> I can not tell what you mean by "addressing within the device". >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Referring to the prefix delegated to the device. >>>>>>> >>>>>>>> Even in a data center, one might choose to treat the hypervisor as >>>>>>>> part >>>>>>>> of >>>>>>>> the network, and allocate a prefix to the hypervisor so it can assign >>>>>>>> a >>>>>>>> /64 >>>>>>>> locator to each device. Or you could assign separate /64s to each >>>>>>>> entitiy >>>>>>>> within the device from the network directly. Neither requires >>>>>>>> changing >>>>>>>> the >>>>>>>> IID space. >>>>>>>> >>>>>>> Right, we're not changing the IID space here. We're specifying which >>>>>>> link (subnet) is the IID space relative to. >>>>>>> >>>>>>>> For something that is a single device, like a UE< it is even simpler >>>>>>>> to >>>>>>>> allow the network to directly assign as many /64 as the device needs. >>>>>>>> >>>>>>>> Note that if the UE is serving as a router for other devices, then >>>>>>>> 1) that is not routing within the device >>>>>>>> 2) the space is likely small enough that routing on the full /128s >>>>>>>> works >>>>>>>> just fine >>>>>>>> >>>>>>>> You have made this assertion a couple of times now, and I can not >>>>>>>> figure >>>>>>>> out >>>>>>>> why you consider the change necessary. ILNP can work fine for mobile >>>>>>>> network UE. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It doesn't work if the UE is assigned a /64, that's my point. The >>>>>>> device is the mobile node that needs to be reflected in the identifier >>>>>>> and then the mapping in the network is mobile device (device >>>>>>> identifier) to locator. The locator is the address of an attachment >>>>>>> point (e.g. base station) in the network. The addresses covered by the >>>>>>> prefix assigned to the device is not relevant in mobility since the >>>>>>> whole prefix follows the device. So what we're really interested in is >>>>>>> which mobile device is the packet being sent to and where is it in the >>>>>>> mobile network. >>>>>>> >>>>>>> I'll give it a shot to show by example. >>>>>>> >>>>>>> Suppose we have a mobile network. Base stations have addresses in the >>>>>>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>>>>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>>>>>> >>>>>>> Consider a packet is sent to an address within a mobile node with >>>>>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>>>>>> to base station with address 2000:0:0:567::. In identifier/locator the >>>>>>> top sixty-four bits of address are overwritten with the locator for >>>>>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet >>>>>>> will reach the correct base station, but we've lost the address >>>>>>> information for the device so the base station has no way to forward >>>>>>> it on. >>>>>>> >>>>>>> Alternatively, assume the identifier is composed of a 32 bit device >>>>>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>>>>>> the form 3000:0:0:0:0:Z::/32. >>>>>>> >>>>>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty >>>>>>> four bits are overwritten with a locator so the destination on the >>>>>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>>>>>> and it can now be forwarded to the correct device that is identified >>>>>>> by the 0:123 device identifier in the address. >>>>>>> >>>>>>> Hope that helps! >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> >>>>>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>>>>>> identfier/locator split addressing (like in ILNP). The motivation is >>>>>>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>>>>>> compatible with identifier/locator split. The reason is that the >>>>>>>>> link >>>>>>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>>>>>> network. The identifier in a mobile network needs to identify the >>>>>>>>> device. >>>>>>>>> >>>>>>>>> In identifier/locator split, the IP address is split into a locator >>>>>>>>> and identifier. Each are 64 bits (although Brian did point out that >>>>>>>>> that could also be a parameter). Just like IIDs, identifiers must be >>>>>>>>> unique within the subnet. In the case of a mobile network the link >>>>>>>>> is >>>>>>>>> an overlay network that is not physical, but none the less it is a >>>>>>>>> type of link. >>>>>>>>> So the properties of it being a link including those for IIDs on the >>>>>>>>> link hold-- this make identifiers equivalent to IIDs by definition. >>>>>>>>> >>>>>>>>> The IPv6 address for identifier/locator split looks like: >>>>>>>>> >>>>>>>>> M bits for locator >>>>>>>>> N bits for device identifier >>>>>>>>> 128 - M - N bits for addresses within the device >>>>>>>>> >>>>>>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>>>>>> >>>>>>>>> 64 bits for locator >>>>>>>>> 32 bits for device identifier >>>>>>>>> 32 bits for addresses within the device >>>>>>>>> >>>>>>>>> Which implies /96 assignment to each UE. >>>>>>>>> >>>>>>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>>>>>> device, and a 32 bit number assigned by the device. If assignments >>>>>>>>> for >>>>>>>>> both of these are randomized this provides 64 bits of entropy for >>>>>>>>> security. >>>>>>>>> >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> -------------------------------------------------------------------- >>>>>>>>> IETF IPv6 working group mailing list >>>>>>>>> ipv6@ietf.org >>>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> -------------------------------------------------------------------- >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From nobody Tue Jun 6 20:24:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCED0129B55 for ; Tue, 6 Jun 2017 20:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rALm8L3kG59Q for ; Tue, 6 Jun 2017 20:24:52 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 D3850124D6C for ; Tue, 6 Jun 2017 20:24:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 5D7C8B42 for ; Wed, 7 Jun 2017 03:24:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqDvVoKvGFd0 for ; Tue, 6 Jun 2017 22:24:51 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 0AD3CB39 for ; Tue, 6 Jun 2017 22:24:50 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id j32so220391uaj.12 for ; Tue, 06 Jun 2017 20:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4ZWmw+DGSnaq/26qWvEeD/FSPA7lItZ6QdEPjAusdas=; b=QVjbaK2co6JDxYACR466Vu8PYsICAgc6iW6d2yY4FIPnKUQdDWtlPtsSjQUluZOWT6 /Totjh/82oi1SEoZQUUnYjZ//qI5DGOIUOzr/Jf9ZFdQ7l7QSX2N5hyDhScFefZvppI+ 9MbZha/+lg2Ey6kH6QeWU4424CboCcjmzepmYnDUUyTamVg4V7JN4MadQe1LcBv7S0PY EeRUCaxoQGCfMxuPm6RVuip2fVkrABwScXOU3j8QmOtNJ68fAwVFbT5W915G3+NF5eRi jLn/e1HRZV8C1JPKR2nvITNQ8fv5AXx2dNUdSdgki4O8Qtr4gJNWSUsgw/ZhXI5OAjLh otzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4ZWmw+DGSnaq/26qWvEeD/FSPA7lItZ6QdEPjAusdas=; b=Zrhdh45SV8J7Atw5E5uoXx9NI7s2tLIJV9KgKM9tRh4I16eHbyS0VNGYwyTzRcW5xa aZM8KKQwP2wjAvWV1CJEH7hC7+xz3H23SQP3BoMZz7rJpnJLMAhytW2baS44JlWmxtTw DAEOCW6QrFX6J6q/vm3cXQWNDt558j6buUzj96zG4GcnwNuUzAZaBzdd+r5NQHmcfqxN fDl7AEeLY1/oUAlOHFxkdHRe9n9E6/8gYcrh/7BQ6kdhFnmZjHMvUwb2Eo3v8T7uWSbe PgzH/gh5lgOhvBJ0G9TwlfjSnVEOwN9M5bQEfNIdw0+8NXdBTH37I0ZTdi5wDh861YR6 tDVg== X-Gm-Message-State: AODbwcCflz9qIK7NOOpprHXexeXwqMquBCMuWIc5XorjHqG2m4W7HTvY BkyaeIpHqX2ejz2rTM8dTV83qsrKMhWcbFuZ69hrLkIE++WSkUPd+n5bX3xjnrDy5jVcoZXLmVu CynRKU83i+x2No3c= X-Received: by 10.31.65.197 with SMTP id o188mr14875006vka.7.1496805890064; Tue, 06 Jun 2017 20:24:50 -0700 (PDT) X-Received: by 10.31.65.197 with SMTP id o188mr14875000vka.7.1496805889850; Tue, 06 Jun 2017 20:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Tue, 6 Jun 2017 20:24:49 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Tue, 6 Jun 2017 22:24:49 -0500 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Job Snijders , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="001a114dde625ccd4705515647fe" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:24:54 -0000 --001a114dde625ccd4705515647fe Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 8:23 PM, Mark Smith wrote: > On 7 June 2017 at 09:30, Job Snijders wrote: > > On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter < > brian.e.carpenter@gmail.com> > > wrote: > >> > > > > >> > > >> > is this draft exactly: > >> > > >> > IPv6 unicast routing is based on prefixes of any valid length up to > >> > 128 [BCP198]. Interface Identifiers should be 64 bit long except > >> > when the addresses are manually configured, or by exceptions > defined > >> > in standards track documents. For example, [RFC6164] standardises > >> > 127 bit prefixes on inter-router point-to-point links. The > rationale > >> > for using 64 bit Interface Identifiers can be found in [RFC7421] > >> > > >> > ? > >> > >> Yes. Put those words in 4291bis and I will be very happy. Oh ;-). > > > > > "Interface Identifiers should be 64 bit long except when the addresses > are manually configured, or by exceptions defined in standards track > documents." > > That doesn't mention that security and privacy properties of addresses > will be compromised if the manually configured addresses are from a > small prefix. > > Security and privacy properties of addresses are independent of the > method used to configure them. Addresses configured via SLAAC, DHCPv6 > or manual configuration from within a small prefix/address range all > lose privacy and security properties and value. > The security considerations for RFC4291bis-07 already says the following; One area relavant to IPv6 addressing is privacy. IPv6 addresses can be created using interface identifiers constructed with unique stable tokens. The addresses created in this manner can be used to track the movement of devices across the Internet. Since earlier versions of this document were published, several approaches have been developed that mitigate these problems. These are described in "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" [RFC7721], "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941], and "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"[RFC7217]. Section 4.2 or RFC7721 already discusses manual configuration of addresses, if you think more is necessary then maybe RFC7721 needs to be updated. Job and others might say those privacy and security properties of > large addresses is only useful to hosts, not infrastructure such as > routers. I disagree. > > Large addresses can be of value in infrastructure addressing too. If a > network operator wants to significantly mitigate if not prevent an > attack such as a BGP listener TCP SYN attack from the Internet, they > can hide the router's interface address somewhere inside a /64 so that > the attacker can't find it via unsolicited inbound probing. If the > attacker decides to persist, they'll have to resort to other methods > to discover the device that are or can be made more costly. > > If a network operator's router vendor supports RFC7217 for interface > addresses, they get that security advantage of large addresses by > default when they add the /64 to the interface. Router interfaces are > one of the motivations for RFC7217 being able to use the interface > ifIndex value for the Net_Iface parameter (Appendix A) - the comment > about ifIndexes being enabled to be consistent across network > interface changes was my suggestion, and the use case in my mind was > router interface module swaps. > > It is self evident that a packet that cannot reach a device cannot be > used to attack the device. > > Perhaps those who commented during rfc4291bis last call and who may > not have seen the WG's addressing privacy and security discussions > over the last 4 years haven't realised that many more addressing bits > can provide more capability and value than just the ability to connect > more hosts. > I agree security and privacy are relevant issues for infrastructure addressing plans, but they are by no means the only or even necessarily the dominant considerations involved. I'll note that at least in my network relying on address obfuscation is not sufficient, I have to assume that the users on my network are untrusted, I have to tell them the first hop router one way or another, and finding the intermediate routers isn't that hard (traceroute). That said, I'll be poking at my routing vendors about RFC7217 support. However, I have a long list of issues for them already, so I'm not sure where this sits on the list of priorities with them. :) Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114dde625ccd4705515647fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 8:23 PM, Mark Smith <markzzzsmith@gmail.co= m> wrote:
job@instituut.net> wrote:
> On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
>>

<snip>

>> >
>> > is this draft exactly:
>> >
>> >=C2=A0 =C2=A0 IPv6 unicast routing is based on prefixes of any= valid length up to
>> >=C2=A0 =C2=A0 128 [BCP198].=C2=A0 Interface Identifiers should= be 64 bit long except
>> >=C2=A0 =C2=A0 when the addresses are manually configured, or b= y exceptions defined
>> >=C2=A0 =C2=A0 in standards track documents.=C2=A0 For example,= [RFC6164] standardises
>> >=C2=A0 =C2=A0 127 bit prefixes on inter-router point-to-point = links.=C2=A0 The rationale
>> >=C2=A0 =C2=A0 for using 64 bit Interface Identifiers can be fo= und in [RFC7421]
>> >
>> > ?
>>
>> Yes. Put those words in 4291bis and I will be very happy. Oh ;-).<= br> >


"Interface Identifiers should be 64 bit long except when the addresses=
are manually configured, or by exceptions defined in standards track
documents."

That doesn't mention that security and privacy properties of addresses<= br> will be compromised if the manually configured addresses are from a
small prefix.

Security and privacy properties of addresses are independent of the
method used to configure them. Addresses configured via SLAAC, DHCPv6
or manual configuration from within a small prefix/address range all
lose privacy and security properties and value.
=C2=A0=
The security considerations for RFC4291bis-07 already says the f= ollowing;

=C2=A0 =C2=A0One area relavant to I= Pv6 addressing is privacy.=C2=A0 IPv6 addresses can
=C2=A0 =C2=A0= be created using interface identifiers constructed with unique stable
=
=C2=A0 =C2=A0tokens.=C2=A0 The addresses created in this manner can be= used to track
=C2=A0 =C2=A0the movement of devices across the In= ternet.=C2=A0 Since earlier versions
=C2=A0 =C2=A0of this documen= t were published, several approaches have been
=C2=A0 =C2=A0devel= oped that mitigate these problems.=C2=A0 These are described in
= =C2=A0 =C2=A0"Security and Privacy Considerations for IPv6 Address Gen= eration
=C2=A0 =C2=A0Mechanisms" [RFC7721], "Privacy Ex= tensions for Stateless Address
=C2=A0 =C2=A0Autoconfiguration in = IPv6" [RFC4941], and "A Method for Generating
=C2=A0 = =C2=A0Semantically Opaque Interface Identifiers with IPv6 Stateless Address=
=C2=A0 =C2=A0Autoconfiguration (SLAAC)"[RFC7217].

Section 4.2 or RFC7721 already discusses manual confi= guration of addresses, if you think more is necessary then maybe RFC7721 ne= eds to be updated.

Job and others might say those privacy and security properties of
large addresses is only useful to hosts, not infrastructure such as
routers. I disagree.

Large addresses can be of value in infrastructure addressing too. If a
network operator wants to significantly mitigate if not prevent an
attack such as a BGP listener TCP SYN attack from the Internet, they
can hide the router's interface address somewhere inside a /64 so that<= br> the attacker can't find it via unsolicited inbound probing. If the
attacker decides to persist, they'll have to resort to other methods to discover the device that are or can be made more costly.

If a network operator's router vendor supports RFC7217 for interface addresses, they get that security advantage of large addresses by
default when they add the /64 to the interface. Router interfaces are
one of the motivations for RFC7217 being able to use the interface
ifIndex value for the Net_Iface parameter (Appendix A) - the comment
about ifIndexes being enabled to be consistent across network
interface changes was my suggestion, and the use case in my mind was
router interface module swaps.

It is self evident that a packet that cannot reach a device cannot be
used to attack the device.

Perhaps those who commented during rfc4291bis last call and who may
not have seen the WG's addressing privacy and security discussions
over the last 4 years haven't realised that many more addressing bits can provide more capability and value than just the ability to connect
more hosts.

I agree security and privac= y are relevant issues for infrastructure addressing plans, but they are by = no means the only or even necessarily the dominant=C2=A0considerations invo= lved.=C2=A0 I'll note that at least in my network relying on address ob= fuscation is not sufficient, I have to assume that the users on my network = are untrusted, I have to tell them the first hop router one way or another,= and finding the intermediate routers isn't that hard (traceroute).

That said, I'll be poking at my routing vendors a= bout RFC7217 support.=C2=A0 However, I have a long list of issues for them = already, so I'm not sure where this sits on the list of priorities with= them. :)=C2=A0
=C2=A0
Thanks
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114dde625ccd4705515647fe-- From nobody Tue Jun 6 20:37:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C3D129B71 for ; Tue, 6 Jun 2017 20:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4slyVxZu87iv for ; Tue, 6 Jun 2017 20:37:27 -0700 (PDT) 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 BF444129B51 for ; Tue, 6 Jun 2017 20:37:26 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id d73so2249805wma.0 for ; Tue, 06 Jun 2017 20:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=volr/qs2En14WwSuIlZ4hsSeXI1v0Al9/QqVIN6jofI=; b=Hs3RKfdY8q/eLHaJ80MDTiZTjp5lBAutjSeWsiAO8/Fo2hF9HtNs7vHz/GRUEZWFHU tPTlivZOcarLnukYNlaRZtpnjsQgCW7x31/vb1ZvpmrYnqP1LQNnoe7/fBmIW39GoDMg 1+iI+bTMTQCKfeKUuXRoTTZXbDu9prv6tPHGaL9gsoxY0fZ2P9Svia9TFehGFluukREW BVmi6kVq3mtb0A36UfMviaKoNjlzMgtGVwSeBwaHjuyz26myVE0q+JdVEkD2gs4IiS4A N6qShUUhK6IFCey2woZLYA71mdU2Eyxdso8SuBvcj+oILirZVGItl1P9+gbX0H+mfGDL /4zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=volr/qs2En14WwSuIlZ4hsSeXI1v0Al9/QqVIN6jofI=; b=ml/NbY7M45zXwr2hya+5BBRlNWyRJ9EZlvYuwl7WhXCXnAffbkJ6S26tJBCX7oOQs8 38RJyt7FnI3nvZK6N+m4FKbU2hIBgHqbeVSZ/q9+ksNy4Mfk9TO7JscOfIlOCFDktyNI la//JZU1XvKVSfBrD0e92vLEMkgNynUyuBtqs2wnlBl/BAz2S08MlXhxrdjJekoXE/hE 0gfG2l0mjLnltiIDxN/nMWz3Vc986CLaeZvAX6VTBCfaWnArHXy+DtI3sATYWbp79Bpl G1kaZwYUjqUluNyF0voJ62Ga8AZ1yuwmnKOweAPwJMaWtykFVZ4lfVsNtJ7/grzN/Azo 2M6A== X-Gm-Message-State: AODbwcAxQdKnJv/fyhquIHWweQNRbbHAITZXumyIEbTVvIzKeiF2wbQt y7nJ6k0QQdxrMA== X-Received: by 10.28.28.134 with SMTP id c128mr469970wmc.112.1496806645388; Tue, 06 Jun 2017 20:37:25 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1da::1014? ([2600:8802:5600:1da::1014]) by smtp.gmail.com with ESMTPSA id 49sm537483wrz.8.2017.06.06.20.37.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 20:37:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) From: Fred Baker In-Reply-To: Date: Tue, 6 Jun 2017 20:37:23 -0700 Cc: Job Snijders , Erik Kline , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:37:28 -0000 On Jun 6, 2017, at 6:23 PM, Mark Smith wrote: >=20 > That doesn't mention that security and privacy properties of addresses > will be compromised if the manually configured addresses are from a > small prefix. Or advertised in DNS? I would expect that any address configured manually would also be = advertised in DNS, the latter being the reason for the former. If the = address is publicly announced, does one have a reasonable expectation of = privacy?= From nobody Tue Jun 6 20:39:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390BB129B9D for ; Tue, 6 Jun 2017 20:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWuS7hdJcswh for ; Tue, 6 Jun 2017 20:39:45 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 2FECF129B51 for <6man@ietf.org>; Tue, 6 Jun 2017 20:39:45 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 7so109473182wmo.1 for <6man@ietf.org>; Tue, 06 Jun 2017 20:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B1QJ3AoXKyH9nwjTSyri+zBupNNSvo0LlEUpB1fcpWU=; b=nPaqG/3w5dBreq+9yGTufRW0Ic21cJb07ylANcBqwiVfKMm9RO8tzGZwzyv3xW+yYW 38o2DvN2/hBJVtlZVxdVNRfV8KQVR/UR9QFA+tEf5wmax4VPp6KK9KB0N3TH/4ExB3Yv mHWBaPK15RCsWfahIPGedWnz9YR0TfP2csoiP3SVGSlrKq6eNhwK/SaHjP5wQ/VlSpwW KKk8X+CRzeKfDDdBsWrFYsjSRRazmxW7SkLr7D6vltbwqwYKAr8eqHOVM8c5ZwGs3HH1 T5IWjAbcYVGHAoHVo3lrWJdwetseVFpXrzMJLA8fQFzSgaxUXq1J1TjVcMjETfbu3hZ0 71EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B1QJ3AoXKyH9nwjTSyri+zBupNNSvo0LlEUpB1fcpWU=; b=Q1GS2BbmTyGBnfnyddOHyN+IyXbAGhtZC0SUl2zqTPX6mVWCpvpC8+MKVm084hFO/o w+4rhKMHkuSlqnsGk8tcFEkzvQFj9hbWWbT1u8a6JQdWDJn6M6YAU9R0m6SNM57qnxiP D8XqzwOghXaKYAZhN8yLfwJFqcBgSQMmeY+89MpfVFnhX7uBxKZqXWniaGA26dStanjF SVAO178xxpqkn2S39wD/7IgU/PGGSHl6fvHmI81W98WLWgbxxJzdnAI2oTVqFM263BQF 81p5G3w4qFJZvXzrSOOPN48KjyqRz5bliIj8+/2BBY9TLXTr0vFYoea+dGw/viFOc5i/ qqGQ== X-Gm-Message-State: AODbwcAVt833PEX72jwCskCv84pQ8g4Qqp6CxVh9S4cJJKVNIsekq/kT j1Zr9sSz3Kur7KKJH/p+e5qKU591/JOH X-Received: by 10.28.105.136 with SMTP id z8mr8990780wmh.60.1496806783551; Tue, 06 Jun 2017 20:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 20:39:42 -0700 (PDT) In-Reply-To: <2bddb55c-3aa5-cd0c-e1b7-3ebc4c84bf86@joelhalpern.com> References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> <8c9874cd-9dde-936e-2c39-8f488cb5fb2c@joelhalpern.com> <2bddb55c-3aa5-cd0c-e1b7-3ebc4c84bf86@joelhalpern.com> From: Tom Herbert Date: Tue, 6 Jun 2017 20:39:42 -0700 Message-ID: Subject: Re: Identifier/locator split addressing and /64 To: "Joel M. Halpern" Cc: 6man@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:39:48 -0000 On Tue, Jun 6, 2017 at 8:18 PM, Joel M. Halpern wrote: > I am really not sure what example you want, but I will try. > > Suppose that each eNodeB is expected to support up to 1000 simultaneous UEs. > (I have not checked whether that is the right number, but we can use it for > working an example. > > Then the operator takes his block (say XXX::/32) And he assigns 11 or 12 > bits of space to each eNodeB. He assigns the block to the eNODEB acording > to his addressing plan so that one can easily route to it. So one eNodeB > might be allocated XXXYZQ/52, and another might get XXXLMN/52, etc. Where > the portion after the XXX is allocated according to the topological > placement of the eNodeB in the operators network. > The eNodeB then assigns /64 locators from its block to each UE. > > (IN practice, due to th4e way mobile network work, the assignments are done > in a more complicate fashion, but they still simply come out of the block > associated with each eNodeB. > > Node that these blocks have nothing formally to do with the address assigned > to the eNodeB, although due to simplicity of forwarding one might assign > eNodeB local addresses from the same blocks. Or one might segregate for > reasons of address isolation. ILNP does not care. > > The point is that the UE uses the combination of assigned locator and > created identifier for its IPV6 communication. And when the UE moves, it > sends the ICMP updates to its correspondents. > I see. What happens if a peer doesn't get the ICMP message, the 12 bit identifier (same 64 bit locator) is assigned to a new UE in the eNodeB, and then the peer wakes up and sends using the now using the out of date locator that reaches some other device. Do locators timeout? Tom > Beyond that we are getting into operational practices for mobile operators, > which are not the topic of this discussion. > > Yours, > Joel > > > On 6/6/17 11:05 PM, Tom Herbert wrote: >> >> On Tue, Jun 6, 2017 at 7:40 PM, Joel M. Halpern >> wrote: >>> >>> In ILNP, the Unique Identifier for the host is used as the lower 64 bits >>> of >>> the IPv6 address, while the locator is the upper 64 bits. >>> This was specifically designed with the 64 bit boundary in mind, and >>> works >>> for fixed and mobile hosts. >>> >>> You say that the boundary causes problems for ILA. I believe you. Having >>> worked through multiple cases, it does not cause any problems for the >>> ILNP. >>> >> Great. Then I ask again "Can you provide concrete end to end example >> for this similar to mine?". This would be most helpful. >> >> Thanks, >> Tom >> >>> Yours, >>> Joel >>> >>> >>> On 6/6/17 10:32 PM, Tom Herbert wrote: >>>> >>>> >>>> On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> If what you are now saying Tom is that ILA would work better with a >>>>> different address arrangement, I guess you would know better than I. >>>>> From >>>>> what I had seen, it seemed likely that if ILA will work for mobiles at >>>>> all, >>>>> it will work with the current /64 boundary. But your invention, your >>>>> judgment. >>>>> >>>>> As for ILNP, if you want to understand how it works, in general, for >>>>> data >>>>> centers, or for mobility, I suggest reading the RFCs. Any paraphrase I >>>>> provided in a short email would probably be a disservice both to ILNP >>>>> and >>>>> to >>>>> the members of this list. >>>>> >>>> Joel, >>>> >>>> I did read the drafts and that is what I base my conclusions on. >>>> Section 6 of RFC6740 on mobility indicates that a mobile host has a >>>> unique identifier, so if each host is already being assigned a /64 >>>> there is no room left for the host identifier. Section 6.3 about >>>> network mobility indicates that each host in the network is >>>> individually mobile which is even more of a problem. >>>> >>>> This is pertinent to the discussion on /64 addressing since in several >>>> RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 >>>> to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) >>>> split for mobility. >>>> >>>> Tom >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 6/6/17 4:05 PM, Tom Herbert wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have several problems with your description. >>>>>>> 1) The address of the Base Station for purposes of communciating with >>>>>>> the >>>>>>> base station is irrelevant. >>>>>>> 2) More importantly, in ILNP, the upper 64 bits are not >>>>>>> "over-written". >>>>>>> Rather, the sender fills in the correct 64 bits that will route the >>>>>>> traffic >>>>>>> to the right place to reach the UE. Thus, the modile operator can >>>>>>> allocate >>>>>>> the structure of the locators (within their allocated IPv6 address >>>>>>> block) >>>>>>> so >>>>>>> as to enable the use of effective and scalable IP routing to reach >>>>>>> the >>>>>>> UE >>>>>>> without over-writing anything. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Can you provide concrete end to end example for this similar to mine. >>>>>> That is how an external host can reach an address in a UE that is >>>>>> moving around in a mobile network. >>>>>> >>>>>>> I presume it is accidental, but your description of ILNP does not >>>>>>> match >>>>>>> the >>>>>>> RFCs, including the ones that discuss mobility and data center >>>>>>> handling. >>>>>>> >>>>>> I didn't say this was specifically ILNP. The description is consistent >>>>>> with ILA. >>>>>> >>>>>> Thanks, >>>>>> Tom >>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> >>>>>>> On 6/6/17 1:33 PM, Tom Herbert wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Joel, >>>>>>>> >>>>>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Tom, I do not follow your reasoning at all. >>>>>>>>> I can not tell what you mean by "addressing within the device". >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Referring to the prefix delegated to the device. >>>>>>>> >>>>>>>>> Even in a data center, one might choose to treat the hypervisor as >>>>>>>>> part >>>>>>>>> of >>>>>>>>> the network, and allocate a prefix to the hypervisor so it can >>>>>>>>> assign >>>>>>>>> a >>>>>>>>> /64 >>>>>>>>> locator to each device. Or you could assign separate /64s to each >>>>>>>>> entitiy >>>>>>>>> within the device from the network directly. Neither requires >>>>>>>>> changing >>>>>>>>> the >>>>>>>>> IID space. >>>>>>>>> >>>>>>>> Right, we're not changing the IID space here. We're specifying which >>>>>>>> link (subnet) is the IID space relative to. >>>>>>>> >>>>>>>>> For something that is a single device, like a UE< it is even >>>>>>>>> simpler >>>>>>>>> to >>>>>>>>> allow the network to directly assign as many /64 as the device >>>>>>>>> needs. >>>>>>>>> >>>>>>>>> Note that if the UE is serving as a router for other devices, then >>>>>>>>> 1) that is not routing within the device >>>>>>>>> 2) the space is likely small enough that routing on the full /128s >>>>>>>>> works >>>>>>>>> just fine >>>>>>>>> >>>>>>>>> You have made this assertion a couple of times now, and I can not >>>>>>>>> figure >>>>>>>>> out >>>>>>>>> why you consider the change necessary. ILNP can work fine for >>>>>>>>> mobile >>>>>>>>> network UE. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It doesn't work if the UE is assigned a /64, that's my point. The >>>>>>>> device is the mobile node that needs to be reflected in the >>>>>>>> identifier >>>>>>>> and then the mapping in the network is mobile device (device >>>>>>>> identifier) to locator. The locator is the address of an attachment >>>>>>>> point (e.g. base station) in the network. The addresses covered by >>>>>>>> the >>>>>>>> prefix assigned to the device is not relevant in mobility since the >>>>>>>> whole prefix follows the device. So what we're really interested in >>>>>>>> is >>>>>>>> which mobile device is the packet being sent to and where is it in >>>>>>>> the >>>>>>>> mobile network. >>>>>>>> >>>>>>>> I'll give it a shot to show by example. >>>>>>>> >>>>>>>> Suppose we have a mobile network. Base stations have addresses in >>>>>>>> the >>>>>>>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>>>>>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>>>>>>> >>>>>>>> Consider a packet is sent to an address within a mobile node with >>>>>>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>>>>>>> to base station with address 2000:0:0:567::. In identifier/locator >>>>>>>> the >>>>>>>> top sixty-four bits of address are overwritten with the locator for >>>>>>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The >>>>>>>> packet >>>>>>>> will reach the correct base station, but we've lost the address >>>>>>>> information for the device so the base station has no way to forward >>>>>>>> it on. >>>>>>>> >>>>>>>> Alternatively, assume the identifier is composed of a 32 bit device >>>>>>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>>>>>>> the form 3000:0:0:0:0:Z::/32. >>>>>>>> >>>>>>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top >>>>>>>> sixty >>>>>>>> four bits are overwritten with a locator so the destination on the >>>>>>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>>>>>>> and it can now be forwarded to the correct device that is identified >>>>>>>> by the 0:123 device identifier in the address. >>>>>>>> >>>>>>>> Hope that helps! >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>>>>>>> identfier/locator split addressing (like in ILNP). The motivation >>>>>>>>>> is >>>>>>>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>>>>>>> compatible with identifier/locator split. The reason is that the >>>>>>>>>> link >>>>>>>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>>>>>>> network. The identifier in a mobile network needs to identify the >>>>>>>>>> device. >>>>>>>>>> >>>>>>>>>> In identifier/locator split, the IP address is split into a >>>>>>>>>> locator >>>>>>>>>> and identifier. Each are 64 bits (although Brian did point out >>>>>>>>>> that >>>>>>>>>> that could also be a parameter). Just like IIDs, identifiers must >>>>>>>>>> be >>>>>>>>>> unique within the subnet. In the case of a mobile network the link >>>>>>>>>> is >>>>>>>>>> an overlay network that is not physical, but none the less it is a >>>>>>>>>> type of link. >>>>>>>>>> So the properties of it being a link including those for IIDs on >>>>>>>>>> the >>>>>>>>>> link hold-- this make identifiers equivalent to IIDs by >>>>>>>>>> definition. >>>>>>>>>> >>>>>>>>>> The IPv6 address for identifier/locator split looks like: >>>>>>>>>> >>>>>>>>>> M bits for locator >>>>>>>>>> N bits for device identifier >>>>>>>>>> 128 - M - N bits for addresses within the device >>>>>>>>>> >>>>>>>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>>>>>>> >>>>>>>>>> 64 bits for locator >>>>>>>>>> 32 bits for device identifier >>>>>>>>>> 32 bits for addresses within the device >>>>>>>>>> >>>>>>>>>> Which implies /96 assignment to each UE. >>>>>>>>>> >>>>>>>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>>>>>>> device, and a 32 bit number assigned by the device. If assignments >>>>>>>>>> for >>>>>>>>>> both of these are randomized this provides 64 bits of entropy for >>>>>>>>>> security. >>>>>>>>>> >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>> IETF IPv6 working group mailing list >>>>>>>>>> ipv6@ietf.org >>>>>>>>>> Administrative Requests: >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From nobody Tue Jun 6 20:41:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA60D127869 for ; Tue, 6 Jun 2017 20:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9d3SuRrQBWK for ; Tue, 6 Jun 2017 20:40:54 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 7CC5F129B7A for ; Tue, 6 Jun 2017 20:40:54 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id g76so464259wrd.1 for ; Tue, 06 Jun 2017 20:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5qk4/j1t2LA4tdYm7NXFO57wZVtsZ3NogAnF2YCz3p8=; b=Ck6Dv0vH2hjYM0wmsFw3eH+aIH8F8Q3GugmU5/3cMyUgvtAVWaUpZqbhowAZwkU72/ MzmZe86PhlghIYnhNcx1C/Lfypvj7f9NMVkmzYkv/3NTNXeEvXhTzRSGfkgvp4HbTEuo M0OgMswOYY9kXyB7lNKX1eUUjk1h9ObiXg163bdutYtTUvver7yx8HHod8Jx4c5nFWBi /KWmpK97wBz3mhO+vXPvr77r8qQyFgcoGK+EXpaZNlSvMC9aRExsrd8ohmuRiX4zcZj9 zwBqYpElF7JhuEQGMNjzqV1gWupTfMDvx+rx57k4m10cOwVjFWaaovaIyJjDuvPZ+xW2 5l9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5qk4/j1t2LA4tdYm7NXFO57wZVtsZ3NogAnF2YCz3p8=; b=A9itdldi1vjanEm8qEoZ8nDRMpdpbgWXct2UA4t7M4Pm1HiIwVbAvCIZnudXJVXPi8 y50Vuw/4w3DDivAn9W6J4pQYuRK62co/oCJBgM2b4UMiKDqqkb7+oLDM4i5P8KToSfXB bBiSLJuepl2SNL44hrjxVQw/RMzgnh5FfP4vo6Y1p3+dkSG7iQ2Bqd93Qb8B5g3HVyfb hNJ7pS5bNi+yGAQOAB3Hpl3A7mFUUON3evu2y52Q0HUQdsu3w7FSJ/wyf6TP9QGAM2oK Jy/HbsW3eOFHNqoE3rfZ+XdbSdpvt3Ju9+24y4OTdefHh4l7iX/xY+5V5x51gYRZNECG H7ag== X-Gm-Message-State: AODbwcDiK4gnOhufzQpGJ7gTo/ejjImcs0UVE5rIVa6BFzC/IfKDc6Td VBzm1HRUUnU1CRN/Ey85G+ane/6ckzXB X-Received: by 10.223.177.158 with SMTP id q30mr10896302wra.82.1496806852944; Tue, 06 Jun 2017 20:40:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Job Snijders Date: Wed, 07 Jun 2017 03:40:41 +0000 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fred Baker , Mark Smith Cc: 6man WG , Erik Kline Content-Type: multipart/alternative; boundary="f403045ec41ec479460551568015" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:40:58 -0000 --f403045ec41ec479460551568015 Content-Type: text/plain; charset="UTF-8" I don't think so. On Tue, 6 Jun 2017 at 20:37, Fred Baker wrote: > > On Jun 6, 2017, at 6:23 PM, Mark Smith wrote: > > > > That doesn't mention that security and privacy properties of addresses > > will be compromised if the manually configured addresses are from a > > small prefix. > > Or advertised in DNS? > > I would expect that any address configured manually would also be > advertised in DNS, the latter being the reason for the former. If the > address is publicly announced, does one have a reasonable expectation of > privacy? --f403045ec41ec479460551568015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think so.

On= Tue, 6 Jun 2017 at 20:37, Fred Baker <fredbaker.ietf@gmail.com> wrote:

On Jun 6, 2017, at 6:23 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>
> That doesn't mention that security and privacy properties of addre= sses
> will be compromised if the manually configured addresses are from a > small prefix.

Or advertised in DNS?

I would expect that any address configured manually would also be advertise= d in DNS, the latter being the reason for the former. If the address is pub= licly announced, does one have a reasonable expectation of privacy?
--f403045ec41ec479460551568015-- From nobody Tue Jun 6 20:48:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9250A129BDA for ; Tue, 6 Jun 2017 20:48:11 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Xjp8OUSwYR for ; Tue, 6 Jun 2017 20:48:10 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 EF4EE129B9B for ; Tue, 6 Jun 2017 20:48:09 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id u12so853106qth.0 for ; Tue, 06 Jun 2017 20:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/11PpIj5VClQy4hjO31YzbqT19bPlkdyI13S3kJz9Rg=; b=SeVilZNFYWPIXL3ZcEGm5/wirn9tZAESOSqsNOf651p3ld4pFt/CWvGWJnBBFmoAGO 0uNQJY2hy393it5z18BfY8lc2rhPbagpOaA68Kik6b3gSXNJa+62X2ry+1YzXtidsPaZ PhrLagSwoXZObZKorqRUEDQhCAl858Z/o2XUp8OpHj0Kft7SURyyLGgqcdhYr+7GDFBT ivXKsreBk20FftjpI5WTApx3/G0v+OpeRGCMqhsA+Xvy7nEZ+6dE4a+uW199KdWqIxM4 MMW5aKggDZ7/+73RojHl1K+n0rEyfo1esbWeeA1rugVorc/MnOfPwV+A8XwYj9Zyt9RU zGgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/11PpIj5VClQy4hjO31YzbqT19bPlkdyI13S3kJz9Rg=; b=Jle+VQZz3sL9ZQNOOMyQvnthRghUwDfTcZ6zD3B8og/QrtQZ0vlRRRrAaNeEkuDioJ pwaa6hc81FdvuupzZAwVPu5VZsQ2yenrfheSy5BDb28B6CWutzfWc3WjgvU8GElS9aUI kbTEKzsgXapNQt7bWIhP0tuNBT2sGu1Gs1K72kfxpJmM8RgZReIJ25pkm//blEW+ZsNg egtNwWqGa8ByVCE2fLBWDCc6lxY0NZP1/04V82shNaw3fpDYbnCGDMEL+QgXUxvdzP3P tFlBe1ueRaVP54wxy9q0Qp14lSekNAgpbT0AyGd9i9zBcM+ktvtw2vfHt5AOaqix8/Gw Jx0w== X-Gm-Message-State: AODbwcCAQ9gJPmyUFee3415+9JXK9cYXuq36jgaucU1MbzAR7QoKGOIW 1RnV04O3vjFVNidtlIMCJKrS74QCGA== X-Received: by 10.237.48.161 with SMTP id 30mr36997118qtf.201.1496807289206; Tue, 06 Jun 2017 20:48:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.106 with HTTP; Tue, 6 Jun 2017 20:48:08 -0700 (PDT) In-Reply-To: References: From: Christopher Morrow Date: Tue, 6 Jun 2017 23:48:08 -0400 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fred Baker Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="94eb2c0cb03ac53e6c0551569aab" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:48:11 -0000 --94eb2c0cb03ac53e6c0551569aab Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 11:37 PM, Fred Baker wrote: > > On Jun 6, 2017, at 6:23 PM, Mark Smith wrote: > > > > That doesn't mention that security and privacy properties of addresses > > will be compromised if the manually configured addresses are from a > > small prefix. > > Or advertised in DNS? > > I would expect that any address configured manually would also be > advertised in DNS, the latter being the reason for the former. If the > address is publicly announced, does one have a reasonable expectation of > privacy? > > for the router interface case there's also just: 1) traceroute, see interfaces in question 2) ddos engine on! there are many ways to skin this cat, address 'privacy' here isn't really the thing that helps (make routers less vulnerable to randos and packet cannons) --94eb2c0cb03ac53e6c0551569aab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 11:37 PM, Fred Baker <fredbaker.ietf@gma= il.com> wrote:

On Jun 6, 2017, at 6:23 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>
> That doesn't mention that security and privacy properties of addre= sses
> will be compromised if the manually configured addresses are from a > small prefix.

Or advertised in DNS?

I would expect that any address configured manually would also be advertise= d in DNS, the latter being the reason for the former. If the address is pub= licly announced, does one have a reasonable expectation of privacy?

<= br>
for the router interface case there's also just:
=C2= =A0 1) traceroute, see interfaces in question
=C2=A0 2) ddos engi= ne on!

there are many ways to skin this cat, addre= ss 'privacy' here isn't really the thing that helps (make route= rs less vulnerable to randos and packet cannons)=C2=A0
--94eb2c0cb03ac53e6c0551569aab-- From nobody Tue Jun 6 20:48:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12395129BDB for ; Tue, 6 Jun 2017 20:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMvzPXjvKAu8 for ; Tue, 6 Jun 2017 20:48:45 -0700 (PDT) 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 22ABD129BEF for ; Tue, 6 Jun 2017 20:48:40 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n195so2332521wmg.1 for ; Tue, 06 Jun 2017 20:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BA/ZJt7m5uoO8jKQkLl3elwMyW88YfeIX7leJqcgFG4=; b=niZPCUJVIi0eN8Y+uwcRB6M6v9lr6TSkb82jlYYxDle8xgIqegW5fFc/yNwJYpAlat jwjsDjk9HrncKBm3XQha0+HF6W5wSPIBZ+19304SUgZ5djsoQnjX1IDRmhNRGLSuGnr6 VLTSAlyHSmZPnJsMu0+IvhdskeyAHnZEahCdlhpiYBa3YhiW9EWv3fGvu626GPN9LLgK 8Sas2VJKTBC8QpiLhlALbicgumGaKcRLpoUV6dNBPZRSaUhRDT5UdChN+JuitHJzM+Y2 /vVkKItpW3yNzBEoeoOIF8ASUTStV8CVYH/8MWzSp5qf4c7CaQhQOSxHKK358RYsi8tl Rb0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BA/ZJt7m5uoO8jKQkLl3elwMyW88YfeIX7leJqcgFG4=; b=fw7xk6fYIM7/CpxZAk37Lbd44o8AoH6ZA/6nDqr3xAJM+ESgVhPQG87/BR2MEMr89H bJ/zZqWG8g5phsK+aiIhqcAtyiyla+BE6ri5BV43BHroxe/cxGQhERSDnCiuIkNLJjb7 Y2XvXA49O3d4dHW2Cw6qNdmJP0dJ8n2FxVKAiH6YUDNeqr9iHHtORZusU5EDpCMS7nv+ 4N03iShIy0GaMXhLlTHBqAWWaDnW9/pFq5m3NiLOw1Hk6hgGp15rS2i1Jq15H9amMG1/ K8lF4DGGcW3FdHB0ourPrHR1BJf1Fju/IXQvoU/iju5WPCeXu7c/U25lGb5yFNioMPGg nQaA== X-Gm-Message-State: AODbwcAX05nKfdSmJvAATKyJ2KwW5tfn/QJ1D7tGIUdx++nRdyPncrne UJwBfhdOfKdg5cqYuwIeNJ117/APgRLj X-Received: by 10.28.54.204 with SMTP id y73mr483074wmh.53.1496807318653; Tue, 06 Jun 2017 20:48:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Tue, 6 Jun 2017 20:48:38 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 6 Jun 2017 20:48:38 -0700 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Job Snijders Cc: Fred Baker , Mark Smith , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:48:49 -0000 On Tue, Jun 6, 2017 at 8:40 PM, Job Snijders wrote: > I don't think so. > Right. This security technique doesn't help any servers on the Internet that have public DNS addresses or other situations where the addresses can be discovered. In reality, hosts should never assume that the network provides any security which is why we need to spend a lot of effort hardening stacks to handle SYN and other types of attacks. It's great if this makes attackers work harder, but I would never count on for security from a host perspective. Tom > On Tue, 6 Jun 2017 at 20:37, Fred Baker wrote: >> >> >> On Jun 6, 2017, at 6:23 PM, Mark Smith wrote: >> > >> > That doesn't mention that security and privacy properties of addresses >> > will be compromised if the manually configured addresses are from a >> > small prefix. >> >> Or advertised in DNS? >> >> I would expect that any address configured manually would also be >> advertised in DNS, the latter being the reason for the former. If the >> address is publicly announced, does one have a reasonable expectation of >> privacy? > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 6 20:49:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F49E129BF0 for ; Tue, 6 Jun 2017 20:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAnrZcXgxELx for ; Tue, 6 Jun 2017 20:48:53 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3C336129BEF for <6man@ietf.org>; Tue, 6 Jun 2017 20:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 269BE1C043D; Tue, 6 Jun 2017 20:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496807333; bh=Wxjcle1tQ3ouPaPR+Ks3rReHjmBs/LQvUsYxlfbcslg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pSZKzVLdF4lOZrlVuCVShzkEp0Ef6emZ/fLKkquISiMidirfuTtEVYNsZstZFXuHp 7VPiWlMUJjdrrVO+9oYnrjsNm43XK4LgfzvVWgn/kjeZg+83lFuFHTnR8sApIvdBnD 5Ra+vSKq5WIsTgDvOwfgmaSEEPyD560LUOA0IU4I= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 74F3C569FD0; Tue, 6 Jun 2017 20:48:52 -0700 (PDT) Subject: Re: Identifier/locator split addressing and /64 To: Tom Herbert Cc: 6man@ietf.org References: <64db2e90-4bd6-785a-d0e2-dc9662341ccd@joelhalpern.com> <1efc17f7-41c7-a36b-3d3e-37bf84dfe826@joelhalpern.com> <8253e2ed-d5fa-0483-fcf2-445a31904975@joelhalpern.com> <8c9874cd-9dde-936e-2c39-8f488cb5fb2c@joelhalpern.com> <2bddb55c-3aa5-cd0c-e1b7-3ebc4c84bf86@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 6 Jun 2017 23:48:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:48:56 -0000 Huh? The ICMP is sent several times, specifically because of loss. This, and the related behaviors are discussed in the ILNP RFCs. If all of them get lost, then communication gets lost. Some other device using the old full locator (the 12 bits in isolation are not meaningful, nor are they analyzed separately by anything. They were just an example of an allocation size for the eNodeB creating /64 locators for the UE, as required by 3GPP) may receive IP packets, but they will be discarded. They will not be considered part of the same session. There are ways to make ti more robust, but then I would be moving the goal-posts, since those are not part of the ILNP RFCs. Yours, Joel On 6/6/17 11:39 PM, Tom Herbert wrote: > On Tue, Jun 6, 2017 at 8:18 PM, Joel M. Halpern wrote: >> I am really not sure what example you want, but I will try. >> >> Suppose that each eNodeB is expected to support up to 1000 simultaneous UEs. >> (I have not checked whether that is the right number, but we can use it for >> working an example. >> >> Then the operator takes his block (say XXX::/32) And he assigns 11 or 12 >> bits of space to each eNodeB. He assigns the block to the eNODEB acording >> to his addressing plan so that one can easily route to it. So one eNodeB >> might be allocated XXXYZQ/52, and another might get XXXLMN/52, etc. Where >> the portion after the XXX is allocated according to the topological >> placement of the eNodeB in the operators network. >> The eNodeB then assigns /64 locators from its block to each UE. >> >> (IN practice, due to th4e way mobile network work, the assignments are done >> in a more complicate fashion, but they still simply come out of the block >> associated with each eNodeB. >> >> Node that these blocks have nothing formally to do with the address assigned >> to the eNodeB, although due to simplicity of forwarding one might assign >> eNodeB local addresses from the same blocks. Or one might segregate for >> reasons of address isolation. ILNP does not care. >> >> The point is that the UE uses the combination of assigned locator and >> created identifier for its IPV6 communication. And when the UE moves, it >> sends the ICMP updates to its correspondents. >> > I see. What happens if a peer doesn't get the ICMP message, the 12 bit > identifier (same 64 bit locator) is assigned to a new UE in the > eNodeB, and then the peer wakes up and sends using the now using the > out of date locator that reaches some other device. Do locators > timeout? > > Tom > > >> Beyond that we are getting into operational practices for mobile operators, >> which are not the topic of this discussion. >> >> Yours, >> Joel >> >> >> On 6/6/17 11:05 PM, Tom Herbert wrote: >>> >>> On Tue, Jun 6, 2017 at 7:40 PM, Joel M. Halpern >>> wrote: >>>> >>>> In ILNP, the Unique Identifier for the host is used as the lower 64 bits >>>> of >>>> the IPv6 address, while the locator is the upper 64 bits. >>>> This was specifically designed with the 64 bit boundary in mind, and >>>> works >>>> for fixed and mobile hosts. >>>> >>>> You say that the boundary causes problems for ILA. I believe you. Having >>>> worked through multiple cases, it does not cause any problems for the >>>> ILNP. >>>> >>> Great. Then I ask again "Can you provide concrete end to end example >>> for this similar to mine?". This would be most helpful. >>> >>> Thanks, >>> Tom >>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 6/6/17 10:32 PM, Tom Herbert wrote: >>>>> >>>>> >>>>> On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern >>>>> wrote: >>>>>> >>>>>> >>>>>> If what you are now saying Tom is that ILA would work better with a >>>>>> different address arrangement, I guess you would know better than I. >>>>>> From >>>>>> what I had seen, it seemed likely that if ILA will work for mobiles at >>>>>> all, >>>>>> it will work with the current /64 boundary. But your invention, your >>>>>> judgment. >>>>>> >>>>>> As for ILNP, if you want to understand how it works, in general, for >>>>>> data >>>>>> centers, or for mobility, I suggest reading the RFCs. Any paraphrase I >>>>>> provided in a short email would probably be a disservice both to ILNP >>>>>> and >>>>>> to >>>>>> the members of this list. >>>>>> >>>>> Joel, >>>>> >>>>> I did read the drafts and that is what I base my conclusions on. >>>>> Section 6 of RFC6740 on mobility indicates that a mobile host has a >>>>> unique identifier, so if each host is already being assigned a /64 >>>>> there is no room left for the host identifier. Section 6.3 about >>>>> network mobility indicates that each host in the network is >>>>> individually mobile which is even more of a problem. >>>>> >>>>> This is pertinent to the discussion on /64 addressing since in several >>>>> RFCs a motivation for that is ILNP or ILA. I claim that assigning /64 >>>>> to UEs prevents using ILNP, ILA, or any identifier/locator (64/64) >>>>> split for mobility. >>>>> >>>>> Tom >>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 6/6/17 4:05 PM, Tom Herbert wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have several problems with your description. >>>>>>>> 1) The address of the Base Station for purposes of communciating with >>>>>>>> the >>>>>>>> base station is irrelevant. >>>>>>>> 2) More importantly, in ILNP, the upper 64 bits are not >>>>>>>> "over-written". >>>>>>>> Rather, the sender fills in the correct 64 bits that will route the >>>>>>>> traffic >>>>>>>> to the right place to reach the UE. Thus, the modile operator can >>>>>>>> allocate >>>>>>>> the structure of the locators (within their allocated IPv6 address >>>>>>>> block) >>>>>>>> so >>>>>>>> as to enable the use of effective and scalable IP routing to reach >>>>>>>> the >>>>>>>> UE >>>>>>>> without over-writing anything. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can you provide concrete end to end example for this similar to mine. >>>>>>> That is how an external host can reach an address in a UE that is >>>>>>> moving around in a mobile network. >>>>>>> >>>>>>>> I presume it is accidental, but your description of ILNP does not >>>>>>>> match >>>>>>>> the >>>>>>>> RFCs, including the ones that discuss mobility and data center >>>>>>>> handling. >>>>>>>> >>>>>>> I didn't say this was specifically ILNP. The description is consistent >>>>>>> with ILA. >>>>>>> >>>>>>> Thanks, >>>>>>> Tom >>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> >>>>>>>> On 6/6/17 1:33 PM, Tom Herbert wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Joel, >>>>>>>>> >>>>>>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tom, I do not follow your reasoning at all. >>>>>>>>>> I can not tell what you mean by "addressing within the device". >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Referring to the prefix delegated to the device. >>>>>>>>> >>>>>>>>>> Even in a data center, one might choose to treat the hypervisor as >>>>>>>>>> part >>>>>>>>>> of >>>>>>>>>> the network, and allocate a prefix to the hypervisor so it can >>>>>>>>>> assign >>>>>>>>>> a >>>>>>>>>> /64 >>>>>>>>>> locator to each device. Or you could assign separate /64s to each >>>>>>>>>> entitiy >>>>>>>>>> within the device from the network directly. Neither requires >>>>>>>>>> changing >>>>>>>>>> the >>>>>>>>>> IID space. >>>>>>>>>> >>>>>>>>> Right, we're not changing the IID space here. We're specifying which >>>>>>>>> link (subnet) is the IID space relative to. >>>>>>>>> >>>>>>>>>> For something that is a single device, like a UE< it is even >>>>>>>>>> simpler >>>>>>>>>> to >>>>>>>>>> allow the network to directly assign as many /64 as the device >>>>>>>>>> needs. >>>>>>>>>> >>>>>>>>>> Note that if the UE is serving as a router for other devices, then >>>>>>>>>> 1) that is not routing within the device >>>>>>>>>> 2) the space is likely small enough that routing on the full /128s >>>>>>>>>> works >>>>>>>>>> just fine >>>>>>>>>> >>>>>>>>>> You have made this assertion a couple of times now, and I can not >>>>>>>>>> figure >>>>>>>>>> out >>>>>>>>>> why you consider the change necessary. ILNP can work fine for >>>>>>>>>> mobile >>>>>>>>>> network UE. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It doesn't work if the UE is assigned a /64, that's my point. The >>>>>>>>> device is the mobile node that needs to be reflected in the >>>>>>>>> identifier >>>>>>>>> and then the mapping in the network is mobile device (device >>>>>>>>> identifier) to locator. The locator is the address of an attachment >>>>>>>>> point (e.g. base station) in the network. The addresses covered by >>>>>>>>> the >>>>>>>>> prefix assigned to the device is not relevant in mobility since the >>>>>>>>> whole prefix follows the device. So what we're really interested in >>>>>>>>> is >>>>>>>>> which mobile device is the packet being sent to and where is it in >>>>>>>>> the >>>>>>>>> mobile network. >>>>>>>>> >>>>>>>>> I'll give it a shot to show by example. >>>>>>>>> >>>>>>>>> Suppose we have a mobile network. Base stations have addresses in >>>>>>>>> the >>>>>>>>> form 2000:0:0:X:: where X is unique for each base station. UEs are >>>>>>>>> assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE. >>>>>>>>> >>>>>>>>> Consider a packet is sent to an address within a mobile node with >>>>>>>>> external address 3000:0:0:123:0:0:0:1. Assume the device is attached >>>>>>>>> to base station with address 2000:0:0:567::. In identifier/locator >>>>>>>>> the >>>>>>>>> top sixty-four bits of address are overwritten with the locator for >>>>>>>>> forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The >>>>>>>>> packet >>>>>>>>> will reach the correct base station, but we've lost the address >>>>>>>>> information for the device so the base station has no way to forward >>>>>>>>> it on. >>>>>>>>> >>>>>>>>> Alternatively, assume the identifier is composed of a 32 bit device >>>>>>>>> identifier and 32 bits delegated to UE. Now UEs are assigned /32 in >>>>>>>>> the form 3000:0:0:0:0:Z::/32. >>>>>>>>> >>>>>>>>> Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top >>>>>>>>> sixty >>>>>>>>> four bits are overwritten with a locator so the destination on the >>>>>>>>> wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station, >>>>>>>>> and it can now be forwarded to the correct device that is identified >>>>>>>>> by the 0:123 device identifier in the address. >>>>>>>>> >>>>>>>>> Hope that helps! >>>>>>>>> >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/6/17 11:54 AM, Tom Herbert wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Both RFC7421 and RFC7136 state that a motivation for the /64 is >>>>>>>>>>> identfier/locator split addressing (like in ILNP). The motivation >>>>>>>>>>> is >>>>>>>>>>> valid, however assigning a /64 to UEs in a mobile network is not >>>>>>>>>>> compatible with identifier/locator split. The reason is that the >>>>>>>>>>> link >>>>>>>>>>> of interest for IIDs is not inside the UE, but is logically in the >>>>>>>>>>> network. The identifier in a mobile network needs to identify the >>>>>>>>>>> device. >>>>>>>>>>> >>>>>>>>>>> In identifier/locator split, the IP address is split into a >>>>>>>>>>> locator >>>>>>>>>>> and identifier. Each are 64 bits (although Brian did point out >>>>>>>>>>> that >>>>>>>>>>> that could also be a parameter). Just like IIDs, identifiers must >>>>>>>>>>> be >>>>>>>>>>> unique within the subnet. In the case of a mobile network the link >>>>>>>>>>> is >>>>>>>>>>> an overlay network that is not physical, but none the less it is a >>>>>>>>>>> type of link. >>>>>>>>>>> So the properties of it being a link including those for IIDs on >>>>>>>>>>> the >>>>>>>>>>> link hold-- this make identifiers equivalent to IIDs by >>>>>>>>>>> definition. >>>>>>>>>>> >>>>>>>>>>> The IPv6 address for identifier/locator split looks like: >>>>>>>>>>> >>>>>>>>>>> M bits for locator >>>>>>>>>>> N bits for device identifier >>>>>>>>>>> 128 - M - N bits for addresses within the device >>>>>>>>>>> >>>>>>>>>>> M is 64, and it seems straightforward to make N be 32 so we get >>>>>>>>>>> >>>>>>>>>>> 64 bits for locator >>>>>>>>>>> 32 bits for device identifier >>>>>>>>>>> 32 bits for addresses within the device >>>>>>>>>>> >>>>>>>>>>> Which implies /96 assignment to each UE. >>>>>>>>>>> >>>>>>>>>>> Thus the IID is constructed from a 32 bit number assigned to the >>>>>>>>>>> device, and a 32 bit number assigned by the device. If assignments >>>>>>>>>>> for >>>>>>>>>>> both of these are randomized this provides 64 bits of entropy for >>>>>>>>>>> security. >>>>>>>>>>> >>>>>>>>>>> Tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>>> IETF IPv6 working group mailing list >>>>>>>>>>> ipv6@ietf.org >>>>>>>>>>> Administrative Requests: >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From nobody Tue Jun 6 22:51:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDF312E858 for ; Tue, 6 Jun 2017 22:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mchUjOlNJu1w for ; Tue, 6 Jun 2017 22:51:34 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A512E856 for ; Tue, 6 Jun 2017 22:51:33 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 173D6E6065; Wed, 7 Jun 2017 07:51:31 +0200 (CEST) Date: Wed, 07 Jun 2017 07:51:31 +0200 (CEST) Message-Id: <20170607.075131.74727436.sthaug@nethelp.no> To: fredbaker.ietf@gmail.com Cc: markzzzsmith@gmail.com, job@instituut.net, ek@google.com, ipv6@ietf.org Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text From: sthaug@nethelp.no In-Reply-To: References: 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 05:51:36 -0000 > > That doesn't mention that security and privacy properties of addresses > > will be compromised if the manually configured addresses are from a > > small prefix. > > Or advertised in DNS? > > I would expect that any address configured manually would also be advertised in DNS, the latter being the reason for the former. If the address is publicly announced, does one have a reasonable expectation of privacy? That's precisely the point. I configure fixed addresses typically for servers, and I put the addresses in the DNS. I *want* those addresses to be publically known. Security and privacy is not relevant in this particular case. Steinar Haug, AS2116 From nobody Wed Jun 7 01:53:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4212EB17 for ; Wed, 7 Jun 2017 01:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDj09WTb90hW for ; Wed, 7 Jun 2017 01:53:27 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 1E4B812EB0E for ; Wed, 7 Jun 2017 01:53:27 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id o9so1373793yba.3 for ; Wed, 07 Jun 2017 01:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OfjDqfrsbTQu/w+VkWQDx2LTzU7BSUjOXCuyfxX2H2Q=; b=rqSU1jtRH1y+LNS5TOKgU7RM6Rp+nc1HmpPd667RpjjN2Z16ddqWf5FAj2kBzN6PCQ 9ibtKkSk29qj+yvYwByn1cJvBcYzwoCoMkY6mWLclcbLgbMHgM1OQIa+5mwSWi0/SRvF BMh8zsY9gQCPG8PJwHRuNVlMFr+XTjJBubQ9v2++3I8NRo/liZ4kx8xe3mg/8Y6vHICe 81yRK+xM4e6JliWIwzwyRjxsI0efvaaogFOFFYVmhNlpubszj68G8l0RN3ERKdYQix58 H3hi55/MOhH0Hp6yft1bwAMcB/GZL2yBP/i347YmJaUZBDpXg+SmIDyknFEfL28lr5oq HFhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OfjDqfrsbTQu/w+VkWQDx2LTzU7BSUjOXCuyfxX2H2Q=; b=Nezp5WampSlS1HLj/sCiMxun5T+jW6vDn8nePPDKyRMGXmhZgdUzIgUVrYsTT5jkbx 7EPkA7q4x4iIVvMjWdABBiy1vNphQ9WdfMdhFt2f6jVYHX7gp3/DwQ1d0QzRdJE3cgJO wuz87dnUn13DWut0HkxRpygIf08OKkFRBnCek/2X/K2AwbJ8BSCcZfb8kc6/c22101jl qWtUVKvmyTtKLnvjNYkvt+kK4oxImz4KV/2MuOTn2+rr/bSM8RL/LiZkz5+UXF7xNfEi hcG/FJwOrP24N8xEIvsw7S+h4a+kQw+3Enwn/2bw2F8V0Ylx4cGnI7DYLNUbWkGDKkFd Dv2A== X-Gm-Message-State: AODbwcAG2ZQavltBORt1grk8Xb922WFus1IuhsSa1HKFQHwhQyzFzs6w qBAfuLOdPe7gXb9hcrW7ltupx6BbESSv X-Received: by 10.37.195.66 with SMTP id t63mr6142821ybf.98.1496825606213; Wed, 07 Jun 2017 01:53:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Wed, 7 Jun 2017 01:53:05 -0700 (PDT) In-Reply-To: <20170607.075131.74727436.sthaug@nethelp.no> References: <20170607.075131.74727436.sthaug@nethelp.no> From: Erik Kline Date: Wed, 7 Jun 2017 17:53:05 +0900 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text To: sthaug@nethelp.no Cc: Fred Baker , Mark Smith , job@instituut.net, IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114d74de92537b05515ade81" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 08:53:29 -0000 --001a114d74de92537b05515ade81 Content-Type: multipart/alternative; boundary="001a114d74de8d2fc705515adecd" --001a114d74de8d2fc705515adecd Content-Type: text/plain; charset="UTF-8" On 7 June 2017 at 14:51, wrote: > > > That doesn't mention that security and privacy properties of addresses > > > will be compromised if the manually configured addresses are from a > > > small prefix. > > > > Or advertised in DNS? > > > > I would expect that any address configured manually would also be > advertised in DNS, the latter being the reason for the former. If the > address is publicly announced, does one have a reasonable expectation of > privacy? > > That's precisely the point. I configure fixed addresses typically for > servers, and I put the addresses in the DNS. I *want* those addresses > to be publically known. Security and privacy is not relevant in this > particular case. > For an authoritative server, sure. But if you're a recursive resolver then using privacy addresses while doing recursion (and changing the privacy addresses frequently) might indeed be very useful. (In fact: a unique source address per query is wonderful.) --001a114d74de8d2fc705515adecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 7= June 2017 at 14:51, <sthaug@nethelp.no> wrote:
> > That doesn't mention that security and= privacy properties of addresses
> > will be compromised if the manually configured addresses are from= a
> > small prefix.
>
> Or advertised in DNS?
>
> I would expect that any address configured manually would also be adve= rtised in DNS, the latter being the reason for the former. If the address i= s publicly announced, does one have a reasonable expectation of privacy?
That's precisely the point. I configure fixed addresses typically for servers, and I put the addresses in the DNS. I *want* those addresses
to be publically known. Security and privacy is not relevant in this
particular case.

For an authoritative s= erver, sure.

But if you're a recursive resolve= r then using privacy addresses while doing recursion (and changing the priv= acy addresses frequently) might indeed be very useful. =C2=A0(In fact: a un= ique source address per query is wonderful.)
--001a114d74de8d2fc705515adecd-- --001a114d74de92537b05515ade81 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgHFaOzEt+X3GcQOiVe5RdexkG4zqeyVCJ 2867+0/60lkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjA3 MDg1MzI2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAHmjLu9beVdxh/5e62qrq3s98faiQI0jiYathk58AU/RWiTIBe/D 6PG7vUsaPg9dFB1sBcISPJdsD5fmmIWZeh7lMw+BLKbFH3y/jV0NdDRx9OUbkBvlG7/fly84jed/ DpnICAH+iQJRcT1fXImooXp8XbO2x3MPeFsh5zjlbDyx6yHY63DbCzgAQ5ZBlMslV+zEjy7sJ6ho ggVBdXYCkvp6jX7tWw5320ZVfLrBgpBOj0FtJRPsJ/OBrmfDmTBP0VtMusHhYJLxA4+uGaWPKSYQ S3eiigZt9dat8Z7MISw5zSpBZzOPy0X9fEWDrZUaTrz9ZJBMLV/6gzjMfCbxErM= --001a114d74de92537b05515ade81-- From nobody Wed Jun 7 01:54:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8584712EB27 for ; Wed, 7 Jun 2017 01:53:59 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib_13B32nkLU for ; Wed, 7 Jun 2017 01:53:57 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 BBA2B12EB2B for ; Wed, 7 Jun 2017 01:53:51 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id h39so3001555uaa.3 for ; Wed, 07 Jun 2017 01:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q9l6MGX7LHOWo4jh8VLMIVJzvafbEjCBBPOnyp64eFs=; b=NbvDzO6Qty416MmrY8oPubEDdTGln3319PfOeeRJP1IAKjqOGxW4nfCKM3iZlNST2l ord4WuPEQsAU9lvVQw4GCEfXh01lJ3Jcs5/U8cTAhZ0FwTh6VWw6Ucj6AQzi+eZ9i1GE fZ8dLXO1CQ1cH5R0pHfQrXzo3CJz+9c5Rd0w5LDbl/T8+YmDmkrodr1DEapsMjUVqeMO QlmMvUjzfZmrd1Uknk5Wb5H8ZyVj/YKyOf1SNyiVeDtAMo1lfrGsMX/jrJX3fu0I/Fr4 V+IuQZaZL3RodOkmO6Cz/SceV3YxdNuKsNyTuVSTni5wiIXj9c+VAGNgrAJLBwfHxY7i YmOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q9l6MGX7LHOWo4jh8VLMIVJzvafbEjCBBPOnyp64eFs=; b=B6Oz79daOqSn/X456Pdis3uYyrqvDVFlJ3lAAhfurJ57SGj1Gi4hX8jYb76tR6/sHv 8tBg6A6vVn6K3BzI9q4iF7nF5OaQr8sUkldVxkYwVuvrONMzvA5A18EhRwr/U+c2uSwp HoGiA/iR/an7UkvXxOS1juxe/XqddVXIMOlnijRLLTuU5SWkpyWXptpQv10xrxyH3Ceu StosTmyeP0F72fE0KoHDbubx8rWcDcHU2FujaPSnRVf4lquZM2db1akk1GT3VQAaujaR ngn2G3oXEMrCfEgAHHaOBhV/OhRDNG4lzr2Z+5csl/Bx9Sp2PxSnO5C1bWz5v/ZqlsgJ r/Kw== X-Gm-Message-State: AODbwcDN2Bm28D0m+5vNEeJg6Kx3hdWLAfcMWztdwcj50DfRpU9fVa9g DL3neiSbRfHdTHrTHbyHRLvKWH92erx1 X-Received: by 10.176.95.217 with SMTP id g25mr12065073uaj.71.1496825630846; Wed, 07 Jun 2017 01:53:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 7 Jun 2017 01:53:30 -0700 (PDT) In-Reply-To: <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> From: Lorenzo Colitti Date: Wed, 7 Jun 2017 17:53:30 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: james woodyatt Cc: Erik Kline , 6man Content-Type: multipart/alternative; boundary="089e0820496004c34605515ae0e9" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 08:53:59 -0000 --089e0820496004c34605515ae0e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt wrote: > > p1. Power conservative ND Proxy isn=E2=80=99t possible with Thread=E2=84= =A2 1.1 (and > earlier) networks. It may never be possible in future versions of Thread= =E2=84=A2. > Can you explain to us why it doesn't work? One might naively think that if the BR is doing NAT for hosts behind it, it has to process a similar packets as it would have to process if it were doing ND. --089e0820496004c34605515ae0e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 7, 2017 at 4:06 AM, james woodyatt <jhw@google.com> wro= te:
=
p1. Power conservative ND Proxy isn=E2=80=99t possible with Thread=E2= =84=A2 1.1 (and earlier) networks. It may never be possible in future versi= ons of Thread=E2=84=A2.

C= an you explain to us why it doesn't work? One might naively think that = if the BR is doing NAT for hosts behind it, it has to process a similar pac= kets as it would have to process if it were doing ND.
--089e0820496004c34605515ae0e9-- From nobody Wed Jun 7 02:44:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109612EB48; Wed, 7 Jun 2017 02:44:03 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3epgZwPan3PF; Wed, 7 Jun 2017 02:44:01 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1D612EB4B; Wed, 7 Jun 2017 02:43:59 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Jun 2017 09:43:58 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CBE8AD788D; Wed, 7 Jun 2017 02:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=R01F5DlzKDZLJ8/OkMo01Zd1ApM=; b= DC/Bj8jA+JMymSnL2bXQbp/lzqdP7vQmxGvE2G6djdniIWB2kRorPGGNSYOu4BgU Uas754f9O6buVdk+p1KoiHaLeUtk/qAV7Kp4EsA4gn/k/rKM+T+lDDAS7/P3hHUN zyOs5DpTlEHee3Gu4oTUUgP1ctRFbKb/Ir5E8eliW6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=KIhBn/CMD2hQbiew4gAlpRX OOq6dKWgTNCduGSM9YuEHTOPmftKiieU5zcdCJFVToXl5V3CLK8IdyaQa40IdQAB KwJBVWomMZxPGOk/dIc5gJzTTeFj8JlkNk7WF6AJh02S8ou+Z7sMLWzFEVAyX06R cyobNyAFLxfO7yqlNASg= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5617ED788B; Wed, 7 Jun 2017 02:43:57 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9458ECE1C14D; Wed, 7 Jun 2017 11:43:57 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5B4C9C97-2BD5-4342-A57E-BB3AD495F38A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Wed, 7 Jun 2017 11:43:56 +0200 In-Reply-To: Cc: draft-bourbaki-6man-classless-ipv6@ietf.org, 6man WG To: Matthew Petach References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 09:44:03 -0000 --Apple-Mail=_5B4C9C97-2BD5-4342-A57E-BB3AD495F38A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Many of the arguments against this draft seem to > be of the form "this is bad because it might allow > uninformed people to make bad decisions which > could have bad outcomes." I find this line of reasoning > to be somewhat disturbing. >=20 > Imagine, if you will, early man, out hunting for food > using his typical tool, a blunt club. Along comes Thag, > with a sharpened stick, ready to join the hunt. Early > man looks at it and says "wait...that looks dangerous; > someone could use that the wrong way, and hurt > themselves, or potentially hurt me. Rather than > take that risk, and potentially learn new, more > efficient ways of getting food, let's just ban it > now, before anyone gets any new ideas." > We could still be out on the plains, beating > our meat with blunt clubs instead of learning > new ways of hunting. We shouldn't fear progress, > even if it comes with a few roadbumps and bruises. >=20 > This draft isn't saying you *have* to use a bit boundary > other than /64; it's simply saying you have the *option* > to do so, if you like. It's giving people the flexibility to > try new combinations out; some of them may be ill-advised; > a few warriors may come back with one less limb, having > discovered the _pointy_ end goes towards the prey. But > on the whole, the potential for advancement would seem > to outweigh the risks of people maybe doing something > stupid here and there. >=20 > I support this draft for its ability to look beyond the > classful box, to a world in which creative new possibilities > open up before us, enabling new and unusual addressing > models and the potential for discovering new network > topologies we'd never considered before. > We shouldn't let ourselves be ruled by the fear of what > someone *might* do, and hold ourselves back from the > chance to progress and expand outside of our current > box. >=20 > Let's bring innovation back to the Internet. I believe that innovation in the IP layer hinders innovation other = places in the stack (aka the Internet). A core principle of the Internet architecture is to keep the waist of = the hourglass/wineglass narrow to allow for Innovation above and below. Best regards, Ole --Apple-Mail=_5B4C9C97-2BD5-4342-A57E-BB3AD495F38A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZN8rdAAoJEL7aWKiYQt922fkQAI7KRCcSLvhbKE1UGDHLI1LO C2cwVUW94syCc0nGfsZ5tmmzWr/YO21Z8ECclTIlfZJHRP+bImFEJi29oKstTTA0 /Ojdf+nWJoNzgWmpbsYKwPm8xi31WRPnXY21nC4WQqAfzLCMVmIZ4Zsb1u98PMpt O8fRYxNoY7zsOwu0FqzZIWSJw2SxUdekvbyfZRy7xoVGYIhK/HiF8CYmMNNaMWgq G+NiNCpVtpGzqmUujHyvvEysBu6RdqF1UeqkV3ETgWZOfRlmgTOZRl5m3+Lf/Rvj lgUzXxXGBIvFccvpRi4g6TBzkH0wy1PgF/x7F6X62qJCo6i7kUEAitsN7+ySI25u 8PP+zPhI5rBXZcSTtVk8wpJ61yUGyz4MGoWtFHQ0Eqqdwi5J0b+rdST9glwyYuwe yv4PcOunENL6+CDHW6E6h9fgvQXd5Oah4jArc7QVKft4u7Jkzm43mnKeqxmCYP4o i8GrmFb+1IBylW+UQDBp+2P2KwXyqan7Qu0opYO+cIEpQ4LfPHd5VJtYP8an14dN 8hC3EW8Npj/ZDvEwvENEBQhLsW8fJ3kN4ZQqy67p4nqmB511iQR89SZj4zr9MmDB IbfXwCfYDaEio8nomNVf9AeLQ2uIfV0YodrnMciO/LxPl84thHVoox5BzKdM2lNv tAIiTZNL3C8CnVB635Os =pABR -----END PGP SIGNATURE----- --Apple-Mail=_5B4C9C97-2BD5-4342-A57E-BB3AD495F38A-- From nobody Wed Jun 7 03:44:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BC412EB95; Wed, 7 Jun 2017 03:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhDHttFfAmzj; Wed, 7 Jun 2017 03:44:56 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 C6E8412EB92; Wed, 7 Jun 2017 03:44:55 -0700 (PDT) X-AuditID: 60721c4b-0e3ff7000000704e-94-5937d924e89c Received: from VAADCEX47.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 11.C2.28750.429D7395; Wed, 7 Jun 2017 06:44:54 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX47.cable.comcast.com (147.191.103.224) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 7 Jun 2017 06:44:51 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Wed, 7 Jun 2017 06:44:51 -0400 From: "Leddy, John" To: "otroan@employees.org" , Matthew Petach CC: "draft-bourbaki-6man-classless-ipv6@ietf.org" , 6man WG Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AQHS33Khh/nIwD5xZ0m2+eOfSnT1nKIZN0aA Date: Wed, 7 Jun 2017 10:44:50 +0000 Message-ID: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@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/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf2wTVRzPu7vWW+2bt9vavZWB7mRDxjY6XFgTjEAksLE/IPEP7TSBW3e0 pbd13rX7QSRZNKBW/ijbglJiIDKELVh0kUDMmK6OVRYYSoB102mWDXUEWTBRJEbivbvrdvWv +97n897n8/l+38ujSfaAxUH7m0OC1MyLnNlC7ZZrXeUlk9Vu581vVrpGpra45q8tEK6hj38z uboPnjFvomqGRx+Amt7eR0TN1398BHaS9ZYXGgXR3ypIa1/cbfH1JftMLTfXtJ/8+W9TJxgp jYAsGjFVaOHqcXMEWGiWuUCgoZlDpPYzDNCl1CTQfr4FqO+vbgpvMTNl6MMjt024zmNeQ3eO 9RC4Jpl96GTkJzOuc5laNHrhPqGt2Y6mP4k8odXr0GCiS91LMStRb1dU0aRpyGxB9w80aF7/ EOj0wDiJ12Qxm1H0UlzVAYwdPRw7q3vlo6m544TWAoN6B6+TWm1D87OPVX0bU4EG+g/qa8rQ tYk5oNVOdP7UEKXVT6OR6GM1A8msRue+XKvJb0KH5g8DrS5CPe/PqPEhk4OuHJ3Ttxag4TMp KgqWxQyJYktKMYNSzKAUMyidAKZ+sKKV5xs9Tb5gOOSsrPDwDaJQ4Qk2eXg5hL8DAB+/VFh3 EcQfbUsAhgacFX6erHazJr5V7mhKgABNcDYYuahA2Q3Bxg4fL/t2SWFRkLk8WDyhwHARbgiL Ac6hobmLaLPQJotCSLlv3ApYHFO4/EVODsstfo8/GJZ3hSUxARBNKrKHL2PZRr5jnyAFNbME WEZTXD7sCVS6WcbLh4SAILQIUppto2kOwQfYOUcSvEL7Hr8YStPKvg0phWGMjBp2ORz/c72b tRsJQ94iaN2o0A4j/f/IBJ2VAF7aquR+/jucW27hm2S/V7fOhfGvFNSaRlXbAliKk7Jp0GC5 HK7CI7KnqUy7MdDhyIdQbQav8IWbF7t02OHktNPNPmUgsJujEN7AuM2ALxk6noEzmC0wsJme 6SfiLvAo1yMXerG7VXlAlppkYT0Gn9RBtUcEn1NPQ8cMLRbCEtyiTWcy3e4qsySUWWbfqMKz DPEh4yx/+KUKz1JH9VmmMMimwYxZTmLKnqYynRydoHiPq+DWsZfCqz6zuj+4d/bd4Mv36l/d ev4tsXrz5RPBruRsztj2DfU/7ri6/5XW/pLZ7OqYN5BsX98evfNratg6Nr2t7t+91Osz79y2 OK1id+XD04Nw3bhn4s3aI53OZHnee6fOxb9fuPVG2dujV+qKejrb2E9/31gejz77hWt/dm3Z 1FGOkn18ZSkpyfx/KzlKc5gFAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 10:44:57 -0000 SW5ub3ZhdGlvbiBhdCB0aGUgTmV0d29yayBsYXllciBjcmVhdGVkIHRoZSBJbnRlcm5ldC4NCklu bm92YXRpb24gYXQgdGhlIE5ldHdvcmsgbGF5ZXIgaGFzIGxldCBpdCBncm93IHRvIHRoZSBwb2lu dCBpdCBpcyBhdCDigJMgaW5jbHVkaW5nIHRoaW5ncyB3ZSBtYXkgbm90IGxpa2UsIGV4LiBOQVQu DQpUaGUgSW50ZXJuZXQgbGV2ZXJhZ2VkL2Fkb3B0ZWQvcmUtYXJjaGl0ZWN0ZWQgaW5ub3ZhdGlv biBhdCB0aGUgTmV0d29yayBsYXllciB0aGF0IG9jY3VycmVkIGV2ZW4gb3V0c2lkZSBvZiBJUCDi gJMgYWxsIHRoZSBvdGhlciBOZXR3b3JraW5nIHByb3RvY29scyB0aGF0IGV4aXN0ZWQg4oCTIEFw cGxldGFsaywgWE5TL0JhbnlhbiBWaW5lcywgREVDbmV04oCmDQoNCldpdGhvdXQgdGhlIGlubm92 YXRpb24sIHdl4oCZZCBzdGlsbCBiZSB0YWxraW5nIGFib3V0IFNPTkVULCBYLjI1LCBBVE0sIEZy YW1lUmVsYXkg4oCTIHZlcnkgbmFycm93IGhvdXJnbGFzc2VzL3dpbmVnbGFzc2VzLg0KDQpIb3cg bmFycm93IG9mIGEgd2Fpc3Qgc3B1cnMgaW5ub3ZhdGlvbiBhdCB0aGUgbGF5ZXJzIGFib3ZlIGFu ZCBiZWxvdyB0aGUgTmV0d29yayBsYXllcj8gIA0KU2hvdWxkIHdlIHJlZ3Jlc3MgaW4gb3JkZXIg dG8gc3B1ciBldmVuIG1vcmUgaW5ub3ZhdGlvbj8gIA0KUGVyaGFwcyBJUCBpdHNlbGYgbGltaXRz IGlubm92YXRpb24gYXQgdGhlIGxheWVycyBhYm92ZSBhbmQgYmVsb3cgSVA/ICBFeC4gRHVhbCBT dGFjayDigJMgYSBkaWZmaWN1bHQgbWlncmF0aW9uIGFuZCBvcGVyYXRpb25hbCBzdGF0ZS4NCg0K VGhlcmUgYXJlIOKAnG5v4oCdIE5ldHdvcmsgcHJvdG9jb2xzIG90aGVyIHRoYW4gSVAgdG9kYXkg 4oCTIGl0IGlzIHZlcnkgaGFyZCB0byBqdXN0aWZ5IGlubm92YXRpb24gb3V0c2lkZSBvZiBJUCBh bmQgSVBWNiBpcyB0aGUgb25seSBwbGF0Zm9ybSB3aGVyZSBjaGFuZ2UgaXMgZXZlbiBwb3NzaWJs ZSBhbmQgd29ydGggdGhlIGVmZm9ydC4gIEl0IHRha2VzIHRvbyBsb25nIGFuZCBtaWdyYXRpb25z IGFyZSBleHBlbnNpdmUuDQoNCldoZW4gdGhlcmUgd2FzIGEgc291cCBvZiBuZXR3b3JraW5nIHBy b3RvY29scyBhbmQgbm8gY2xlYXIgY29uc2Vuc3VzIGFib3V0IGhvdyBOZXR3b3JraW5nIGNvbnNv bGlkYXRlcyBhcm91bmQgYSBzdGFuZGFyZCBzZXQgb2YgcHJvdG9jb2xzIGZvciBzeXN0ZW1zIHRv IGNvbW11bmljYXRlIOKAkyDigJxBIGNvcmUgcHJpbmNpcGxlIG9mIHRoZSBJbnRlcm5ldCBhcmNo aXRlY3R1cmUgaXMgdG8ga2VlcCB0aGUgd2Fpc3Qgb2YgdGhlIGhvdXJnbGFzcy93aW5lZ2xhc3Mg bmFycm934oCdIC0gYmVjYXVzZSB1YmlxdWl0eSB3YXMgYSBtYWpvciBnb2FsLiAgSVAgaXRzZWxm IHdhcyB0aGUgTWFqb3IgSW5ub3ZhdGlvbi4NCg0KSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEg YmFzaXMgdG8gc2F5IHRoYXQgdGhhdCBwcmluY2lwbGUgaXMgY29ycmVjdCBpbiB0b2RheeKAmXMg SW50ZXJuZXQsIG15IGJlbGllZi4NCg0KSm9obiBMZWRkeQ0KDQpPbiA2LzcvMTcsIDU6NDMgQU0s ICJpcHY2IG9uIGJlaGFsZiBvZiBvdHJvYW5AZW1wbG95ZWVzLm9yZyIgPGlwdjYtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2Ygb3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KDQogICAg PiBNYW55IG9mIHRoZSBhcmd1bWVudHMgYWdhaW5zdCB0aGlzIGRyYWZ0IHNlZW0gdG8NCiAgICA+ IGJlIG9mIHRoZSBmb3JtICJ0aGlzIGlzIGJhZCBiZWNhdXNlIGl0IG1pZ2h0IGFsbG93DQogICAg PiB1bmluZm9ybWVkIHBlb3BsZSB0byBtYWtlIGJhZCBkZWNpc2lvbnMgd2hpY2gNCiAgICA+IGNv dWxkIGhhdmUgYmFkIG91dGNvbWVzLiIgIEkgZmluZCB0aGlzIGxpbmUgb2YgcmVhc29uaW5nDQog ICAgPiB0byBiZSBzb21ld2hhdCBkaXN0dXJiaW5nLg0KICAgID4gDQogICAgPiBJbWFnaW5lLCBp ZiB5b3Ugd2lsbCwgZWFybHkgbWFuLCBvdXQgaHVudGluZyBmb3IgZm9vZA0KICAgID4gdXNpbmcg aGlzIHR5cGljYWwgdG9vbCwgYSBibHVudCBjbHViLiAgQWxvbmcgY29tZXMgVGhhZywNCiAgICA+ IHdpdGggYSBzaGFycGVuZWQgc3RpY2ssIHJlYWR5IHRvIGpvaW4gdGhlIGh1bnQuICBFYXJseQ0K ICAgID4gbWFuIGxvb2tzIGF0IGl0IGFuZCBzYXlzICJ3YWl0Li4udGhhdCBsb29rcyBkYW5nZXJv dXM7DQogICAgPiBzb21lb25lIGNvdWxkIHVzZSB0aGF0IHRoZSB3cm9uZyB3YXksIGFuZCBodXJ0 DQogICAgPiB0aGVtc2VsdmVzLCBvciBwb3RlbnRpYWxseSBodXJ0IG1lLiAgUmF0aGVyIHRoYW4N CiAgICA+IHRha2UgdGhhdCByaXNrLCBhbmQgcG90ZW50aWFsbHkgbGVhcm4gbmV3LCBtb3JlDQog ICAgPiBlZmZpY2llbnQgd2F5cyBvZiBnZXR0aW5nIGZvb2QsIGxldCdzIGp1c3QgYmFuIGl0DQog ICAgPiBub3csIGJlZm9yZSBhbnlvbmUgZ2V0cyBhbnkgbmV3IGlkZWFzLiINCiAgICA+IFdlIGNv dWxkIHN0aWxsIGJlIG91dCBvbiB0aGUgcGxhaW5zLCBiZWF0aW5nDQogICAgPiBvdXIgbWVhdCB3 aXRoIGJsdW50IGNsdWJzIGluc3RlYWQgb2YgbGVhcm5pbmcNCiAgICA+IG5ldyB3YXlzIG9mIGh1 bnRpbmcuICBXZSBzaG91bGRuJ3QgZmVhciBwcm9ncmVzcywNCiAgICA+IGV2ZW4gaWYgaXQgY29t ZXMgd2l0aCBhIGZldyByb2FkYnVtcHMgYW5kIGJydWlzZXMuDQogICAgPiANCiAgICA+IFRoaXMg ZHJhZnQgaXNuJ3Qgc2F5aW5nIHlvdSAqaGF2ZSogdG8gdXNlIGEgYml0IGJvdW5kYXJ5DQogICAg PiBvdGhlciB0aGFuIC82NDsgaXQncyBzaW1wbHkgc2F5aW5nIHlvdSBoYXZlIHRoZSAqb3B0aW9u Kg0KICAgID4gdG8gZG8gc28sIGlmIHlvdSBsaWtlLiAgSXQncyBnaXZpbmcgcGVvcGxlIHRoZSBm bGV4aWJpbGl0eSB0bw0KICAgID4gdHJ5IG5ldyBjb21iaW5hdGlvbnMgb3V0OyBzb21lIG9mIHRo ZW0gbWF5IGJlIGlsbC1hZHZpc2VkOw0KICAgID4gYSBmZXcgd2FycmlvcnMgbWF5IGNvbWUgYmFj ayB3aXRoIG9uZSBsZXNzIGxpbWIsIGhhdmluZw0KICAgID4gZGlzY292ZXJlZCB0aGUgX3BvaW50 eV8gZW5kIGdvZXMgdG93YXJkcyB0aGUgcHJleS4gIEJ1dA0KICAgID4gb24gdGhlIHdob2xlLCB0 aGUgcG90ZW50aWFsIGZvciBhZHZhbmNlbWVudCB3b3VsZCBzZWVtDQogICAgPiB0byBvdXR3ZWln aCB0aGUgcmlza3Mgb2YgcGVvcGxlIG1heWJlIGRvaW5nIHNvbWV0aGluZw0KICAgID4gc3R1cGlk IGhlcmUgYW5kIHRoZXJlLg0KICAgID4gDQogICAgPiBJIHN1cHBvcnQgdGhpcyBkcmFmdCBmb3Ig aXRzIGFiaWxpdHkgdG8gbG9vayBiZXlvbmQgdGhlDQogICAgPiBjbGFzc2Z1bCBib3gsIHRvIGEg d29ybGQgaW4gd2hpY2ggY3JlYXRpdmUgbmV3IHBvc3NpYmlsaXRpZXMNCiAgICA+IG9wZW4gdXAg YmVmb3JlIHVzLCBlbmFibGluZyBuZXcgYW5kIHVudXN1YWwgYWRkcmVzc2luZw0KICAgID4gbW9k ZWxzIGFuZCB0aGUgcG90ZW50aWFsIGZvciBkaXNjb3ZlcmluZyBuZXcgbmV0d29yaw0KICAgID4g dG9wb2xvZ2llcyB3ZSdkIG5ldmVyIGNvbnNpZGVyZWQgYmVmb3JlLg0KICAgID4gV2Ugc2hvdWxk bid0IGxldCBvdXJzZWx2ZXMgYmUgcnVsZWQgYnkgdGhlIGZlYXIgb2Ygd2hhdA0KICAgID4gc29t ZW9uZSAqbWlnaHQqIGRvLCBhbmQgaG9sZCBvdXJzZWx2ZXMgYmFjayBmcm9tIHRoZQ0KICAgID4g Y2hhbmNlIHRvIHByb2dyZXNzIGFuZCBleHBhbmQgb3V0c2lkZSBvZiBvdXIgY3VycmVudA0KICAg ID4gYm94Lg0KICAgID4gDQogICAgPiBMZXQncyBicmluZyBpbm5vdmF0aW9uIGJhY2sgdG8gdGhl IEludGVybmV0Lg0KICAgIA0KICAgIEkgYmVsaWV2ZSB0aGF0IGlubm92YXRpb24gaW4gdGhlIElQ IGxheWVyIGhpbmRlcnMgaW5ub3ZhdGlvbiBvdGhlciBwbGFjZXMgaW4gdGhlIHN0YWNrIChha2Eg dGhlIEludGVybmV0KS4NCiAgICBBIGNvcmUgcHJpbmNpcGxlIG9mIHRoZSBJbnRlcm5ldCBhcmNo aXRlY3R1cmUgaXMgdG8ga2VlcCB0aGUgd2Fpc3Qgb2YgdGhlIGhvdXJnbGFzcy93aW5lZ2xhc3Mg bmFycm93IHRvIGFsbG93IGZvciBJbm5vdmF0aW9uIGFib3ZlIGFuZCBiZWxvdy4NCiAgICANCiAg ICBCZXN0IHJlZ2FyZHMsDQogICAgT2xlDQogICAgDQoNCg== From nobody Wed Jun 7 04:35:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F886127843; Wed, 7 Jun 2017 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxH7xEGAkKTt; Wed, 7 Jun 2017 04:35:56 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 633EA1275C5; Wed, 7 Jun 2017 04:35:56 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Jun 2017 11:35:54 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 05E90D788D; Wed, 7 Jun 2017 04:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=FrVLgGBmpGy+8Jk7s0UGB+Imw2c=; b= NiDvkv5tn3lmmM+h8P2XaRHRvg0L/aEtE5AWXNwpR7z/YMXsvkAQSAf+6Gx0FyWE iUFD2ETOgA3xDBDn/t/5YSYOVSxzzGv6o493FSdCOPH7IKyuc29PCcC7iGF7iGA0 wGPjLFCCBKGcEASTDqbQBYv0C+ExdVUsMjb1z7uJqyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=L6WcRpd1ohfZTCy5KhzkG3U R4zw5StF7JHTKey3ZN5Q7/b0U5sydQUR7Ccv58GZoTueLNdwhaoHGSsHcw0xv4Xe piaGnP8scWsgy8hX/x68537Tx5/3XzdNCgFZTSxLnImWoLYXsihuy3YHsYrjcrPs k3mZmtymCnb64pQ0EZeM= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A543ED788B; Wed, 7 Jun 2017 04:35:53 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 16941CE2E92D; Wed, 7 Jun 2017 13:35:50 +0200 (CEST) From: otroan@employees.org Message-Id: <32658EA6-B8A1-4D16-850B-42132FC8301C@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DB20FD68-19C2-4B81-85E7-08DA84D59854"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: The waist diameter (was: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)) Date: Wed, 7 Jun 2017 13:35:49 +0200 In-Reply-To: Cc: Matthew Petach , "draft-bourbaki-6man-classless-ipv6@ietf.org" , 6man WG To: "Leddy, John" References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 11:35:58 -0000 --Apple-Mail=_DB20FD68-19C2-4B81-85E7-08DA84D59854 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 John, > Innovation at the Network layer created the Internet. > Innovation at the Network layer has let it grow to the point it is at = =E2=80=93 including things we may not like, ex. NAT. > The Internet leveraged/adopted/re-architected innovation at the = Network layer that occurred even outside of IP =E2=80=93 all the other = Networking protocols that existed =E2=80=93 Appletalk, XNS/Banyan Vines, = DECnet=E2=80=A6 >=20 > Without the innovation, we=E2=80=99d still be talking about SONET, = X.25, ATM, FrameRelay =E2=80=93 very narrow hourglasses/wineglasses. >=20 > How narrow of a waist spurs innovation at the layers above and below = the Network layer? > Should we regress in order to spur even more innovation? > Perhaps IP itself limits innovation at the layers above and below IP? = Ex. Dual Stack =E2=80=93 a difficult migration and operational state. >=20 > There are =E2=80=9Cno=E2=80=9D Network protocols other than IP today = =E2=80=93 it is very hard to justify innovation outside of IP and IPV6 = is the only platform where change is even possible and worth the effort. = It takes too long and migrations are expensive. >=20 > When there was a soup of networking protocols and no clear consensus = about how Networking consolidates around a standard set of protocols for = systems to communicate =E2=80=93 =E2=80=9CA core principle of the = Internet architecture is to keep the waist of the hourglass/wineglass = narrow=E2=80=9D - because ubiquity was a major goal. IP itself was the = Major Innovation. >=20 > I don=E2=80=99t think there is a basis to say that that principle is = correct in today=E2=80=99s Internet, my belief. Of course both of us are paid to put smarts into the network layer = (:-)), but if you look at it from an Internet-wide perspective, can you = name any innovations at the network layer that has been successful? - IP multicast -> fail - IPsec -> fail - Mobile IP -> fail - Fragmentation -> partly fail - Path MTU discovery -> partly fail The only thing I can think of are the various forms of tunnelling that = are a raging successes. And NAT. I guess you can say that the network layer's territorial = dispute with the transport layer, where network has permanently occupied = the first 8 bytes of the transport header have been successful. The network layer is the only thing ubiquitous among all nodes on the = Internet. Thereby making incredibly difficult to change. The fact that you have near infinite address space does perhaps allow = for innovation. Some good some horrid. E.g. semantic addresses (put the MTU value in the = address), or giving individual chunks in a video individual addresses. = But the address space is part of the tussle. Where we as a community has = decided that the left-most 64 bits are given to the network and the = rightmost 64 bits are given to the hosts. Both groups are going to = invent stuff that requires more than 64 bits for themselves. If the IETF = decided to reset the playing field and withdraw from participating = setting the ground rules. Where would that tussle play out? Best regards, Ole >=20 > John Leddy >=20 > On 6/7/17, 5:43 AM, "ipv6 on behalf of otroan@employees.org" = wrote: >=20 >> Many of the arguments against this draft seem to >> be of the form "this is bad because it might allow >> uninformed people to make bad decisions which >> could have bad outcomes." I find this line of reasoning >> to be somewhat disturbing. >>=20 >> Imagine, if you will, early man, out hunting for food >> using his typical tool, a blunt club. Along comes Thag, >> with a sharpened stick, ready to join the hunt. Early >> man looks at it and says "wait...that looks dangerous; >> someone could use that the wrong way, and hurt >> themselves, or potentially hurt me. Rather than >> take that risk, and potentially learn new, more >> efficient ways of getting food, let's just ban it >> now, before anyone gets any new ideas." >> We could still be out on the plains, beating >> our meat with blunt clubs instead of learning >> new ways of hunting. We shouldn't fear progress, >> even if it comes with a few roadbumps and bruises. >>=20 >> This draft isn't saying you *have* to use a bit boundary >> other than /64; it's simply saying you have the *option* >> to do so, if you like. It's giving people the flexibility to >> try new combinations out; some of them may be ill-advised; >> a few warriors may come back with one less limb, having >> discovered the _pointy_ end goes towards the prey. But >> on the whole, the potential for advancement would seem >> to outweigh the risks of people maybe doing something >> stupid here and there. >>=20 >> I support this draft for its ability to look beyond the >> classful box, to a world in which creative new possibilities >> open up before us, enabling new and unusual addressing >> models and the potential for discovering new network >> topologies we'd never considered before. >> We shouldn't let ourselves be ruled by the fear of what >> someone *might* do, and hold ourselves back from the >> chance to progress and expand outside of our current >> box. >>=20 >> Let's bring innovation back to the Internet. >=20 > I believe that innovation in the IP layer hinders innovation other = places in the stack (aka the Internet). > A core principle of the Internet architecture is to keep the waist = of the hourglass/wineglass narrow to allow for Innovation above and = below. >=20 > Best regards, > Ole >=20 >=20 --Apple-Mail=_DB20FD68-19C2-4B81-85E7-08DA84D59854 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZN+UVAAoJEL7aWKiYQt92CqMP/1WUlpzEfbbpY8ulBIl75i8q of1y1VzumX1bAcmfvKlL5Yx1RWF+l1zPShqBjp8YlDcOzbaTS8EcGe2ZSuHrzIs1 v92hQ+wRLOpuh/L3M4W8h0MdnN3fP6Da+HEp14at9WqiyJYD+TBX1IrQob5E5kl8 SsQOXziL/ICCJKQuEWrwOzYvW9cD7WuPWAMDnTOl8taule2TRo0jx/rnjxSKIMCA qAUP/npQs1fSYnmWwCizafDY1LUGVXyFqvGpDlmnILOlWLNwUVbgdvk/0ilLDKDC ihnEvqJWI3RcjjJXxdHpqiU2djeyIvHCtrYsp3sqKZzSPiFmNF49PtFkKV8WX2R/ SVdMKbkatzgBoOwcVVUfs6d314TMGsgmE/zd6JP2nXiuJadPTVKkpXgPJ2w4o1nf A3lshbsSEKsJRMRIHZ+6+LWXmzrBftephQAe3PiTBkY6nb/Q6AtmL3nsfrZ5BzGd i4W1TBAScbmlOuzkd8mBQ6dGlhMKWzrZs7Iw1CEtfzmDj2Biaq0GqkM1VeS2oSZG 9WN44Db8jgPBgxBLYK9BFCFbH8nuBsZQleQtpWtKy5fr2wxoiEFR7H4aEpdl8fg/ aNV7EQe9BGt6P16qa+ZNqSdG3/oPbWGp2O1nc9MmtaJlLfcdFhidTCtW8EYO5+eH 8/GnUf4gXRDtOQMlZoVd =5SwH -----END PGP SIGNATURE----- --Apple-Mail=_DB20FD68-19C2-4B81-85E7-08DA84D59854-- From nobody Wed Jun 7 05:05:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F173129B07 for ; Wed, 7 Jun 2017 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeF-LEajALQ9 for ; Wed, 7 Jun 2017 05:05:50 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3279129432 for ; Wed, 7 Jun 2017 05:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HEEtvXhHrn5B5DpJgOrJHLoq/DF4b2i8vSu72KRqyas=; b=Cklgv1d8/9QYHzNohHzQmjPOxEC2883374GWVQsjYDgl+JOwHK5btdi4d3La0QKXuj8h7YokNvCCsh0WopmvZ6WucnzSIiMHpcybPfEHtn9zwP1yoHM6STwPziVgpPWWcSQcaYg0AEg5jKp3odt/g0Ei7GfjyRgbxD6I3sQMzZE= Authentication-Results: wide.ad.jp; dkim=none (message not signed) header.d=none;wide.ad.jp; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Wed, 7 Jun 2017 12:05:46 +0000 Message-ID: <02b901d2df85$f05f7d80$4001a8c0@gateway.2wire.net> From: "t.petch" To: Cc: "Erik Kline" , "6man WG" References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Wed, 7 Jun 2017 13:02:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: HE1P195CA0001.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::11) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007: X-MS-Office365-Filtering-Correlation-Id: 1f162a26-32bf-48cc-5e11-08d4ad9d8802 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:VI1PR0701MB3007; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:Y9KXOzeseTNyStBeQMeYu1zAovxyvdJU+vDdPxBeQ/nUo7umVKo4OlxjxC+X4HOQ+wBQ2CUiTl1AjzBmy2nWkHT4GqDG2VAkZJw1OMEzotgtntfOB8zn2vrsvlKEbmkwNB8nKB/4K/1AVSZmRd5BLetA6sqArhCAnBkYAmUYXheZHICmjGdJ50ondCoLXadSxGPbDn+Kj4XLQgwOoRqXh1vaTHDCW0Tboh7PimgjYi0B06R7i6XKIIXoBtiJW/rNtJS32k8MjfvR0tIGJHtGN68A70ukUcvhTVtP6VPPOOL7BkeJoV+WvjsaJdbUiC7Xx3aMiQUfx2FdzzmhZsZRmQ==; 25:dIIqCj9ndfC7MvwMOl/3LgWYmFjC5xrJFjdjXX0oObCW1x2op1HifVBrXR+ytNHwHPMGI0Ce618fuWqthD50JsaSiMh3/4GYoXL+2Wwd0LtmL7YT+Ka2vFmS4F6V7fDLIZbAJSaRoTQYt6dNjWep2Sj3ZwdDY8Y55eyKIRCO7gm8ISmokNRy9JRnnmzRDQRQOA1SdsAWSMak5yDE7i36dSee/KjYbtj0LIGppVT5BaJYgClbtS+0vDhu9pDsBHZi3PN1gZOgFPY/MEuevdj04Z9qMeftPFT3kUHEl0owQGH/SU6IlBbOIRNtJOtqweOW5DYQ31ATnQQUwy4kYQPvWmmXK50Mo1EDax152zp6TrYfKsaY+MuVUOXFNi4ohBxQ8aAiulAiO5dyVXnONRSg2IGOC+RcBYqJjFJuGz5Zu90yJ/39LwiScoixhRsFzOXkjIOL9SsgroeyLMBIvG7Vb1XmGK9kS53V8fhycOpbpIA= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 31:wVGqEt9pz3+ng962kHiCu7Jjw0i3BFQxxRLECarcqUvla2NUOXdwyitBmAARop5JLopvv5R4oq5qi2Af3uMZnrZZzl8euVd+23IUvq/fJsg4p5vMl9QrLSOSkHXKMENfA7Yh9QrH7+VszlWXF1rx9n3PWIwCc3k2/ABbiXofAE5fRGUJTRa+0/4ia32HsdDLFr4X2AZHv16gqMsiyvGkhwrqfqzL5sR8PTMJ2S/ALMA56sn87Oi4PbZH2HInRIu36N+XkTKVGWpLM4bmuTAQbg==; 20:cvUY0BkA6KmLoLEwpEDnAA+bZQg1WeNkrNSYYDGfQB/uzEq7tt1pmdpHhkXNWLos4g+Uftw3YZFztkswR0PCY7ZJfKBXybP5u1j7HqEYcqiVZLgDthBJZ9Y8mt7odGPjbErRTWQF9pXXy5FOWXhUDK8V5itzIZNeAyTZVnbgS4o= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(211936372134217); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3007; 4:a2lIXeJOwumgSBrjaB/CXlymOEwuvICdvv3eTE?= =?iso-8859-1?Q?WEWWD5pYx+TkP581t3Fuo1L7EN6UY8Btj/eMTSP1EZ5z68fLTPU1sF29RA?= =?iso-8859-1?Q?UTeOE5N0eb/ZdOl8PUibaBZwF0PQVGCg5xzvbBpSXh5ia1lD4tu0BygwKZ?= =?iso-8859-1?Q?IIzGUrzodvSPOji69XkCcXtRq+br6a99500Bk6qUlKcT6Q9wsquw649DYg?= =?iso-8859-1?Q?+1SkDESPXMhPrX5iTGajdI1U37jNm6pYSAe1u9v8UP9P9dx1QMCbr7oQ8g?= =?iso-8859-1?Q?nzy3Cu2gWoOPYkQgB+aawlcRZgoax30eYzLeYfWe9M7xDn5m4eSr62rrcG?= =?iso-8859-1?Q?ZXogWrejuhPDgO3oSF9+WUZjDcsjUPRVkdZrpuRMCpv3QbfYd5HuqTMjBG?= =?iso-8859-1?Q?+tV0XMiys5Xn2YsCQLG4BCgu06hUBQa20gIHSjw9rQrNOzAP0Aql/b0hVz?= =?iso-8859-1?Q?D90LPUhnZhdHL6jZ3WmTfv52+CQqdEVl/v9wH0ugUIFfyffYTnEqLOgiXz?= =?iso-8859-1?Q?xrRdbcTw5Z6+sPkLxeY6GqLlNKStwzXGj5duyKwbdK/PZk/oDP2BIq7eV9?= =?iso-8859-1?Q?v2OsTpWgIBUGGrr45nxVUi1aN8EoNrcLSmMhFSvru/XB1oP9Ak3PaSEhsQ?= =?iso-8859-1?Q?SjezIT6Rs5gUtL+GBgLpW8RBOVir1qiD3hvbs7x3AMKaEilT/qfRlzYgyN?= =?iso-8859-1?Q?GLzFw/pLVTfaSPwzIFukx/DRLHMMvlzLMtgu/dj4GuH+JNl9kUwa9b8twv?= =?iso-8859-1?Q?fhStErCQbc0tUJUSPVb+jwEQC13YA/dyy+VLvotMrb3gJEqefNNVkAZoBR?= =?iso-8859-1?Q?fbu3kjzrXIb+ANQw6eHsSWhn0yE+CPAKGoAO55RY6p6GlonoB6jAE0cheQ?= =?iso-8859-1?Q?3Y5xsqnzYB1HgG65e9VbQJdXRp3yGDCVQBaOunmutatrI14h+NjRDZPhCk?= =?iso-8859-1?Q?wynQu982xA4uyyW821tW+Zuker67b7FoS4P1lqqoZ8PvN8+vMEbS1o+ZIh?= =?iso-8859-1?Q?oz6rBM9jF7ja5G8kj21WlDbecd6e1awZ7hxuIG0rhbPOljCvJPUIefmB/G?= =?iso-8859-1?Q?biEtZjKagBweDmi88pp9SHIR0fvBCfZiVGBxVg+DuTwhtXb9ESomPLVIgR?= =?iso-8859-1?Q?6zO3Go7l+GXPbbh7CpL1lXQHCaY1ubLPiBFX8MbT1pXajTc8EDfCpx3XQS?= =?iso-8859-1?Q?95Y3ewA1TDyO0kN9KRy6EoCcpdgxHqXpW52MJhQ4+CFHRHb8ktJhiFY=3D?= X-Forefront-PRVS: 03319F6FEF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39850400002)(39840400002)(39860400002)(39410400002)(39450400003)(39400400002)(24454002)(13464003)(377454003)(50986999)(54906002)(33646002)(6246003)(230700001)(9686003)(25786009)(76176999)(50226002)(4326008)(5660300001)(81166006)(6486002)(44736005)(6496005)(110136004)(6116002)(38730400002)(6916009)(53936002)(189998001)(3846002)(230783001)(81686999)(6306002)(86362001)(2351001)(6666003)(42186005)(61296003)(1556002)(66066001)(966005)(229853002)(47776003)(84392002)(2906002)(44716002)(7736002)(478600001)(23756003)(50466002)(305945005)(62236002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3007; 23:NYKRbV7UZfXGvjCkJwY5KqhR0He0Vu8W5CJcy?= =?iso-8859-1?Q?Aal1iI59OOF0FWcuKqo0E62hm731czvx27ohZTyNgimikVSoVs+/yGxp4g?= =?iso-8859-1?Q?Z/ihV6K7LiQbG7/kJL/MdX4QcRlPov9cyNiJHGejlTh8lPVDhsOa+6YUzj?= =?iso-8859-1?Q?qWEhpQYIljUi1YdFq61+u80qe86eDyunGJaAll1Eh0SRSxV4YJPt+/brle?= =?iso-8859-1?Q?jRLthtaxYQ2odOBPnz7i1L/XRlcNbiPqwT/3n6X4QOumGIBa2p2nTlRECn?= =?iso-8859-1?Q?kNTWSpUcJ7twvbcSSa8mvbk5P7Yv+o4d36iMPHdSOtUhbHIp5GnQj0KbFD?= =?iso-8859-1?Q?y5Uw8+ecIUNSVYXqGNRforkwQkUNLTcvqZJ4dhl4bUDLfdcGE0qE0GUcfh?= =?iso-8859-1?Q?8PIeNko0gf5jOxvlDG64IW+lBrJFrcLHO4jT3kuNOsyGz+ChfYHwLwLl1y?= =?iso-8859-1?Q?VkbqaIp++SnmTThc88AvCeO/U+/QryauuJ0FAyiaILJIpGA01KqRk348ma?= =?iso-8859-1?Q?yE6H+Hag7wxaUjE9+VCIYQ6EnQSTiihoYWgQMWAFoGfeOWDEAxddYSw9jS?= =?iso-8859-1?Q?PLlzMpBMNNlRoy6lIxup5ZnQng7n40gnN3iWYtuRQU7Y+YwVtkviNNrQ3Q?= =?iso-8859-1?Q?QuoOVlyEUMxH3hEi50qDMejMYW2FAiSv0077m4p6QrBJwnPyJ7KW3YJWs8?= =?iso-8859-1?Q?wHqWjcmgDDMNcxUJmLu1qXM6z+UOhqAbcyYkPSLIWBoqukoB76GYN0UAp9?= =?iso-8859-1?Q?ojTu15uRHknH6gwYFHWjRMb0NsErMNDtWXjrTfarlu+QWvE+62b71at7m/?= =?iso-8859-1?Q?+0PUE7r+XTI+xRijGMFMCPLVFC5tq/jge/kaEApr9iLIqSfseVYVL0TPFq?= =?iso-8859-1?Q?OhflD0NQ5e1hfJVJrfcqyq9V30cB7TQFX3Wm37wFZOTfLS4rQsB0gXJeaB?= =?iso-8859-1?Q?U57lDR/l7SRKYj+ZAplCQWkE3FpuZV2JfS9+e3YWV9KsJfirWJ86runWII?= =?iso-8859-1?Q?vWrYc6+3n5e8rzmcnUU3RZv3hgZN4Ml8Nn+T6oSQvKz4ISfaYYiJP0z6BY?= =?iso-8859-1?Q?JCnkGbLyYUwN6Y6/YncDUiBLemW2soAmpBrxmF+wolBAw5Dz8iTn61b92u?= =?iso-8859-1?Q?Knd5YU4ReU1EuncdVgVCw+/HWp45ecT43iHNjsE30UxE36NNC2Dm+bqNIT?= =?iso-8859-1?Q?6Y5i0eNFLguqXIU5i8P2NyUfKfb+vOWbgerRQf86QZDXmiA5MOiwGY0Kwa?= =?iso-8859-1?Q?v3Or/teFaF7Nv092dioDECAJ56lLk9vpSd6FRF+rW0VK6CUUEoB9IQbGxH?= =?iso-8859-1?Q?KRYX1DvIbo16BPim+AdU9o3NM/DdSqMsB/IuZWvTY15Np/ox92pMfHrd50?= =?iso-8859-1?Q?7subGdJfemg0M/3J2XfNcocYlkT80/aG7fEcsLQKIk/SvZEyiqxQQ=3D?= =?iso-8859-1?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:r2n1ZAnvECdnrj9OF465KiU4vzhFulfdQ94PWef9v2wVmoOwI3wxPBwPWt/8aYWJkQ1x+4WcwSyw2hJfkaU19gydfv52bB5GNKAP0F1fG5d3U8n1ZF32Va8sAfLINrPCFROcN9LI7VRnEMnXmWvKDGD4+ustpJFYqsgD4pl9Y1BNTy2pt1Q/36X31qIjtUnUFHTmOtbzZ6dL6LVCn2ufQKJjkgYSMiZZ5eyOshl2czzFeExG80fGcTb9HV8IWjBzr/kDoRz+Wtu7+5ffA50nFjIxhmIU/ZovebF5oQD/sc4896txEyK6o+KYO4CFke4vlruZhv18UHCeB5KBSO3pzzs8apgN+pmAOushvsWMUEAke01v5uivgK2XylXYH+DXvYJ4rJNYjMKR8Yz2ik7dJL22AXE7yYZLnbtZLukEDYYK6+vgYRpo2quunHefVpqtp6lNKnBVzQiWOUO8dEs65+9F52t8ygAnqbuRPHDe3dSIhPb2gAFehjEYyxTku+6mSkbVDXBPsFasNyIFbBWJdA== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 5:S4akKQ15LB5GNBek44BcIWoWo5wKmAjZbjTKz15s3LaAFi615ZN2CfOMqmmdiuDuHG7bT1DhK5a7jD9H6Q2e3pjF/xxGI8+GxQMWAGHjY1jbZpme3iuwHI0fR1aBzZy1JTO09Ha9J46Rq4V3oNNyaG5sufe/lOKofkN6pxctdtTq1seGsCBK51Z6JW2LMaQVxfRSxbe1PqLdWQQVMYD/VJ+3ZLSx9Q49+mS9Y5O3pdS99SgQ3peM4UdLm80VsjlryP+jAltuWd10Vp5mFFjmMuc2rCuaRUU67h2o22AuQZSLA3AKd/gJpuKTER1cyxwXVhtvV9Zv68FUnwyacsxCq1zUWoSBgy6g4kvOQZaVVfsWBzXCRi1DqkTFPsErRGLclwkVyuM51K3w1RiPKbx3othJwgHJR20wEQq6yoEgsBm8I2EChVn640jjBO4kGTPmQkbFJI7HO6Un3cAopLeWoR+loPOBMW0hlBGIB07hrRz3OddqsI/BS8LuraZv8kME; 24:V9JfFVGWEE7DeRxuIg1tnHQCd5GnbutkNp/c6NgnLhJsNCDSi3j/4kspAHuhvitsd1KFEEQlr0yxYzqpM29TQEfNxd4SUgs8aAFqybF0Vyw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 7:BuNKq4slN6w8hIgGInbt+/Q0IWNbP3igzjFM7warWD9ZhTsnc5WH4NLQpvzXj/9QcK5n02rg6A4/FRF44s0NcG1ZP9E1hHnHi5Epl5p+eLnohttcDek89p+ghtSwRXwmW+PwZ/Vz+f4oAAEz2tk6MO8Y1RrvZtogySu23LW0+uhVZmy6K/dscfZZ2gxR0OB4NO3/fiWS1bYoreZYL3xzrn1TWxCfjmgHpRMzBafgsb6qkCeSOsvuLIDGc3LUgNz+1flCf334Ou9xNtf5sIMql/TpLv0yToGSQ9u7e55o4dLephH95oFc65vl6C6UiKoM5iihVtTqrZKZwhVvgaP6xg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2017 12:05:46.3003 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:05:53 -0000 ----- Original Message ----- From: To: "Job Snijders" Cc: "Erik Kline" ; "6man WG" Sent: Wednesday, June 07, 2017 2:14 AM > At Tue, 06 Jun 2017 23:30:30 +0000, > Job Snijders wrote: > > > > >> But that is exactly what the draft does *not* do. Nobody would > > > >> change a single instruction in existing code as a result of this > > > >> draft. (I agree with you that some O/S stacks may need fixing, but > > > >> they already need fixing.) > > > > > > > > is this draft exactly: > > > > > > > > IPv6 unicast routing is based on prefixes of any valid length up to > > > > 128 [BCP198]. Interface Identifiers should be 64 bit long except > > > > when the addresses are manually configured, or by exceptions defined > > > > in standards track documents. For example, [RFC6164] standardises > > > > 127 bit prefixes on inter-router point-to-point links. The rationale > > > > for using 64 bit Interface Identifiers can be found in [RFC7421] > > > > > > > > ? > > > > > > Yes. Put those words in 4291bis and I will be very happy. Oh ;-). > > > > I recall a small but vocal group arguing fiercely against that text > > adjustment, so here we are. > > As several people including myself have already pointed out, it's very > hard for ordinary readers to understand that's really what > draft-bourbaki-6man-classless-ipv6-00 tries to propose. It will have > to be heavily revised to convey that message. I agree. I think that the message is much obscured, perhaps as a counter to the recent history of vigorous discussion. And it all starts with the title which ... well, I would say is rubbish IMHO. Tom Petch > As for the above text, my recollection is that some people (I don't > know if that was a small group, btw - to me both groups looked equally > vocal and equally small/large) were against one specific point in > text like the above one: > > - "should be 64" instead of "must be 64" (but in my understanding they > were/are okay with "except when the addresses are manually > configured") > > It's also not clear to me whether the real intent of > draft-bourbaki-6man-classless-ipv6-00 includes the subtle (but > seemingly very important for those who were "fiercely against" it) > change from "must" to "should". I guess if the authors of > 6man-classless-ipv6 are actually also happy/okay with this one: > > IPv6 unicast routing is based on prefixes of any valid length up to > 128 [BCP198]. Interface Identifiers must be 64 bit long except > when the addresses are manually configured, or by exceptions defined > in standards track documents. For example, [RFC6164] standardises > 127 bit prefixes on inter-router point-to-point links. The rationale > for using 64 bit Interface Identifiers can be found in [RFC7421] > > then there will be no dispute or further time wasting (we'll still > need to decide what to do with the magic leading bits of 000 in terms > of the interface identifier length, but if we can agree at this level > this will be a relatively minor point to address). > > -- > JINMEI, Tatuya > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jun 7 05:29:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE612EBF7 for ; Wed, 7 Jun 2017 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpuID04D9De8 for ; Wed, 7 Jun 2017 05:29:38 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1C112EBF4 for ; Wed, 7 Jun 2017 05:29:38 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 26BACE6065; Wed, 7 Jun 2017 14:29:36 +0200 (CEST) Date: Wed, 07 Jun 2017 14:29:36 +0200 (CEST) Message-Id: <20170607.142936.74725051.sthaug@nethelp.no> To: ek@google.com Cc: fredbaker.ietf@gmail.com, markzzzsmith@gmail.com, job@instituut.net, ipv6@ietf.org Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text From: sthaug@nethelp.no In-Reply-To: References: <20170607.075131.74727436.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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:29:40 -0000 > > That's precisely the point. I configure fixed addresses typically for > > servers, and I put the addresses in the DNS. I *want* those addresses > > to be publically known. Security and privacy is not relevant in this > > particular case. > > For an authoritative server, sure. > > But if you're a recursive resolver then using privacy addresses while doing > recursion (and changing the privacy addresses frequently) might indeed be > very useful. (In fact: a unique source address per query is wonderful.) Different strokes for different folks. I'm fine with fixed addresses for the query sources of my recursive resolvers, and have no plans to change this. I have no problems with others using a unique source address per query. Steinar Haug, AS2116 From nobody Wed Jun 7 05:33:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6012EBF7 for ; Wed, 7 Jun 2017 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHHoG9cyUW-1 for ; Wed, 7 Jun 2017 05:33:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EF912EBE3 for ; Wed, 7 Jun 2017 05:33:21 -0700 (PDT) Received: from [192.168.0.185] (unknown [196.105.209.136]) (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 4555C83838; Wed, 7 Jun 2017 14:33:36 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith , Job Snijders Cc: Erik Kline , 6man WG References: From: Fernando Gont Message-ID: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> Date: Wed, 7 Jun 2017 15:03:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:33:23 -0000 On 06/07/2017 04:23 AM, Mark Smith wrote: >>>> >>>> is this draft exactly: >>>> >>>> IPv6 unicast routing is based on prefixes of any valid length up to >>>> 128 [BCP198]. Interface Identifiers should be 64 bit long except >>>> when the addresses are manually configured, or by exceptions defined >>>> in standards track documents. For example, [RFC6164] standardises >>>> 127 bit prefixes on inter-router point-to-point links. The rationale >>>> for using 64 bit Interface Identifiers can be found in [RFC7421] >>>> >>>> ? >>> >>> Yes. Put those words in 4291bis and I will be very happy. Oh ;-). >> > > > "Interface Identifiers should be 64 bit long except when the addresses > are manually configured, or by exceptions defined in standards track > documents." > > That doesn't mention that security and privacy properties of addresses > will be compromised if the manually configured addresses are from a > small prefix. > > Security and privacy properties of addresses are independent of the > method used to configure them. Addresses configured via SLAAC, DHCPv6 > or manual configuration from within a small prefix/address range all > lose privacy and security properties and value. Measurements indicate that when folks do manual configuration, they do "low-byte" addresses -- i.e., no matter the prefix length, they just set the IID to all zeroes except for the last byte or so. -- having "easy to remember" addresses seems to be the goal in that case. In that sense, I'd say that the security/privacy properties are closely tied to *both* the prefix length *and* the mechanism employed to configure the address. -- for instance, a DHCPv6 server that leases addresses from a small pool or with a specific pattern still results in the same properties, even if the subnet is a /64. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 7 05:33:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1616212EBFD for ; Wed, 7 Jun 2017 05:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YHuUAG47iBK for ; Wed, 7 Jun 2017 05:33:24 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A3E12EBF8 for ; Wed, 7 Jun 2017 05:33:24 -0700 (PDT) Received: from [192.168.0.185] (unknown [196.105.209.136]) (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 EEB1D838CB; Wed, 7 Jun 2017 14:33:40 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fred Baker , Mark Smith Cc: Job Snijders , Erik Kline , 6man WG References: From: Fernando Gont Message-ID: Date: Wed, 7 Jun 2017 15:07:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:33:26 -0000 On 06/07/2017 06:37 AM, Fred Baker wrote: > > On Jun 6, 2017, at 6:23 PM, Mark Smith wrote: >> >> That doesn't mention that security and privacy properties of addresses >> will be compromised if the manually configured addresses are from a >> small prefix. > > Or advertised in DNS? > > I would expect that any address configured manually would also be advertised in DNS, the latter being the reason for the former. If the address is publicly announced, does one have a reasonable expectation of privacy? Not for rivacy, I'd say. However, posting addresses in the DNS is not necessarily an excuse for making the predictable. If a company posts addresses on the DNS, but the addressses are not predictable (they do not follow patterns), in the even that I want to target "all of such organization's servers" IPv6 address scans is not an option., so I'd have to resort to DNS bruteforcing, reverse-mapings dns lookups, or some alternative technique. OTOH, if the ORG employs predictable/patter addresses, then I can simply resort to address scans. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 7 08:03:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820712946E for ; Wed, 7 Jun 2017 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z55e6uyUkAlr for ; Wed, 7 Jun 2017 08:03:15 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B3F12ECA2 for ; Wed, 7 Jun 2017 08:03:06 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id d73so13213058wma.0 for ; Wed, 07 Jun 2017 08:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UlcsNojlDWyeiZ6qz68Km3yiCqDgdvRTKftjNxSKrPI=; b=I5RIX52vu6DyFUcMJRTsY3Wz7y1GMwoLWu/25Xtal7JrsChjYnlJXIp8z3x9Be46I/ qm/SQ5toKVjB6If9Wu7u7+W0+oJzlXAvB4CzMpO9h8xehwgboPLBgIGfEPVtFhWM8KtP wOXRF8AVwzVE5qgy3SO2SskCgzq2L6S36QrTcacwZb1Rf7NUUvmxttGQ0knR9vDixxIK GNhZ3aH6aiLIcqkA/tnKehKy2dW6ntsPfRKPRV/vWGuol5G5+iypcwRCZXyP1BmCk+PJ cDhY/q8ArMpHBsCO6C6hjMYOAEWSUhfxBR1outMsry/h7Rh7gW+vPWiQBjXYfuFlSnMI a4Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UlcsNojlDWyeiZ6qz68Km3yiCqDgdvRTKftjNxSKrPI=; b=e275glyiOlkegal+RqEU8h1LXHuOb0qtIrIaiTQ0i2T8XQ8akxFEGTGZkffclLthea OhKWdLY4NoUVi0DRk3sXok/o2DgYULlLGeT4+cemAaLmz+T7qXejTdyil9hNW7FK3lSV SRuO752s3+u88Hwuvfc9t6EI0/0ABZDZYVhqUe0QFevjS/yzOoY1qpbILILeNU4w9S0g ShEknahKoODZZcB8JRGv5VmOmM/05gtGhHGgxfOgtuwF6m2gVzVyqNHGf59X6TKotYpj iYUlBkE6jlF2Nhua9QJnVWM0KrMLR4VR1pTNw3MezeoEV6MZuYVMpj4zxOamVtYFwcdl mjng== X-Gm-Message-State: AODbwcCUe3DO2UOErDhiTNIMJyFezE9AMOSayPcD1iWmFkn6T5RmY8M8 MeHeVcBvw/QUDbbvM9J9Fb/qBmTqENjs X-Received: by 10.28.54.204 with SMTP id y73mr62856wmh.53.1496847784321; Wed, 07 Jun 2017 08:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.135 with HTTP; Wed, 7 Jun 2017 08:03:03 -0700 (PDT) In-Reply-To: <32658EA6-B8A1-4D16-850B-42132FC8301C@employees.org> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <32658EA6-B8A1-4D16-850B-42132FC8301C@employees.org> From: Tom Herbert Date: Wed, 7 Jun 2017 08:03:03 -0700 Message-ID: Subject: Re: The waist diameter (was: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)) To: Ole Troan Cc: "Leddy, John" , "draft-bourbaki-6man-classless-ipv6@ietf.org" , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 15:03:17 -0000 On Wed, Jun 7, 2017 at 4:35 AM, wrote: > John, > >> Innovation at the Network layer created the Internet. >> Innovation at the Network layer has let it grow to the point it is at = =E2=80=93 including things we may not like, ex. NAT. >> The Internet leveraged/adopted/re-architected innovation at the Network = layer that occurred even outside of IP =E2=80=93 all the other Networking p= rotocols that existed =E2=80=93 Appletalk, XNS/Banyan Vines, DECnet=E2=80= =A6 >> >> Without the innovation, we=E2=80=99d still be talking about SONET, X.25,= ATM, FrameRelay =E2=80=93 very narrow hourglasses/wineglasses. >> >> How narrow of a waist spurs innovation at the layers above and below the= Network layer? >> Should we regress in order to spur even more innovation? >> Perhaps IP itself limits innovation at the layers above and below IP? E= x. Dual Stack =E2=80=93 a difficult migration and operational state. >> >> There are =E2=80=9Cno=E2=80=9D Network protocols other than IP today =E2= =80=93 it is very hard to justify innovation outside of IP and IPV6 is the = only platform where change is even possible and worth the effort. It takes= too long and migrations are expensive. >> >> When there was a soup of networking protocols and no clear consensus abo= ut how Networking consolidates around a standard set of protocols for syste= ms to communicate =E2=80=93 =E2=80=9CA core principle of the Internet archi= tecture is to keep the waist of the hourglass/wineglass narrow=E2=80=9D - b= ecause ubiquity was a major goal. IP itself was the Major Innovation. >> >> I don=E2=80=99t think there is a basis to say that that principle is cor= rect in today=E2=80=99s Internet, my belief. > > Of course both of us are paid to put smarts into the network layer (:-)),= but if you look at it from an Internet-wide perspective, can you name any = innovations at the network layer that has been successful? > > - IP multicast -> fail > - IPsec -> fail > - Mobile IP -> fail > - Fragmentation -> partly fail > - Path MTU discovery -> partly fail > Ole, If you look at it from a protocol perspective the above are successful. Several of these are productively used in private networks some of which are quite large. The fact that multicast of extension headers aren't usable in the Internet is no justification to remove them from the protocol. > The only thing I can think of are the various forms of tunnelling that ar= e a raging successes. > And NAT. I guess you can say that the network layer's territorial dispute= with the transport layer, where network has permanently occupied the first= 8 bytes of the transport header have been successful. > > The network layer is the only thing ubiquitous among all nodes on the Int= ernet. Thereby making incredibly difficult to change. > > The fact that you have near infinite address space does perhaps allow for= innovation. I would hardly call 2^128 infinite and certainly wouldn't call 2^64 infinite. Like any numbering space it's likely the hierarchical divisions will exhaust the space long before the number of actual addressed objects hits the maximum. Tom > Some good some horrid. E.g. semantic addresses (put the MTU value in the = address), or giving individual chunks in a video individual addresses. But = the address space is part of the tussle. Where we as a community has decide= d that the left-most 64 bits are given to the network and the rightmost 64 = bits are given to the hosts. Both groups are going to invent stuff that req= uires more than 64 bits for themselves. If the IETF decided to reset the pl= aying field and withdraw from participating setting the ground rules. Where= would that tussle play out? > > Best regards, > Ole > > >> >> John Leddy >> >> On 6/7/17, 5:43 AM, "ipv6 on behalf of otroan@employees.org" wrote: >> >>> Many of the arguments against this draft seem to >>> be of the form "this is bad because it might allow >>> uninformed people to make bad decisions which >>> could have bad outcomes." I find this line of reasoning >>> to be somewhat disturbing. >>> >>> Imagine, if you will, early man, out hunting for food >>> using his typical tool, a blunt club. Along comes Thag, >>> with a sharpened stick, ready to join the hunt. Early >>> man looks at it and says "wait...that looks dangerous; >>> someone could use that the wrong way, and hurt >>> themselves, or potentially hurt me. Rather than >>> take that risk, and potentially learn new, more >>> efficient ways of getting food, let's just ban it >>> now, before anyone gets any new ideas." >>> We could still be out on the plains, beating >>> our meat with blunt clubs instead of learning >>> new ways of hunting. We shouldn't fear progress, >>> even if it comes with a few roadbumps and bruises. >>> >>> This draft isn't saying you *have* to use a bit boundary >>> other than /64; it's simply saying you have the *option* >>> to do so, if you like. It's giving people the flexibility to >>> try new combinations out; some of them may be ill-advised; >>> a few warriors may come back with one less limb, having >>> discovered the _pointy_ end goes towards the prey. But >>> on the whole, the potential for advancement would seem >>> to outweigh the risks of people maybe doing something >>> stupid here and there. >>> >>> I support this draft for its ability to look beyond the >>> classful box, to a world in which creative new possibilities >>> open up before us, enabling new and unusual addressing >>> models and the potential for discovering new network >>> topologies we'd never considered before. >>> We shouldn't let ourselves be ruled by the fear of what >>> someone *might* do, and hold ourselves back from the >>> chance to progress and expand outside of our current >>> box. >>> >>> Let's bring innovation back to the Internet. >> >> I believe that innovation in the IP layer hinders innovation other pl= aces in the stack (aka the Internet). >> A core principle of the Internet architecture is to keep the waist of= the hourglass/wineglass narrow to allow for Innovation above and below. >> >> Best regards, >> Ole >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jun 7 08:13:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA24112ECA1 for ; Wed, 7 Jun 2017 08:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iBZs6OTWjQz for ; Wed, 7 Jun 2017 08:13:53 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEAFB12ECA5 for ; Wed, 7 Jun 2017 08:13:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 26915A3A for ; Wed, 7 Jun 2017 15:13:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5peTRbQ69hz for ; Wed, 7 Jun 2017 10:13:53 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id E43079F0 for ; Wed, 7 Jun 2017 10:13:52 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id q74so1516783vkb.14 for ; Wed, 07 Jun 2017 08:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OLQTf0fotHoNieNqh0GimA7fxaTFJrjJOeZDx/EJVuU=; b=YXMVGUgs0WU4DmsZ/J3NxdgRIYgR1jM26KyKJppJ1dbqtBVioWNsiK5AoMpDUqoFnz N49+VhVc7DvM2x2E3Diy6Fhml5+RHUZ8WZ6MLWXPYUBpb3mbKrIuSJvSNtpJ1Gi8wKs5 gZPPlyncv9YtJx608NxcfdezD1pv79LqdzkSi8aDQyrafIoQ0OlW6ofN0BA05Xg/OEIj HuwWrQqX0VSjyK+3rzWmSyZFrjb4YvxfW9w9L7zmadRW+LG5kVE0aySGL0nntRt2S7Rj 2mDHirxg8O5h3tYZII1XBDWftcbjVqHA+6RUAiGgY6E+t2UQ5J2Hi9zyJ9A2LdUtE5/1 ay0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OLQTf0fotHoNieNqh0GimA7fxaTFJrjJOeZDx/EJVuU=; b=hGpTUGpW5e1wyloduyuN/XtaQz20Ft/hKyafF7iKN7nj0+ylT00/8vF74Di4ZAHF2x lx9htbDYMuamdWrDhIzbBQZ/0mTDdnJx1zgMP8vrkcbtD+t2DE3LTzB3UN/nWb64xxGe DLCaxHJr2xbPcviAB9YTl1it1u+P/qIIDpeDyAx+WrtUWgPKq7tPEz1jrcAipuzNpwPd y+Vbo6OKmNypqXjG5QXx1W5lZku59nX7R/OXM1b0xtsHz4umvv2yCrKkx3TlP0H0FdXL 2cgl/BEHy3t6xSxsQaTa+D4+4AkCMZbpKk8ieTbtEyYVNnCERETvXknWnsMGSZtGDzuX okZw== X-Gm-Message-State: AODbwcAkaZ3mhEEeoHgJbCx6BZX4AzCJZUli07Ed4uQ57EAjBkK6UmiD GawV1SEOs1EMQ1ISkr0fWiAMsUdqcuwdVBT3kiNK7EIuD065r8MVXF0wjuqKE9adM5AuqrlTWfZ XPjdlnSbAWL/mzX4= X-Received: by 10.31.171.3 with SMTP id u3mr14277984vke.22.1496848432225; Wed, 07 Jun 2017 08:13:52 -0700 (PDT) X-Received: by 10.31.171.3 with SMTP id u3mr14277980vke.22.1496848432063; Wed, 07 Jun 2017 08:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Wed, 7 Jun 2017 08:13:51 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: David Farmer Date: Wed, 7 Jun 2017 10:13:51 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Job Snijders , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="001a11440008137d1a0551602fa1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 15:13:56 -0000 --001a11440008137d1a0551602fa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 6, 2017 at 8:14 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > As for the above text, my recollection is that some people (I don't > know if that was a small group, btw - to me both groups looked equally > vocal and equally small/large) were against one specific point in > text like the above one: > > - "should be 64" instead of "must be 64" (but in my understanding they > were/are okay with "except when the addresses are manually > configured") > > It's also not clear to me whether the real intent of > draft-bourbaki-6man-classless-ipv6-00 includes the subtle (but > seemingly very important for those who were "fiercely against" it) > change from "must" to "should". I guess if the authors of > 6man-classless-ipv6 are actually also happy/okay with this one: > > IPv6 unicast routing is based on prefixes of any valid length up to > 128 [BCP198]. Interface Identifiers must be 64 bit long except > when the addresses are manually configured, or by exceptions defined > in standards track documents. For example, [RFC6164] standardises > 127 bit prefixes on inter-router point-to-point links. The rationale > for using 64 bit Interface Identifiers can be found in [RFC7421] > > then there will be no dispute or further time wasting (we'll still > need to decide what to do with the magic leading bits of 000 in terms > of the interface identifier length, but if we can agree at this level > this will be a relatively minor point to address). > I think "should be 64" is the correct language, primarily because "must be 64" has been misinterpreted several times to justify hard coding 64 in IPv6 implementations, but also it seems like a false imperative. Now that an explicit manual configuration exception is included, I could live with "must be 64", only if the language is further clarified as an operational directive and not an implementation directive to hard code 64 along with the list of exceptions. So I'd prefer; "Interface Identifiers should be 64 bits long except..." However, I could live with; "Operationally, Interface Identifiers must be 64 bits long except..." I think either of these makes it clear 64 bit is the norm, but this should not enforced by an IPv6 implementations or hard coded in some way. Unless someone has language to clarify the purpose for the magic leading bits of 000, I'd prefer to just level that execution out, in my experience it only confuses the discussion. Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a11440008137d1a0551602fa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 8:14 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <= jinmei@wide.ad.jp> wrote:
As for the above text, my recollection is that some people (I don't
know if that was a small group, btw - to me both groups looked equally
vocal and equally small/large) were against one specific point in
text like the above one:

- "should be 64" instead of "must be 64" (but in my und= erstanding they
=C2=A0 were/are okay with "except when the addresses are manually
=C2=A0 configured")

It's also not clear to me whether the real intent of
draft-bourbaki-6man-classless-ipv6-00 includes the subtle (but
seemingly very important for those who were "fiercely against" it= )
change from "must" to "should".=C2=A0 I guess if the au= thors of
6man-classless-ipv6 are actually also happy/okay with this one:

=C2=A0 =C2=A0 IPv6 unicast routing is based on prefixes of any valid length= up to
=C2=A0 =C2=A0 128 [BCP198].=C2=A0 Interface Identifiers must be 64 bit long= except
=C2=A0 =C2=A0 when the addresses are manually configured, or by exceptions = defined
=C2=A0 =C2=A0 in standards track documents.=C2=A0 For example, [RFC6164] st= andardises
=C2=A0 =C2=A0 127 bit prefixes on inter-router point-to-point links.=C2=A0 = The rationale
=C2=A0 =C2=A0 for using 64 bit Interface Identifiers can be found in [RFC74= 21]

then there will be no dispute or further time wasting (we'll still
need to decide what to do with the magic leading bits of 000 in terms
of the interface identifier length, but if we can agree at this level
this will be a relatively minor point to address).
I think "should be 64" is the correct language, prima= rily because "must be 64" has been misinterpreted several times t= o justify hard coding 64 in IPv6 implementations, but also it seems like a = false imperative.=C2=A0 Now that an explicit manual configuration exception= is included, I could live with "must be 64", only if the languag= e is further clarified as an operational directive and not an implementatio= n directive to hard code 64 along with the list of exceptions.
So I'd prefer;=C2=A0"= ;Interface Identifiers should be 64 bits long except..."=C2=A0<= /div>
However, I could live with; "Operationally, Interface Identi= fiers must be 64 bits long except..."

I think= either of these makes it clear 64 bit is the norm, but this should not enf= orced by an IPv6 implementations or hard coded in some way.=C2=A0

Unless someone has language to clarify the purpose for the = magic leading bits of 000, I'd prefer to just level that execution out,= in my experience it only confuses the discussion.

Thanks
=C2=A0
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Ser= vices
Office of Information Technology
University of Minnesota=C2=A0= =C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-= 0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
--001a11440008137d1a0551602fa1-- From nobody Wed Jun 7 08:26:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AE412951E for ; Wed, 7 Jun 2017 08:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwtop9ZLjGMv for ; Wed, 7 Jun 2017 08:26:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24D129458 for ; Wed, 7 Jun 2017 08:26:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dIcr4-0000FyC; Wed, 7 Jun 2017 17:26:42 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> In-reply-to: Your message of "Wed, 7 Jun 2017 10:13:51 -0500 ." Date: Wed, 07 Jun 2017 17:26:39 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 15:26:49 -0000 >So I'd prefer; "Interface Identifiers should be 64 bits long except..." However, I could live with; "Operationally, Interface Identifiers must be >64 bits long except..." I don't know if we have to rewrite too many RFC to do the following... The concept of an IID is only relevant to SLAAC. That's the only place where a locally generated or configured IID is combined with either a well known prefix (link local) or a prefix received in an RA. In the case of SLAAC, IPv6-over-foo documents specify the number of bits of the IID for that particular link type. For anything else, manual configuration, DHCPv6 IA_NA we need to get rid of any implied prefix length when dealing with addresses. An address is just that, a single address, a /128 if you have to use prefix notation. Everything is else is in the domain of routing and is irrelevant to assigning addresses to interfaces. Ideally, we should try to get software vendors to stop combining addresses with on-link prefixes in user interfaces, but that may be an uphill battle. From nobody Wed Jun 7 10:35:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26510128D8B for ; Wed, 7 Jun 2017 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdp8ibnf0pwy for ; Wed, 7 Jun 2017 10:35:16 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 70494128ACA for ; Wed, 7 Jun 2017 10:35:16 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u19so14233522qta.3 for ; Wed, 07 Jun 2017 10:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5mntgpGQPDW6GvxqMMJgyVP4N8SQd5UKdsbe2jrgwb0=; b=cmmoGuk3krCfoPPgHOwl6tqnJZQdDKHQhdwBCcUfQ5tlQqLaJhS8bKez897h1Pq4cx OjPFbr7wmVt2gi8a0BUy1C9eodqCvBPYJ7q49iApNYygKsc/zqIega06kNVgfm+dSKqM cVtjf4r3d2Ppl8vI8rspTk2S1X9Aiwe9MfjPJdvZi+P9DrPfy+b0RgaEGvd5OyAQOkrO zPHbQmoZgHbAjAhZRs5WqJQ4/0zoBQYOGmpXX3/VNcX3rNdhRIG/K3eZy3BJfzsTvFXC DfGN5HVw5+VAnd5smHr6TJnC9QUoUvqV1krCwBGxEMVvBhDtSg6kaBdQrOohQNgCQsoK 8cOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5mntgpGQPDW6GvxqMMJgyVP4N8SQd5UKdsbe2jrgwb0=; b=a9M8Ze+uGMIgkw0VGinOansIkF5okG2ttwMOe+WUT2Dy+jVCyootJJBMSWTZ4YLy73 vtnuTL4O0uWM1iyx3y6VHw2ru+BAS+fxeOw9FBSGvpoiPgVinMhdE2+kXVrAPUV4tjeg XiDbmIDmOJpHj3YLzuZ2ENBmlKY2zdmJGPlagF5eoz/GALAd4d/ogpfo1dhAtYsFq8pe zY4KJYh8fc85/9WIBMHV3Aae13hQWzk6YXTGp7b7q/cGIffKBC4U5FFFtsu7ar04AwnY vYXcgwyFgYCNwLgniqwToOdfvBHirlVVCuZi4ft815fh0W9HPAOP0+QoRHGxclMyfx8S OoCw== X-Gm-Message-State: AKS2vOyijvKTeNa4BSHYkzbrpEw0LhbOdFRglgwMdcb+uJutx2nUWqGP JXFWGRioA/x/HJltsgaKjmprHtojhx7yPyM= X-Received: by 10.200.8.169 with SMTP id v38mr35699363qth.213.1496856915474; Wed, 07 Jun 2017 10:35:15 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Wed, 7 Jun 2017 10:35:14 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 7 Jun 2017 10:35:14 -0700 X-Google-Sender-Auth: YKqW2IshDcYYiFiDzKf610nijW0 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: David Farmer Cc: Job Snijders , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 17:35:18 -0000 At Wed, 7 Jun 2017 10:13:51 -0500, David Farmer wrote: > > IPv6 unicast routing is based on prefixes of any valid length up to > > 128 [BCP198]. Interface Identifiers must be 64 bit long except > > when the addresses are manually configured, or by exceptions defined > > in standards track documents. For example, [RFC6164] standardises > > 127 bit prefixes on inter-router point-to-point links. The rationale > > for using 64 bit Interface Identifiers can be found in [RFC7421] > > > > then there will be no dispute or further time wasting (we'll still > > need to decide what to do with the magic leading bits of 000 in terms > > of the interface identifier length, but if we can agree at this level > > this will be a relatively minor point to address). > > I think "should be 64" is the correct language, primarily because "must be > 64" has been misinterpreted several times to justify hard coding 64 in IPv6 > implementations, but also it seems like a false imperative. Now that an > explicit manual configuration exception is included, I could live with > "must be 64", only if the language is further clarified as an operational > directive and not an implementation directive to hard code 64 along with > the list of exceptions. > > So I'd prefer; "Interface Identifiers should be 64 bits long except..." > However, I could live with; "Operationally, Interface Identifiers must be > 64 bits long except..." Personally I don't care about should vs must here. I just thought this "must" was critical for the so-called "small but vocal" group, and, if others can accept it with "except..." then it might be a way forward. In that sense, I don't see the point of tweaking it further by such as adding "operationally". As you said, with the "except" it's already pretty clear that we cannot simply hardcode the magic number. If we are still worried about the blind hardcoding we can just say implementations must not unconditionally hardcode a particular value for all cases. Anyway, my humble suggestion to the wg at this point is to hold off until the next version of the draft is submitted. Several people have already pointed out the current version is so confusing, and, as a result everyone seems to interpret it in their favorite way (or overreact to it due to the confusion). Most of the discussions since the submission of 00 seem to be largely irrelevant and just time wasting. It looks like the authors also acknowledge the need for a substantial revise, so it's more productive to wait for it and have a more focused discussion on it. -- JINMEI, Tatuya From nobody Wed Jun 7 11:42:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0885B12F29A for ; Wed, 7 Jun 2017 11:42:55 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldlV8ls9ThZz for ; Wed, 7 Jun 2017 11:42:53 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC0313145C for ; Wed, 7 Jun 2017 11:41:25 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 9so8562755pfj.1 for ; Wed, 07 Jun 2017 11:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=CNwpmBROMkJe0TrrdwMwBFMEZbQQLyFN0IZgSufIe4U=; b=BO0Umcgjcasng6HzQre9mtIwbceMdxtvSlnWwwT24ahVQ9bhIAntndcqP98D5+iGDe hJ71lBorswQhtWCDvH9xh5WPILVL3XDRMYcjfetfcLQcse7lhgUIJXvFavvcCt2zt2x1 7NIAFDgE4P2bFnCiHjruL2HPS56mqBWz34uyc5faRZcTGfMqVYxFuYaChhjc9bldbfAL aP5I1aEeowY7suMpRswNManK33r5pEQ9jE7rwLJm5YUj85bdC4pFc4m1YyVRqNLUoZMb +ZQhKfwE2dV/GYoLo45rp6mk8/UllFdtnUhD/PQBgf4ycszHvRPL+xsb8750LdcPW9aG J1xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=CNwpmBROMkJe0TrrdwMwBFMEZbQQLyFN0IZgSufIe4U=; b=Rn1JNfWx9yUzGwHVKQ8YJZRQLD8V548VrbvXhj1ZreCpXHrE9gZb6w2X1kdzYgcB0C yCZaH+IYTNfJrgajxM33Gr27VyHnA2RS6Om3QXlLuE3Y3HChnn2a5+z58MLS5cKbTF5W xSIrtk1+qA5MU160jsPPcquCky+uqTF3bjdL7CkiD74/M/zOS+XxNbhPHCShAYUovpLb 5aPTkHS0+IHksE7AdkwA5TznJg48LaYGC6hogjCWLZu/GdkK27LezAO85k+TMN0GGb0m xPB95qOpwHHSk24XZWmAMUnuzqiowKeza1AnxLey1QLpD8xCwwo2EaKXG0YQzkwjG1tI zPiQ== X-Gm-Message-State: AODbwcDLcOX7p3AVwbx6lB04nPIDTvYaJ3oHXomlNhqpIVVyXCgWh7XZ BB6q6Si3Y+U5UfVb7oR+wg== X-Received: by 10.84.133.3 with SMTP id 3mr29631227plf.283.1496860884758; Wed, 07 Jun 2017 11:41:24 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:c04e:499a:a99:a8ba? ([2620:0:10e7:10:c04e:499a:a99:a8ba]) by smtp.gmail.com with ESMTPSA id z64sm5242628pfd.20.2017.06.07.11.41.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 11:41:24 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_FFB0776E-F501-4462-8F23-D9C84AE7B10C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Wed, 7 Jun 2017 11:41:23 -0700 References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> To: 6man In-Reply-To: Message-Id: <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 18:42:55 -0000 --Apple-Mail=_FFB0776E-F501-4462-8F23-D9C84AE7B10C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 7, 2017, at 01:53, Lorenzo Colitti wrote: > On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt > wrote: > p1. Power conservative ND Proxy isn=E2=80=99t possible with Thread=E2=84= =A2 1.1 (and earlier) networks. It may never be possible in future = versions of Thread=E2=84=A2. >=20 > Can you explain to us why it doesn't work? One might naively think = that if the BR is doing NAT for hosts behind it, it has to process a = similar packets as it would have to process if it were doing ND. Thread=E2=84=A2 1.1 doesn=E2=80=99t even use RFC 4861 much less RFC = 6775. A proxy for RFC 4861 at the Thread=E2=84=A2 1.1 border router = would require DAD and NUD to be translated into prohibitively expensive = multicast floods into the mesh. Use of IPv6/NAT allows the border router = to make an entire Thread=E2=84=A2 mesh reach the public Internet via the = one stable IPv6 address that is reliably available on all residential = networks with IPv6 providers. For years, we have been hoping that HOMENET would address the basic = problem here, but now that it's clear the forthcoming update to RFC 7084 = will not recommend adoption of the HOMENET protocol suite in IPv6 CPE = residential gateways, Thread=E2=84=A2 has no other option than to = recommend IPv6/NAT to cope with operational reality. --james woodyatt > --Apple-Mail=_FFB0776E-F501-4462-8F23-D9C84AE7B10C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 7, 2017, at 01:53, Lorenzo Colitti <lorenzo@google.com> = wrote:
On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt = <jhw@google.com> = wrote:
p1. Power conservative ND Proxy isn=E2=80=99t possible with = Thread=E2=84=A2 1.1 (and earlier) networks. It may never be possible in = future versions of Thread=E2=84=A2.

Can you explain to us = why it doesn't work? One might naively think that if the BR is doing NAT = for hosts behind it, it has to process a similar packets as it would = have to process if it were doing ND.

Thread=E2=84=A2 1.1 doesn=E2=80=99t even use RFC 4861 much = less RFC 6775. A proxy for RFC 4861 at the Thread=E2=84=A2 1.1 border = router would require DAD and NUD to be translated into prohibitively = expensive multicast floods into the mesh. Use of IPv6/NAT allows the = border router to make an entire Thread=E2=84=A2 mesh reach the public = Internet via the one stable IPv6 address that is reliably available on = all residential networks with IPv6 providers.

For years, we have been hoping that = HOMENET would address the basic problem here, but now that it's clear = the forthcoming update to RFC 7084 will not recommend adoption of the = HOMENET protocol suite in IPv6 CPE residential gateways, Thread=E2=84=A2 = has no other option than to recommend IPv6/NAT to cope with operational = reality.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_FFB0776E-F501-4462-8F23-D9C84AE7B10C-- From nobody Wed Jun 7 12:41:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF0129B34 for ; Wed, 7 Jun 2017 12:41:40 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxu2sK6Tw77Z for ; Wed, 7 Jun 2017 12:41:38 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 56CB5126CC4 for ; Wed, 7 Jun 2017 12:41:38 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id g76so10239957wrd.1 for ; Wed, 07 Jun 2017 12:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2EqVnR4xmxwcm2OC2TrSzxFsc1yuhfgsVj1PlfZYrw4=; b=YHDHrCV0aOKEoMvIXtd0eqGqnUUPu+u+NMG8LZwY9zYUjiyMglyzBSmrm2UyIBpWXv U2U73aAfBGE3LSAsWgPAF7O2thz5QLknIVvKI+UdsMH3FFspbU87BNzcFfXxUVlvmmoz C0ZfeG8HQHLqel5OegGaY2EEylWMisyGE818jdOUynDyER0UtWh50otoqPZagULT6lhc 9gpWxsksMWVWPjmtaQxcRGBh6RtyKMq5qI47V5Y+0Lfd79LoSPKGTDfElMusphZVAMXJ KTPtLBSSnNTIBuC4NF0z4wK2KtePfhzirkzNNWH3a865UKUERNMyy2jQx/yYvm+9BKh9 FpVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2EqVnR4xmxwcm2OC2TrSzxFsc1yuhfgsVj1PlfZYrw4=; b=TG0Zmowvh9Q6Wv/aEpWjqNYeduAgk/noQNDt1EyU8xApTgysjcGvvIOvEHx5lYXbgV AV6n5yuPMYBl/P8MkU4X/f+uUQZD6EZdP46xudjQGurODrzPCmHcukGxQfYMJ5ZwRSNb /ADBifqO8YZnDRbEQfkkDSwwf9KcBmCNtR9/KdL7PYeYbcuHPQni0aGy3V4Ke4cCP8uC rPDYNpSG1ZTgG6fGkvaNcU4H4LIqxyQ+OnnqHEFR+/W71H5y2YDFskH0vxKU6KkxNn2x oZRSDdFgXpkDoMk42U9OqxI9UoW8RRz26u71k6nhGhvOP+vxbT+ezEBh6Hu3sKjK7wX2 qDcw== X-Gm-Message-State: AODbwcBUbRIF9buxTKdjPsjptUiHQOSaoea9f28Db/hYNjNLnKl3EaSw 1YusTr5J6bMXdxN9PeM= X-Received: by 10.223.182.130 with SMTP id j2mr3126944wre.87.1496864496899; Wed, 07 Jun 2017 12:41:36 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1da::1015? ([2600:8802:5600:1da::1015]) by smtp.gmail.com with ESMTPSA id l16sm2073546wre.25.2017.06.07.12.41.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 12:41:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Fred Baker In-Reply-To: <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> Date: Wed, 7 Jun 2017 12:41:32 -0700 Cc: 6man Content-Transfer-Encoding: quoted-printable Message-Id: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> To: james woodyatt X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:41:41 -0000 I'm struggling here. Thread is one adaptation of 6LowPAN etc; OCF = (formerly OIC) describes and network "on IPv6" and treats 6LowPAN as an = encoding of IPv6. For reasons that remain inscrutable to me, Thread acts = as if the only link layer in the world were IEEE 802.15.4; OCF is = extensible to (gasp) Ethernet, 802.11, ITU G.hn/G.9960 or IEEE 1901, and = whatever else. IPv6, and 6LowPAN, is the dog. The industry associations that use them = are the tail. Why is the tail wagging the dog? = https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/thread_overview= / = https://workspace.openconnectivity.org/apps/org/workgroup/technology_sc_op= en/download.php/8950/Technology-Discussion-v3.pptx On Jun 7, 2017, at 11:41 AM, james woodyatt wrote: > On Jun 7, 2017, at 01:53, Lorenzo Colitti wrote: >> On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt = wrote: >> p1. Power conservative ND Proxy isn=E2=80=99t possible with Thread=E2=84= =A2 1.1 (and earlier) networks. It may never be possible in future = versions of Thread=E2=84=A2. >>=20 >> Can you explain to us why it doesn't work? One might naively think = that if the BR is doing NAT for hosts behind it, it has to process a = similar packets as it would have to process if it were doing ND. >=20 > Thread=E2=84=A2 1.1 doesn=E2=80=99t even use RFC 4861 much less RFC = 6775. A proxy for RFC 4861 at the Thread=E2=84=A2 1.1 border router = would require DAD and NUD to be translated into prohibitively expensive = multicast floods into the mesh. Use of IPv6/NAT allows the border router = to make an entire Thread=E2=84=A2 mesh reach the public Internet via the = one stable IPv6 address that is reliably available on all residential = networks with IPv6 providers. >=20 > For years, we have been hoping that HOMENET would address the basic = problem here, but now that it's clear the forthcoming update to RFC 7084 = will not recommend adoption of the HOMENET protocol suite in IPv6 CPE = residential gateways, Thread=E2=84=A2 has no other option than to = recommend IPv6/NAT to cope with operational reality. >=20 >=20 > --james woodyatt >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jun 7 13:21:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEE1129B38 for ; Wed, 7 Jun 2017 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fc7PRQz7Jka for ; Wed, 7 Jun 2017 13:21:23 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7237129AEE for ; Wed, 7 Jun 2017 13:21:23 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 9so9334233pfj.1 for ; Wed, 07 Jun 2017 13:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mJCYq0dIDadBZzjpfHekmwoWNWVbM4nnnzkWgAQYxhI=; b=Pee365Hm/MunpWdyycbdGEU5S7tZMfKNnoWJOTy1KQrltBqFPyCVmonq//D9U1cWIL 5USrQwjA2ozb2VOzpVhAmQ7fuw2XxXQhsXy8aEeEz9BPJXR5ZyQTwE9/keN5QdTW75AO Js2dgdXAdi/DYIWmcNI8AjNc4GnrcePmlWs+2CcddKE49f3Sq/yUDSj379Kjvtgp2s4Q k8SRPsztYSLE68ndHPbo9TWv1M0COI4AYtsp4TikhW6CafcIaLQvFJUN+JjkNcvBxBt6 7G28XfEE1sAhTjGb/IARqSqqCSeuZ4QFy13fdbpsDsDNopJHP5D+It8SVkQ8AmQPHkyw Icyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mJCYq0dIDadBZzjpfHekmwoWNWVbM4nnnzkWgAQYxhI=; b=Jboct/LtrtjS7yFn0pfKhNVr06vFPVbqAj0rX33yE6NuMcH4yRQzX8qJzSC4g4W/20 vesjh6I6nuI/QHzueFzxIk9l6lr0Icw8FQMRB8xmecGAR5XRh8X2L0yivuNOW9tZwUhd nyn2DlLpPXRB0P6SVBCbPtas1Lfm+FL7+/WjeqU6agKl3qs5KakZWO0gFSylb/cBCcza KVpxkvAw7dxpHZ6W3JjNIfY5O4holBtMelz1ntn2Dt+jyjMsKAfxznNuo3oW6qmP4jJI WVJwvSKfIjUOh9gm24mk0Ysd8Vq5CLKUmSojgSg/mSez2ARXZ+JsilxEkDL6FAyjdaF2 2ksw== X-Gm-Message-State: AODbwcDCZ3cy2uYMuazeawXyZ8se2RWVYUF5yPM+XWAfQhdseU4hJEVn mU0eeLBC3xheyaXlP1A0bA== X-Received: by 10.99.66.5 with SMTP id p5mr33970905pga.107.1496866883231; Wed, 07 Jun 2017 13:21:23 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:c04e:499a:a99:a8ba? ([2620:0:10e7:10:c04e:499a:a99:a8ba]) by smtp.gmail.com with ESMTPSA id x73sm5478519pfa.71.2017.06.07.13.21.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 13:21:22 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D56C6F2B-E672-4460-8F7A-94C73F1164AE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Wed, 7 Jun 2017 13:21:21 -0700 In-Reply-To: Cc: 6man To: Fred Baker References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:21:26 -0000 --Apple-Mail=_D56C6F2B-E672-4460-8F7A-94C73F1164AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 7, 2017, at 12:41, Fred Baker wrote: >=20 > Thread is one adaptation of 6LowPAN etc; OCF (formerly OIC) describes = and network "on IPv6" and treats 6LowPAN as an encoding of IPv6. See "OCF Will Run Over Thread" = >. They=E2=80=99re not = operating at comparable levels in the stack. > The industry associations that use them are the tail. Why is the tail = wagging the dog? I see no dogs wagging. =46rom my perspective, I see a wagging tail on a = dog that doesn=E2=80=99t even know it has one. --james woodyatt > --Apple-Mail=_D56C6F2B-E672-4460-8F7A-94C73F1164AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 7, 2017, at 12:41, Fred Baker <fredbaker.ietf@gmail.com> wrote:

Thread is one adaptation of 6LowPAN etc; OCF (formerly OIC) = describes and network "on IPv6" and treats 6LowPAN as an encoding of = IPv6.

See "OCF Will Run Over Thread" <https://www.infoq.com/news/2016/07/ocf-thread>. = They=E2=80=99re not operating at comparable levels in the = stack.

The industry associations that use them are the = tail. Why is the tail wagging the dog?

I see no dogs wagging. =46rom my = perspective, I see a wagging tail on a dog that doesn=E2=80=99t even = know it has one.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_D56C6F2B-E672-4460-8F7A-94C73F1164AE-- From nobody Wed Jun 7 13:43:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67819128854 for ; Wed, 7 Jun 2017 13:43:07 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv8eXdai1AeK for ; Wed, 7 Jun 2017 13:43:06 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CE6124BE8 for ; Wed, 7 Jun 2017 13:43:05 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id x63so9464117pff.3 for ; Wed, 07 Jun 2017 13:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=///oa/mOHD5xf1JVIrvr3s/VpYbrju3q2ThD7yTfY6g=; b=qeMwlcNoWYTTGzFv4Xw3WUXUYQuelbpiIh17vHTgI9Fbsj72bM7Ub1Z9LE+2c9N2W0 zFmHuF29cVeEf+pWHy0ACSV6ExXR5SHwOc/Vbr0G/l3KkdD2KDPQmB/W0NZSeVi02cD+ s6bYdBD1EJZ2a4XCbtcGY3kZc8p85nNIY213oEI3TrE5gAhxKW4uXvjuXuK70dawpdyj LRZtRaLjaMpDQB3sJY70Sbgq49SHW4IlfO6L2C4ah8+ZcTtdtFA43wawzraMvlN+3RRx BDBhwdYZzL5Zf1FixiUcUq4PPM7/W7oHP0eEXdbiHBN+A9uC2sw1Z66VSG4bXfp1AK29 Gw9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=///oa/mOHD5xf1JVIrvr3s/VpYbrju3q2ThD7yTfY6g=; b=iq1FpW/iWg2POs+ehbjZZINh7lIlWbk+Ok01NPtgAB53fDhgRx+0mvPe6ZGeSAaNsc j0ZYe0xfOZYS0O0Z5V4R2u1z8pmNcSWCczMLMAc+nRM08dxmi/HhD89KPjpW3jrGw17D baFtAA80sqwrvQO/PKBIjQtxWnxDxB28VjmwKjt7xnhL81wkrGjUMw05vUHS2pYX8kgx hK7mF6JEq4pbw47pMfnvX6DzrU/aaH7EiZRGpAhdVhKw86GEDe8MrlSV4FsCIqyFvbPy iOyjV4qWNUioxNW7snQ7uPevrKFA+48GxFypSFFybBvK36S0zzn9G6L13l1Ro/1Rrm4+ hUJg== X-Gm-Message-State: AODbwcBbBc28s/HpLobheRkS1qbyC414B65o01BsqBnK5IcFc8tQ8Erb cK9xWa3g0kjegTOo X-Received: by 10.84.253.23 with SMTP id z23mr30485725pll.11.1496868185439; Wed, 07 Jun 2017 13:43:05 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:c04e:499a:a99:a8ba? ([2620:0:10e7:10:c04e:499a:a99:a8ba]) by smtp.gmail.com with ESMTPSA id s68sm6987326pfj.33.2017.06.07.13.43.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 13:43:04 -0700 (PDT) From: james woodyatt Message-Id: <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BB4DEB82-AF55-453E-9F2A-6115269DF885" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Wed, 7 Jun 2017 13:43:03 -0700 In-Reply-To: Cc: 6man To: Fred Baker References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:43:07 -0000 --Apple-Mail=_BB4DEB82-AF55-453E-9F2A-6115269DF885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 7, 2017, at 13:21, james woodyatt wrote: >=20 > I see no dogs wagging. =46rom my perspective, I see a wagging tail on = a dog that doesn=E2=80=99t even know it has one. Furthermore, I should clarify that I=E2=80=99m taking no position = whatsoever against what I view to be an effort to update IPv6 Address = Assignment to End Sites [RFC 6177] to drop the following reaffirmation = on page 3: A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. I no longer feel this must be avoided. It=E2=80=99s too late to stop = that from happening. It now seems perfectly acceptable that end sites = should feel compelling to use IPv6-to-IPv6 Network Address Translation = or other burdensome address conservation techniques because it cannot = get sufficient address space. --james woodyatt > --Apple-Mail=_BB4DEB82-AF55-453E-9F2A-6115269DF885 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 7, 2017, at 13:21, james woodyatt <jhw@google.com> = wrote:

I see no dogs wagging. =46rom my perspective, = I see a wagging tail on a dog that doesn=E2=80=99t even know it has = one.

Furthermore, = I should clarify that I=E2=80=99m taking no position whatsoever against = what I view to be an effort to update IPv6 Address Assignment to End = Sites [RFC 6177] to drop the following reaffirmation on page = 3:

      A key principle for address management is that end sites =
always be
      able to obtain a reasonable amount of address space for their
      actual and planned usage, and over time ranges specified in years
      rather than just months.  In practice, that means at least one
      /64, and in most cases significantly more.  One particular
      situation that must be avoided is having an end site feel
      compelled to use IPv6-to-IPv6 Network Address Translation or other
      burdensome address conservation techniques because it could not
      get sufficient address space.

I no longer feel this must be avoided. = It=E2=80=99s too late to stop that from happening. It now seems = perfectly acceptable that end sites should feel compelling to use = IPv6-to-IPv6 Network Address Translation or other burdensome address = conservation techniques because it cannot get sufficient address = space.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_BB4DEB82-AF55-453E-9F2A-6115269DF885-- From nobody Wed Jun 7 15:41:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292F1271FD for ; Wed, 7 Jun 2017 15:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di1u25xjLior for ; Wed, 7 Jun 2017 15:41:30 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 324AC1270A7 for ; Wed, 7 Jun 2017 15:41:30 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l75so8035666ywc.3 for ; Wed, 07 Jun 2017 15:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fclpym6arLY/Ft2y9nKwvutLQCbNueIEQGGKalBqmhg=; b=VnBBiqt8bMIT1+CA/bbdoQ/kRkgR5Cdj8JPOR+cGQbefOxM5WS1UDcbDwYFJVEBqBT FdczDTekkUvD5sZPWS2jF9ptD4iCmCw/UqGdrul6yMOaES8SUf5j5WeYDbgXbdVBu1po SfJnWOqzSTGYjWs1lSiACXk4uN785e5p6y8lFMdIvCjG1vMSEUtJC4zmoC9WwoOjzatI QX6gwbPBQTcOZSgK5qOpLphaMGKlkmvmy+CDFA1FLt1zSAE0HcY1uH8uquvtDE7SGf+W LDNAEZxCx1ZE7srEatsqJSqV/kM95UBbYhqKU1xkw0HCQ9SKH7eN6GEb96WSd3NxJpEM r4Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fclpym6arLY/Ft2y9nKwvutLQCbNueIEQGGKalBqmhg=; b=jIBOtuAqg+LZ8bGtzRQimz7bbQUjOsqUjj1nNwcCpmTs69F+kwpfBkMV92FI9iN/Jl t9kvCDCKzmzuDQzG+NMtwgFIR4+/cR8C4mqcwk4Lp5PISoiGgLlHjZsfNcc3DOpECq0X fmdr/LmYqEXREjWTlW3FaUvy23GO6MCDmb2QF5FcA0RfwbxiKYE9g/z+zKYOJgrpYRiz 1ums9cN6LLzLqkFptC4Mi/fW6ZDtBJx9qGuzCvgrzRhuYaBN4cExVDN4xu2PNHikG/L3 Hr/ki75+ZQ9/kOy8gUnVJKavr7dcx8yym3ZZMfOswwyVf7deFIvsTNtDEEkVHcfkVLcN eEwg== X-Gm-Message-State: AODbwcBvW5ZX7qq7lfRKbL5YMb4xeHYTybLwx2KXTCDqHeO/+kvs/ktd iWb6cSD9GJ0r24pXP/DfwtrOo8J5mg== X-Received: by 10.13.232.10 with SMTP id r10mr9314490ywe.161.1496875289448; Wed, 07 Jun 2017 15:41:29 -0700 (PDT) MIME-Version: 1.0 References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> In-Reply-To: <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> From: Ca By Date: Wed, 07 Jun 2017 22:41:18 +0000 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fred Baker , james woodyatt Cc: 6man Content-Type: multipart/alternative; boundary="94eb2c088658e6ae6d0551666fc7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:41:32 -0000 --94eb2c088658e6ae6d0551666fc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 7, 2017 at 1:43 PM james woodyatt wrote: > On Jun 7, 2017, at 13:21, james woodyatt wrote: > > > I see no dogs wagging. From my perspective, I see a wagging tail on a dog > that doesn=E2=80=99t even know it has one. > > > Furthermore, I should clarify that I=E2=80=99m taking no position whatsoe= ver > against what I view to be an effort to update IPv6 Address Assignment to > End Sites [RFC 6177] to drop the following reaffirmation on page 3: > > A key principle for address management is that end sites always be > able to obtain a reasonable amount of address space for their > actual and planned usage, and over time ranges specified in years > rather than just months. In practice, that means at least one > /64, and in most cases significantly more. One particular > situation that must be avoided is having an end site feel > compelled to use IPv6-to-IPv6 Network Address Translation or other > burdensome address conservation techniques because it could not > get sufficient address space. > > > I no longer feel this must be avoided. It=E2=80=99s too late to stop that= from > happening. It now seems perfectly acceptable that end sites should feel > compelling to use IPv6-to-IPv6 Network Address Translation or other > burdensome address conservation techniques because it cannot get sufficie= nt > address space. > I am unfamiliar with thread () in the real world and don't yet feel compelled to believe a widely deployed ietf standards track specifications should bend due some niche design choices that may or may not achieve a significant deployment. Thread () makes design choices and they deal with them. Same for ietf. I believe i am agreeing with Fred > > --james woodyatt > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c088658e6ae6d0551666fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jun 7, 2017 at 1:43 PM jam= es woodyatt <jhw@google.com> wr= ote:
On Jun 7, 2017, at 13:21, james woodyatt <jhw@google.com> wrote:

I see no= dogs wagging. From my perspective, I see a wagging tail on a dog that does= n=E2=80=99t even know it has one.

<= /div>
Furthermore, I should clarify= that I=E2=80=99m taking no position whatsoever against what I view to be a= n effort to update IPv6 Address Assignment to End Sites [RFC 6177] to drop = the following reaffirmation on page 3:

      A key principle f=
or address management is that end sites always be
      able to obtain a reasonable amount of address space for their
      actual and planned usage, and over time ranges specified in years
      rather than just months.  In practice, that means at least one
      /64, and in most cases significantly more.  One particular
      situation that must be avoided is having an end site feel
      compelled to use IPv6-to-IPv6 Network Address Translation or other
      burdensome address conservation techniques because it could not
      get sufficient address space.

I no longer fe= el this must be avoided. It=E2=80=99s too late to stop that from happening.= It now seems perfectly acceptable that end sites should feel compelling to= use IPv6-to-IPv6 Network Address Translation or other burdensome address c= onservation techniques because it cannot get sufficient address space.

I am unfamiliar wi= th thread () in the real world and don't yet feel compelled to believe = a widely deployed ietf standards track specifications should bend due some = niche design choices that may or may not achieve a significant deployment.= =C2=A0

Thread () makes design choices and they dea= l with them.=C2=A0 Same for ietf.=C2=A0

I believe = i am agreeing with Fred=C2=A0



--james woodyatt <jhw@google.com>



-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--94eb2c088658e6ae6d0551666fc7-- From nobody Wed Jun 7 16:42:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7D131493 for ; Wed, 7 Jun 2017 16:42:16 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhuQ-A2OMOgI for ; Wed, 7 Jun 2017 16:42:14 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77570128CD5 for ; Wed, 7 Jun 2017 16:42:14 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id x63so10677385pff.3 for ; Wed, 07 Jun 2017 16:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0HjnMBtpw21Q1ROvBOBDKrsscXvY1o23XNaBIaIUlzs=; b=EneNqDHL5iKoKDxcIvkh7S335RHJoSm7A64iuVgYBN9vXkHGTN/wr39BsMpzuLSknv +1RrHhA7AV7r+75/hUDvg4MlPhv0Q1oOt/qj/LIFjG0ap6SMQhCO3o++Y7r76mSj7qTa JeX4RJNPbjaAYOnZz8ysmcur0gxwr/UQzhPPLzlLpV/2nml8tT5vZ2H8EwXvwzMfL82Q IEona8SL8JU+efmZWk6CzM5/8fdJOsz0KuVhLplv0tKW4+oq7xtKZ1rO9rsUCyAST59b aiEKVjMvORkf1+z1Om8an7YhwhUxKrF37X3UAdKxn7rHJr6chETwaAL0P3ASKwdKG091 Q80A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0HjnMBtpw21Q1ROvBOBDKrsscXvY1o23XNaBIaIUlzs=; b=ntxcPtQtzKg8HoZjNFne7gQmacVSA5tbivMBwkalOGttlJUgq86q8yUfK8EmwT+wvF l0xcmIpmHeS8HHA4yIcuoaRvkpkFGmEWY7zz0KhhHOoJqimldDPAWwb3bn7E4ZHKQtPy i5Vw8Oq+XAYstJW5JUzx1DBWtDXXbVZQ5IHsmCamYvDUL2vNcdPxIqzl7kSP9foi9J1i bljWuhMOXb3pKGpNJtn+BbYKUb+7pStrw4ka0SFaqR2I+Jibx5Fhcqwv5+JwI5wem0vJ cEo++zJMtuC4d1NwJ8WVZbsUlacBzqXxVPJEXBnBocOpoX6j3D/P4UjmtRDrc7XyLmPL sPXw== X-Gm-Message-State: AODbwcCVVxy1IE0y4KxMXTRsyZ8VdY376QTs8s6xqv7zTS1JvS0+nJ4C 6yx3rZPC3/Gz1mjv X-Received: by 10.101.86.11 with SMTP id l11mr1874842pgs.202.1496878933945; Wed, 07 Jun 2017 16:42:13 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:c04e:499a:a99:a8ba? ([2620:0:10e7:10:c04e:499a:a99:a8ba]) by smtp.gmail.com with ESMTPSA id i68sm6283307pfi.72.2017.06.07.16.42.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 16:42:13 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_904BE603-3DA1-46D9-A81F-3E11AD6C09D7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Date: Wed, 7 Jun 2017 16:42:12 -0700 In-Reply-To: Cc: Fred Baker , 6man To: Ca By References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 23:42:16 -0000 --Apple-Mail=_904BE603-3DA1-46D9-A81F-3E11AD6C09D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 7, 2017, at 15:41, Ca By wrote: >=20 > I am unfamiliar with thread () in the real world and don't yet feel = compelled to believe a widely deployed ietf standards track = specifications should bend due some niche design choices that may or may = not achieve a significant deployment.=20 As far as I know, nobody associated with Thread=E2=84=A2 apart from me = is even listening to IETF much less offering anything to say. And the = only thing I=E2=80=99m saying is that IETF should stop pretending that = IPv6/NAT in end site addressing plans is preventable. It=E2=80=99s = inevitable. I=E2=80=99m not asking IETF to bend its standards accordingly. I=E2=80=99m= actually expecting that IETF will not bend, and that it will continue = promoting standards that leave end sites compelled to use IPv6-to-IPv6 = Network Address Translation to conserve address space (despite the = contrary statement in RFC 6177). The only thing I would prefer to see = here is for 6MAN discussions to recognize the operational reality about = IPv6/NAT and stop using discussion points about how this or that draft = should be opposed because its adoption might lead to the widespread = deployment of IPv6/NAT, which I now believe to be impossible to stop. = Indeed, I don=E2=80=99t think there is any desire among service = providers and equipment vendors to prevent it. Therefore, in the context of discussions around this particular draft, = I-D.bourbaki-6man-classless-ipv6, I would say that arguments about how = subnet prefixes longer than /64 could leave end sites feeling compelled = to use IPv6/NAT for address conservation are not technically strong = arguments. They are already feeling compelled, even at the existing /64 = boundary. There may be other good arguments for retaining the fixed /64 subnet = prefix length in the IPv6 address architecture, but I would say that = preventing the rise of ubiquitous IPv6/NAT should not be one of them. = That ship sailed when RFC 6177 was passed, and it went over the horizon = when HOMENET didn=E2=80=99t receive any significant uptake among service = providers. --james woodyatt > --Apple-Mail=_904BE603-3DA1-46D9-A81F-3E11AD6C09D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 7, 2017, at 15:41, Ca By <cb.list6@gmail.com> = wrote:

I = am unfamiliar with thread () in the real world and don't yet feel = compelled to believe a widely deployed ietf standards track = specifications should bend due some niche design choices that may or may = not achieve a significant = deployment. 

As far as I know, nobody associated with Thread=E2=84= =A2 apart from me is even listening to IETF much less offering anything = to say. And the only thing I=E2=80=99m saying is that IETF should stop = pretending that IPv6/NAT in end site addressing plans is preventable. = It=E2=80=99s inevitable.

I=E2=80=99m = not asking IETF to bend its standards accordingly. I=E2=80=99m actually = expecting that IETF will not bend, and that it will continue promoting = standards that leave end sites compelled to use IPv6-to-IPv6 Network = Address Translation to conserve address space (despite the contrary = statement in RFC 6177). The only thing I would prefer to see here is for = 6MAN discussions to recognize the operational reality about IPv6/NAT and = stop using discussion points about how this or that draft should be = opposed because its adoption might lead to the widespread deployment of = IPv6/NAT, which I now believe to be impossible to stop. Indeed, I = don=E2=80=99t think there is any desire among service providers and = equipment vendors to prevent it.

Therefore, in the context of discussions around = this particular draft, I-D.bourbaki-6man-classless-ipv6, I would say = that arguments about how subnet prefixes longer than /64 could leave end = sites feeling compelled to use IPv6/NAT for address conservation are not = technically strong arguments. They are already feeling compelled, even = at the existing /64 boundary.

There = may be other good arguments for retaining the fixed /64 subnet prefix = length in the IPv6 address architecture, but I would say that preventing = the rise of ubiquitous IPv6/NAT should not be one of them. That ship = sailed when RFC 6177 was passed, and it went over the horizon when = HOMENET didn=E2=80=99t receive any significant uptake among service = providers.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_904BE603-3DA1-46D9-A81F-3E11AD6C09D7-- From nobody Wed Jun 7 17:20:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A816131498 for ; Wed, 7 Jun 2017 17:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2bJniD8IwsG for ; Wed, 7 Jun 2017 17:20:11 -0700 (PDT) Received: from nm10-vm1.access.bullet.mail.bf1.yahoo.com (nm10-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.208]) (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 D1161126DFF for ; Wed, 7 Jun 2017 17:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1496881209; bh=av6MpyPcnz8xIBtp384D17Gujr+iglLXQ6IPR8WUeHM=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=r815C3FTKxpRm//CP8RUSI7pgjTA0n2dTIixi75cKkXxlyAPaV0USopl/Fbnnx/JNquM//n6ySTG12v1NBKBfRspMzYuKK/91up/226tKpFFzlLX+cREt4MdGNcOSYlEvm0Qrq4XEqGsHuTtuwl77T+PgX4NzmlIXa+/uth9JNw= Received: from [66.196.81.156] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jun 2017 00:20:09 -0000 Received: from [98.139.221.250] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jun 2017 00:20:09 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.bf1.yahoo.com with NNFMP; 08 Jun 2017 00:20:09 -0000 X-Yahoo-Newman-Id: 933026.64020.bm@smtp120.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3KSHc5QVM1lWwZapR67O.SJDQEPypkSHYUAj1_Ix9qP28HE LuycQrgZTjL8eoROybE7NMkjeByVNQP3LiCmb8lMhBFYHLe9bAcQ_BbYlNAF CWX7onVIkKvdso7pkU.I4vOoxKeJLw0PWFW5reGU509sEB0sB7E6_xDXYLgj cKPKkxk2qjrpvcHmUuoa19DGsIReUlpqHRxyqzvQ4jIqqfIP71QKvuh1q09m 5FcP7oQn0V4EZkGLv84G1Kg8c3MxAkLwQ4omcDCp2z9NZbkNqIgi80Kk_4.Y 66pJl8Turisc0tgZzCOKGJ8pPRYMHzr8NPG7G7mJVdSjHIY_2lrpWZ2iMNjW kU2B0HT6kg4a.kg6VRtXF0U9IuocxptjgJ9qfPoTMZipIpMOp41d3woOi96I ZOyoZQGoWxYhYd82s0GvPTVGSl4fd1136opevgxI7muTSL9l01OgOu_LLO.6 H.QsG2WrLiDf.0NrZM6xurxXCBWpglefag8iT8PXidT_1InO1o7lzVTGhCOn w_RFpnkAOFR3bQ29Pwuhpjq6CNOEtvadfsvd2C.QUy1XKWmLVvbpjYw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.7.3.170325 Date: Wed, 07 Jun 2017 17:20:03 -0700 Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Don Sturek To: james woodyatt , Ca By CC: 6man Message-ID: Thread-Topic: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3579700808_2027714" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 00:20:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3579700808_2027714 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi James, I have not participated in Thread at all and this is mostly hearsay=8A.. However, isn=B9t the source of the problem that Thread went down the path of using a Layer 2 routing scheme that they need to harmonize? I don=B9t see ho= w IETF is the source of the addressing issues if that is the case. Don Sturek From: ipv6 on behalf of james woodyatt Date: Wednesday, June 7, 2017 at 4:42 PM To: Ca By Cc: 6man Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) On Jun 7, 2017, at 15:41, Ca By wrote: >=20 > I am unfamiliar with thread () in the real world and don't yet feel compe= lled > to believe a widely deployed ietf standards track specifications should b= end > due some niche design choices that may or may not achieve a significant > deployment.=20 As far as I know, nobody associated with Thread=81 apart from me is even listening to IETF much less offering anything to say. And the only thing I=B9= m saying is that IETF should stop pretending that IPv6/NAT in end site addressing plans is preventable. It=B9s inevitable. I=B9m not asking IETF to bend its standards accordingly. I=B9m actually expecting that IETF will not bend, and that it will continue promoting standards that leave end sites compelled to use IPv6-to-IPv6 Network Addres= s Translation to conserve address space (despite the contrary statement in RF= C 6177). The only thing I would prefer to see here is for 6MAN discussions to recognize the operational reality about IPv6/NAT and stop using discussion points about how this or that draft should be opposed because its adoption might lead to the widespread deployment of IPv6/NAT, which I now believe to be impossible to stop. Indeed, I don=B9t think there is any desire among service providers and equipment vendors to prevent it. Therefore, in the context of discussions around this particular draft, I-D.bourbaki-6man-classless-ipv6, I would say that arguments about how subnet prefixes longer than /64 could leave end sites feeling compelled to use IPv6/NAT for address conservation are not technically strong arguments. They are already feeling compelled, even at the existing /64 boundary. There may be other good arguments for retaining the fixed /64 subnet prefix length in the IPv6 address architecture, but I would say that preventing th= e rise of ubiquitous IPv6/NAT should not be one of them. That ship sailed whe= n RFC 6177 was passed, and it went over the horizon when HOMENET didn=B9t receive any significant uptake among service providers. --james woodyatt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --B_3579700808_2027714 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi James,

I have not participated in Thread at all and this is mostly hearsay&= #8230;..

However, isn’t the source of the pro= blem that Thread went down the path of using a Layer 2 routing scheme that t= hey need to harmonize?  I don’t see how IETF is the source of the= addressing issues if that is the case.

Don Sturek<= /div>


From: = ipv6 <ipv6-bounces@ietf.org&g= t; on behalf of james woodyatt <jhw@googl= e.com>
Date: Wednesday, Jun= e 7, 2017 at 4:42 PM
To: Ca By <= ;cb.list6@gmail.com>
Cc: 6man <ip= v6@ietf.org>
Subject: Re: D= eprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
On Jun 7, 2017, at 15:41, Ca By <cb.list6@gmail.com> wrote:<= br class=3D"">

I am unfamiliar with thread () in the real world and don't yet feel = compelled to believe a widely deployed ietf standards track specifications s= hould bend due some niche design choices that may or may not achieve a signi= ficant deployment. 

As far as I know, nobody associated with Thread™ apart from me is ev= en listening to IETF much less offering anything to say. And the only thing = I’m saying is that IETF should stop pretending that IPv6/NAT in end si= te addressing plans is preventable. It’s inevitable.

I’m not asking IETF to bend its standards accordingly= . I’m actually expecting that IETF will not bend, and that it will con= tinue promoting standards that leave end sites compelled to use IPv6-to-IPv6= Network Address Translation to conserve address space (despite the contrary= statement in RFC 6177). The only thing I would prefer to see here is for 6M= AN discussions to recognize the operational reality about IPv6/NAT and stop = using discussion points about how this or that draft should be opposed becau= se its adoption might lead to the widespread deployment of IPv6/NAT, which I= now believe to be impossible to stop. Indeed, I don’t think there is = any desire among service providers and equipment vendors to prevent it.

Therefore, in the context of discussions aroun= d this particular draft, I-D.bourbaki-6man-classless-ipv6, I would say that = arguments about how subnet prefixes longer than /64 could leave end sites fe= eling compelled to use IPv6/NAT for address conservation are not technically= strong arguments. They are already feeling compelled, even at the existing = /64 boundary.

There may be other good argu= ments for retaining the fixed /64 subnet prefix length in the IPv6 address a= rchitecture, but I would say that preventing the rise of ubiquitous IPv6/NAT= should not be one of them. That ship sailed when RFC 6177 was passed, and i= t went over the horizon when HOMENET didn’t receive any significant up= take among service providers.


--james woodyatt <jhw@google.com>



------= -------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --B_3579700808_2027714-- From nobody Wed Jun 7 18:57:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23691294E7 for ; Wed, 7 Jun 2017 18:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VORT0bC8_ZBb for ; Wed, 7 Jun 2017 18:57:14 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 2FE711294C4 for ; Wed, 7 Jun 2017 18:57:14 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id v18so2962796pgb.3 for ; Wed, 07 Jun 2017 18:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nzbrGesI+igN8rRWzc/gio437iO+kOiM3V2ZMHqivnM=; b=N/NBlWrqclWeZVOzalZAMd93NPoIskQcChDHRZmpGWA2L+dXygsz5aoXLo7BEEWTGq zipzvIHs+Z9iirn8F/t0YnVAJ9LnQodsqpyY+T2Pdir4nncaXwrU2PYFmdNh64o32+b5 vlNkzq5EARUYiqJH8c9Etw5HG1/Kwc6fVJEOJTzOBAD2ni7sEEqBymdrFpVUA9sX7hW0 0HLL14bZO9AadQpjL9WrxDUL9Xtm51Zrz4mjiMIeyn4vvrAq5t7LAY14149j3/cKKueT xyCJaKXmWK4/zpBhHePe0YcErk0nhYDBFaverglLwFXlNHv2K8hOMuIVVDIh2SaHNGd9 IZOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nzbrGesI+igN8rRWzc/gio437iO+kOiM3V2ZMHqivnM=; b=BqzlRSYd9ry+/larrH0l4/rqw78OMLScPwoDkwyiIpjwUsxYh7zISHXCEjgvB1roGL x0Yj5dd7NB1Hn3jst2zXbzV3eFP0bhR9MUCkDca3CA8AooxtRAxHw6+2+lZsJAIexOaL H5iy/JpRO+OpoFqwTRqsdT7MDPyPzEGQrUr7jdzJOvaS4PcNYfIi+lw1eo7xUUainupH ZeJKZrpq4EJ0lvF+inBweo6f9Vwe0oPNzFaLH8dbx/iQO8bodsORajMaSBZvATHK7mK6 UVwgibeNemRIcrNSSK5pH4c/uxmJfWWrzRiAVmGQIsQCm5qxBlmk09QikUt8dr3q9i8C Z9VA== X-Gm-Message-State: AODbwcDwSLBAqUXtgQtE/0iTL8eoFKlTU8oxeR62zpy1Zdo4ct/s2nLo 0HufI5UXfFZE/MyO X-Received: by 10.84.193.3 with SMTP id e3mr32264477pld.178.1496887033571; Wed, 07 Jun 2017 18:57:13 -0700 (PDT) Received: from [192.168.178.21] (44.219.69.111.dynamic.snap.net.nz. [111.69.219.44]) by smtp.gmail.com with ESMTPSA id r85sm5836683pfb.61.2017.06.07.18.57.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 18:57:12 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Job Snijders Cc: Ole Troan , Erik Kline , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1a5979f3-ef1b-8099-b1fa-fc19571898a2@gmail.com> Date: Thu, 8 Jun 2017 13:57:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 01:57:16 -0000 On 07/06/2017 13:14, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 06 Jun 2017 23:30:30 +0000, > Job Snijders wrote: >=20 >>>>> But that is exactly what the draft does *not* do. Nobody would >>>>> change a single instruction in existing code as a result of this >>>>> draft. (I agree with you that some O/S stacks may need fixing, but >>>>> they already need fixing.) >>>> >>>> is this draft exactly: >>>> >>>> IPv6 unicast routing is based on prefixes of any valid length up = to >>>> 128 [BCP198]. Interface Identifiers should be 64 bit long except= >>>> when the addresses are manually configured, or by exceptions defi= ned >>>> in standards track documents. For example, [RFC6164] standardise= s >>>> 127 bit prefixes on inter-router point-to-point links. The ratio= nale >>>> for using 64 bit Interface Identifiers can be found in [RFC7421] >>>> >>>> ? >>> >>> Yes. Put those words in 4291bis and I will be very happy. Oh ;-). >> >> I recall a small but vocal group arguing fiercely against that text >> adjustment, so here we are. >=20 > As several people including myself have already pointed out, it's very > hard for ordinary readers to understand that's really what > draft-bourbaki-6man-classless-ipv6-00 tries to propose. It will have > to be heavily revised to convey that message. >=20 > As for the above text, my recollection is that some people (I don't > know if that was a small group, btw - to me both groups looked equally > vocal and equally small/large) were against one specific point in > text like the above one: >=20 > - "should be 64" instead of "must be 64" (but in my understanding they > were/are okay with "except when the addresses are manually > configured") >=20 > It's also not clear to me whether the real intent of > draft-bourbaki-6man-classless-ipv6-00 includes the subtle (but > seemingly very important for those who were "fiercely against" it) > change from "must" to "should". I guess if the authors of > 6man-classless-ipv6 are actually also happy/okay with this one: >=20 > IPv6 unicast routing is based on prefixes of any valid length up to= > 128 [BCP198]. Interface Identifiers must be 64 bit long except > when the addresses are manually configured, or by exceptions define= d > in standards track documents. For example, [RFC6164] standardises > 127 bit prefixes on inter-router point-to-point links. The rationa= le > for using 64 bit Interface Identifiers can be found in [RFC7421] Speaking for myself only, yes, happy. Brian >=20 > then there will be no dispute or further time wasting (we'll still > need to decide what to do with the magic leading bits of 000 in terms > of the interface identifier length, but if we can agree at this level > this will be a relatively minor point to address). >=20 > -- > JINMEI, Tatuya >=20 From nobody Wed Jun 7 19:12:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E83129541 for ; Wed, 7 Jun 2017 19:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9JVR51OJO27 for ; Wed, 7 Jun 2017 19:12:02 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 4C1B8129524 for ; Wed, 7 Jun 2017 19:12:02 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id v18so2995037pgb.3 for ; Wed, 07 Jun 2017 19:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=L2V/n4pTrvvwvPDrfQlRaH7+d/7PtL8q+Vq0ZIbTWoY=; b=gtEqUV8tFZmjUsMlYJLwvS3uS9/Xdy/PcVR2MfhDhxAg8YBRjnbjPLtpC1N3ZWVkPI 4rds3mvneax3Y7Y0lK57jA+BUsdycS2iLvQKwAKTALWiPmV+9sV/GyzGrVpoZmbvowB8 hVl6Mh8Gpyli9t/aa5gucu/wQPYlwq+qbjIF6HkiRm8lQBjIkeYf2qYiWrH3BdfGefeG G+PTj+rwwqS4ve5+HF5kl+fM3A486Ggv+9Clwvc0oN0IhE2VuE9uG2ChxMsXKxh3a4Kp FmBs9BdGPwzeuLkEIZWS6+65pCePFNQeKoacVGDwxxbyrxYQ+nJRaK/AAgbvZBv8naxw 8vUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=L2V/n4pTrvvwvPDrfQlRaH7+d/7PtL8q+Vq0ZIbTWoY=; b=l31+WSuFoXKkWx7DnO3mDpiFkIgELN7GVbBdQwk5jv+Yf3TNfi5OkCbR2hkYa4eorz Yp9f682PL51SrdyRxlEfPejZyFY9TgAHRaIVxWzOuwwqBxAuEMvb6RcpR+Km4vUG5yXf nVw1jVehluB5XJJe/GX8YKuVaYwhEICjNDf3DS5nMw1essbKhc+J5nxdjmlrvPeSrEy1 +xKwG56BCqhNwR0q833p8TZO5B8CQQ7K4YOZxi/efugNVleXciw0U6P4R3vEn5+jcjg5 Te7wLgzeJStECHPdhXfjIHlz1d4OS8Ug5rs/Q/ULrAYK2K5k1ILLt6qNHySCVnx5H62l NXKQ== X-Gm-Message-State: AODbwcDvDkjllcCqktOXMtDc9IAOS/5Dr5rjz/4F+SFE37o+xDoULJwd cHVCYpK4zWSygkSj X-Received: by 10.98.193.129 with SMTP id i123mr11346893pfg.138.1496887921719; Wed, 07 Jun 2017 19:12:01 -0700 (PDT) Received: from [192.168.178.21] (44.219.69.111.dynamic.snap.net.nz. [111.69.219.44]) by smtp.gmail.com with ESMTPSA id n123sm953670pga.35.2017.06.07.19.11.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 19:12:01 -0700 (PDT) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <79bbcff2-3adf-7a7c-ccd9-1f1f3f2d647c@gmail.com> Date: Thu, 8 Jun 2017 14:12:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:12:04 -0000 On 08/06/2017 07:41, Fred Baker wrote: > I'm struggling here. Thread is one adaptation of 6LowPAN etc; OCF (form= erly OIC) describes and network "on IPv6" and treats 6LowPAN as an encodi= ng of IPv6. For reasons that remain inscrutable to me, Thread acts as if = the only link layer in the world were IEEE 802.15.4; OCF is extensible to= (gasp) Ethernet, 802.11, ITU G.hn/G.9960 or IEEE 1901, and whatever else= =2E >=20 > IPv6, and 6LowPAN, is the dog. The industry associations that use them = are the tail. Why is the tail wagging the dog? Well said. Also, the fact that rfc7084-bis might or might not require HNC= P support doesn't prevent any vendor (or ISP procuring CE routers) requir= ing HNCP. In any case, it hasn't even reached WGLC yet so its content is = all open for discussion. Brian > https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/thread_overv= iew/ > https://workspace.openconnectivity.org/apps/org/workgroup/technology_sc= _open/download.php/8950/Technology-Discussion-v3.pptx >=20 > On Jun 7, 2017, at 11:41 AM, james woodyatt wrote: >> On Jun 7, 2017, at 01:53, Lorenzo Colitti wrote: >>> On Wed, Jun 7, 2017 at 4:06 AM, james woodyatt wrote= : >>> p1. Power conservative ND Proxy isn=E2=80=99t possible with Thread=E2= =84=A2 1.1 (and earlier) networks. It may never be possible in future ver= sions of Thread=E2=84=A2. >>> >>> Can you explain to us why it doesn't work? One might naively think th= at if the BR is doing NAT for hosts behind it, it has to process a simila= r packets as it would have to process if it were doing ND. >> >> Thread=E2=84=A2 1.1 doesn=E2=80=99t even use RFC 4861 much less RFC 67= 75. A proxy for RFC 4861 at the Thread=E2=84=A2 1.1 border router would r= equire DAD and NUD to be translated into prohibitively expensive multicas= t floods into the mesh. Use of IPv6/NAT allows the border router to make = an entire Thread=E2=84=A2 mesh reach the public Internet via the one stab= le IPv6 address that is reliably available on all residential networks wi= th IPv6 providers. >> >> For years, we have been hoping that HOMENET would address the basic pr= oblem here, but now that it's clear the forthcoming update to RFC 7084 wi= ll not recommend adoption of the HOMENET protocol suite in IPv6 CPE resid= ential gateways, Thread=E2=84=A2 has no other option than to recommend IP= v6/NAT to cope with operational reality. >> >> >> --james woodyatt >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Jun 7 19:13:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6D31314D2 for ; Wed, 7 Jun 2017 19:13:56 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTB6WWOxjjC9 for ; Wed, 7 Jun 2017 19:13:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 127B61314D0 for ; Wed, 7 Jun 2017 19:13:55 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0F2A63493A2; Thu, 8 Jun 2017 02:13:52 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EB38E160050; Thu, 8 Jun 2017 02:13:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D4BF6160055; Thu, 8 Jun 2017 02:13:51 +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 wYq-ofs2GAqj; Thu, 8 Jun 2017 02:13:51 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 88C44160050; Thu, 8 Jun 2017 02:13:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B3C0C7B5522C; Thu, 8 Jun 2017 12:13:49 +1000 (AEST) To: sthaug@nethelp.no Cc: ek@google.com, job@instituut.net, ipv6@ietf.org From: Mark Andrews References: <20170607.075131.74727436.sthaug@nethelp.no> <20170607.142936.74725051.sthaug@nethelp.no> Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text In-reply-to: Your message of "Wed, 07 Jun 2017 14:29:36 +0200." <20170607.142936.74725051.sthaug@nethelp.no> Date: Thu, 08 Jun 2017 12:13:49 +1000 Message-Id: <20170608021349.B3C0C7B5522C@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:13:57 -0000 In message <20170607.142936.74725051.sthaug@nethelp.no>, sthaug@nethelp.no writ es: > > > That's precisely the point. I configure fixed addresses typically for > > > servers, and I put the addresses in the DNS. I *want* those addresses > > > to be publically known. Security and privacy is not relevant in this > > > particular case. > > > > For an authoritative server, sure. > > > > But if you're a recursive resolver then using privacy addresses while doing > > recursion (and changing the privacy addresses frequently) might indeed be > > very useful. (In fact: a unique source address per query is wonderful.) > > Different strokes for different folks. I'm fine with fixed addresses > for the query sources of my recursive resolvers, and have no plans to > change this. I have no problems with others using a unique source > address per query. And it really don't add much in terms of privacy as the /64 would be the same. Nor is it needed to combat spoofing of responses. We have DNS COOKIES for that. We are looking at removing port randomisation when talking with servers that support DNS COOKIES. Send a query with a cookie then if we don't get a cookie response resend using a random port. > Steinar Haug, AS2116 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 7 22:26:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5169A127444 for ; Wed, 7 Jun 2017 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_bzZinVLUu3 for ; Wed, 7 Jun 2017 22:26:46 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 DABB8124D6C for ; Wed, 7 Jun 2017 22:26:45 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id u26so3840843pfd.2 for ; Wed, 07 Jun 2017 22:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/JKuBBj5LwwO9H42aVagMv8ehiafwJfMvZrSibWN+A8=; b=QeHGhdaRzQdOonEjg3Z9XCjHcgF+tG28eVbWpN1qkHT24D6FsyzBZ1qtfjddN++521 ruf1cZxRjRd5topGdAvkOCYfEbyLKAuxd8DNHlfVD74dIjNfnFqtVdqiV/O+PClQFWqO /vbL/MkZMqeOOlxxeuD2IG6JaKz8nWIO7Tsx9AJ3HUeeYdEkOGKaDrXTawIyHgZ4CAXR xZh/KtGeZIbVzX4F3KFOge/lRIO2ZyueE1ye+aM6IxO/AZLhulSA/y8FSk7QO2BKzvDm PW6+SMkp4iZitTby2ljwzx96GzrCFfELlTKhc4SVWgYuofTm2ZlhUHKnP9E369qjqklx 8LFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/JKuBBj5LwwO9H42aVagMv8ehiafwJfMvZrSibWN+A8=; b=Z3jakimDZlZ7ndlExlK3+UusLuqOeFSMUA3PvwFn9JRjydwIEHy68yx56nXGyiz9Cg L7d/HXNh3NL1OSIxxa6/oqinGvwjy1qudh0Q5ahC4r6DAuj4BX3ggMinynkhAvU6DehE IYWz79U55mXTKe9F6F9ZwToPMowjRXw9UxthnLgLEsKIp+nmm0MQ1bSNDs2lnbmOr/k+ rQOVa/LbOKwYVL2qLFKIC5lsDCysWwrsqCzdRa3nxeoRHhs/WnC4ZaDeiJSGG2jZQdpM Y87GnbxsOk+YiACvvVieuP557BFfHinNx8GMujbxEXHtz9EEfDswuJM9vQxO7XnF+QdG 2IdQ== X-Gm-Message-State: AODbwcCqp2N/yh4CmhbgHVB2+nfMOhz9cpzQC/mtCiwaTKt6ClyP05cb Y0zkU1fkYANP9bBIfEA= X-Received: by 10.84.217.158 with SMTP id p30mr32653129pli.211.1496899605552; Wed, 07 Jun 2017 22:26:45 -0700 (PDT) Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id w3sm6179980pfw.19.2017.06.07.22.26.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 22:26:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Fred Baker In-Reply-To: Date: Wed, 7 Jun 2017 22:26:43 -0700 Cc: Ca By , 6man Content-Transfer-Encoding: quoted-printable Message-Id: <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> To: james woodyatt X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 05:26:48 -0000 On Jun 7, 2017, at 4:42 PM, james woodyatt wrote: > As far as I know, nobody associated with Thread=E2=84=A2 apart from me = is even listening to IETF much less offering anything to say. And the = only thing I=E2=80=99m saying is that IETF should stop pretending that = IPv6/NAT in end site addressing plans is preventable. It=E2=80=99s = inevitable. That's not LACNIC's experience. They have been testing to see what the = real story is - put an ad in a web page that accesses a STUN server, and = reports whether the addresses are the same or different. What they find = is that, in Latin America, IPv4 hosts have a 94% probability of being = behind a NAT, but IPv6 hosts have only a 0.6% probability. Just saying... Last I checked data trumps opinion. https://natmeter.labs.lacnic.net/= From nobody Thu Jun 8 00:20:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95695127868 for ; Thu, 8 Jun 2017 00:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R395oKcxntLI for ; Thu, 8 Jun 2017 00:20:06 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455E7120725 for ; Thu, 8 Jun 2017 00:20:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 751B81BC37 for ; Thu, 8 Jun 2017 07:19:42 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> Date: Thu, 8 Jun 2017 08:19:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> To: 6man X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 07:20:09 -0000 Fred Baker wrote: >=20 > On Jun 7, 2017, at 4:42 PM, james woodyatt wrote: >> As far as I know, nobody associated with Thread=99 apart from me is = even listening to IETF much less offering anything to say. And the only = thing I=92m saying is that IETF should stop pretending that IPv6/NAT in = end site addressing plans is preventable. It=92s inevitable. >=20 > That's not LACNIC's experience. They have been testing to see what the = real story is - put an ad in a web page that accesses a STUN server, and = reports whether the addresses are the same or different. What they find = is that, in Latin America, IPv4 hosts have a 94% probability of being = behind a NAT, but IPv6 hosts have only a 0.6% probability. >=20 > Just saying... Last I checked data trumps opinion. Well said. I also can't see how anything good can come of an attitude that "people = will do it, so lets drop any standards/best practice statements saying = it shouldn't be done". Taking that to an extreme, you could say that = [CG]NAT solves the IPv4 addressing problem so why do IPv6 at all ! I can well believe that most IPv4 traffic involves NAT. NAT is the = band-aid that's kept IPv4 going for the last decade or two, and without = it, most users would not get online at all. As others have said, there's no need for any form of address translation = in IPv6 **other than due to operator shenanigans**. If there are = established standards that say "thou shalt do xxx" and "thou shalt not = do yyy" then there is something for customers to beat up the more = idiotic service providers and give them some incentive to fix things. It = might help if software developers, instead of spending time on = workarounds, simply (or at least, start with) put up a warning to the = user that their IPv6 network is broken according to RFCblah and only = then offer to carry on with a "best effort" attempt to work around it. If support forums for packages have threads which come down to "complain = to your ISP that they don't comply with RFCblah" then that will get a = support loading for the ISP that the bean counters will see as a cost = they can remove. Ie, make it more expensive for them to try the sort of = tricks (like "you only get a nobbled IP allocation unless you pay us = business rates") so there's a commercial incentive for them to do the = right thing. My very limited experience with ISP provided IPv6 is that so far, what = I've seen is sensible allocations (eg a /56 for a home user). If the = majority do the right thing, then the exceptions can stand out and get a = reputation for "broken". I know in the real world there will be cases = where there's an effective monopoly (for some group of users) allowing = the ISP to do what they want, but that's not an excuse to just throw in = the towel and give the rest carte blanch. From nobody Thu Jun 8 03:27:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F4512EA53 for ; Thu, 8 Jun 2017 03:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypoGjh1_EKcI for ; Thu, 8 Jun 2017 03:27:22 -0700 (PDT) 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 66AA512E91F for ; Thu, 8 Jun 2017 03:27:12 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local ([194.88.241.230]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v58AR3mb005034 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jun 2017 11:27:04 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.230] claimed to be crumpet.local Message-ID: <59392678.1080000@foobar.org> Date: Thu, 08 Jun 2017 11:27:04 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.14 (Macintosh/20170515) MIME-Version: 1.0 To: Mark Smith CC: 6man WG Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 10:27:24 -0000 Mark Smith wrote: > Large addresses can be of value in infrastructure addressing too. If a > network operator wants to significantly mitigate if not prevent an > attack such as a BGP listener TCP SYN attack from the Internet, they > can hide the router's interface address somewhere inside a /64 so that > the attacker can't find it via unsolicited inbound probing. this is a non argument and obscure addresses are of no value to network operators: 1. most routers will answer traceroute probes, so it's trivial to find out the address of a bgp-enabled router. 2. if you are serious about protecting infrastructure, you install infrastructure ACLs which actually fix the problem. Nick From nobody Thu Jun 8 04:17:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B586F12DFDB for ; Thu, 8 Jun 2017 04:17:11 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RNjmPvJWk2p for ; Thu, 8 Jun 2017 04:17:10 -0700 (PDT) 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 2E91C12EA8C for ; Thu, 8 Jun 2017 04:17:09 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id p62so15609226vkp.0 for ; Thu, 08 Jun 2017 04:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mlE99fXxFPLxClYl91abXOCggsLsCpgRXVYumLFzmrk=; b=Q0JTPtup/EJE4nGKkSV+Lc9MDpia11o9RzyBfVbo9P+ikOg5ZP1weT1fKU136ywEXA 7eTlr2162ScLbBPgEM5ANYbey1EHFMkIox/ZpOWhfTSGYhgiKZEkfUwKIY4s1+Wvkmsm miXB3UNV5/dKockDD1xRmtUqVv5FpcE+Jn9XJ9T10cv911ErRi0ndGB5uSvNc5XugJVM 7+hbysIyFpfL93+ZYX42xzhHsdYaQmhFntS5rgzcGTVVy2dI8aQThEmctdZLb7y3Ouye vHxRNWJfDdayGf83D85D2zd6WjmyBh3ulzymh5i+tOYeuhd0KIrph36LwQukL68nqvGb OLCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mlE99fXxFPLxClYl91abXOCggsLsCpgRXVYumLFzmrk=; b=CCsbgzo3AnaJYHTs85S1oAL4QXxcp4LQRrAwuK+Wg7eZa2SdA4Xr2AbGLeVBu+GIcF b+KkGEE1knv9xRT3uUE3Kd7FXln5HjgwKm7rjyNzEuviu6e8AZkvjzYRKiIIiKEBvYv0 5GxVcY3dII4DnAC+vC8CKoczhZABya/M+byIsEBjs0itdkaI5eVGLln+ETFbNYN8/XVU Y51SlxdxsoOutzp++9rWqLn6QxJx1UROkVnd7AaUCC86X7lMEpSsn7zR4VSDu1cZwt/c /U7ChPLy6k3X1B8sbZs0cdYLIltta085VptN3Y02dg5lKaVretcF2nLtBt1QC3Ytel80 eJug== X-Gm-Message-State: AODbwcC+Wsia5tYWp7LZHVkJqo7myJl2zff5EzBHMqKmqOgB0274pFLr XR0khR9cJ1MbzqOkivUkugiCzgYhFtDc X-Received: by 10.31.129.17 with SMTP id c17mr12088050vkd.36.1496920628288; Thu, 08 Jun 2017 04:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.67 with HTTP; Thu, 8 Jun 2017 04:16:37 -0700 (PDT) In-Reply-To: <59392678.1080000@foobar.org> References: <59392678.1080000@foobar.org> From: Mark Smith Date: Thu, 8 Jun 2017 21:16:37 +1000 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Nick Hilliard Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 11:17:12 -0000 On 8 June 2017 at 20:27, Nick Hilliard wrote: > Mark Smith wrote: >> Large addresses can be of value in infrastructure addressing too. If a >> network operator wants to significantly mitigate if not prevent an >> attack such as a BGP listener TCP SYN attack from the Internet, they >> can hide the router's interface address somewhere inside a /64 so that >> the attacker can't find it via unsolicited inbound probing. > > this is a non argument and obscure addresses are of no value to network > operators: > Next you'll say that stripes have no value to zebras and camouflage has no value to armies. > 1. most routers will answer traceroute probes, so it's trivial to find > out the address of a bgp-enabled router. > > 2. if you are serious about protecting infrastructure, you install > infrastructure ACLs which actually fix the problem. > > Nick > From nobody Thu Jun 8 04:31:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E737112E04F for ; Thu, 8 Jun 2017 04:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNkUCPgZaxp0 for ; Thu, 8 Jun 2017 04:31:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8EB12DFDB for ; Thu, 8 Jun 2017 04:31:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dIveo-0000EPC; Thu, 8 Jun 2017 13:31:18 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <59392678.1080000@foobar.org> In-reply-to: Your message of "Thu, 8 Jun 2017 21:16:37 +1000 ." Date: Thu, 08 Jun 2017 13:31:17 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 11:31:24 -0000 >Next you'll say that stripes have no value to zebras and camouflage >has no value to armies. I find this a bizar discussion. We already have plenty of options for providing nodes with addresses that have lots of randomness. Some operators don't care about that feature and would like to be able to use those bits elsewhere. So if you want to make it hard to discover a node, assign a /64 to a link and use put a random value in the remaining bits. That should not proclude other people from using /120 prefixes and numbering nodes 1, 2, 3. From nobody Thu Jun 8 04:32:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D312EAA5 for ; Thu, 8 Jun 2017 04:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXtnfcn3Q_Zl for ; Thu, 8 Jun 2017 04:32:04 -0700 (PDT) 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 F1A1D12EAA7 for ; Thu, 8 Jun 2017 04:32:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 54B08A5; Thu, 8 Jun 2017 13:32:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1496921521; bh=2mC7vCtVj3CVisN7KoKNI2Sh9rPVDbl4CvHsE3Ot7ck=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Xx095teES8RhN0ojLLb+pO/Ylwbu+XiNQ5zezJvsLmZ5o0NJq6AvrBT1ulM8D8OcT b2NUi6vqqnSUguaS2GpdadpAZXcSteueJbFsQtkrIN8DCie/5i/CpIgzbBRyyveRFg 7k2ysg1P+Rrs8/fe1VjyF+WTAUMqM4hJtmEHuUFg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3D5EFA4; Thu, 8 Jun 2017 13:32:01 +0200 (CEST) Date: Thu, 8 Jun 2017 13:32:01 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt cc: 6man Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) In-Reply-To: <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> Message-ID: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1493922853-1496921521=:17963" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 11:32:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1493922853-1496921521=:17963 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 7 Jun 2017, james woodyatt wrote: > mesh. Use of IPv6/NAT allows the border router to make an entire > Threadâ„¢ mesh reach the public Internet via the one stable IPv6 address > that is reliably available on all residential networks with IPv6 > providers. Why does it have to be just one? Why can't it be one per thread device, so you can do 1:1 NAT and not PAT? I know we have discussed this before. Why was DHCPv6-PD out of scope? Because you needed stable addresses internally? Did you decide to use ULA? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1493922853-1496921521=:17963-- From nobody Thu Jun 8 04:35:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBB312EAA4 for ; Thu, 8 Jun 2017 04:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5JUUHP9Tpkc for ; Thu, 8 Jun 2017 04:35:40 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F82612E04F for ; Thu, 8 Jun 2017 04:35:40 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id p62so15760923vkp.0 for ; Thu, 08 Jun 2017 04:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9c4fxeeZ7PMu7XYktFGjy9x9WlebxGhWILAi48ld4R0=; b=UlAqYFMw9NlAoKkNE7cvrWpCSHoHTM50gR/mc8ZtOdLJ1WDgH051nMgZrFh8crVnFP MVy9fjf4FCJgxjOA4ZvbcyAAzEXQM0T7m2pvmN/bVUC+wIt/rOpF6Uw4C2x1Bub/koqA nHCbVKnh9k3nfSckuwSh+Dx+6y+96byG2cerix3/srctXuVITZ1AgTgBa/CXYhDqj8Rk avRqSbwXL0z7W90YFk3hDELYl+xCecoK1nfioLJEl78lfenOebwXBiAFvNvwnqINhK2a DjDTkmb6RzfF4gjCKEfIWS3dd2zZsMIZNWmpnnPMTIe9BM4krJbqiHDBBvWOviycA/VL YsPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9c4fxeeZ7PMu7XYktFGjy9x9WlebxGhWILAi48ld4R0=; b=doRBAO4dDWQpaGq/Wi11o4GYPvu+VFNLI4pwTqP8bMdkk/K5oUR2L3En9cYzWcb3Rc IzZP3Qv7wOKCPjvsjL+YRvphJ0H+pFBsnh8Il0+bHwNATHCOmnRBjWYsSy4+9yXZ/L5I VmTe/zB+GoSqPXSGsofIkZcUKxWIRmqrngF8px+m9gdN/UlUUZs/iQZPfm33WAe3mInS GFabb5IoEqRYYKJWPNRl3SbvKWsVEtpevF2+Si8vB8yQLlY8Q83d+rNE7gID1mxY81YA Kd2Rb+boRMZE91XS/Z1PZIJ3AxaLuKwYF2gdkkqvAE+qjsKGplN8qGzjWLvZPirIRFqo ie4Q== X-Gm-Message-State: AODbwcDIZmKeFaepFcS7d0uwozDerHxduFNHUr0376LKn6yL63SOVQKl h5AJ56AlDU2OJIayU4SY5y2uec9xniYI X-Received: by 10.31.64.130 with SMTP id n124mr7060110vka.44.1496921739051; Thu, 08 Jun 2017 04:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 04:35:17 -0700 (PDT) In-Reply-To: <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> From: Lorenzo Colitti Date: Thu, 8 Jun 2017 20:35:17 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: james woodyatt Cc: 6man Content-Type: multipart/alternative; boundary="001a114479a684302c0551714036" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 11:35:42 -0000 --001a114479a684302c0551714036 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 8, 2017 at 3:41 AM, james woodyatt wrote: > Thread=E2=84=A2 1.1 doesn=E2=80=99t even use RFC 4861 much less RFC 6775.= A proxy for RFC > 4861 at the Thread=E2=84=A2 1.1 border router would require DAD and NUD t= o be > translated into prohibitively expensive multicast floods into the mesh. U= se > of IPv6/NAT allows the border router to make an entire Thread=E2=84=A2 me= sh reach > the public Internet via the one stable IPv6 address that is reliably > available on all residential networks with IPv6 providers. > If thread doesn't use RFC 4861, then it probably uses address registration? If so it's trivial: have the BR do the work of replying to DAD and NS, for only the addresses that exist in the mesh. > For years, we have been hoping that HOMENET would address the basic > problem here, but now that it's clear the forthcoming update to RFC 7084 > will not recommend adoption of the HOMENET protocol suite in IPv6 CPE > residential gateways, Thread=E2=84=A2 has no other option than to recomme= nd > IPv6/NAT to cope with operational reality. > That sounds like a false dichotomy to me. --001a114479a684302c0551714036 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 8, 2017 at 3:41 AM, james woodyatt <jhw@google.com> wro= te:
<= div>
Thread=E2=84=A2 1= .1 doesn=E2=80=99t even use RFC 4861 much less RFC 6775. A proxy for RFC 48= 61 at the Thread=E2=84=A2 1.1 border router would require DAD and NUD to be= translated into prohibitively expensive multicast floods into the mesh. Us= e of IPv6/NAT allows the border router to make an entire Thread=E2=84=A2 me= sh reach the public Internet via the one stable IPv6 address that is reliab= ly available on all residential networks with IPv6 providers.
<= /div>

If thread doesn't use RFC 4= 861, then it probably uses address registration? If so it's trivial: ha= ve the BR do the work of replying to DAD and NS, for only the addresses tha= t exist in the mesh.
=C2=A0
<= div style=3D"word-wrap:break-word">
For years, we have been hoping that HOMENET would addres= s the basic problem here, but now that it's clear the forthcoming updat= e to RFC 7084 will not recommend adoption of the HOMENET protocol suite in = IPv6 CPE residential gateways, Thread=E2=84=A2 has no other option than to = recommend IPv6/NAT to cope with operational reality.

That sounds like a false dichotomy to me= .
--001a114479a684302c0551714036-- From nobody Thu Jun 8 04:42:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACE4129405 for ; Thu, 8 Jun 2017 04:42:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C46cVeTnbEE1 for ; Thu, 8 Jun 2017 04:42:11 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 D95A5124281 for ; Thu, 8 Jun 2017 04:42:10 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id m31so18456783uam.1 for ; Thu, 08 Jun 2017 04:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8cXlqbm0SphUnMr0Dhwu2yvorlRjc10YDVM042WXLWI=; b=r3wLsjmeYZxL6ZOvLLeS3/0gjaUdRKjemB2n0vFKOCbV0VJMKwkyxC7/SpZ/pZA7lE FwUz5GALxC+Nd/wPv4D/+H47qvFzqP3ephzPuyKyV7xxFPRhl8y83PLw2F4NfBsSY79J oXOaPdf36RBS/CEkMK6p/XZSaRKmU4Ux044bJh0r3D3Dj1aCDYF+hvtYQcmIZat237bM zK7iGdrJUkr1vXgoh46XKUBEU2GXaSDBtxyGHrlehbA6A5PgiPDo1lsS0sc2/lRfQSw5 xglur0JZc9M8Amu6/dqbNqeeCr0HuyYpziVIyZXz8VUtKgCmmmRrUI1YZpPuUlBl3Q04 yPRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8cXlqbm0SphUnMr0Dhwu2yvorlRjc10YDVM042WXLWI=; b=g3t+qJJmYVfvPFErSOZQYv6d6cE3T1Bjpdsr9RhqSG0y45EzXzoz2FrPWDXGj9TTkF pe91kf27MmsODiL2+E36m6M4+BlxeXcXdIdWD7gEtkN+PPEbXceVIPbVBfiRokKSgiXE H2FW8vIspROBLCSubUHxwSw5glGFfTgHbge2qwvDANOGb1WRDj5oDksPinMteLSVupYR lqhMaE0CPiVrfaKO55If4scSg5qwCyhjTJlaOW5oyMP+t1jhjxw+GpGww/fKd+0p5UTp CU/9IKRFgBA9s72yJEN5+2LqyULmQz4M7smPXS/lDhTTQte8ek8UEth+TD+gcyKgAZSx q8/A== X-Gm-Message-State: AODbwcBMGnzqyo46vObZrdeaQjMJrDXDY5ouLjqUQ++EdBzDUeOZb2ys rvjGC0c52YH/9oPszGjFwoIPgiGwX318 X-Received: by 10.176.95.217 with SMTP id g25mr15147569uaj.71.1496922129834; Thu, 08 Jun 2017 04:42:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 04:41:49 -0700 (PDT) In-Reply-To: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Lorenzo Colitti Date: Thu, 8 Jun 2017 20:41:49 +0900 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fernando Gont Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="089e08204960ce8f910551715733" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 11:42:12 -0000 --089e08204960ce8f910551715733 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont wrote: > Measurements indicate that when folks do manual configuration, they do > "low-byte" addresses -- i.e., no matter the prefix length, they just set > the IID to all zeroes except for the last byte or so. -- having "easy to > remember" addresses seems to be the goal in that case. > I don't think you have measurements that prove this. You almost certainly can make a statement that there are a number of low-entropy addresses where the top bytes are all zeros, and that those are *likely* statically configured. I don't think you can prove that the high-entropy addresses with lots of nonzero bits are NOT manually configured. As for "last byte" - using the last 32 bits of the address to store the IPv4 address seems pretty common too. Akamai has published data about this, I believe. --089e08204960ce8f910551715733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 7, 2017 at 9:03 PM, Fernando Gont <fgont@si6networks.com&g= t; wrote:
Measurements indicate th= at when folks do manual configuration, they do
"low-byte" addresses -- i.e., no matter the prefix length, they j= ust set
the IID to all zeroes except for the last byte or so. -- having "easy = to
remember" addresses seems to be the goal in that case.

I don't think you have measurements that prove thi= s. You almost certainly can make a statement that there are a number of low= -entropy addresses where the top bytes are all zeros, and that those are *l= ikely* statically configured. I don't think you can prove that the high= -entropy addresses with lots of nonzero bits are NOT manually configured.
=C2=A0
As for "last byte" - using the last 32 = bits of the address to store the IPv4 address seems pretty common too. Akam= ai has published data about this, I believe.
--089e08204960ce8f910551715733-- From nobody Thu Jun 8 04:56:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EAE127078 for ; Thu, 8 Jun 2017 04:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrNkp158NZQl for ; Thu, 8 Jun 2017 04:56:37 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9821201F2 for ; Thu, 8 Jun 2017 04:56:37 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id g66so15887159vki.1 for ; Thu, 08 Jun 2017 04:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=COM3DiuUFtrX6Q6zmjGBUe7c1Fr+a8hypV9Vd/h+5kU=; b=fl/4SaZNrddlle7qxzGSOCEapWL+QIfagBg52Zg3J3YL7TJ+gjJd0LL4kq6+eOob4a K9ETufDsE+YfFH6mhH0LCn7llr8QKlCs1NmfLr9r4h/VHx8UN0mrZlyVYHiLOuud76dN vDg470xw7qodRg5hN+I4IQsyGNbO+LoDM6fX8dxMbigl7jG1E51mPP2+Rk0fiYKbTOzR hnGhElSpmDk5KnO25lb5nKniEhMYzmoUQn0CD4jzpoMH2xRVPfF/5nhBuCqy1eI8yHBH fibdO3ZrA1RNKakMLWYWO2H9PdEb2wUN/sDAj9LnEFf5xtxRjW8NT5riUqfIh9ZtdYrx 2qnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=COM3DiuUFtrX6Q6zmjGBUe7c1Fr+a8hypV9Vd/h+5kU=; b=F+4ID3Q5ezJM19XmDFSqEfTPTAPwtP/MftgmuBn+9i6DxY9L5GUCWAKEyFLHS36TQv jvBapstrORme+YNZMf9PuEiYvmba0clEk2jjAgevra1nKmdYEYECVdnzxfdK162+zmm/ ixupAVSkwcKSDCvK/VcckhmoPb8pTjAx0FCBlMWdwPJiqIqPFcn0tnETdHaR7o8qNlap UXvfM5VQNKBSuGSh6ez6d0reQiepurr/4hl5CrexJtm8O4hqV/v+Xcfm5Tymth3bscF+ LI688Gf2F53tDGWggD71aC988vZISJnVrpwG+bdMMoNXb37vOHUDmH5gSkMZNL52aBqw 59YQ== X-Gm-Message-State: AODbwcCo+W2RUcsbdU+A44951RpLNA1twROhAFI/AsLz1NB18AQa1GrK vCpfsniBfhoOnKuYRCqZWTufThXUeGys X-Received: by 10.31.170.2 with SMTP id t2mr727231vke.100.1496922996581; Thu, 08 Jun 2017 04:56:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 04:56:15 -0700 (PDT) In-Reply-To: <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> From: Lorenzo Colitti Date: Thu, 8 Jun 2017 20:56:15 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Ca By , Philip Homburg , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a11430a727853220551718b0c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 11:56:39 -0000 --001a11430a727853220551718b0c Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 8:24 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > "Interface Identifiers should be 64 bit long except > when the addresses are manually configured, > In order to publish that text we need to agree on what it means. Can you explain the semantics of the the interface identifier of a manually configured IPv6 address? What are they used for? Note: the semantics are *not* the same as the prefix length of an IPv4 address. The prefix length of an IPv4 address implies that that subnet is reachable on, but the IID implies nothing about reachability. --001a11430a727853220551718b0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 7, 2017 at 8:24 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
"Interface Identifiers should be 64 = bit long except
when the addresses are manually configured,
In order to publish that text we need to agree on what it means= . Can you explain the semantics of the the interface identifier of a manual= ly configured IPv6 address? What are they used for?

Note: the semantics are *not* the same as the prefix length of an IPv4 ad= dress. The prefix length of an IPv4 address implies that that subnet is rea= chable on, but the IID implies nothing about reachability.
--001a11430a727853220551718b0c-- From nobody Thu Jun 8 05:10:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACB4127078 for ; Thu, 8 Jun 2017 05:10:53 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSs11pcV-cz0 for ; Thu, 8 Jun 2017 05:10:51 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id B4025126C89 for ; Thu, 8 Jun 2017 05:10:51 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 08 Jun 2017 12:10:51 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AE731D788E; Thu, 8 Jun 2017 05:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=tmD3TLxhpn8O2p6OKJ/3O+KeYVA=; b= bkkiCXbGtwu/yEINDUr2mCF/tCIt+G6b4htZQOm48uce1El/gCHuRom+gFg3t286 sT/oW8Luj9/trbrKUDyr4uKh7in7grx4EGjC5pJRqz4YtwIzQRyGMAAdpilEClaa FeKSdPgR9XzN7c7oaTV+rPJ7sxC4Y+AU/6VjQB0Vf3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=qQ+TSytKtdtGGBJBEg6hQbH 336t6ZV7mXx7S1JKBuwWDwxEcY/sYsocfLs1CDudXawIbCqrIRKo2KlSUYqb0t7n mMejAYMMw1AiVXu2YQwdp1sSp17b8LzKrMXrZQtagspzLaHed9Id3nFiiFW/RGMb SYnaHqGg3jeT8zZphLrg= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 409C6D788B; Thu, 8 Jun 2017 05:10:50 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4F881CF4DD58; Thu, 8 Jun 2017 14:10:48 +0200 (CEST) From: otroan@employees.org Message-Id: <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_CCCBAFFC-EFE6-4DBC-9F50-C8EAA717F8FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Thu, 8 Jun 2017 14:10:47 +0200 In-Reply-To: Cc: Brian E Carpenter , 6man WG To: Lorenzo Colitti References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 12:10:53 -0000 --Apple-Mail=_CCCBAFFC-EFE6-4DBC-9F50-C8EAA717F8FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > "Interface Identifiers should be 64 bit long except > when the addresses are manually configured, >=20 > In order to publish that text we need to agree on what it means. Can = you explain the semantics of the the interface identifier of a manually = configured IPv6 address? What are they used for? >=20 > Note: the semantics are *not* the same as the prefix length of an IPv4 = address. The prefix length of an IPv4 address implies that that subnet = is reachable on, but the IID implies nothing about reachability. I'm not sure I understand your point. RFC4291: IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (for instance, host versus router). At a minimum, a node may consider that unicast addresses (including its own) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+ A slightly sophisticated host (but still rather simple) may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ Ole --Apple-Mail=_CCCBAFFC-EFE6-4DBC-9F50-C8EAA717F8FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZOT7HAAoJEL7aWKiYQt92jbkP/3EqBqYbRzl+UmRYB9wKDZsT svD7SL1vpEzSqWs/s++l3Ff6Il1aNDV+GCc4kMKAdKGEFi9meL/3RAQvS0yxRvIb KUsxZcz+qwS7hkYK+IQ5JzijDI7JwJbvAwne8dMYfrwHeX9oWfQD/lfrTvEY4VXM xV5ClN7ZBZ2tmOEaNK5wZVBzQpjaZ/+UiKyQKHCrEBREqSOYucAEFwjRLosOuf1S /4s0MmFJMvDz5fIrgBqK1651YI2mYsg4FNSaAgrSG+RY+Ab/I/fTcVpn8nao0FSO Zo9QHORts1k4xgSWQXyaWgK+VLh5vkxOOg90stCfQTwI+dbL43VftvLp7akJThbY EAAO7tcEAEb2JtGgHAdXaFMz/u+TOaDll4m6IfRBB2bZxpkMvzICDqCbP/Kfki61 jVcEaH3hfjlIxnSU5HByqqLPEz/o/NmgweC6Nx57JYwqUoYbVTuq+5Apk/4zdt1n tC8wq7poIZAhTNpb0I6OLN0JQsJkLQD698FUdOnnDuOG45Dm3RAFJm4A3BmZcGF7 vHXguYBW+5ZzKOPyhLI8sTsXCNKQGeE7D2sT4eFnZVE8DbQgWXUKtSi9e6xjSYfV XmPer0EE6EsrHup20wUSU3AjHDAHpQ7kbjW7JrxjnNxFWOMEv3K9KzodC/5CXths 5Lf+qZfz+AYluvfgPHT8 =12pM -----END PGP SIGNATURE----- --Apple-Mail=_CCCBAFFC-EFE6-4DBC-9F50-C8EAA717F8FE-- From nobody Thu Jun 8 05:42:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5AB129508 for ; Thu, 8 Jun 2017 05:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yyxQmB82Uva for ; Thu, 8 Jun 2017 05:42:22 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1943126CF6 for ; Thu, 8 Jun 2017 05:42:22 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id g66so16333900vki.1 for ; Thu, 08 Jun 2017 05:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jv2IilCHDV+B4beyvIE6bTQEJaGgOvSJsR53rq4D4EM=; b=czxAw6FHUW1EPtarZdSsJbZhwexYKn2AUKte/0lkuinXwUBI5D5WPemYfhe7NBtuyg XYB7EeCrSZdgxbhd4irdefh0NvkaLWTtTg0NBYYiOsp51XeyWY1M8kn9M3eWR8RnHFbV 34HRe1vmm/tL3vSSViKiNMcG28CGG8ioBAXVyb0xZvuQwC5PChxhLtE9OHqM/LTMNHzh 85AatGzlLQF0DfsAVipSIUAK503Aquosd8N+jA71MLsNULbJRrmIVxkYFY7CiUvqMNkF /jPNdewDStHf+u+avER8S22Rn2ogRRMFX2oyCHhf1v8yx3L+FLjQD4I97GQ1PJYO/EHT Wd2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jv2IilCHDV+B4beyvIE6bTQEJaGgOvSJsR53rq4D4EM=; b=nw/E5ZBbEcWF5Z+MWwjmRBOfSs9mGOxROYCnjbfzLvTu06yefQgqBiFcn0LQVz5I22 kywOOBp5GVPdaBn17fs2U2B2bhinxEKlkWR6sbXYyUAiRlTZWY9pLzlcS+RjNjXXjHsm jcVTTHN//wCnLUdFc2seVOonHkU5fD63IKDmjZgthHm9GiiHR+WL94cX+3LWfh8aqKXn 3jYUlXjCqRnxt6VUUXJlgGhdAEScLK9BK5AP8wl+4+NQFDC9i86HJ666S2m2fLKV5i19 /EXyNmD+kAoRoHZKMO4gJBRvjG5HBj6zqqKlpgH7+w62DrMEwWhxcoZMf4dEH8ceVwB5 48sQ== X-Gm-Message-State: AODbwcAYIWc0yV1b44wmw9mydRw4hBxpWchh+Pn5XNK6R4eE/GGlJMjf RDemng7YpeBLoxQrKAN0Edtg3JFPvuQO X-Received: by 10.31.69.138 with SMTP id s132mr16267140vka.13.1496925741593; Thu, 08 Jun 2017 05:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 05:42:00 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: Lorenzo Colitti Date: Thu, 8 Jun 2017 21:42:00 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: David Farmer Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Job Snijders , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="001a114dd2d215acea0551722ff0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 12:42:24 -0000 --001a114dd2d215acea0551722ff0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 8, 2017 at 12:13 AM, David Farmer wrote: > I think "should be 64" is the correct language, primarily because "must be > 64" has been misinterpreted several times to justify hard coding 64 in IPv6 > implementations, but also it seems like a false imperative. > Currently the standard says "are 64 bits long". Do we need to change that? Can we just say "are 64 bits long except when manually configured"? I think either of these makes it clear 64 bit is the norm, but this should > not enforced by an IPv6 implementations or hard coded in some way. > I have no issue with manual configuration. However, I think IPv6 implementations that don't support manual configuration must be able to reject non-64 bit IIDs, since that is the standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or /123", and those are against BCP 204 (RFC 7934). It's not clear to me whether the signatories of this document care about future IPv6-over-foo documents. They seem to be mostly focused on manual configuration. However, if we want to say that future IPv6-over-foo documents can specify non-64-bit IIDs, then that should require formally updating this document and providing rationale of why the link layer does not allow the network to follow the addressing best practices in BCP 204. --001a114dd2d215acea0551722ff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 8, 2017 at 12:13 AM, David Farmer <farmer@umn.edu> wrot= e:
I think "should be 64" is t= he correct language, primarily because "must be 64" has been misi= nterpreted several times to justify hard coding 64 in IPv6 implementations,= but also it seems like a false imperative.

Currently the standard says "are 64 bits long= ". Do we need to change that? Can we just say "are 64 bits long e= xcept when manually configured"?

I think either of these makes it clear 64 bit is the norm, b= ut this should not enforced by an IPv6 implementations or hard coded in som= e way.=C2=A0

I have= no issue with manual configuration.

However, I th= ink IPv6 implementations that don't support manual configuration must b= e able to reject non-64 bit IIDs, since that is the standard. Saying "= SHOULD be 64 bits long" means they "MAY be /81, /99 or /123"= , and those are against BCP 204 (RFC 7934).=C2=A0

= It's not clear to me whether the signatories of this document care abou= t future IPv6-over-foo documents. They seem to be mostly focused on manual = configuration. However, if we want to say that future IPv6-over-foo documen= ts can specify non-64-bit IIDs, then that should require formally updating = this document and providing rationale of why the link layer does not allow = the network to follow the addressing best practices in BCP 204.
=
--001a114dd2d215acea0551722ff0-- From nobody Thu Jun 8 08:59:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED241293FD for ; Thu, 8 Jun 2017 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVrx8zRBessO for ; Thu, 8 Jun 2017 08:59:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 90272128BA2 for ; Thu, 8 Jun 2017 08:59:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3E08B349315; Thu, 8 Jun 2017 15:59:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 22BAB160041; Thu, 8 Jun 2017 15:59:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D06716006A; Thu, 8 Jun 2017 15:59:19 +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 JSN5PW8Byz6J; Thu, 8 Jun 2017 15:59:18 +0000 (UTC) Received: from jmb.localhost (c-50-156-82-172.hsd1.ca.comcast.net [50.156.82.172]) by zmx1.isc.org (Postfix) with ESMTPSA id AF6D0160041; Thu, 8 Jun 2017 15:59:18 +0000 (UTC) Date: Thu, 08 Jun 2017 08:59:18 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Lorenzo Colitti Cc: Brian E Carpenter , IETF IPv6 Mailing List Subject: Re: draft-bourbaki-6man-classless-ipv6-00 In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:59:26 -0000 At Thu, 8 Jun 2017 20:56:15 +0900, Lorenzo Colitti wrote: > > "Interface Identifiers should be 64 bit long except > > when the addresses are manually configured, > > In order to publish that text we need to agree on what it means. Can you > explain the semantics of the the interface identifier of a manually > configured IPv6 address? What are they used for? Right, this text is actually a bit awkward in that sense. I think this message is a good answer to this question: https://www.ietf.org/mail-archive/web/ipv6/current/msg27573.html "only relevant to SLAAC" may be too strong from an architectural point of view, but at least that's today's reality. So "except when the addresses are manually configured" actually doesn't make much sense. I was aware of that oddity too, but I didn't go into this point so we could focus on whether we can at least agree on a more higher level point, i.e., if we can agree that manual configuration is (effectively) an exception of the IID length woe while 64 is acceptable for SLAAC (unless other standard protocol overturns it). Now that we are on this detail, this is what I would envision as something that this draft might actually have wanted to say and that most of us can hopefully agree on: Interface Identifiers must be 64 bit except for addresses that start with the binary value 000 and unless a different value is defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. Note that the separation between the interface identifier and the subnet prefix is not important unless the address is configured using stateless address autoconfiguration [RFC4862]. So, for example, this constraint on the length of interface identifiers is irrelevant to manually configured addresses in practice. IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198], and so is on-link determination ([RFC5942], [I-D.jinmei-6man-prefix-clarify]). In particular, the fact that the "subnet prefix" length of certain addresses is 64 in terms of the addressing architecture is independent from whether addresses that match this prefix are considered to be on-link. For example, [RFC6164] standardises 127 bit prefixes for on-link determination on inter-router point-to-point links. This is not contradictory to that an address used in this link may have a 64-bit interface identifier (and a 64-bit subnet prefix as a result). Notes: - I've replaced "should" with "must" in the first sentence as discussed before, as I thought this is critical for some group and is still acceptable for other group with the additional conditions ("except" and "unless"). - Brian might want to be more explicit about the relationship between this and ipv6-over-foo specs, but I didn't do that for now. If we can agree on the sense of the text it will be a relatively straightforward update. - we may also want to emphasize that an implementation must not blindly hardcode 64 either as the length of interface identifiers or as on-link prefix length. again, as long as we can agree on the general sense it will be a trivial update. -- JINMEI, Tatuya From nobody Thu Jun 8 09:31:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBD12943D for ; Thu, 8 Jun 2017 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5snrN3QTrTU9 for ; Thu, 8 Jun 2017 09:31:03 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BA71293F4 for ; Thu, 8 Jun 2017 09:31:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 759BF1BC37 for ; Thu, 8 Jun 2017 16:30:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: Date: Thu, 8 Jun 2017 17:30:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06B0C516-1F46-4279-8F43-A83F8540A8CF@thehobsons.co.uk> References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 16:31:05 -0000 Lorenzo Colitti wrote: > As for "last byte" - using the last 32 bits of the address to store = the IPv4 address seems pretty common too. Akamai has published data = about this, I believe. That's an understandable approach to take - in a transitional = environment (ie almost all of them these days) it's going to make it = easier to remember and type addresses. On that, it's not unreasonable to assume that a lot of operators might = be deliberately using "lots of zeroes" simply to make it easier for = humans to work with stuff. Eg, it's a lot less typing to type (say) = 2001:470:7f09:cbb::57 than 2001:470:7f09:cbb:756e:20d6:e7f6:a544 ! In = environments where the DNS just isn't done right, which in my experience = is the vast majority of small/medium business networks*, this is even = more important. * Yes, this irritates me, but I've met few network admins below "big = corporate" level who seem to care about DNS. It generally seems to come = down to "the Windows AD controller does all that's needed" in making = servers accessible to clients. From nobody Thu Jun 8 10:25:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC441293D9 for ; Thu, 8 Jun 2017 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4TJzmjpl2hT for ; Thu, 8 Jun 2017 10:25:49 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29F31286D6 for ; Thu, 8 Jun 2017 10:25:49 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id f185so18161470pgc.0 for ; Thu, 08 Jun 2017 10:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DLLhhjlRN5BPdvtLFbswPm5Ps7v1AFK3Nj4K7VCXekk=; b=AnbeXU0cBTilHLO6n3en54mM9Ybge68knXgY2kjIJLPRT9xGF1j3fvUV69fyuGZyMw 81hafpgmpOndcsH4p/aWVajWI0Yf485QrvFCacEPXe68XTFctbwvQMnqwdfXryIc+nEf 1bDkhxgK/zlOLYUVHrVYkdegyT5GGBs32vlE8y84NRJX7K+fXzawjTz63IRSO/KqnCES fOtyqugRWiQ4/RP7cLdUPVTHyc2lok3Rx5jvSCUhgfDgKEB8F0KKCDxKOm6qcOTVk0pA lgswmH6+henDGz31ptzZkZ+7eszCym1/Hq9Z14x5m1ZMsjIkdJUoEFruQ+pXgtcB1XBa nGZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DLLhhjlRN5BPdvtLFbswPm5Ps7v1AFK3Nj4K7VCXekk=; b=jiL8C5n5uv/zZpM0sOXZuAMN0HqHggrlCPzW03QqfZdMdsWI6M3xHtfRb6oni/nFMQ W/5H1Cy22UTWxaHTXJ8BpFjBy8yUgr6ksIzZ0pKWt1LmodNWZKoXdIAlMAJ6XVhc1y+N z5lXhmtffzuMrZMmoJUn+K7vDMqmwVU1512m8m6DFanlHpUDuEwfrzjtNuxSJ/jMhy7y rWYyaSnAnOAdKFQMC3D7xbsc//NEIWmjZifvGiTwvPVRN/dbY9M8pZ6pKUfX4T6crL88 XH/Lk0ZCRTtRUa2NRnahs6UyGq0xeg6DgxDZDprvNWjbZSw8u9+KcmUfpmbxfa4HKmky o1eA== X-Gm-Message-State: AODbwcBsF/AV73k9YKe8iUdvlXARh7dxJ+BehHnU0oCPSjLuF+EekmLy uzEMktJ6CBNzAyqLnPq6wQ== X-Received: by 10.98.39.2 with SMTP id n2mr27140009pfn.182.1496942749160; Thu, 08 Jun 2017 10:25:49 -0700 (PDT) Received: from [10.151.75.170] (mobile-166-177-251-145.mycingular.net. [166.177.251.145]) by smtp.gmail.com with ESMTPSA id n4sm374103pgt.3.2017.06.08.10.25.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 10:25:48 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0601BA0D-35AE-4B4F-8335-12ADB6D5E6A6 Mime-Version: 1.0 (1.0) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: james woodyatt X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 8 Jun 2017 10:25:47 -0700 Cc: 6man Content-Transfer-Encoding: 7bit Message-Id: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> To: Lorenzo Colitti Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 17:25:51 -0000 --Apple-Mail-0601BA0D-35AE-4B4F-8335-12ADB6D5E6A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 8, 2017, at 04:35, Lorenzo Colitti wrote: >=20 > If thread doesn't use RFC 4861, then it probably uses address registration= ? If so it's trivia[...] It does not. The problem is not trivial. You're invited to have a look at the Thread 1.1 mesh protocol. If you think y= ou can devise a power conservative method for making a Thread 1.1 border rou= ter efficiently join a home Wi-fi network using IPv6 Neighbor Discovery, the= n I'm sure the Thread engineering team would be happy to consider your ideas= . =E2=80=94sent from my phone= --Apple-Mail-0601BA0D-35AE-4B4F-8335-12ADB6D5E6A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

= --Apple-Mail-0601BA0D-35AE-4B4F-8335-12ADB6D5E6A6-- From nobody Thu Jun 8 15:21:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B21127867 for ; Thu, 8 Jun 2017 15:21:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y17vbIlVfdeH for ; Thu, 8 Jun 2017 15:20:59 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361B8126E64 for ; Thu, 8 Jun 2017 15:20:59 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.165.153.76]) (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 78D8483391; Fri, 9 Jun 2017 00:21:13 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Fernando Gont Message-ID: Date: Thu, 8 Jun 2017 20:17:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 22:21:01 -0000 On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: > On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont > wrote: > > Measurements indicate that when folks do manual configuration, they do > "low-byte" addresses -- i.e., no matter the prefix length, they just set > the IID to all zeroes except for the last byte or so. -- having "easy to > remember" addresses seems to be the goal in that case. > > > I don't think you have measurements that prove this. You almost > certainly can make a statement that there are a number of low-entropy > addresses where the top bytes are all zeros, and that those are *likely* > statically configured. Are you assuming that such low-byte addresses are the result of automatic configuration? How come? > I don't think you can prove that the high-entropy > addresses with lots of nonzero bits are NOT manually configured. That's the point: there are not a lot of high-entropy addresses. See the measurements in RFC7707. > As for "last byte" - using the last 32 bits of the address to store the > IPv4 address seems pretty common too. Akamai has published data about > this, I believe. we have similar measurements in RFC7707. However, using the low-order 32 bits in such way is equivalent to simply setting the low byte of the addresses. The point is that when employing manual configuration, addresses always have small entropy. Hence employing a lot of bits doesn't buy much, because folks simply do not use them for additional entropy. 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 Jun 8 17:20:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5E8128CD5 for ; Thu, 8 Jun 2017 17:20:25 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPa0eTezWr4j for ; Thu, 8 Jun 2017 17:20:23 -0700 (PDT) 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 89AD1129B69 for ; Thu, 8 Jun 2017 17:20:23 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id p85so22940523vkd.3 for ; Thu, 08 Jun 2017 17:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jthm0fqH7M+4PJMjSXuTDLOEvSN87MmhtN9dehsCuYU=; b=WmiuCbfk3f7YxuXsP3a5o7g5kbvb1tlLzG/3WRJ8ExRbKePqZgIXAmvG6qISVHxTIu LE9UNhin+rZwCLewwfXycgKm2sAnfnKClEa3Qud5wGEXy6MzGR5bcvSS9UGsRogdUiwk q+Vp92Rg8iuw+ZVc97pThWmXoTWnZx9BN96VbC84kaT+okStCxiDK5w7xKUQeuQIn0jq gMj5+T/1amIg2yZB5bHo5f+8MOGKECLTnfypG/ujy1dVwGF4xU2g2CjQY8RANK/OJqtc 40vtm1taWRaV/SGABptrOWKyeApuXarwyn4ndB3KfcX/oCSDR9HfzsO2bceT75AkqT5M H36g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jthm0fqH7M+4PJMjSXuTDLOEvSN87MmhtN9dehsCuYU=; b=UjK6C8cxx/2am7TbWdVEahOEkzMFMZvp4KdhhGGx8SLZhazZ43PBU6aZOWfTXwg33b wEAjYchubGg7R6K1LKs+vK1qS4YHJ3m925Id4TemdUSXWB/0K1yN11hbXAfU+xsPFClg ekdYS+wBjh52BJAZDXpz/XL1Hk8NHrZot2nBSekV3WQkSjLKGsyS1EoKaaDwWWSRcPFo xj8Z3W1xggRtLXbMBZmrJ5R5ej1xreqquNDDJjFdxy2JTPdtmgiIhccGYWHBbR4+5+OH SbMJ8UQIfakss+VN86m1vMg51FCFmqn38abjDLO5Ikw0jZqOt2xD8fdVLAIpQMG1obRK NNjw== X-Gm-Message-State: AODbwcCjg3i+r0bjHLpCeJ8fdgz0cuJzweK+SkNfI3owJ36JwPDPylUr Ssbd73yAQKJsJM5sMAynuKDEduA5+y8V X-Received: by 10.31.210.1 with SMTP id j1mr19766645vkg.144.1496967622447; Thu, 08 Jun 2017 17:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 17:20:01 -0700 (PDT) In-Reply-To: References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Lorenzo Colitti Date: Fri, 9 Jun 2017 09:20:01 +0900 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fernando Gont Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG Content-Type: multipart/alternative; boundary="001a114bc9e261216b05517bef51" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 00:20:25 -0000 --001a114bc9e261216b05517bef51 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 2:17 AM, Fernando Gont wrote: > > I don't think you have measurements that prove this. You almost > > certainly can make a statement that there are a number of low-entropy > > addresses where the top bytes are all zeros, and that those are *likely* > > statically configured. > > Are you assuming that such low-byte addresses are the result of > automatic configuration? How come? > No, what I'm saying is: I don't think you can prove that high-entropy addresses are *not* the result of manual configuration or DHCPv6 address assignment. That's the point: there are not a lot of high-entropy addresses. See the > measurements in RFC7707. Oh, I see. You're talking about publicly-accessible servers, not clients. we have similar measurements in RFC7707. However, using the low-order 32 > bits in such way is equivalent to simply setting the low byte of the > addresses. > Equivalent in what way? It provides 4 times more nonzero bits, does it not? > The point is that when employing manual configuration, addresses always > have small entropy. Hence employing a lot of bits doesn't buy much, > because folks simply do not use them for additional entropy. But they could. If the server had a /64 prefix, then it could store useful information in the 64 bits. For example, SNI (which sends information in the clear) might not be necessary any more. --001a114bc9e261216b05517bef51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 9, 2017 at 2:17 AM, Fernando Gont <fgont@si6networks.com&g= t; wrote:
> I = don't think you have measurements that prove this. You almost
> certainly can make a statement that there are a number of low-entropy<= br> > addresses where the top bytes are all zeros, and that those are *likel= y*
> statically configured.

Are you assuming that such low-byte addresses are the result of
automatic configuration? How come?

No, = what I'm saying is: I don't think you can prove that high-entropy a= ddresses are *not* the result of manual configuration or DHCPv6 address ass= ignment.

That's the = point: there are not a lot of high-entropy addresses. See the
measurements in RFC7707.
=C2=A0
Oh, I see. You&#= 39;re talking about publicly-accessible servers, not clients.=C2=A0

we have similar measurements in= RFC7707. However, using the low-order 32
bits in such way is equivalent to simply setting the low byte of the
addresses.

Equivalent in what way? It p= rovides 4 times more nonzero bits, does it not?
=C2=A0
The point is that when employing manual configura= tion, addresses always
have small entropy. Hence employing a lot of bits doesn't buy much,
because folks simply do not use them for additional entropy.
But they could. If the server had a /64 prefix, then it c= ould store useful information in the 64 bits. For example, SNI (which sends= information in the clear) might not be necessary any more.
--001a114bc9e261216b05517bef51-- From nobody Thu Jun 8 17:36:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EE5129B6D for ; Thu, 8 Jun 2017 17:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOzeqxOZ2ZAN for ; Thu, 8 Jun 2017 17:36:24 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C79812751F for ; Thu, 8 Jun 2017 17:36:24 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 E1DA582681; Fri, 9 Jun 2017 02:36:37 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Fernando Gont Message-ID: <089d5e62-360a-9daf-339e-397ab0f4361f@si6networks.com> Date: Fri, 9 Jun 2017 03:35:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 00:36:27 -0000 On 06/09/2017 03:20 AM, Lorenzo Colitti wrote: > On Fri, Jun 9, 2017 at 2:17 AM, Fernando Gont > wrote: > > > I don't think you have measurements that prove this. You almost > > certainly can make a statement that there are a number of low-entropy > > addresses where the top bytes are all zeros, and that those are *likely* > > statically configured. > > Are you assuming that such low-byte addresses are the result of > automatic configuration? How come? > > > No, what I'm saying is: I don't think you can prove that high-entropy > addresses are *not* the result of manual configuration or DHCPv6 address > assignment. Look at the percentage of addresses with high entropy in the measurements in RFC7707: they are marginal. > That's the point: there are not a lot of high-entropy addresses. See the > measurements in RFC7707. > > > Oh, I see. You're talking about publicly-accessible servers, not clients. Exactly. I doubt clients do manual configuration. > we have similar measurements in RFC7707. However, using the low-order 32 > bits in such way is equivalent to simply setting the low byte of the > addresses. > > > Equivalent in what way? It provides 4 times more nonzero bits, does it not? Equivalent in terms of entropy. If you do low-byte addresses, th entropy is 8-16 bits. If you embed IPv4 addresses in the IID, and the IPv4 prefix is known or guessable, you get roughly the same number of bits of entropy. In both cases, you'd have got the same entropy if you ha been using a /120 prefix or the like. > The point is that when employing manual configuration, addresses always > have small entropy. Hence employing a lot of bits doesn't buy much, > because folks simply do not use them for additional entropy. > But they could. If the server had a /64 prefix, then it could store > useful information in the 64 bits. For example, SNI (which sends > information in the clear) might not be necessary any more. We're talking about entropy here. If you want entropy, randomize your IPv6 address (RFC7217), rather than set it manually. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jun 8 18:11:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581AD127775 for ; Thu, 8 Jun 2017 18:11:16 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfXagzHsAxTj for ; Thu, 8 Jun 2017 18:11:14 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B5F126557 for ; Thu, 8 Jun 2017 18:11:14 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 352583493F0; Fri, 9 Jun 2017 01:11:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 03BA7160041; Fri, 9 Jun 2017 01:11:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E295E16006B; Fri, 9 Jun 2017 01:11:09 +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 E7Mbj65BCK83; Fri, 9 Jun 2017 01:11:09 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 23678160041; Fri, 9 Jun 2017 01:11:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 22E967B64301; Fri, 9 Jun 2017 11:11:06 +1000 (AEST) To: Simon Hobson Cc: 6man From: Mark Andrews References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) In-reply-to: Your message of "Thu, 08 Jun 2017 08:19:41 +0100." <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> Date: Fri, 09 Jun 2017 11:11:06 +1000 Message-Id: <20170609011106.22E967B64301@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 01:11:16 -0000 In message <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk>, Simon Hobso n writes: > Fred Baker wrote: > > > > > On Jun 7, 2017, at 4:42 PM, james woodyatt wrote: > >> As far as I know, nobody associated with Thread apart from me is even > >> listening to IETF much less offering anything to say. And the only thing > >> I'm saying is that IETF should stop pretending that IPv6/NAT in end site > >> addressing plans is preventable. It's inevitable. > > > > That's not LACNIC's experience. They have been testing to see what the > > real story is - put an ad in a web page that accesses a STUN server, and > > reports whether the addresses are the same or different. What they find > > is that, in Latin America, IPv4 hosts have a 94% probability of being > > behind a NAT, but IPv6 hosts have only a 0.6% probability. > > > > Just saying... Last I checked data trumps opinion. > > Well said. > I also can't see how anything good can come of an attitude that "people > will do it, so lets drop any standards/best practice statements saying it > shouldn't be done". Taking that to an extreme, you could say that [CG]NAT > solves the IPv4 addressing problem so why do IPv6 at all ! > > I can well believe that most IPv4 traffic involves NAT. NAT is the > band-aid that's kept IPv4 going for the last decade or two, and without > it, most users would not get online at all. > As others have said, there's no need for any form of address translation > in IPv6 **other than due to operator shenanigans**. If there are > established standards that say "thou shalt do xxx" and "thou shalt not do > yyy" then there is something for customers to beat up the more idiotic > service providers and give them some incentive to fix things. It might > help if software developers, instead of spending time on workarounds, > simply (or at least, start with) put up a warning to the user that their > IPv6 network is broken according to RFCblah and only then offer to carry > on with a "best effort" attempt to work around it. > > If support forums for packages have threads which come down to "complain > to your ISP that they don't comply with RFCblah" then that will get a > support loading for the ISP that the bean counters will see as a cost > they can remove. Ie, make it more expensive for them to try the sort of > tricks (like "you only get a nobbled IP allocation unless you pay us > business rates") so there's a commercial incentive for them to do the > right thing. > > My very limited experience with ISP provided IPv6 is that so far, what > I've seen is sensible allocations (eg a /56 for a home user). If the > majority do the right thing, then the exceptions can stand out and get a > reputation for "broken". I know in the real world there will be cases > where there's an effective monopoly (for some group of users) allowing > the ISP to do what they want, but that's not an excuse to just throw in > the towel and give the rest carte blanch. And 256 prefixes very quickly become too few as we develop new technologies to take advantage that you can get prefixes easily. ISP's have been short sighted here. The IETF started out saying /48 to give every site enough prefixes that they shouldn't have to go back and get more except in exceptional circumstances. Note: the rule always has been "if you don't have enough prefixes ask your ISP for more". DHCP-PD allows for this, you can us DHCP-PD to request additional blocks. RIR's allow ISP's to get more addresses to support this. Mark > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 8 19:47:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D96129408 for ; Thu, 8 Jun 2017 19:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmvipMZwrWPG for ; Thu, 8 Jun 2017 19:47:16 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 23CC91200F3 for ; Thu, 8 Jun 2017 19:47:16 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 68so10495618uas.0 for ; Thu, 08 Jun 2017 19:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3OSQQovNlYm2bKSdictFM75SvoHbxftnbxx5xcFlGw8=; b=ppNyF/RspNoM2CCF4ob6L8A4S49P8ukgIV/V1pVDbjlRFxQ2XNv/ZoHOil/LWQPHv3 tVw9dcEgh6AKH3thcnu4dhBlUJU9rY0PEbeHVeL/cHmWOSRff1Q0Fpxs+Y3597Ctrf0r QF+x/vf7xsY3ur/tvBavOckoGEfuNbPs9uTrKR9jFFy5Wc77KllZ12ZU75Vbg2v5RHLx yUfOAT2dvo5AZmoJZHlgvG4GSbuWljZqmXUntyXqLX9opHG8A23/l4X6gP0ktU+64bwK gS+P/9WOaEoWx+5gCenVHU+bkwTrsvz7H9CZDQvEbCJq7dbAoeT0WB1cU+zX2LKVgsrr FykQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3OSQQovNlYm2bKSdictFM75SvoHbxftnbxx5xcFlGw8=; b=LjlMMxFZXJPkAZvz3iID5+hsAEJSTompBOCvizuFmyT/2MrfjGXjljt6au4RPdB77Z p1yyGkNCV1JqajyAo7QR8FHsGJiVjZ17hp8twlMh7qgdbG+/pZNsj68fo2+UP899IiGx 3i6hRVkDwWMb7BaqXo7XeSWgPeApsMhwYI6h3/kEViPCfwP7sGFPlRZ7epAN1/JriLuy UF3jE9YBjWw0refir7XpAcLAriRnKldWkz+l40ps+ibVjeLYbZuv40VOGxf0ytY/7lTA xkI0t0cbXs7mpJ/umyNPuKOn8+5W4QFzFtIBZgjIL8chXX3GLrYO//905YUoy77dnJui ynPA== X-Gm-Message-State: AODbwcDjqKmwMF8FbLwiKUbdeN674BzSIJKYUT6U3zOX0e291ETMGxmt PPPNfvS+k2Bt5N0XTTKEpjPg7OthNA== X-Received: by 10.176.23.41 with SMTP id j41mr24052811uaf.32.1496976435249; Thu, 08 Jun 2017 19:47:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.67 with HTTP; Thu, 8 Jun 2017 19:46:44 -0700 (PDT) In-Reply-To: References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Mark Smith Date: Fri, 9 Jun 2017 12:46:44 +1000 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fernando Gont Cc: Lorenzo Colitti , Job Snijders , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 02:47:18 -0000 On 9 June 2017 at 03:17, Fernando Gont wrote: > On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: >> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont > > wrote: >> > > The point is that when employing manual configuration, addresses always > have small entropy. Hence employing a lot of bits doesn't buy much, > because folks simply do not use them for additional entropy. > So I was specifically talking about network infrastructure devices benefiting from large entropy in 64 bit IIDs. My view comes from slides like this one, showing in 2012 there were 268 000 Cisco IOS devices SNMP exposed to the Internet with a 'public' community, and 18 000 with 'private'. https://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=54 Cisco IOS devices obviously aren't hosts. People have very successfully scanned for and discovered devices that network operators should be securing. Here's more recent similar data from 2016. Much better, however still a lot of targets. https://www.shodan.io/report/mTVIRLZi I'm not aware of similar data for other network equipment vendors. Cisco is going to be the biggest target. This is about raising the security bar, and with manually configured addresses with high entropy, or RFC7217 on routers and switches out of the box, raising it by default. If the device can't be discovered, it isn't possible to send a packet to it. If you choose to specifically lower device security against discovery by putting routers in DNS, or allowing routers to respond to traceroutes, you consciously know you're lowering it for the specific device and can be vigilant when taking other measures to raise it again (ACLs etc.) Note that I'm not saying this is the only security measure you should have. It is an additional defence in depth measure that IPv6 addressing can provide to network infrastructure devices that IPv4 addressing could not. Regards, Mark. From nobody Thu Jun 8 20:03:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A139D1200F3 for ; Thu, 8 Jun 2017 20:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1t2ElfcLbJH for ; Thu, 8 Jun 2017 20:03:36 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 1736D127286 for ; Thu, 8 Jun 2017 20:03:33 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id v111so25041518wrc.3 for ; Thu, 08 Jun 2017 20:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SL1lSfNnR9onmBE+2R5xK2sL1I5d/4sNt2d4pCNmXsE=; b=nL6rSa1QhHRpsdiLmgx2lH83iE/Ho+380KocK2RQ9TdjJSTyZV8YnV8S7wQCQoTJ5O Zf3PzcN3PHnb/5730d2+GygNYC5m0aWf4xb9ixROowVgvwOHI8vnBkyAH41TAB90Dm4A +iaKCXL88GnqDLw++cCMr33UisXWW+Y8d7adPV3f35Pro6nPI0wyLKpbfBdmQgRcvP1i uEW7jGsmsbsN7nF0b3qaV/uyTgos3qQetLHvRGEPVOFUpkbXJMkDaG0YdWQaXbNtazYS 9fceTS2vPZpRc0gA6IOGVG3pVE5HtUDAsD4XhIo4dld6nBmGb96T5QwWjCX8rY7Wav68 P3vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SL1lSfNnR9onmBE+2R5xK2sL1I5d/4sNt2d4pCNmXsE=; b=QkPyt6z/+zM2f4Nlkuw0skHRim1rUJ11sOk7gyZAXVk8ZfoaOpekW8POE6TifN8QRr fUZi64zBGfK3Ts64OTe6npiz5+ghpgZvHWhZ+XfTcTSrzFRR0HZ8DqQEPDQIy/RAkWIV U7c/LjW/41EzEo4m77dPo58vjG5VHU8PMuT6Q2pNUNUBM/YOidOWFHay9b1KwjEWUFcb 2XSG6FIb0ZHf9O0csmtt3TkX2tbYP+9EsIx9v+vFqICB5WGxnKdE7B0Y7afyl7XST5yp BgIhm0sfO7I34YpEH400U6IXZqNuQVQyb09JRfH1YchLaIFiHxRfp6x5CicH0XDTM4BS t+Tw== X-Gm-Message-State: AODbwcBk2LZMsnTsHDIf5FC1Hd5sXAqPYAv6x9KWEmugppRRsu1PvWMQ 1iEGbRkRdovBXi/HOlG6yB3QawClIylA X-Received: by 10.223.128.80 with SMTP id 74mr32503955wrk.30.1496977411585; Thu, 08 Jun 2017 20:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Thu, 8 Jun 2017 20:03:30 -0700 (PDT) In-Reply-To: References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Tom Herbert Date: Thu, 8 Jun 2017 20:03:30 -0700 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Fernando Gont , Job Snijders , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 03:03:38 -0000 On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith wrote: > On 9 June 2017 at 03:17, Fernando Gont wrote: >> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: >>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont >> > wrote: >>> > >> >> The point is that when employing manual configuration, addresses always >> have small entropy. Hence employing a lot of bits doesn't buy much, >> because folks simply do not use them for additional entropy. >> > > So I was specifically talking about network infrastructure devices > benefiting from large entropy in 64 bit IIDs. > > My view comes from slides like this one, showing in 2012 there were > 268 000 Cisco IOS devices SNMP exposed to the Internet with a > 'public' community, and 18 000 with 'private'. > > https://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=54 > > Cisco IOS devices obviously aren't hosts. People have very > successfully scanned for and discovered devices that network operators > should be securing. > > Here's more recent similar data from 2016. Much better, however still > a lot of targets. > > https://www.shodan.io/report/mTVIRLZi > > > I'm not aware of similar data for other network equipment vendors. > Cisco is going to be the biggest target. > > This is about raising the security bar, and with manually configured > addresses with high entropy, or RFC7217 on routers and switches out of > the box, raising it by default. If the device can't be discovered, it > isn't possible to send a packet to it. > Mark, I don't quite understand this statement. Isn't is true that If I send a packet to any IID in the prefix for a device it will reach the device and be processed? I may not get a response because that's not the IID randomly chosen as the address of the device, but it still seems like that could be used for DOS (like a tuple attack on a NIC queue) if the prefix is discovered or predictable. Tom > If you choose to specifically lower device security against discovery > by putting routers in DNS, or allowing routers to respond to > traceroutes, you consciously know you're lowering it for the specific > device and can be vigilant when taking other measures to raise it > again (ACLs etc.) > > Note that I'm not saying this is the only security measure you should > have. It is an additional defence in depth measure that IPv6 > addressing can provide to network infrastructure devices that IPv4 > addressing could not. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jun 8 20:04:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B96129408 for ; Thu, 8 Jun 2017 20:04:56 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2QoMGG0zY7e for ; Thu, 8 Jun 2017 20:04:54 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 73C4A1200F3 for ; Thu, 8 Jun 2017 20:04:54 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id q15so27934501uaa.2 for ; Thu, 08 Jun 2017 20:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OksFEhiR/ye49JY6upUA5F69kuoFtGyagHO0ul7nIg8=; b=MOW7ztuiK/w6OVUmnCd5EL62arlFI1BvkVqFKQP/GJrHHwh8Iq5fOPQU8EpIbaGBEa ndXal8LL17VUnAVssrGffU8Z5kAKUw5c1zlksmKhFsAryVVT80mvW1Q93xVPUMkk7URa FMF365glXc9kT0MrDjufmli40FU1khFP/mTSim8ZpXPXamBzQ/FGlra2iWNpXern7Ifr 6GiViSVfkDx9L365jwZmiyu25L5HdwZPQffPhQf232+t0khGTNHsk1s3JJZu/bGKBUwR rmOoL/TQ0xbmjbJVVdbKi3kvUMd64c+Zl3fwfRNaQEusI6oqL2afxPQNwnvvmnG2+zkA pO+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OksFEhiR/ye49JY6upUA5F69kuoFtGyagHO0ul7nIg8=; b=RGQgnzfpL8deQ5kzuFdb9etJdcCYb1XXgmdwe+Wsm1CLVxPp3mcalqzM4DbWu/iTBw zyLyjhJTe0FvYg3gwnKhKbwmyTpzcbjcaF7gCB4VavPk+qW4yV820HNbs1SaGV6x1AV2 l2TRHNE2oRlPGGXtuIYEIrYdK6oA8JnfWm4NFbN7RGRCRd/5d6iHzQz2TMyFra8r7Hlj k9xLyK0WYYPzkxZQCXzQ9QG4qxo70CPEdkAaUfzvNZXuT6z791EpHJ7+Oe6iPph+ypCm pQiYAOGBSelcjR7i8BpgCndjr8J5B9f4uwQ1y34ADzZFaGttBMcYsjjSX1HZT5phiRZe i3Cw== X-Gm-Message-State: AODbwcDPcCa6IPcdOS3mcQsAFzunsjGBHsz+FMFLMiJmMZSdSwHgVUk2 c0mH5CwsxX++m69InisRQHfoiH+dOREz X-Received: by 10.159.49.91 with SMTP id n27mr13582292uab.93.1496977493339; Thu, 08 Jun 2017 20:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 20:04:32 -0700 (PDT) In-Reply-To: <089d5e62-360a-9daf-339e-397ab0f4361f@si6networks.com> References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> <089d5e62-360a-9daf-339e-397ab0f4361f@si6networks.com> From: Lorenzo Colitti Date: Fri, 9 Jun 2017 12:04:32 +0900 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Fernando Gont Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 03:04:56 -0000 On Fri, Jun 9, 2017 at 9:35 AM, Fernando Gont wrote: >> But they could. If the server had a /64 prefix, then it could store >> useful information in the 64 bits. For example, SNI (which sends >> information in the clear) might not be necessary any more. > > We're talking about entropy here. If you want entropy, randomize your > IPv6 address (RFC7217), rather than set it manually. Well, but the entropy that we care about is not the entropy of the IP address, but the entropy of the network communications. Those can be achieved by using many IP addresses in parallel. From nobody Thu Jun 8 21:19:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C559712704A for ; Thu, 8 Jun 2017 21:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex23UrTfwrLq for ; Thu, 8 Jun 2017 21:19:36 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5483D1242F7 for ; Thu, 8 Jun 2017 21:19:36 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 4ABEF827A2; Fri, 9 Jun 2017 06:19:52 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Philip Homburg , ipv6@ietf.org References: <59392678.1080000@foobar.org> From: Fernando Gont Message-ID: Date: Fri, 9 Jun 2017 07:13:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 04:19:39 -0000 On 06/08/2017 02:31 PM, Philip Homburg wrote: >> Next you'll say that stripes have no value to zebras and camouflage >> has no value to armies. > > I find this a bizar discussion. We already have plenty of options for providing > nodes with addresses that have lots of randomness. > > Some operators don't care about that feature and would like to be able to use > those bits elsewhere. > > So if you want to make it hard to discover a node, assign a /64 to a link and > use put a random value in the remaining bits. > > That should not proclude other people from using /120 prefixes and numbering > nodes 1, 2, 3. +1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jun 8 21:19:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A38D1293DB for ; Thu, 8 Jun 2017 21:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNl4Hg10T50V for ; Thu, 8 Jun 2017 21:19:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0319A1242F7 for ; Thu, 8 Jun 2017 21:19:40 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 A394E82762; Fri, 9 Jun 2017 06:19:56 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti , Brian E Carpenter Cc: IETF IPv6 Mailing List References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> From: Fernando Gont Message-ID: Date: Fri, 9 Jun 2017 07:19:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 04:19:42 -0000 On 06/08/2017 02:56 PM, Lorenzo Colitti wrote: > On Wed, Jun 7, 2017 at 8:24 AM, Brian E Carpenter > > wrote: > > "Interface Identifiers should be 64 bit long except > when the addresses are manually configured, > > > In order to publish that text we need to agree on what it means. Can you > explain the semantics of the the interface identifier of a manually > configured IPv6 address? What are they used for? > > Note: the semantics are *not* the same as the prefix length of an IPv4 > address. The prefix length of an IPv4 address implies that that subnet > is reachable on, but the IID implies nothing about reachability. The semantics are exactly the same. An address is an address. The IID only comes into play when you specify prefixes: when you know that a given subnet employs a given prefix, the 128-prefix bits are what differentiate among nodes within such subnet (although such distinction is not even necessary). The only reason why we care abut IIDs is because with SLAAC, that's the part each host has to generate. -- e.g., in a DHCPv6 world you only care about whole addresses, and prefixes in your routing table. 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 Jun 8 21:24:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DB21273E2 for ; Thu, 8 Jun 2017 21:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJE_a-gRcM0u for ; Thu, 8 Jun 2017 21:24:08 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E837127275 for ; Thu, 8 Jun 2017 21:24:08 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 191198024E; Fri, 9 Jun 2017 06:24:23 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti , David Farmer Cc: Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> From: Fernando Gont Message-ID: <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> Date: Fri, 9 Jun 2017 07:24:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 04:24:10 -0000 On 06/08/2017 03:42 PM, Lorenzo Colitti wrote: > On Thu, Jun 8, 2017 at 12:13 AM, David Farmer > wrote: > > I think "should be 64" is the correct language, primarily because > "must be 64" has been misinterpreted several times to justify hard > coding 64 in IPv6 implementations, but also it seems like a false > imperative. > > > Currently the standard says "are 64 bits long". This is certainly a historical artifact arising from SLAAC. > Do we need to change > that? Can we just say "are 64 bits long except when manually configured"? > > I think either of these makes it clear 64 bit is the norm, but this > should not enforced by an IPv6 implementations or hard coded in some > way. > > > I have no issue with manual configuration. > > However, I think IPv6 implementations that don't support manual > configuration must be able to reject non-64 bit IIDs, since that is the > standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or > /123", and those are against BCP 204 (RFC 7934). BCP204 talks about multiple addresses. As long as whatever prefix is employed allows for multiple addresses, I don't see how that goes against BCP204. 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 Jun 8 23:17:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1350127275 for ; Thu, 8 Jun 2017 23:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5YOUsrfFxby for ; Thu, 8 Jun 2017 23:17:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 4CD3F120721 for ; Thu, 8 Jun 2017 23:17:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v596Ha4d106614 for ; Fri, 9 Jun 2017 08:17:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40A7A203496 for ; Fri, 9 Jun 2017 08:17:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 36D40202A4A for ; Fri, 9 Jun 2017 08:17:36 +0200 (CEST) Received: from [132.166.84.95] ([132.166.84.95]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v596HZQX011734 for ; Fri, 9 Jun 2017 08:17:35 +0200 Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Alexandre Petrescu Message-ID: <4c510f4e-f6cb-4b9d-490f-9b873db7d2f0@gmail.com> Date: Fri, 9 Jun 2017 08:17:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 06:17:42 -0000 Le 09/06/2017 à 05:03, Tom Herbert a écrit : > On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith > wrote: >> On 9 June 2017 at 03:17, Fernando Gont >> wrote: >>> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: >>>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont >>>> > wrote: >>>> >> >>> >>> The point is that when employing manual configuration, addresses >>> always have small entropy. Hence employing a lot of bits doesn't >>> buy much, because folks simply do not use them for additional >>> entropy. >>> >> >> So I was specifically talking about network infrastructure devices >> benefiting from large entropy in 64 bit IIDs. >> >> My view comes from slides like this one, showing in 2012 there were >> 268 000 Cisco IOS devices SNMP exposed to the Internet with a >> 'public' community, and 18 000 with 'private'. >> >> https://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=54 >> >> Cisco IOS devices obviously aren't hosts. People have very >> successfully scanned for and discovered devices that network >> operators should be securing. >> >> Here's more recent similar data from 2016. Much better, however >> still a lot of targets. >> >> https://www.shodan.io/report/mTVIRLZi >> >> >> I'm not aware of similar data for other network equipment vendors. >> Cisco is going to be the biggest target. >> >> This is about raising the security bar, and with manually >> configured addresses with high entropy, or RFC7217 on routers and >> switches out of the box, raising it by default. If the device >> can't be discovered, it isn't possible to send a packet to it. >> > Mark, > > I don't quite understand this statement. Isn't is true that If I send > a packet to any IID in the prefix for a device it will reach the > device and be processed? Well depends on the link on which that device is. If it is on a ptp link like current cellular then yes, it receives all the packets addressed to all IIDs within the /64 it is allocated. It is this property that is exploited by '64share' technique to make such devices routers. It is not a good property, but yes there is. On another hand, if it is a device on a more shared link more like true Ethernet, then it receives only packets addressed to the addresses within that /64 that have been configured on the interface (for which it answers with NA). Remark also that there are proposals of acting more like ptp even in the second case (the 'WiFi /64 unique prefix per host' document). So - it depends on the link. > I may not get a response because that's not the IID randomly chosen > as the address of the device, but it still seems like that could be > used for DOS (like a tuple attack on a NIC queue) if the prefix is > discovered or predictable. This is the case if the link is ptp, or if it is WiFi with a /64 assigned per host. It is not the case (not all packets to all IIDs in a /64 reach a host which has not configured them on the iface) if the link is WiFi and the /64 is shared among all hosts on that link. (which makes think what you say above is a security risk that could be literally be pointed to the /64-per-host draft-v6ops-unique-ipv6-prefix-per-host proposal in v6ops WG; and that there are some RFCs about network scanning like RFC5157 "Implications of IPv6 Network Scanning"). And, even if the /64 is shared among multiple hosts on that link, sending an arbitrary packet (TCP Ack?) in a D-DoS manner to all addresses in a /64 prefix is an attack to the Router in charge of that link and on the link itself: there could be very many NSs sent to the link (a 'storm'). The larger the plen the bigger the storm. Alex > Tom > >> If you choose to specifically lower device security against >> discovery by putting routers in DNS, or allowing routers to >> respond to traceroutes, you consciously know you're lowering it for >> the specific device and can be vigilant when taking other measures >> to raise it again (ACLs etc.) >> >> Note that I'm not saying this is the only security measure you >> should have. It is an additional defence in depth measure that IPv6 >> addressing can provide to network infrastructure devices that IPv4 >> addressing could not. >> >> Regards, Mark. >> >> -------------------------------------------------------------------- >> >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 8 23:36:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32F6126C25 for ; Thu, 8 Jun 2017 23:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lLMBtUcEqAL for ; Thu, 8 Jun 2017 23:36:30 -0700 (PDT) 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 0EC1E124D6C for ; Thu, 8 Jun 2017 23:36:30 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id p85so24830214vkd.3 for ; Thu, 08 Jun 2017 23:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qdmfavNmY3K7lNgr+QxgtQKqoiPC2APQIm7RXMywB9o=; b=AHHcv6iRuMx63tebyzTIbpCJUa3PbldyIOZKd7w+DpXGW0JG3jlkYH40XL85arGOA8 tEDNL8FDacTxpQKobkwwm1uYrFZMJSu1BLQ+3c3NtzToYUq8EHPEwWfceeZFzQR+yroK /eb6OaZaOVFXkhHKV6iAJn3F1Y3CAUE1QSgbF+Trgrr7orvqO9h571sSgWokwAWhRSRk GAVvgoevgtnyi3L/Z7h/mr53XoBZg+TWEy4McOIaNRTVIuyvtnI4jpF3FVtiJMDd8bth D6m25O+M3NPcdTqWMM6YeBepAX0JbOsPrZaGLi0jyVQMP2aTZiSORMgIcKtD9v9n4gOj NRsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qdmfavNmY3K7lNgr+QxgtQKqoiPC2APQIm7RXMywB9o=; b=ne13HvOtBRhqYwvRXYvopcJ7cDSJbV+QKmN1KPjqxL1LWqsvxG4TFUoJtnDqRbaIdg +EnmJKFyX8NI0kIrTWfBV28K4FUi8l9l5Ze0HZKhb3g2CeTV9GzdsVil9Nl6XdNNXOVi LNK6A0h6XIIjTeR5CHJ/MZG4AZWmrmblnoguHbNDvNalHNzf/ZlN0hN90/Gl7E6PAbxB Ay0JyJRrQBj6As89XTlJsqHBcp99hIeGLItSh2yvAqVI/xvDMRFkZltaKGa0ctsW/Tso zVogfE42WFZ57JuG3VIX97fAWmpK0FghlCXsLmE34bXjqXLivpCiNwgP4AmCXvwf4C/p A8oQ== X-Gm-Message-State: AODbwcC4XG5p/GZC9vvdEvWdp/ZKU7KY/uLy8+1+g89U9SSQlJY7HOmc 4RBswqNiROHzL4JVYp3IBIVbK8oIl6iV X-Received: by 10.31.69.138 with SMTP id s132mr18265336vka.13.1496990189047; Thu, 08 Jun 2017 23:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 23:36:08 -0700 (PDT) In-Reply-To: <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> From: Lorenzo Colitti Date: Fri, 9 Jun 2017 15:36:08 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont Cc: David Farmer , Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="001a114dd2d273d413055181304a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 06:36:33 -0000 --001a114dd2d273d413055181304a Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont wrote: > > However, I think IPv6 implementations that don't support manual > > configuration must be able to reject non-64 bit IIDs, since that is the > > standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or > > /123", and those are against BCP 204 (RFC 7934). > > BCP204 talks about multiple addresses. As long as whatever prefix is > employed allows for multiple addresses, I don't see how that goes > against BCP204. That's not true at all. As an example: see if you can build a network that uses a /99 and satisfies the recommendations in section 8 or BCP 204. --001a114dd2d273d413055181304a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 9, 2017 at 1:24 PM, Fernando Gont <fgont@si6networks.com&g= t; wrote:
> Ho= wever, I think IPv6 implementations that don't support manual
> configuration must be able to reject non-64 bit IIDs, since that is th= e
> standard. Saying "SHOULD be 64 bits long" means they "M= AY be /81, /99 or
> /123", and those are against BCP 204 (RFC 7934).

BCP204 talks about multiple addresses. As long as whatever prefix is=
employed allows for multiple addresses, I don't see how that goes
against BCP204.

That's not true at all.= As an example: see if you can build a network that uses a /99 and satisfie= s the recommendations in section 8 or BCP 204.
--001a114dd2d273d413055181304a-- From nobody Thu Jun 8 23:53:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DFC126C25 for ; Thu, 8 Jun 2017 23:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODVMjY4xAEhI for ; Thu, 8 Jun 2017 23:53:36 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58D11242F7 for ; Thu, 8 Jun 2017 23:53:35 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id p62so25037776vkp.0 for ; Thu, 08 Jun 2017 23:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XWXcnC7HBij8jxipZsoHDkZQD2rOlkfe4Z1l3TfrPq0=; b=iKakamaHi2ZgrZNwb+8Xlq+xM1G0uVGrMpBlsk9+EQ3oQcW58TT+5fL4rQfnZlMMvi MYwNFzdoR+JMD4xmG+YChrzDyQlvVcyzDGm3b6yauzsHdRf1NP0udOEDStGoK6muwZu3 kQfeslNwBoPqK1JcCcqL5QuANlQXslEk/uRFzt+alkIBs6oMwHrB7K96eD/9+9rnJ/pw /lf83tpao+uALZ518vjjkZ+KxsB2D5yKgptt4Jptw9WWGYqo9w2XpiJ/7dCDj8mOXZd/ pXaM/RykkiNgc0oIkL61GbdDItxDYa+kV8S7pfBdTxs9nuLJu4sABzJKELrCoXKIeGbF Oiqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XWXcnC7HBij8jxipZsoHDkZQD2rOlkfe4Z1l3TfrPq0=; b=P7Iwm+EFVDqNmyHeafaDycgBLf5MTpv5Sw3+v+lPUy30vpnlAC6vhMKh4XewKIyG7o oBYtl/rxRpGl3erxphfxNx4hMJBVP6NIKAS0xzbyIKPQcmH+Po5+algzghIDWLL1vUm0 h1koMXpD3igyA13CInTfLx1HmXGiB+2FPkRS2cz5yoTvxrurIfPD7u6dz0qIhUixIfgd 1LSGaEcJ2Y21nldD/dozok52+23kq8cCu9c7OJqhDoa7ZBqqSQ9M28Y7BmGuhlDgUPc4 cYJ1/QXdnqGmp43pSXuAvF7S3mkcVr6YQoB9JE6lgrNiHpXgZ2j3Zc1Jg3S1fBkjwXfc CO/Q== X-Gm-Message-State: AODbwcCRN8fKzJ8xNlJcBeObmJJ2DaFWDdlFXv6x+deQoU6dIih3edi9 9vzTNh0OO9wOsnF65FY1VEQFjQFCkbCLHdo= X-Received: by 10.31.210.1 with SMTP id j1mr20246250vkg.144.1496991214867; Thu, 08 Jun 2017 23:53:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 8 Jun 2017 23:53:13 -0700 (PDT) In-Reply-To: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> From: Lorenzo Colitti Date: Fri, 9 Jun 2017 15:53:13 +0900 Message-ID: Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: james woodyatt Cc: 6man Content-Type: multipart/alternative; boundary="001a114bc9e2988ae70551816d77" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 06:53:38 -0000 --001a114bc9e2988ae70551816d77 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 2:25 AM, james woodyatt wrote: > If thread doesn't use RFC 4861, then it probably uses address > registration? If so it's trivia[...] > > > It does not. The problem is not trivial. > > You're invited to have a look at the Thread 1.1 mesh protocol. If you > think you can devise a power conservative method for making a Thread 1.1 > border router efficiently join a home Wi-fi network using IPv6 Neighbor > Discovery, then I'm sure the Thread engineering team would be happy to > consider your ideas. > Is it publicly documented? If not, I'd be happy to sit down with you and debate this :-) --001a114bc9e2988ae70551816d77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 9, 2017 at 2:25 AM, james woodyatt <jhw@google.com> wro= te:
If thread doesn't use RFC 4861, then it probably uses add= ress registration? If so it's trivia[...]

It does not. The problem is not trivial.

You're invited to= have a look at the Thread 1.1 mesh protocol. If you think you can devise a= power conservative method for making a Thread 1.1 border router efficientl= y join a home Wi-fi network using IPv6 Neighbor Discovery, then I'm sur= e the Thread engineering team would be happy to consider your ideas.

Is it publicly documented? If not= , I'd be happy to sit down with you and debate this :-)
--001a114bc9e2988ae70551816d77-- From nobody Fri Jun 9 00:49:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC9129534 for ; Fri, 9 Jun 2017 00:49:08 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHhiGMR9LnpL for ; Fri, 9 Jun 2017 00:49:04 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9C9127444 for ; Fri, 9 Jun 2017 00:49:01 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 09 Jun 2017 07:47:00 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6C925D788A; Fri, 9 Jun 2017 00:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=EUT+Fs5y/m2z7s6A000UIgQ7uuU=; b= NEy8qtR7G0dfKGOVhQZirbQFe8Om2K9T8WzjnbfwG7F2tmOq1B868VjfhF5E9lZQ neYqQjZND34P7XaAQgYzzN0UmNKioflRf2K/A1/5zUMnKjS5J1Ts0e6XMLEVrQ2U uP3mSsyLv4kjJ0Hgx4tph4L4hmJt3rkDlkyoBzNjbGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=MwnEsc9jRll3oNhh/vZ2ccQ 6eFZhFo3VJEd3SeUfbKIhxZZmCcyykD6IZ8U5YZX84DkP6QijWFEbRimPYnGvVYG gFmR7x7FsMmcWEzclv7xNlLDjQJ7HwMyb8onhGdOBn4Rzu121coQ7g3ThEbTbGti B21fT+UVoQP3ArqP2bQE= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 38287D788B; Fri, 9 Jun 2017 00:47:00 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 220F1D0B8AAB; Fri, 9 Jun 2017 09:46:58 +0200 (CEST) From: otroan@employees.org Message-Id: <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D7B4B2AE-D27C-46AC-9E58-478A9DB48D6B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Fri, 9 Jun 2017 09:46:56 +0200 In-Reply-To: <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> Cc: Lorenzo Colitti , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 07:49:08 -0000 --Apple-Mail=_D7B4B2AE-D27C-46AC-9E58-478A9DB48D6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 6 Jun 2017, at 00:25, Brian E Carpenter = wrote: >=20 > On 05/06/2017 19:45, Lorenzo Colitti wrote: >> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >>=20 >>> None of that is the point. The point is to establish >>> that routing is classless >>=20 >>=20 >> Routing is already classless because BCP 198. >>=20 >>=20 >>> and /64 is a parameter of specific addressing schemes. >>>=20 >>=20 >> It *is* a parameter. The parameter's value is 64 for all unicast = addresses >> except those starting with 000. >=20 > The parameter's *current* value, yes. But should we really be fixing > the value of the parameter once and for all in the addressing = architecture? > Why don't we fix it in each IPv6-over-foo, which is what the SLAAC = design > assumes? do we have a rationale for fixing the value in the IPv6-over-foo = documents (anymore)? Cheers, Ole --Apple-Mail=_D7B4B2AE-D27C-46AC-9E58-478A9DB48D6B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZOlJxAAoJEL7aWKiYQt92GAAQAKUqZLDbBVIaWUsgCr/WoLYc nC6DVfRwqXWJ/c6GgnYm0azTx8K7N6+sDlqTA0I2tEinVZ1gSZ0SYT7GXI6kyNPm XXT4oomE+IFz2yAmhSkPOVPOLDVbRUjVtQNrdgO/7MGjs3Vr0Q8LnrnYcdrb9Qhs sq5AoKfZ+Dyy0j9wfYKKftrUiOoc7EUT95uerbIrG5a/VmhpQNEoHJIvZQvJ7QK9 cQraGBgLnoWgS1ZkCbgdBVCEPy7XBr7JNEj8uy1ls2UKGvYeDUT654/flMH12YCM 6EfwAADeK9j6jv4jYU2OCDFmbAMZUiUq4IaAjto1rKLv1uKAeTfriXx5+x1rVZA9 nisbQkpWzFSfwos/vlfIavncOLYwkEFol0slbQgTMaQp9ZAm4KQo3T/JWznUMDPj wycdFm6zUx7p5U74Wm2lyWg5SFXjfSkqCUGaaR+gT42NAX8rCABfyZOdRhyTGzuO zYBj5/d5u1sgX9jY7pv1XWv199g1acaxmHGgqhAhrsvO4KGkGcU4BsXN+GO8Dnn2 tsQi6QyLPFjbbhFgm+7iZqM+1hJb4GEsCXNRN4YD2eIyAJ8cVMb6GvW995qebl/U C9YFlytWlTElswR53V3gCbKPyXCYEk0p+XErFw86u5BsupAgJQyoxKwGjzUtsMU8 O0Q98AqElOF1IusK8p9a =0jpc -----END PGP SIGNATURE----- --Apple-Mail=_D7B4B2AE-D27C-46AC-9E58-478A9DB48D6B-- From nobody Fri Jun 9 01:18:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2C129526 for ; Fri, 9 Jun 2017 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaebTdfrdC0n for ; Fri, 9 Jun 2017 01:18:32 -0700 (PDT) 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 E9204124D37 for ; Fri, 9 Jun 2017 01:18:31 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 191so25531144vko.2 for ; Fri, 09 Jun 2017 01:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NHZl8j+1YSxqChItg9soey+97ydQRb9N63w2197M+UE=; b=lTUGxr5zPm7t8Kl8b+i6FGr04VSrYB6kaSaC7nqkuy9SF5MkX6L/IXkYIZKW/nRqrX qJ8gFVst1B1HIJX4TjCia0vlquPEEWGyu9y39TJaho+29on2QAfYCZ7mwZU89byMOszz ZyX5jx03J7W7Povmf+y7qwxqC11co9OWIlHTBK8nHbz4WsnBNiXaR6DcUyiXuOs/HteN 5x0tFKUAHCPp4x1C+Mjo0CgzJCk/5vQ4DYfjkqbfEuPGJS2b8bGcuGVNg/Lkykk5oWv9 V7y7tdQObAW6yP7JHfugDDFbv6soy7xbfMRbqKcqWtwPNaFgDMcOvp9ZpXv2HubgzHtF gs4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NHZl8j+1YSxqChItg9soey+97ydQRb9N63w2197M+UE=; b=erUm7/dmcC9K8leHv/NH2IGCmxJ4s29Be5OmUHMI0nWlr52uT8MOj6wEvFzJ0FfJsc LgofbRaF5PRfxcDCOA3ysNJzb0sCPwYFUErrdMn62n73A8IpoW2JuPo4yLDmytYuacAN oBFEIpDscTF+9N+BB8VFOprKNkKKlcuZg0wJCn3iixZ7IoabgEHZ6o4i1Tlan6e/GTc5 ahBSe3ToRirplLxeeeJfNne8fhbhkJH4EXr6Kdy76AQZDs0FTl3yquRnfpOeqCi8cBpZ IeJL+zB1zybQhNzPYt6n9C+N170uDOZEU+1kE9KcUo00N0UgbH4cY/puJXzZvkQqr1GM txSg== X-Gm-Message-State: AODbwcBuwpajPS84NVPApRm6HwlHBU/CGHb9iMFpWofiXTrUNhQoiSL0 4dqoWKiNl9+rCYEAU6R798W4zRi0RQ== X-Received: by 10.31.7.72 with SMTP id 69mr5395290vkh.119.1496996310995; Fri, 09 Jun 2017 01:18:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.67 with HTTP; Fri, 9 Jun 2017 01:18:00 -0700 (PDT) In-Reply-To: References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Mark Smith Date: Fri, 9 Jun 2017 18:18:00 +1000 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Tom Herbert Cc: Erik Kline , 6man WG , Job Snijders , Fernando Gont Content-Type: multipart/alternative; boundary="001a1143d69058d9010551829d49" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 08:18:35 -0000 --001a1143d69058d9010551829d49 Content-Type: text/plain; charset="UTF-8" Hi Tom, On 9 Jun. 2017 13:03, "Tom Herbert" wrote: On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith wrote: > On 9 June 2017 at 03:17, Fernando Gont wrote: >> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: >>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont >> > wrote: >>> > This is about raising the security bar, and with manually configured > addresses with high entropy, or RFC7217 on routers and switches out of > the box, raising it by default. If the device can't be discovered, it > isn't possible to send a packet to it. > Mark, I don't quite understand this statement. Isn't is true that If I send a packet to any IID in the prefix for a device it will reach the device and be processed? Yes. You know the IID is valid at the point in time you send the packet, meaning the IID is in use by a device and the device can be targetted with an attack. This is mitigation against discovery of IIDs assigned to devices via probing, prior to launching the attack on the device. I'm pointing out that concerns about discovery of valid addresses on conventional hosts via probing can also be concerns for networking devices with IPv6 addresses as well, such as routers and switches, and that large entropy IIDs can provide them with an additional level of defence in depth that wasn't possible to have in IPv4. The control planes of networking devices are performing host functions too, so host security mitigations are applicable. Some seem to believe that network devices software/firmware is far more robust and they're universally configured far more securely such that limiting the exposure and discoverability of the devices' addresses provides no value. I think the links I provided earlier and the following links to network OS vulnerabilities shows that this isn't the case. https://www.cvedetails.com/vulnerability-list/vendor_id- 874/product_id-3989/Juniper-Junos.html https://www.cvedetails.com/vulnerability-list/vendor_id- 16/product_id-19/Cisco-IOS.html Regards, Mark. I may not get a response because that's not the IID randomly chosen as the address of the device, but it still seems like that could be used for DOS (like a tuple attack on a NIC queue) if the prefix is discovered or predictable. Tom > If you choose to specifically lower device security against discovery > by putting routers in DNS, or allowing routers to respond to > traceroutes, you consciously know you're lowering it for the specific > device and can be vigilant when taking other measures to raise it > again (ACLs etc.) > > Note that I'm not saying this is the only security measure you should > have. It is an additional defence in depth measure that IPv6 > addressing can provide to network infrastructure devices that IPv4 > addressing could not. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --001a1143d69058d9010551829d49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

On 9 Jun. 2017 13:03, "Tom Herbert&q= uot; <tom@herbe= rtland.com> wrote:
=
On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith <markzzzsmith@gmail.com> wrot= e:
> On 9 June 2017 at 03:17, Fernando Gont <fgont@si6networks.com> wrote:
>> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote:
>>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont <fgont@si6networks.com >>> <mailto:fgont@si6networks.com>> wrote:
>>>

<snip>

> This is about raising the security bar, and with manually configured > addresses with high entropy, or RFC7217 on routers and switches out of=
> the box, raising it by default. If the device can't be discovered,= it
> isn't possible to send a packet to it.
>
Mark,

I don't quite understand this statement. Isn't is true that If I se= nd
a packet to any IID in the prefix for a device it will reach the
device and be processed?

Yes. You know the IID is valid at = the point in time you send the packet, meaning the IID is in use by a devic= e and the device can be targetted with an attack.
This is mitigation against discovery of IIDs assi= gned to devices via probing, prior to launching the attack on the device.

I'm pointing out that concerns abo= ut discovery of valid addresses on conventional hosts via probing can also = be concerns for networking devices with IPv6 addresses as well, such as rou= ters and switches, and that large entropy IIDs can provide them with an add= itional level of defence in depth that wasn't possible to have in IPv4.= The control planes of networking devices are performing host functions too= , so host security mitigations are applicable.

Som= e seem to believe that network devices software/firmware is far more robust= and they're universally configured far more securely such that limitin= g the exposure and discoverability of the devices' addresses provides n= o value. I think the links I provided earlier and the following links to ne= twork OS vulnerabilities shows that this isn't the case.

=



Regards,
Mark.


I may not get a response because that'= ;s not
the IID randomly chosen as the address of the device, but it still
seems like that could be used for DOS (like a tuple attack on a NIC
queue) if the prefix is discovered or predictable.

Tom

> If you choose to specifically lower device security against discovery<= br> > by putting routers in DNS, or allowing routers to respond to
> traceroutes, you consciously know you're lowering it for the speci= fic
> device and can be vigilant when taking other measures to raise it
> again (ACLs etc.)
>
> Note that I'm not saying this is the only security measure you sho= uld
> have. It is an additional defence in depth measure that IPv6
> addressing can provide to network infrastructure devices that IPv4
> addressing could not.
>
> Regards,
> Mark.
>
> ---------------------------------------------------= -----------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------

--001a1143d69058d9010551829d49-- From nobody Fri Jun 9 02:34:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A5129420 for ; Fri, 9 Jun 2017 02:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzT5wX1rU75n for ; Fri, 9 Jun 2017 02:34:03 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773C5126FDC for ; Fri, 9 Jun 2017 02:34:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 272C31BC37 for ; Fri, 9 Jun 2017 09:33:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: Date: Fri, 9 Jun 2017 10:33:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85EDB7AA-6E5C-4834-8E63-14086B4F868B@thehobsons.co.uk> References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 09:34:06 -0000 Lorenzo Colitti wrote: > But they could. If the server had a /64 prefix, then it could store = useful information in the 64 bits. For example, SNI (which sends = information in the clear) might not be necessary any more. I don't think that's much of a security feature ! Whether you use SNI or distinct addresses, it's clear what site the = packets are going to. If anything, it's easier with distinct addresses = as you only need to see the destination address field rather than = inspect the contents of the packet to get the SNI element. The sort of = people who are going to be looking into packets to get the SNI will have = no trouble building a table of addresses-sites to map destination = addresses to site just using destination address. Mark Smith wrote: > If you choose to specifically lower device security against discovery > by putting routers in DNS, or allowing routers to respond to > traceroutes, you consciously know you're lowering it for the specific > device and can be vigilant when taking other measures to raise it > again (ACLs etc.) Firstly, I think you are over-estimating the skills of the "typical" = network admin. In my experience, only a small minority would realise the = tradeoffs and take any sensible measures - hence the figures given for = the number of known Cisco devices with the front doors open. It was = interesting when I pointed NetDisco at the campus network I used to = admin and saw how many of the customers' routers it was able to = interrogate just by following CDP neighbour information from my Cisco = switches (which were locked down with non-standard SNMP community = strings). These were mostly engineering firms in an industry where you'd = expect security to be "somewhat better" ! But then we come to the other aspects. One of my pet peeves is people = who disable pings (and/or traceroute) "for security" - and thus making = network troubleshooting far more of a problem than it should be. But if you are going to use well randomised addresses for network = devices - you will have to put them in DNS if you want to be able to = access them in a convenient manner. Once you put them in DNS, then = you've lost half the benefit of random addresses anyway. Well you could = randomise the DNS names - but then you shift the problem to knowing the = DNS name ! From nobody Fri Jun 9 03:01:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3412956C for ; Fri, 9 Jun 2017 03:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8hdm2vANOjg for ; Fri, 9 Jun 2017 03:01:42 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5ACE126FDC for ; Fri, 9 Jun 2017 03:01:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 94F6F1BC37 for ; Fri, 9 Jun 2017 10:01:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: <20170609011106.22E967B64301@rock.dv.isc.org> Date: Fri, 9 Jun 2017 11:01:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 10:01:44 -0000 Mark Andrews wrote: >> My very limited experience with ISP provided IPv6 is that so far, = what >> I've seen is sensible allocations (eg a /56 for a home user). If the >> majority do the right thing, then the exceptions can stand out and = get a >> reputation for "broken". I know in the real world there will be cases >> where there's an effective monopoly (for some group of users) = allowing >> the ISP to do what they want, but that's not an excuse to just throw = in >> the towel and give the rest carte blanch. >=20 > And 256 prefixes very quickly become too few as we develop new > technologies to take advantage that you can get prefixes easily. > ISP's have been short sighted here. The IETF started out saying > /48 to give every site enough prefixes that they shouldn't have to > go back and get more except in exceptional circumstances. I disagree - at least for home users. Most home users simply unpack the ISP router, plug it in, and connect = their devices to it. They plug in their webcams = https://www.theregister.co.uk/2017/06/08/whitebox_webcam_scatters_vulnerab= ilities_through_multiple_oems/ plug in their "smart" lightbulbs = https://www.theregister.co.uk/2016/07/27/osram_smart_lightbulbs/ plug in their "smart" doorbell & locks = https://www.theregister.co.uk/2016/01/12/ring_doorbell_reveals_wifi_creden= tials/ = http://www.theregister.co.uk/2016/08/08/using_a_smart_bluetooth_lock_to_pr= otect_your_valuables_youre_an_idiot/ connect their kids toys = http://www.theregister.co.uk/2015/02/19/hello_barbie/ and their own = "toys" = http://www.theregister.co.uk/2016/08/07/your_sec_toy_is_spying_on_you_hack= ers_crack_our_plastic_pals/ I could go on (kettles, fridges, bathroom scales, ... all with reported = security flaws), but I think you get the idea ! All of this will be on one network, one subnet/prefix. The majority of = users (some small rounding error below 100%) will have no idea at all = about networking, they won't have any clue about setting up multiple = networks - and the way much of the kit works, it won't work anyway if = the device isn't on the same network/subnet/prefix and the users = phone/tablet. I recall a few years ago visiting my alma mater and found that ethernet = ports had appeared in the rooms. When I plugged into one, I could see = all the security cameras etc were on the same segment and even the same = subnet ! If a university college can't get simple things like this = right, what makes you think home users will do any better ? As I sit here (as part of that rounding error of users), to be frank, I = am struggling to think what I could (practically) use 10 separate = networks for, let alone 100 or 200 or 256 ! > Note: the rule always has been "if you don't have enough prefixes > ask your ISP for more". At which point you come up against the technically illiterate = beancounters running (some of) the ISPs who figure that if you want more = IPs then you must be a customer worthy of paying them more. The same = ones who, in the IPv4 world want a significant amount extra just to have = a single fixed IP rather than a dynamic one, and even more if you want = more than one address. From nobody Fri Jun 9 03:10:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77D6129455 for ; Fri, 9 Jun 2017 03:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hDiKF1pK2lY for ; Fri, 9 Jun 2017 03:10:02 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 813961201F8 for ; Fri, 9 Jun 2017 03:10:02 -0700 (PDT) X-AuditID: 60721c4c-813ff7000000211d-79-593a73f78ebe Received: from VAADCEX43.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id D7.33.08477.7F37A395; Fri, 9 Jun 2017 06:10:01 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX43.cable.comcast.com (147.191.103.220) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Jun 2017 06:09:58 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Fri, 9 Jun 2017 06:09:57 -0400 From: "Leddy, John" To: Simon Hobson , 6man WG Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Thread-Topic: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) Thread-Index: AQHS4Qdfh/nIwD5xZ0m2+eOfSnT1nKIcTwmA Date: Fri, 9 Jun 2017 10:09:57 +0000 Message-ID: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="utf-8" Content-ID: <235513791818E0498B881C4002EA1555@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA12Uf2wTZRjHfa/X9Vb64suNti/nVuUQiboflShW4g80UwcB9Z8Fij/g1p1r XX9x15ZV/8HoDM4/wMU0rJGIsayMLVFnkAlqYplMluCiI6hMNHUzplNhEhOdiYvve9fbrv51 z32+7/N8n+d5L8dZ+FK1wIWiCVmJSmGxys7uVjf7GubVjX7viT94X+n8Vcb37+BQ1SamJZeb Z1r+Hrtqe4LZab+3XQ6HUrLSdP9ue7D4di8b/7Cha+CfjG0fOFLfA6o5jO7E3T8W2R5g53h0 ksH5nn6L/vIZwPn9Q1b95QuAvzo9ZqMpVageH8pctNJ4JXoIF78f0eIatBmfPXmF0fkWfLm/ h5znSLweLwxspZhFN+NzEx9pxyFqxoMHxspmkzZ8OPOqJlQToS+TZ2kMkAv/NT6k1bQgN740 8xajt41w7uMJix47cWl6Qct1okY8fPyV8pl6fP6bGaDHXnzi6KesHt+IRw8usLQ3C7oVv3uq SQ834fFf3LrTavzGa0Wb3uYKfK5vppzpxmdGR6wHgZA1NZRdKpRdKpQ1FcqaCh0B1uPAk5Kk 9kAkGEsmvOsbA1JbWG4MxCIBSU3Q5zCgV6zUbh0B1zItBYA4IDrg46GNft4qpdR0pAA6OUZ0 wkycoOVtsfZ0UFKDu5RkWFbFlbDZTjBcxG3JcKcowAsKoTWLNCrvVcNygnxTogeuzd7t592L mppU46FAKJZUdyWVcAFgzkLKVqm0bLuUfl5WYrpZAdzAsaIb4tQ9fh51SAm5U5bjsmKoezlO xDC1hySuUOQOuevZUDhhyCRPpgoyK1qzdTC6jRR0mQVTv6vh9F0kTzDL/2+Z4aoLoINzkL4f eJL2rcaliBrqKFvXQLePUIdBNdtVcJzuiDegybIOrqMrchlSpd04SAtu+ANNRvREMBldnFJw we8ue/389SaBugm18GvKnSa+ZCjcBItUXWVSKz2N38AsCJDPowb2UncH+UksDcnrd76sDLUZ MTys3UaZmUashbfQEZ1lpdJtluySIbvMXfHRXSakhHmXJUodBi3vcppC3oAVu5ylksuQKp2E feD24rLhQaddOjD4vrfQVJg83d3q2fMrjwc+v+/1rp+e2/HinH106OjPf068c2r/xTT/W6T7 2txZ5elj3uvezOfZl2wjvQsv71g+9/vOtR80r9ngaqybFFqntj/1wpmp2b7SvOeS7wL7bcP2 Q8+M5jxTaF3r/HuP2fo3WD7xc8EHH859+cijIqsGpTtusyiq9B8WGcuPfAUAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 10:10:05 -0000 4oCcICAgIEkgZGlzYWdyZWUgLSBhdCBsZWFzdCBmb3IgaG9tZSB1c2Vycy4NCiAgICBNb3N0IGhv bWUgdXNlcnMgc2ltcGx5IHVucGFjayB0aGUgSVNQIHJvdXRlciwgcGx1ZyBpdCBpbiwgYW5kIGNv bm5lY3QgdGhlaXIgZGV2aWNlcyB0byBpdC4NCiAgICBUaGV5IHBsdWcgaW4gdGhlaXIgd2ViY2Ft c+KApiDigJwNCg0KVGhpcyBpcyB3aGF0IEhvbWVuZXQgd2FzIHN1cHBvc2VkIHRvIHNvbHZlIOKA kyBhbiBlYXN5LCBhdXRvbWF0aWMgd2F5IHRvIHNlZ21lbnQgbmV0d29ya3MgYXQgTGF5ZXIgMy4N CkFzc2lnbiBwcmVmaXhlcyB3aGVyZSBhdCBsZWFzdCB0aGVyZSBpcyBhIGNoYW5jZSBhdCBQb2xp Y3kvU2VjdXJpdHkgYmV0d2VlbiB0aGVtIGFuZCBhdm9pZCB2ZXJ5IGRpc3NpbWlsYXIgTGF5ZXIg MiBzdWJuZXRzIGJlaW5nIGJyaWRnZWQgdG9nZXRoZXIg4oCTIHJlcXVpcmluZyBldmVyIGdyb3dp bmcgc2V0cyBvZiBBcHBsaWNhdGlvbiBhbmQgUHJvdG9jb2wgcHJveGllcyBiZXR3ZWVuIHRoZW0u DQoNCkpvaG4NCg0KT24gNi85LzE3LCA2OjAxIEFNLCAiaXB2NiBvbiBiZWhhbGYgb2YgU2ltb24g SG9ic29uIiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaW51eEB0aGVob2Jz b25zLmNvLnVrPiB3cm90ZToNCg0KICAgIE1hcmsgQW5kcmV3cyA8bWFya2FAaXNjLm9yZz4gd3Jv dGU6DQogICAgDQogICAgPj4gTXkgdmVyeSBsaW1pdGVkIGV4cGVyaWVuY2Ugd2l0aCBJU1AgcHJv dmlkZWQgSVB2NiBpcyB0aGF0IHNvIGZhciwgd2hhdA0KICAgID4+IEkndmUgc2VlbiBpcyBzZW5z aWJsZSBhbGxvY2F0aW9ucyAoZWcgYSAvNTYgZm9yIGEgaG9tZSB1c2VyKS4gSWYgdGhlDQogICAg Pj4gbWFqb3JpdHkgZG8gdGhlIHJpZ2h0IHRoaW5nLCB0aGVuIHRoZSBleGNlcHRpb25zIGNhbiBz dGFuZCBvdXQgYW5kIGdldCBhDQogICAgPj4gcmVwdXRhdGlvbiBmb3IgImJyb2tlbiIuIEkga25v dyBpbiB0aGUgcmVhbCB3b3JsZCB0aGVyZSB3aWxsIGJlIGNhc2VzDQogICAgPj4gd2hlcmUgdGhl cmUncyBhbiBlZmZlY3RpdmUgbW9ub3BvbHkgKGZvciBzb21lIGdyb3VwIG9mIHVzZXJzKSBhbGxv d2luZw0KICAgID4+IHRoZSBJU1AgdG8gZG8gd2hhdCB0aGV5IHdhbnQsIGJ1dCB0aGF0J3Mgbm90 IGFuIGV4Y3VzZSB0byBqdXN0IHRocm93IGluDQogICAgPj4gdGhlIHRvd2VsIGFuZCBnaXZlIHRo ZSByZXN0IGNhcnRlIGJsYW5jaC4NCiAgICA+IA0KICAgID4gQW5kIDI1NiBwcmVmaXhlcyB2ZXJ5 IHF1aWNrbHkgYmVjb21lIHRvbyBmZXcgYXMgd2UgZGV2ZWxvcCBuZXcNCiAgICA+IHRlY2hub2xv Z2llcyB0byB0YWtlIGFkdmFudGFnZSB0aGF0IHlvdSBjYW4gZ2V0IHByZWZpeGVzIGVhc2lseS4N CiAgICA+IElTUCdzIGhhdmUgYmVlbiBzaG9ydCBzaWdodGVkIGhlcmUuICBUaGUgSUVURiBzdGFy dGVkIG91dCBzYXlpbmcNCiAgICA+IC80OCB0byBnaXZlIGV2ZXJ5IHNpdGUgZW5vdWdoIHByZWZp eGVzIHRoYXQgdGhleSBzaG91bGRuJ3QgaGF2ZSB0bw0KICAgID4gZ28gYmFjayBhbmQgZ2V0IG1v cmUgZXhjZXB0IGluIGV4Y2VwdGlvbmFsIGNpcmN1bXN0YW5jZXMuDQogICAgDQogICAgSSBkaXNh Z3JlZSAtIGF0IGxlYXN0IGZvciBob21lIHVzZXJzLg0KICAgIE1vc3QgaG9tZSB1c2VycyBzaW1w bHkgdW5wYWNrIHRoZSBJU1Agcm91dGVyLCBwbHVnIGl0IGluLCBhbmQgY29ubmVjdCB0aGVpciBk ZXZpY2VzIHRvIGl0Lg0KICAgIFRoZXkgcGx1ZyBpbiB0aGVpciB3ZWJjYW1zIGh0dHBzOi8vd3d3 LnRoZXJlZ2lzdGVyLmNvLnVrLzIwMTcvMDYvMDgvd2hpdGVib3hfd2ViY2FtX3NjYXR0ZXJzX3Z1 bG5lcmFiaWxpdGllc190aHJvdWdoX211bHRpcGxlX29lbXMvDQogICAgcGx1ZyBpbiB0aGVpciAi c21hcnQiIGxpZ2h0YnVsYnMgaHR0cHM6Ly93d3cudGhlcmVnaXN0ZXIuY28udWsvMjAxNi8wNy8y Ny9vc3JhbV9zbWFydF9saWdodGJ1bGJzLw0KICAgIHBsdWcgaW4gdGhlaXIgInNtYXJ0IiBkb29y YmVsbCAmIGxvY2tzIGh0dHBzOi8vd3d3LnRoZXJlZ2lzdGVyLmNvLnVrLzIwMTYvMDEvMTIvcmlu Z19kb29yYmVsbF9yZXZlYWxzX3dpZmlfY3JlZGVudGlhbHMvDQogICAgaHR0cDovL3d3dy50aGVy ZWdpc3Rlci5jby51ay8yMDE2LzA4LzA4L3VzaW5nX2Ffc21hcnRfYmx1ZXRvb3RoX2xvY2tfdG9f cHJvdGVjdF95b3VyX3ZhbHVhYmxlc195b3VyZV9hbl9pZGlvdC8NCiAgICBjb25uZWN0IHRoZWly IGtpZHMgdG95cyBodHRwOi8vd3d3LnRoZXJlZ2lzdGVyLmNvLnVrLzIwMTUvMDIvMTkvaGVsbG9f YmFyYmllLyBhbmQgdGhlaXIgb3duICJ0b3lzIiBodHRwOi8vd3d3LnRoZXJlZ2lzdGVyLmNvLnVr LzIwMTYvMDgvMDcveW91cl9zZWNfdG95X2lzX3NweWluZ19vbl95b3VfaGFja2Vyc19jcmFja19v dXJfcGxhc3RpY19wYWxzLw0KICAgIA0KICAgIEkgY291bGQgZ28gb24gKGtldHRsZXMsIGZyaWRn ZXMsIGJhdGhyb29tIHNjYWxlcywgLi4uIGFsbCB3aXRoIHJlcG9ydGVkIHNlY3VyaXR5IGZsYXdz KSwgYnV0IEkgdGhpbmsgeW91IGdldCB0aGUgaWRlYSAhDQogICAgQWxsIG9mIHRoaXMgd2lsbCBi ZSBvbiBvbmUgbmV0d29yaywgb25lIHN1Ym5ldC9wcmVmaXguIFRoZSBtYWpvcml0eSBvZiB1c2Vy cyAoc29tZSBzbWFsbCByb3VuZGluZyBlcnJvciBiZWxvdyAxMDAlKSB3aWxsIGhhdmUgbm8gaWRl YSBhdCBhbGwgYWJvdXQgbmV0d29ya2luZywgdGhleSB3b24ndCBoYXZlIGFueSBjbHVlIGFib3V0 IHNldHRpbmcgdXAgbXVsdGlwbGUgbmV0d29ya3MgLSBhbmQgdGhlIHdheSBtdWNoIG9mIHRoZSBr aXQgd29ya3MsIGl0IHdvbid0IHdvcmsgYW55d2F5IGlmIHRoZSBkZXZpY2UgaXNuJ3Qgb24gdGhl IHNhbWUgbmV0d29yay9zdWJuZXQvcHJlZml4IGFuZCB0aGUgdXNlcnMgcGhvbmUvdGFibGV0Lg0K ICAgIA0KICAgIEkgcmVjYWxsIGEgZmV3IHllYXJzIGFnbyB2aXNpdGluZyBteSBhbG1hIG1hdGVy IGFuZCBmb3VuZCB0aGF0IGV0aGVybmV0IHBvcnRzIGhhZCBhcHBlYXJlZCBpbiB0aGUgcm9vbXMu IFdoZW4gSSBwbHVnZ2VkIGludG8gb25lLCBJIGNvdWxkIHNlZSBhbGwgdGhlIHNlY3VyaXR5IGNh bWVyYXMgZXRjIHdlcmUgb24gdGhlIHNhbWUgc2VnbWVudCBhbmQgZXZlbiB0aGUgc2FtZSBzdWJu ZXQgISBJZiBhIHVuaXZlcnNpdHkgY29sbGVnZSBjYW4ndCBnZXQgc2ltcGxlIHRoaW5ncyBsaWtl IHRoaXMgcmlnaHQsIHdoYXQgbWFrZXMgeW91IHRoaW5rIGhvbWUgdXNlcnMgd2lsbCBkbyBhbnkg YmV0dGVyID8NCiAgICANCiAgICBBcyBJIHNpdCBoZXJlIChhcyBwYXJ0IG9mIHRoYXQgcm91bmRp bmcgZXJyb3Igb2YgdXNlcnMpLCB0byBiZSBmcmFuaywgSSBhbSBzdHJ1Z2dsaW5nIHRvIHRoaW5r IHdoYXQgSSBjb3VsZCAocHJhY3RpY2FsbHkpIHVzZSAxMCBzZXBhcmF0ZSBuZXR3b3JrcyBmb3Is IGxldCBhbG9uZSAxMDAgb3IgMjAwIG9yIDI1NiAhDQogICAgDQogICAgPiBOb3RlOiB0aGUgcnVs ZSBhbHdheXMgaGFzIGJlZW4gImlmIHlvdSBkb24ndCBoYXZlIGVub3VnaCBwcmVmaXhlcw0KICAg ID4gYXNrIHlvdXIgSVNQIGZvciBtb3JlIi4NCiAgICANCiAgICBBdCB3aGljaCBwb2ludCB5b3Ug Y29tZSB1cCBhZ2FpbnN0IHRoZSB0ZWNobmljYWxseSBpbGxpdGVyYXRlIGJlYW5jb3VudGVycyBy dW5uaW5nIChzb21lIG9mKSB0aGUgSVNQcyB3aG8gZmlndXJlIHRoYXQgaWYgeW91IHdhbnQgbW9y ZSBJUHMgdGhlbiB5b3UgbXVzdCBiZSBhIGN1c3RvbWVyIHdvcnRoeSBvZiBwYXlpbmcgdGhlbSBt b3JlLiBUaGUgc2FtZSBvbmVzIHdobywgaW4gdGhlIElQdjQgd29ybGQgd2FudCBhIHNpZ25pZmlj YW50IGFtb3VudCBleHRyYSBqdXN0IHRvIGhhdmUgYSBzaW5nbGUgZml4ZWQgSVAgcmF0aGVyIHRo YW4gYSBkeW5hbWljIG9uZSwgYW5kIGV2ZW4gbW9yZSBpZiB5b3Ugd2FudCBtb3JlIHRoYW4gb25l IGFkZHJlc3MuDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QNCiAgICBpcHY2QGlldGYub3JnDQogICAgQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KICAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQogICAgDQogICAgDQoNCg== From nobody Fri Jun 9 04:25:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF80512711E for ; Fri, 9 Jun 2017 04:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NinAixOTpOKY for ; Fri, 9 Jun 2017 04:25:36 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE2D12956D for ; Fri, 9 Jun 2017 04:25:34 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 86A4D832D8; Fri, 9 Jun 2017 13:25:49 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: David Farmer , Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> From: Fernando Gont Message-ID: <3c9f6fca-f356-67c0-5e43-077e039dce86@si6networks.com> Date: Fri, 9 Jun 2017 14:06:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 11:25:39 -0000 On 06/09/2017 09:36 AM, Lorenzo Colitti wrote: > On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont > wrote: > > > However, I think IPv6 implementations that don't support manual > > configuration must be able to reject non-64 bit IIDs, since that is the > > standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or > > /123", and those are against BCP 204 (RFC 7934). > > BCP204 talks about multiple addresses. As long as whatever prefix is > employed allows for multiple addresses, I don't see how that goes > against BCP204. > > > That's not true at all. As an example: see if you can build a network > that uses a /99 and satisfies the recommendations in section 8 or BCP 204. Could you explain why a 799 wouldn't satisfy bcp204? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 05:29:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A44A129AD7 for ; Fri, 9 Jun 2017 05:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxWEvTOygrAI for ; Fri, 9 Jun 2017 05:29:16 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C29129B06 for ; Fri, 9 Jun 2017 05:29:16 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 669DD805AC; Fri, 9 Jun 2017 14:29:32 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org, Brian E Carpenter Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> From: Fernando Gont Message-ID: <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> Date: Fri, 9 Jun 2017 15:24:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 12:29:18 -0000 On 06/09/2017 10:46 AM, otroan@employees.org wrote: > >> On 6 Jun 2017, at 00:25, Brian E Carpenter wrote: >> >> On 05/06/2017 19:45, Lorenzo Colitti wrote: >>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> None of that is the point. The point is to establish >>>> that routing is classless >>> >>> >>> Routing is already classless because BCP 198. >>> >>> >>>> and /64 is a parameter of specific addressing schemes. >>>> >>> >>> It *is* a parameter. The parameter's value is 64 for all unicast addresses >>> except those starting with 000. >> >> The parameter's *current* value, yes. But should we really be fixing >> the value of the parameter once and for all in the addressing architecture? >> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >> assumes? > > do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? At the time of this writing, we should probably be in the camp of "If you do slaac, better stick to 64, since it's know to work with legacy implementations, and besides, allows for sparse allocation (reduced collisions of IIDs when you pick a random one, resistance to address scans, etc.). There's no compelling technical argument for mandating /64 (i.e., such specific value) if you do manual configuration or, for instance, stateful DHCPv6. And the recommendation for /64 for slaac mostly has to do with backwards compatibility than with anything else. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 05:45:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FFC128B44 for ; Fri, 9 Jun 2017 05:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1JndpTafl4C for ; Fri, 9 Jun 2017 05:45:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D58127137 for ; Fri, 9 Jun 2017 05:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1497012345; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=72xeNk8lfhkx7EgXycgey1Kumf2CrjZyw4xHCevGThk=; b=cd+nwTe+Msa2gDrYsu/gMSXZ6g7XSM/9ZWjUSf0UTalpXegcf2SmuqPCnM094CdKY5ICmTJxT3IwDeWE180FybgKO7IRspf8WbgnxlZQXBtoTtTRQ7aUkEY8+xNGt8/jNLKy4PePrsALpqIkpfxSeuID699lOfwYpXX+kBFi/TE= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0151.outbound.protection.outlook.com [213.199.180.151]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-80-hck5EDrlMzyC93DKnWsjLA-1; Fri, 09 Jun 2017 13:45:40 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB275.eurprd07.prod.outlook.com (10.242.18.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Fri, 9 Jun 2017 12:45:39 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d2f:d4cd:c3bf:b708]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d2f:d4cd:c3bf:b708%15]) with mapi id 15.01.1178.006; Fri, 9 Jun 2017 12:45:39 +0000 From: Tim Chown To: Fernando Gont CC: 6man WG Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4PSR9UKMgETCHEKlrb4cRNK+sqIcdOaAgAAFxwA= Date: Fri, 9 Jun 2017 12:45:39 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> In-Reply-To: <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB275; 20:ZGUb4wZ6cB3Cj6Z1PnazEQgUwagSE/NcvL6hZuchRiulHAsRaxBAu6tZ0Q70liAW1S5dWPfznXB0w6uW5iJuyojLTveS+cOiKE3wT6h5tnNZzH0OGHfF5d7ZL6/ZAs9nN9/+SXvZywz2APartimSzEOBeoWyvsKF7YCLKvJiSL0= x-ms-office365-filtering-correlation-id: 6afaedc2-66bd-4821-484f-08d4af356ec1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB275; x-ms-traffictypediagnostic: AM3PR07MB275: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB275; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(24454002)(2906002)(3280700002)(8936002)(189998001)(82746002)(74482002)(6436002)(2900100001)(6512007)(7736002)(99286003)(81166006)(305945005)(72206003)(83716003)(53546009)(25786009)(36756003)(5660300001)(76176999)(53936002)(5250100002)(57306001)(50986999)(4326008)(6506006)(230783001)(14454004)(86362001)(8676002)(6486002)(6916009)(42882006)(110136004)(3846002)(66066001)(50226002)(3660700001)(6246003)(2950100002)(93886004)(38730400002)(229853002)(478600001)(102836003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB275; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <82254862A28A0E4C897F4E86DC57E7B8@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 12:45:39.1740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB275 X-MC-Unique: hck5EDrlMzyC93DKnWsjLA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 12:45:50 -0000 PiBPbiA5IEp1biAyMDE3LCBhdCAxMzoyNCwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29y a3MuY29tPiB3cm90ZToNCj4gDQo+IEF0IHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZywgd2Ugc2hv dWxkIHByb2JhYmx5IGJlIGluIHRoZSBjYW1wIG9mICJJZg0KPiB5b3UgZG8gc2xhYWMsIGJldHRl ciBzdGljayB0byA2NCwgc2luY2UgaXQncyBrbm93IHRvIHdvcmsgd2l0aCBsZWdhY3kNCj4gaW1w bGVtZW50YXRpb25zLCBhbmQgYmVzaWRlcywgYWxsb3dzIGZvciBzcGFyc2UgYWxsb2NhdGlvbiAo cmVkdWNlZA0KPiBjb2xsaXNpb25zIG9mIElJRHMgd2hlbiB5b3UgcGljayBhIHJhbmRvbSBvbmUs IHJlc2lzdGFuY2UgdG8gYWRkcmVzcw0KPiBzY2FucywgZXRjLikuDQo+IA0KPiBUaGVyZSdzIG5v IGNvbXBlbGxpbmcgdGVjaG5pY2FsIGFyZ3VtZW50IGZvciBtYW5kYXRpbmcgLzY0IChpLmUuLCBz dWNoDQo+IHNwZWNpZmljIHZhbHVlKSBpZiB5b3UgZG8gbWFudWFsIGNvbmZpZ3VyYXRpb24gb3Is IGZvciBpbnN0YW5jZSwNCj4gc3RhdGVmdWwgREhDUHY2LiBBbmQgdGhlIHJlY29tbWVuZGF0aW9u IGZvciAvNjQgZm9yIHNsYWFjIG1vc3RseSBoYXMgdG8NCj4gZG8gd2l0aCBiYWNrd2FyZHMgY29t cGF0aWJpbGl0eSB0aGFuIHdpdGggYW55dGhpbmcgZWxzZS4NCg0KSSB0aGluayB0aGUgdGVybSDi gJxtYW51YWwgY29uZmlndXJhdGlvbuKAnSBmb3Igbm9uLVNMQUFDIGNhc2VzIGlzIGEgbGl0dGxl IG1pc2xlYWRpbmcuIE1hbnkgZGVwbG95bWVudHMsIGJlIHRoZXkgc2VydmVyIGRlcGxveW1lbnRz LCBvciBwb2ludC10by1wb2ludCBsaW5rIGNvbmZpZ3VyYXRpb25zLCBhcmUgbGlrZWx5IHRvIGJl IGluY3JlYXNpbmdseSBhdXRvbWF0aWNhbGx5IHByb3Zpc2lvbmVkIGluIHNvbWUgd2F5OyB0aGVu IHRoZXJlIGlzIG5vIOKAnG1hbnVhbOKAnSBjb25maWd1cmF0aW9uIHBlciBzZS4gDQoNClRpbQ== From nobody Fri Jun 9 05:55:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46761129B2C for ; Fri, 9 Jun 2017 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66nVZqlWdl3F for ; Fri, 9 Jun 2017 05:55:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03A129B2B for ; Fri, 9 Jun 2017 05:55:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dJJRa-0000FVC; Fri, 9 Jun 2017 14:55:14 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> In-reply-to: Your message of "Fri, 9 Jun 2017 12:45:39 +0000 ." Date: Fri, 09 Jun 2017 14:55:13 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 12:55:18 -0000 > I think the term manual configuration for non-SLAAC cases is a > little misleading. Many deployments, be they server deployments, > or point-to-point link configurations, are likely to be increasingly > automatically provisioned in some way; then there is no manual > configuration per se. Historically, in a networking context, this is called manual or static configuration. I'm not aware of a any term that is in wide spread use that specifically refers to the case where host addresses are set by provisioning software. From nobody Fri Jun 9 06:00:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833631201F2 for ; Fri, 9 Jun 2017 06:00:22 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de_QG9FNEvu7 for ; Fri, 9 Jun 2017 06:00:15 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 B838B12878D for ; Fri, 9 Jun 2017 06:00:15 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 81E5824AE09; Fri, 9 Jun 2017 12:58:52 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 32057160044; Fri, 9 Jun 2017 12:58:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1F8F616006B; Fri, 9 Jun 2017 12:58:55 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lg3RNxbQXuVA; Fri, 9 Jun 2017 12:58:55 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A533B160044; Fri, 9 Jun 2017 12:58:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 29C107B6EB8F; Fri, 9 Jun 2017 22:58:52 +1000 (AEST) To: Simon Hobson Cc: 6man WG From: Mark Andrews References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) In-reply-to: Your message of "Fri, 09 Jun 2017 11:01:33 +0100." Date: Fri, 09 Jun 2017 22:58:52 +1000 Message-Id: <20170609125852.29C107B6EB8F@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 13:00:22 -0000 In message , Simon Hobso n writes: > Mark Andrews wrote: > > >> My very limited experience with ISP provided IPv6 is that so far, what > >> I've seen is sensible allocations (eg a /56 for a home user). If the > >> majority do the right thing, then the exceptions can stand out and get a > >> reputation for "broken". I know in the real world there will be cases > >> where there's an effective monopoly (for some group of users) allowing > >> the ISP to do what they want, but that's not an excuse to just throw in > >> the towel and give the rest carte blanch. > > > > And 256 prefixes very quickly become too few as we develop new > > technologies to take advantage that you can get prefixes easily. > > ISP's have been short sighted here. The IETF started out saying > > /48 to give every site enough prefixes that they shouldn't have to > > go back and get more except in exceptional circumstances. > > I disagree - at least for home users. > Most home users simply unpack the ISP router, plug it in, and connect their d > evices to it. > They plug in their webcams https://www.theregister.co.uk/2017/06/08/whitebox_ > webcam_scatters_vulnerabilities_through_multiple_oems/ > plug in their "smart" lightbulbs https://www.theregister.co.uk/2016/07/27/osr > am_smart_lightbulbs/ > plug in their "smart" doorbell & locks https://www.theregister.co.uk/2016/01/ > 12/ring_doorbell_reveals_wifi_credentials/ > http://www.theregister.co.uk/2016/08/08/using_a_smart_bluetooth_lock_to_prote > ct_your_valuables_youre_an_idiot/ > connect their kids toys http://www.theregister.co.uk/2015/02/19/hello_barbie/ > and their own "toys" http://www.theregister.co.uk/2016/08/07/your_sec_toy_is > _spying_on_you_hackers_crack_our_plastic_pals/ > > I could go on (kettles, fridges, bathroom scales, ... all with reported secur > ity flaws), but I think you get the idea ! > All of this will be on one network, one subnet/prefix. The majority of users > (some small rounding error below 100%) will have no idea at all about network > ing, they won't have any clue about setting up multiple networks - and the wa > y much of the kit works, it won't work anyway if the device isn't on the same > network/subnet/prefix and the users phone/tablet. Just because you are not used to home routers that configure multiple subnets doesn't mean they don't exist. > I recall a few years ago visiting my alma mater and found that ethernet > ports had appeared in the rooms. When I plugged into one, I could see > all the security cameras etc were on the same segment and even the same > subnet ! If a university college can't get simple things like this right, > what makes you think home users will do any better ? Because we will ship routers that do multiple subnets by default because that is what is needed to deal with situations like you describe above. > As I sit here (as part of that rounding error of users), to be frank, I > am struggling to think what I could (practically) use 10 separate networks > for, let alone 100 or 200 or 256 ! Uses will come up. I use 3 subnets today for the home. I would expect that I'll use more in the future. Once more than one becomes common people will design stuff that can make use of additional subnets. > > Note: the rule always has been "if you don't have enough prefixes > > ask your ISP for more". > > At which point you come up against the technically illiterate > beancounters running (some of) the ISPs who figure that if you want more > IPs then you must be a customer worthy of paying them more. The same ones > who, in the IPv4 world want a significant amount extra just to have a > single fixed IP rather than a dynamic one, and even more if you want more > than one address. A /48 costs a cent. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 9 07:32:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79085129B07 for ; Fri, 9 Jun 2017 07:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65jiLX0YM2VF for ; Fri, 9 Jun 2017 07:31:58 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 5FEC01200E5 for ; Fri, 9 Jun 2017 07:31:58 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id AE3A694E for ; Fri, 9 Jun 2017 14:31:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLYaCpwrQaAt for ; Fri, 9 Jun 2017 09:31:57 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 78CAA1AD for ; Fri, 9 Jun 2017 09:31:57 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id g66so8203521vki.0 for ; Fri, 09 Jun 2017 07:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ODCCyGd4NO9RYuHjBr8tvZPQ/4v8LYxRILR97qpdoyo=; b=qTwtFRBaRMafqrdIQ3MJ9t/Uqi0l2sQxQlMcuU/+iBk/5iKhklUoBEMNS+4b7Ai1DY c/mV3FURHFzZy2ZB8z15+CXkWd04qaxaX+ifwwDyTp4/nN4DMWwVC8UpKR7dTAYDybDo 1YI2NnVnKQZiHgw07Zwi8BOlC4PwJyX+hQbid4c3A5qydN4DFAwkRsHIhI3w4UUybBQf 8F1fWY8cNys5DbJgMnLhqZjbHSlVnQ33qxaMnF2oGyel/CQAIpA5Xs3VRjRRQ05qgqJk 2oCQjaqYUb4s9tbUuW5xsHIAzsiwXGAvMgZU3gRip2sT7oP5l5Q3i6WFY+n6JxSE7Rkd d95Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ODCCyGd4NO9RYuHjBr8tvZPQ/4v8LYxRILR97qpdoyo=; b=gOB38IwZeAy03rSsAYUIFyvuyiL3GYR22c5fmY5zu6ASNm8L6wDP2zgrBTgxCJdUHP 6p4qI2hxTg7o9V5Y4foxrcZ30MHUTCv6M0/n7tV/yQhiaopTDbVdMjtfDFBriEOTkFcU +17owcn+FSfWg++GhtP2m4yZh32Fa3h3adKOwwIJJV+I97duRZT9dSdvLhRXLD3Lzcvr K+EAfqSBjHdLr6nezIEZrI8oacsYXi+wyAqwZD73qasCovB4QIUGsVsJJwYbeJ/0QP+K LCqLhEHZPpuJVAo4O+x8+ABx9Q0iyibnG6xQUbiHBVdXGZWAIA9KsObTdfF+V7UQx70x 9+pg== X-Gm-Message-State: AODbwcDNzMWCUkdI1vOKs3LK2dBM77utTbxwKnI5uUQAle//cjOQpszX NOkr8yFAuaqsNtPitumey55qRtahaxGAh96vK6ecKjVomC/kgfJnFqeAgHu9Il/KoS24OSO6+DI RDG7gGnhak/R9RdM= X-Received: by 10.159.53.72 with SMTP id o66mr3243231uao.113.1497018716442; Fri, 09 Jun 2017 07:31:56 -0700 (PDT) X-Received: by 10.159.53.72 with SMTP id o66mr3243221uao.113.1497018716258; Fri, 09 Jun 2017 07:31:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Fri, 9 Jun 2017 07:31:55 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> From: David Farmer Date: Fri, 9 Jun 2017 09:31:55 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Fernando Gont , Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="94eb2c03d0b2ce1907055187d4b9" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 14:32:00 -0000 --94eb2c03d0b2ce1907055187d4b9 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 1:36 AM, Lorenzo Colitti wrote: > On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont > wrote: > >> > However, I think IPv6 implementations that don't support manual >> > configuration must be able to reject non-64 bit IIDs, since that is the >> > standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or >> > /123", and those are against BCP 204 (RFC 7934). >> >> BCP204 talks about multiple addresses. As long as whatever prefix is >> employed allows for multiple addresses, I don't see how that goes >> against BCP204. > > > That's not true at all. As an example: see if you can build a network that > uses a /99 and satisfies the recommendations in section 8 or BCP 204. > Yes, to meet the specific RECOMMENDATIONS in BCP204 /64 is necessary. However, the fundamental intent of BCP 204 is that general-purpose hosts should get as many addresses as they reasonably want, in some situation hundreds or thousands of addresses could be consider unreasonable. I'll note it doesn't directly speak to security or privacy consideration such as randomized assignment or even suggest sparse assignment, it does reference RFC7217 in the Common IPv6 Deployment Model section, but that's it. So, in short BCP204 is fundamentally about making sure hosts have many addresses available to them. It seems to me that extremely long prefixes like /120 or longer are likely unable to achieve the intent of BCP204 for any significant number of hosts. However, anything in the range /112 or shorter should have plenty of address to achieve the intent of BCP204 for a quite reasonable numbers of hosts, at least many hundreds of hosts. So, of the examples you provided, /123 is unlikely to achieve the intent of BCP204, but /81 or /99, while they don't meet the specific RECOMMENDATIONS of BCP204 there doesn't seem to be any reason they couldn't achieve the fundamental intent of BCP204, granted with without much sparseness or entropy in the assignments, but that's not specifically part of BCP204. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c03d0b2ce1907055187d4b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 9, 2017 at 1:36 AM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
<= div dir=3D"ltr">
On Fr= i, Jun 9, 2017 at 1:24 PM, Fernando Gont <fgont@si6networks.com>= ; wrote:
= > However, I think IPv6 implementations that don't support manual > configuration must be able to reject non-64 bit IIDs, since that is th= e
> standard. Saying "SHOULD be 64 bits long" means they "M= AY be /81, /99 or
> /123", and those are against BCP 204 (RFC 7934).

BCP204 talks about multiple addresses. As long as whatever prefix is=
employed allows for multiple addresses, I don't see how that goes
against BCP204.

That's not true at all.= As an example: see if you can build a network that uses a /99 and satisfie= s the recommendations in section 8 or BCP 204.

Yes, to meet the specific RECOMMENDATIONS in BCP204 = /64 is necessary. However, the fundamental intent of BCP 204 is that genera= l-purpose hosts should get as many addresses as they reasonably want, in so= me situation=C2=A0hund= reds or thousands of=C2=A0addresses could be consider unreasonable.=C2=A0 I'll = note it doesn't directly speak=C2=A0to security or privacy consideratio= n such as randomized assignment or even suggest sparse assignment, it does = reference RFC7217 in the Common IPv6 Deployment Model=C2=A0section, but tha= t's it. So, in short BCP204 is fundamentally=C2=A0about making sure hos= ts have many addresses available=C2=A0to them.=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0

It see= ms to me that extremely long prefixes like /120 or longer are likely unable= to achieve the intent of BCP204 for any significant number of hosts. Howev= er, anything in the range /112 or shorter should have plenty of address to = achieve the intent of BCP204 for a quite reasonable numbers of hosts, at le= ast many hundreds of hosts.

So, of the examples yo= u provided, /123 is unlikely to achieve the intent of BCP204, but /81 or /9= 9, while they don't meet the specific RECOMMENDATIONS of BCP204 there d= oesn't seem to be any reason they couldn't achieve the fundamental = intent of BCP204, granted with without much sparseness or entropy in the as= signments, but that's not specifically part of BCP204.

Thanks.

=C2=A0

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Service= s
Office of Information Technology
University of Minnesota=C2=A0=C2= =A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-08= 15
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c03d0b2ce1907055187d4b9-- From nobody Fri Jun 9 08:16:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D588127735 for ; Fri, 9 Jun 2017 08:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cTuFV3WNQKD for ; Fri, 9 Jun 2017 08:16:18 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A2A1271DF for ; Fri, 9 Jun 2017 08:16:18 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 2CA2C833FA; Fri, 9 Jun 2017 17:16:33 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Tim Chown Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> From: Fernando Gont Message-ID: Date: Fri, 9 Jun 2017 16:14:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 15:16:21 -0000 On 06/09/2017 03:45 PM, Tim Chown wrote: >> On 9 Jun 2017, at 13:24, Fernando Gont wrote: >> >> At the time of this writing, we should probably be in the camp of "If >> you do slaac, better stick to 64, since it's know to work with legacy >> implementations, and besides, allows for sparse allocation (reduced >> collisions of IIDs when you pick a random one, resistance to address >> scans, etc.). >> >> There's no compelling technical argument for mandating /64 (i.e., such >> specific value) if you do manual configuration or, for instance, >> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to >> do with backwards compatibility than with anything else. > > I think the term “manual configuration†for non-SLAAC cases is a little misleading. Many deployments, be they server deployments, or point-to-point link configurations, are likely to be increasingly automatically provisioned in some way; then there is no “manual†configuration per se. Say "non-automatic"? Something else? (but..well... for the pov of IPv6, if it's not slaac or stateful dhcpv6, it's manual). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 08:16:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED87129B51 for ; Fri, 9 Jun 2017 08:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJrTp8wVfn84 for ; Fri, 9 Jun 2017 08:16:29 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEEF12960D for ; Fri, 9 Jun 2017 08:16:28 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 665C383406; Fri, 9 Jun 2017 17:16:44 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: David Farmer , Lorenzo Colitti Cc: Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> From: Fernando Gont Message-ID: Date: Fri, 9 Jun 2017 17:50:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 15:16:32 -0000 On 06/09/2017 05:31 PM, David Farmer wrote: > > > On Fri, Jun 9, 2017 at 1:36 AM, Lorenzo Colitti > wrote: > > On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont > wrote: > > > However, I think IPv6 implementations that don't support manual > > configuration must be able to reject non-64 bit IIDs, since that is the > > standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or > > /123", and those are against BCP 204 (RFC 7934). > > BCP204 talks about multiple addresses. As long as whatever prefix is > employed allows for multiple addresses, I don't see how that goes > against BCP204. > > > That's not true at all. As an example: see if you can build a > network that uses a /99 and satisfies the recommendations in section > 8 or BCP 204. > > > Yes, to meet the specific RECOMMENDATIONS in BCP204 /64 is necessary. I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED. > It seems to me that extremely long prefixes like /120 or longer are > likely unable to achieve the intent of BCP204 for any significant number > of hosts. However, anything in the range /112 or shorter should have > plenty of address to achieve the intent of BCP204 for a quite reasonable > numbers of hosts, at least many hundreds of hosts. > > So, of the examples you provided, /123 is unlikely to achieve the intent > of BCP204, but /81 or /99, while they don't meet the specific > RECOMMENDATIONS of BCP204 there doesn't seem to be any reason they > couldn't achieve the fundamental intent of BCP204, granted with without > much sparseness or entropy in the assignments, but that's not > specifically part of BCP204. Could you copy&paste the "specific recommendations" you're referring to? I haven't found any. And I see no reason for which the authors of bcp204 should have cared about a specific prefix length. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 08:30:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4B7129B51 for ; Fri, 9 Jun 2017 08:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5NCh3TKUkxi for ; Fri, 9 Jun 2017 08:30:06 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 930C7129AE8 for ; Fri, 9 Jun 2017 08:30:05 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id q97so37200844wrb.2 for ; Fri, 09 Jun 2017 08:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q2aVQcY5LovHCCpPD3rqrV/PiI+KHxhiSe6XFZ4/dok=; b=xkRMlkOuqzYP8CWd3Lh47t2Z/hULxGeqNPhAglAZd5DVYBmNQSVoubKeWLjgYAk5d0 dZ84jyyoRrgOX2VrLhR7BDURiZRVR4Gia++XMB1oOtHTO1/ufcFbBqlUiL6DqTqg+Fe+ abiDnZZkYlsAYKWurLai2TcH+7rq2KVM6TwNdNPFaPA1wD9ji8VtQsIOrKs14W4qnXr6 yyOs9VGQgOyLuqaI4rGey9DiXtTycHPkN87PyHQ6/nFw2T+MbQRaAv0mXXL1a8Hwo3pg 1+Nx4LzwwOrEeo0NOIPajVgp9qJI789iey1cTewwz7SjuMB56GuHrnU1ZsuCMadRtBYi OiTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q2aVQcY5LovHCCpPD3rqrV/PiI+KHxhiSe6XFZ4/dok=; b=SRoMwG3cbcGny/graBvgGxxuIrnc3Gr3qgcCTvXLrVHaaUOlRIx2yDD9+8+LY7sdCP dTy1sIU7ZmcPJv9ahS598O6fWnPlk05lsCXI8Yxb+fAqaGWwsLAVqDubHax0YSPxU+Jb N1HE5nwVTjgZ835HQIG9Mtxmi4k5DKwvLrm45EwIYLHMrAyEDu2OrsNSaOBTkAMGiAGV c8PHgbucDNobnGMRguCvxgYuVg21pbsVMbkqTzGPo6NNVnVIoSgfonz3n/HXO9Zl6xsP /GdNvSmdxZnjDaNbg1czs6GVHJJXzKjVDqrhOERbyszrUF4lD0Cq66j3MRVSAiCC+t3W aFGA== X-Gm-Message-State: AKS2vOyvyKiL07vjj3f/WcX2wazU/d0xIaNPC5V4ETv0LuLyh3Uj8TNG yA+sKNhinPZL4UvgXE24hLROhnIKSDN1 X-Received: by 10.28.23.131 with SMTP id 125mr78195wmx.42.1497022203974; Fri, 09 Jun 2017 08:30:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Fri, 9 Jun 2017 08:30:03 -0700 (PDT) In-Reply-To: References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Tom Herbert Date: Fri, 9 Jun 2017 08:30:03 -0700 Message-ID: Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Erik Kline , 6man WG , Job Snijders , Fernando Gont Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 15:30:09 -0000 On Fri, Jun 9, 2017 at 1:18 AM, Mark Smith wrote: > Hi Tom, > > On 9 Jun. 2017 13:03, "Tom Herbert" wrote: > > On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith wrote: >> On 9 June 2017 at 03:17, Fernando Gont wrote: >>> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: >>>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont >>> > wrote: >>>> > > > >> This is about raising the security bar, and with manually configured >> addresses with high entropy, or RFC7217 on routers and switches out of >> the box, raising it by default. If the device can't be discovered, it >> isn't possible to send a packet to it. >> > Mark, > > I don't quite understand this statement. Isn't is true that If I send > a packet to any IID in the prefix for a device it will reach the > device and be processed? > > > > Yes. You know the IID is valid at the point in time you send the packet, > meaning the IID is in use by a device and the device can be targetted with > an attack. > > This is mitigation against discovery of IIDs assigned to devices via > probing, prior to launching the attack on the device. > > I'm pointing out that concerns about discovery of valid addresses on > conventional hosts via probing can also be concerns for networking devices > with IPv6 addresses as well, such as routers and switches, and that large > entropy IIDs can provide them with an additional level of defence in depth > that wasn't possible to have in IPv4. The control planes of networking > devices are performing host functions too, so host security mitigations are > applicable. > > Some seem to believe that network devices software/firmware is far more > robust and they're universally configured far more securely such that > limiting the exposure and discoverability of the devices' addresses provides > no value. I think the links I provided earlier and the following links to > network OS vulnerabilities shows that this isn't the case. > > https://www.cvedetails.com/vulnerability-list/vendor_id-874/product_id-3989/Juniper-Junos.html > > https://www.cvedetails.com/vulnerability-list/vendor_id-16/product_id-19/Cisco-IOS.html > And wannacry exploits an OS vulnerability in Windows. I think the intent of address randomization might be in the right place, but there too many caveats to call this real security for hosts. As I said, when we do host development we can never assume that every network uniformly provides any in sort of security. It is prudent to assume the opposite: the network is an untrusted entity, anyone can intercept our packets, there is no firewall to protect us. Anything sent in the clear, including IP addresses, should be considered as being exposed to the whole world. If you want to hide something it needs to be encrypted. This is the correct mindset to start with for building robust and secure host implementations. Tom > > Regards, > Mark. > > > I may not get a response because that's not > the IID randomly chosen as the address of the device, but it still > seems like that could be used for DOS (like a tuple attack on a NIC > queue) if the prefix is discovered or predictable. > > > Tom > >> If you choose to specifically lower device security against discovery >> by putting routers in DNS, or allowing routers to respond to >> traceroutes, you consciously know you're lowering it for the specific >> device and can be vigilant when taking other measures to raise it >> again (ACLs etc.) >> >> Note that I'm not saying this is the only security measure you should >> have. It is an additional defence in depth measure that IPv6 >> addressing can provide to network infrastructure devices that IPv4 >> addressing could not. >> >> Regards, >> Mark. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > From nobody Fri Jun 9 09:42:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740D1127F0E for ; Fri, 9 Jun 2017 09:42:57 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nJ81E7CGJQ7 for ; Fri, 9 Jun 2017 09:42:56 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 25ABC124234 for ; Fri, 9 Jun 2017 09:42:56 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id c10so82149362qtd.1 for ; Fri, 09 Jun 2017 09:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=0xCTMZuVajRtnoz4knWgvEClxOSn2KJl6KTzlxnOAoY=; b=YTzB0frb6RPv/9pwAFWrqN49y5+bEDskXkwsP+ENEsLnz9w8nbcAQoGWgdWQj8JhOw G7nZlF9oKJctOh4V3lOTNumFzPEfF77PptGpL4iIJ6TuO6uO8s1EH4VuVbHS1wrvJ6hc /hUazmb/o8G+iZrcsbUuCW0Gpapur/GiFNsnJpKL8CDw6mAJcUNUvA5exbxmZs9iQXp9 FDLGw4z9ivIYeLxWwl0kPSzG2760TzXhJvXPlfFWSfeJsBdY0exgVmGTaRPrYK4sxlWq A+0YWa5G3q8m9rrgrQuJtCvv4qg62x+YIvPXov+RL9Ztgf+Ly5hm+veWT/lZOrMYZ2H2 uKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0xCTMZuVajRtnoz4knWgvEClxOSn2KJl6KTzlxnOAoY=; b=DaR6Pn54QeL0gJuaKJK5FeccZZMkPsTqNRBmZN0C0IMY2Ofe8+kE+khLqSL5uFuNG7 Z2IdXXSbCCJGRe7FX5cP/7YvgiPhfv0AYxY6WU2I+IPXx0C/VKr/Gafa5iu0jAP5r73L K4Y/JgRZSgnAIMw4Z/pqVxsJgaZalswxJnezKkRMdt+NqTZLSvNayU4pWFyTpwn46gnr I9vPoNnlSPyXSrJyhuRukVXHSzA1krsq8w2u9nH9HAuZPbGKiO+85nbPeYnhfTyf0xHs 1RtcUYGzBvSwpu9cOX0tWOH6ge+vFuh3OBuS1KqP6GVDqdgHxfG8d5wC0cAI0FkPNrqQ rEgQ== X-Gm-Message-State: AKS2vOxbdJ3ZLgl7tAFvXdSSJD+oAjSCicuwIAvMAjJiTgrLzW1RlFfY Sjjg2ixlm1CaHQ== X-Received: by 10.55.111.134 with SMTP id k128mr4837797qkc.206.1497026575217; Fri, 09 Jun 2017 09:42:55 -0700 (PDT) Received: from [200.7.87.94] ([2001:13c7:7001:7000:7dfd:5f3f:c1e9:6f2e]) by smtp.gmail.com with ESMTPSA id o50sm1020936qto.55.2017.06.09.09.42.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 09:42:54 -0700 (PDT) From: "Carlos M. Martinez" To: "Peter Hessler" Cc: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Fri, 09 Jun 2017 13:42:50 -0300 Message-ID: <443740A7-D86F-4B23-9DC2-828373A5F3E5@gmail.com> In-Reply-To: <20170604132200.GK30896@gir.theapt.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <5932DA16.9040008@foobar.org> <20170604124829.GI30896@gir.theapt.org> <20170604132200.GK30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_42E956A2-A3F6-4AB9-803C-D1C226F54033_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:42:57 -0000 --=_MailMate_42E956A2-A3F6-4AB9-803C-D1C226F54033_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello all, This has NOT been what we have been seeing in our measurements. In fact, for some of us it came as a bit of a surprise. We were looking into detecting IPv6 NAT in the wild. Obviously all experiments are limited and can be skewed in various ways, but the data we got so far seems to indicate a prevalence of over 95% for IPv4 NAT but hardly over 0.6% for IPv6 NAT. I am **very** interested in whatever concrete, specific evidence of IPv6 NAT you may have since I´d like to contrast it against our experiment and see what we could be doing wrong. Thank you! /Carlos On 4 Jun 2017, at 10:22, Peter Hessler wrote: > Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*. --=_MailMate_42E956A2-A3F6-4AB9-803C-D1C226F54033_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello all,

This has NOT been what we have been seeing in our measure= ments. In fact, for some of us it came as a bit of a surprise. We were lo= oking into detecting IPv6 NAT in the wild.

Obviously all experiments are limited and can be skewed i= n various ways, but the data we got so far seems to indicate a prevalence= of over 95% for IPv4 NAT but hardly over 0.6% for IPv6 NAT.

I am very interested in whatever concret= e, specific evidence of IPv6 NAT you may have since I=C2=B4d like to cont= rast it against our experiment and see what we could be doing wrong.

Thank you!

/Carlos

On 4 Jun 2017, at 10:22, Peter Hessler wrote:

Besides, *Lots of pe= ople are already deplyoing IPv6 NAT in the wild*.

--=_MailMate_42E956A2-A3F6-4AB9-803C-D1C226F54033_=-- From nobody Fri Jun 9 09:46:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AA4129422 for ; Fri, 9 Jun 2017 09:46:47 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ynIyUPd6zvl for ; Fri, 9 Jun 2017 09:46:45 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 772CE124234 for ; Fri, 9 Jun 2017 09:46:45 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id u19so82308554qta.3 for ; Fri, 09 Jun 2017 09:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=6/ZNlG0vZ9GfrD15FL7TnpsUS5mRVxmsJUTE9OonkFk=; b=hZfqKryf1vfeIzQBG6ddThEHqzMPcO2qdq4wXOPfgG4VoWdr6r1WZGGUXD+wku6F6E eLe0EW9ROJIMgRgPC2g1Og8WJ9/GUOgUBprg4iqT7bilw6qeKZN2NFDxvfOvLuyhiOmx KxHiNjJPXquNlGbXoS0lqeSENTVh/S1DtPSzVzY7CUb08DVCud4K1D6MxG1j3SF9tQuL T0nxeID/fRVjAvOjhCYftj7Ubj8RS05f6CXhb1eJ/PV/5nvbmTHsL2Rq1NiyeEDUMNcv yHhgr81y/00uixYnbUZQKWibT7L3DnvU+LqsXhgRK3NY+EY/1budYmuc5S+0M2poA2OE o+Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=6/ZNlG0vZ9GfrD15FL7TnpsUS5mRVxmsJUTE9OonkFk=; b=FVUdn+Iugk/FDybrIMtPF9oDbR0cpxL87HMK70/QN6sQn5iEy8K9gTSQkKQHQEIAWV +hEMFaHRnt5j2itEqLUiCBYyzTKhzBUNYDp31EOme5b2gSCY8SfzPQy/1QJFvn3ckiUS CT0+W5fY8zMBZO/sXSN7TJ2ppVdzW6lqGiGUiIinX2JG0/8rfS9PIs1+6DehsTW3w2Nx M6pT0/Q/lj/0VHGmaNpghFOhmL4AwmAZ0uPQxNP0nHTpyB7Hw7GsdGSUDqrW2oOWRwQB Q1DqQf1/PLndeZXsnFDP4Os4Fm/5un8AdjAJk0Ejp+BZjXvmXKmMGXoTVCYGokz/v5nD ywGA== X-Gm-Message-State: AODbwcBouxpu0o2/n3xUx4+3nMoNoxvwZYIpzlRXpnPFuTNrC7U5nlMj Td8Eku0FV3dBAG8b5/E= X-Received: by 10.237.38.193 with SMTP id q59mr49424401qtd.69.1497026804693; Fri, 09 Jun 2017 09:46:44 -0700 (PDT) Received: from [200.7.87.94] ([2001:13c7:7001:7000:7dfd:5f3f:c1e9:6f2e]) by smtp.gmail.com with ESMTPSA id t15sm1000827qke.50.2017.06.09.09.46.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 09:46:43 -0700 (PDT) From: "Carlos M. Martinez" To: "Job Snijders" Cc: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Fri, 09 Jun 2017 13:46:40 -0300 Message-ID: <1870BF26-C465-4F3C-8C96-A69380CCEEE7@gmail.com> In-Reply-To: <20170602141112.x64nleqclygz7dwd@Vurt.local> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:46:47 -0000 I support this draft. Prefix length should have always been a parameter. Since when hardcoding things became a good idea ? On 2 Jun 2017, at 11:11, Job Snijders wrote: > Hi Working Group, > > Please review the below. > > Kind regards, > > Job > en ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Mon, 22 May 2017 04:25:28 -0700 > From: internet-drafts@ietf.org > To: Job Snijders , Randy Bush , > Christopher Morrow , > Fernando Gont , Nick Hilliard , > Geoff Huston > , Brian Carpenter , Chris > Morrow > > Subject: New Version Notification for > draft-bourbaki-6man-classless-ipv6-00.txt > > > A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt > has been successfully submitted by Randy Bush and posted to the > IETF repository. > > Name: draft-bourbaki-6man-classless-ipv6 > Revision: 00 > Title: IPv6 is Classless > Document date: 2017-05-22 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ > Htmlized: > https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00 > > > Abstract: > Over the history of IPv6, various classful address models have been > proposed, none of which has withstood the test of time. The last > remnant of IPv6 classful addressing is a rigid network interface > identifier boundary at /64. This document removes the fixed > position > of that boundary for interface addressing. > > > > > 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 > > > ----- End forwarded message ----- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jun 9 10:27:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB99129411 for ; Fri, 9 Jun 2017 10:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1Y54evjOtvl for ; Fri, 9 Jun 2017 10:27:13 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B241293F4 for ; Fri, 9 Jun 2017 10:27:12 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 1EE7583123; Fri, 9 Jun 2017 19:27:27 +0200 (CEST) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Andrews , Simon Hobson Cc: 6man WG References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> <20170609125852.29C107B6EB8F@rock.dv.isc.org> From: Fernando Gont Message-ID: <6d1acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> Date: Fri, 9 Jun 2017 20:26:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170609125852.29C107B6EB8F@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:27:16 -0000 On 06/09/2017 03:58 PM, Mark Andrews wrote: > > In message , Simon Hobso > n writes: >> Mark Andrews wrote: >> >>>> My very limited experience with ISP provided IPv6 is that so far, what >>>> I've seen is sensible allocations (eg a /56 for a home user). If the >>>> majority do the right thing, then the exceptions can stand out and get a >>>> reputation for "broken". I know in the real world there will be cases >>>> where there's an effective monopoly (for some group of users) allowing >>>> the ISP to do what they want, but that's not an excuse to just throw in >>>> the towel and give the rest carte blanch. >>> >>> And 256 prefixes very quickly become too few as we develop new >>> technologies to take advantage that you can get prefixes easily. >>> ISP's have been short sighted here. The IETF started out saying >>> /48 to give every site enough prefixes that they shouldn't have to >>> go back and get more except in exceptional circumstances. >> >> I disagree - at least for home users. >> Most home users simply unpack the ISP router, plug it in, and connect their d >> evices to it. >> They plug in their webcams https://www.theregister.co.uk/2017/06/08/whitebox_ >> webcam_scatters_vulnerabilities_through_multiple_oems/ >> plug in their "smart" lightbulbs https://www.theregister.co.uk/2016/07/27/osr >> am_smart_lightbulbs/ >> plug in their "smart" doorbell & locks https://www.theregister.co.uk/2016/01/ >> 12/ring_doorbell_reveals_wifi_credentials/ >> http://www.theregister.co.uk/2016/08/08/using_a_smart_bluetooth_lock_to_prote >> ct_your_valuables_youre_an_idiot/ >> connect their kids toys http://www.theregister.co.uk/2015/02/19/hello_barbie/ >> and their own "toys" http://www.theregister.co.uk/2016/08/07/your_sec_toy_is >> _spying_on_you_hackers_crack_our_plastic_pals/ >> >> I could go on (kettles, fridges, bathroom scales, ... all with reported secur >> ity flaws), but I think you get the idea ! >> All of this will be on one network, one subnet/prefix. The majority of users >> (some small rounding error below 100%) will have no idea at all about network >> ing, they won't have any clue about setting up multiple networks - and the wa >> y much of the kit works, it won't work anyway if the device isn't on the same >> network/subnet/prefix and the users phone/tablet. > > Just because you are not used to home routers that configure multiple > subnets doesn't mean they don't exist. > >> I recall a few years ago visiting my alma mater and found that ethernet >> ports had appeared in the rooms. When I plugged into one, I could see >> all the security cameras etc were on the same segment and even the same >> subnet ! If a university college can't get simple things like this right, >> what makes you think home users will do any better ? > > Because we will ship routers that do multiple subnets by default > because that is what is needed to deal with situations like you > describe above. > >> As I sit here (as part of that rounding error of users), to be frank, I >> am struggling to think what I could (practically) use 10 separate networks >> for, let alone 100 or 200 or 256 ! > > Uses will come up. I use 3 subnets today for the home. I would > expect that I'll use more in the future. Once more than one becomes > common people will design stuff that can make use of additional > subnets. (you || me || we) != users network_knowledge(users) == NULL (and that's the way it should be) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 10:35:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2200129426 for ; Fri, 9 Jun 2017 10:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5OjtjbHNcgp for ; Fri, 9 Jun 2017 10:35:03 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7DD129411 for ; Fri, 9 Jun 2017 10:35:02 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 5A36D82897; Fri, 9 Jun 2017 19:35:17 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Mark Smith Cc: Lorenzo Colitti , Job Snijders , Erik Kline , 6man WG References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> From: Fernando Gont Message-ID: <1159530d-b0d0-08c1-95dd-70c1c56f2bf5@si6networks.com> Date: Fri, 9 Jun 2017 20:32:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:35:05 -0000 On 06/09/2017 05:46 AM, Mark Smith wrote: [...] >> The point is that when employing manual configuration, addresses always >> have small entropy. Hence employing a lot of bits doesn't buy much, >> because folks simply do not use them for additional entropy. > > So I was specifically talking about network infrastructure devices > benefiting from large entropy in 64 bit IIDs. Then dont do manual configuration. :-) [...] > This is about raising the security bar, and with manually configured > addresses with high entropy, or RFC7217 on routers and switches out of > the box, raising it by default. If the device can't be discovered, it > isn't possible to send a packet to it. THing here is: if you want resistence to address scanning, go for SLAAC/RFC7217. If you're setting addresses manually, then you probably know what you're doing. That's why I think that suggesting /64 for slaac (particularly for backwards compatibility) is fine. But not for anything else. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 10:35:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E069129426 for ; Fri, 9 Jun 2017 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Km1v0sZ8tdQ for ; Fri, 9 Jun 2017 10:35:08 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D683712944A for ; Fri, 9 Jun 2017 10:35:07 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 17610828D6; Fri, 9 Jun 2017 19:35:23 +0200 (CEST) Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00) To: Lorenzo Colitti Cc: Mark Smith , Job Snijders , Erik Kline , 6man WG References: <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> <089d5e62-360a-9daf-339e-397ab0f4361f@si6networks.com> From: Fernando Gont Message-ID: <63613823-fd24-7758-b40f-cad961de565e@si6networks.com> Date: Fri, 9 Jun 2017 20:34:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:35:09 -0000 On 06/09/2017 06:04 AM, Lorenzo Colitti wrote: > On Fri, Jun 9, 2017 at 9:35 AM, Fernando Gont wrote: >>> But they could. If the server had a /64 prefix, then it could store >>> useful information in the 64 bits. For example, SNI (which sends >>> information in the clear) might not be necessary any more. >> >> We're talking about entropy here. If you want entropy, randomize your >> IPv6 address (RFC7217), rather than set it manually. > > Well, but the entropy that we care about is not the entropy of the IP > address, but the entropy of the network communications. Those can be > achieved by using many IP addresses in parallel. Huh? We're talking about entropy of addresses. If you're going to use 64 bits and randomize addresses in such space, fine. If you're going to use 64 bits just to use the low-order 16-bits, then you've wasted a lot of bits. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 10:51:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B0D126C89 for ; Fri, 9 Jun 2017 10:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4NA0NyYG1Yh for ; Fri, 9 Jun 2017 10:51:52 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 C93691267BB for ; Fri, 9 Jun 2017 10:51:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 1F72CCA7 for ; Fri, 9 Jun 2017 17:51:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9rW9ZWKybXf for ; Fri, 9 Jun 2017 12:51:51 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id D8E85C59 for ; Fri, 9 Jun 2017 12:51:51 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id w23so8740636vke.15 for ; Fri, 09 Jun 2017 10:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WbkiLGPWAMisEKE5ylWSqvmBdCPMZ8AnFf1hmRGL43s=; b=USwJOgbatPpvMISE5HL8JBk5PM+nz0PXLV+zy4pMkkPrx2O7Pad4slPMXYGmvkX6/r ND3PjQH8HzNGHqTPQgEMX2+9s4rZ1xSiFC24YIfjVmScx84oeTeW9XJSXgi06mQsaYyf 5sHawaXFAkFr8rgEGmd8+ONnWQ0SslxMmmvmhU7JJ+f6TXSApC6E1cVAu2XxZTaiT8OD dm10mdiInny899SJedQVh9nEU6JtRyVhAENiy6f08yrO9u8TeobPQVR29GzOEAfx3FRV 6FfmL6jgv1MGYoBVUGrGXGgzuEhb1MdM7WlwY4drBn7tONTo0kI0HWXnBBtH3g7L7qKB WJNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WbkiLGPWAMisEKE5ylWSqvmBdCPMZ8AnFf1hmRGL43s=; b=J83DMW6r+rbXZu+yrSkQP4TafBt1fXg5TQUv0zAInrwL6rqMx+EW0orjQ63CA64XXh QWR7EeGXRKabgcKGefL5b9xaVCtuOCVRh7OnCOVFOzW7nlG2R1WMBMbKMTW/MFKaBT7R YE+iaZ6YF461PwqrQXObmrzPMVYdWnCTVG71X9Jkb6G416Sy7fFU0fEyEui1mtR/4NbT FNhgLicJPA+MFuddjE6JwGTJyPkLs7+Ci2KFqzeSlVtgLxyCqolcpdxfz+/TCd9qzaMQ 2W1YDz0GdBnWk4chRCH9dwQZL/w9qJI7H5N5DkL/U38EKfygT3LYR/kDbuoQNDsL9plL fVLg== X-Gm-Message-State: AODbwcC4jY48qq2ZyhM7j1uYXfnYjYJbp7o3ZRVKtOMiCCEviCbuYnOs LdsZDdPqfiMLZClqFP5VoEbdkSopyiAEp/ZYgVqQJIQdgcbwF/HVzv7tDK2yDmrlwjgU3BTCkO8 mjHoKlplg/bD4LT4= X-Received: by 10.159.53.72 with SMTP id o66mr3713700uao.113.1497030710824; Fri, 09 Jun 2017 10:51:50 -0700 (PDT) X-Received: by 10.159.53.72 with SMTP id o66mr3713694uao.113.1497030710662; Fri, 09 Jun 2017 10:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Fri, 9 Jun 2017 10:51:49 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> From: David Farmer Date: Fri, 9 Jun 2017 12:51:49 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont Cc: Lorenzo Colitti , Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="94eb2c03d0b2ba29c105518a9fd5" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:51:55 -0000 --94eb2c03d0b2ba29c105518a9fd5 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 9:50 AM, Fernando Gont wrote: > On 06/09/2017 05:31 PM, David Farmer wrote: > > > > > > On Fri, Jun 9, 2017 at 1:36 AM, Lorenzo Colitti > > wrote: > > > > On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont > > wrote: > > > > > However, I think IPv6 implementations that don't support manual > > > configuration must be able to reject non-64 bit IIDs, since > that is the > > > standard. Saying "SHOULD be 64 bits long" means they "MAY be > /81, /99 or > > > /123", and those are against BCP 204 (RFC 7934). > > > > BCP204 talks about multiple addresses. As long as whatever > prefix is > > employed allows for multiple addresses, I don't see how that goes > > against BCP204. > > > > > > That's not true at all. As an example: see if you can build a > > network that uses a /99 and satisfies the recommendations in section > > 8 or BCP 204. > > > > > > Yes, to meet the specific RECOMMENDATIONS in BCP204 /64 is necessary. > > I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED. > It's not in the normative language, but it is part of the RFCs recommendations section, see below. > > It seems to me that extremely long prefixes like /120 or longer are > > likely unable to achieve the intent of BCP204 for any significant number > > of hosts. However, anything in the range /112 or shorter should have > > plenty of address to achieve the intent of BCP204 for a quite reasonable > > numbers of hosts, at least many hundreds of hosts. > > > > So, of the examples you provided, /123 is unlikely to achieve the intent > > of BCP204, but /81 or /99, while they don't meet the specific > > RECOMMENDATIONS of BCP204 there doesn't seem to be any reason they > > couldn't achieve the fundamental intent of BCP204, granted with without > > much sparseness or entropy in the assignments, but that's not > > specifically part of BCP204. > > Could you copy&paste the "specific recommendations" you're referring to? > Second paragraph, second and third sentences of section 8; This can be achieved either by allowing the host to form new addresses autonomously (e.g., via SLAAC) or by providing the host with a dedicated /64 prefix. The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. Furthermore, I would concur that those are the only current standards track ways to achieve the desired result and they require /64 either per host or per subnet. I haven't found any. And I see no reason for which the authors of bcp204 > should have cared about a specific prefix length. > > Thanks, > Hope that helps! -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c03d0b2ba29c105518a9fd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 9, 2017 at 9:50 AM, Fernando Gont <fgont@si6networks.c= om> wrote:
On 06/09/2017 05:31 PM, David Farmer wrote:
>
>
> On Fri, Jun 9, 2017 at 1:36 AM, Lorenzo Colitti <lorenzo@google.com
> <mailto:lorenzo@google.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont <<= a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com
>=C2=A0 =C2=A0 =C2=A0<mailto:fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> However, I think IPv6 implementa= tions that don't support manual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> configuration must be able to re= ject non-64 bit IIDs, since that is the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> standard. Saying "SHOULD be= 64 bits long" means they "MAY be /81, /99 or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> /123", and those are agains= t BCP 204 (RFC 7934).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BCP204 talks about multiple addresses= . As long as whatever prefix is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0employed allows for multiple addresse= s, I don't see how that goes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0against BCP204.
>
>
>=C2=A0 =C2=A0 =C2=A0That's not true at all. As an example: see if y= ou can build a
>=C2=A0 =C2=A0 =C2=A0network that uses a /99 and satisfies the recommend= ations in section
>=C2=A0 =C2=A0 =C2=A08 or BCP 204.
>
>
> Yes, to meet the specific RECOMMENDATIONS in BCP204 /64 is necessary.<= br>
I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED.=

It's not in the normative language= , but it is part of the RFCs recommendations section, see below.
= =C2=A0
> It seems to me that extremely long prefixes like /120 or longer are > likely unable to achieve the intent of BCP204 for any significant numb= er
> of hosts. However, anything in the range /112 or shorter should have > plenty of address to achieve the intent of BCP204 for a quite reasonab= le
> numbers of hosts, at least many hundreds of hosts.
>
> So, of the examples you provided, /123 is unlikely to achieve the inte= nt
> of BCP204, but /81 or /99, while they don't meet the specific
> RECOMMENDATIONS of BCP204 there doesn't seem to be any reason they=
> couldn't achieve the fundamental intent of BCP204, granted with wi= thout
> much sparseness or entropy in the assignments, but that's not
> specifically part of BCP204.

Could you copy&paste the "specific recommendations" you'r= e referring to?

Second paragraph, secon= d and third sentences of section 8;

=C2=A0 = =C2=A0This can be achieved either by allowing the host
=C2=A0 =C2= =A0to form new addresses autonomously (e.g., via SLAAC) or by providing
=C2=A0 =C2=A0the host with a dedicated /64 prefix.=C2=A0 The prefix = MAY be provided
=C2=A0 =C2=A0using DHCPv6 PD, SLAAC with per-devi= ce VLANs, or any other means.
=C2=A0
Furthermore,= I would concur that those are the only current standards track ways to ach= ieve the desired result and they require /64 either per host or per subnet.=

I haven't found any. And I see no reason for which the authors of bcp20= 4
should have cared about a specific prefix length.

Thanks,

Hope that helps!=C2=A0

--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--94eb2c03d0b2ba29c105518a9fd5-- From nobody Fri Jun 9 11:04:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF2212702E for ; Fri, 9 Jun 2017 11:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTsjqtiXZ0X0 for ; Fri, 9 Jun 2017 11:04:37 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A887D126C89 for ; Fri, 9 Jun 2017 11:04:36 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 04F2A826AA; Fri, 9 Jun 2017 20:04:50 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: David Farmer Cc: Lorenzo Colitti , Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> From: Fernando Gont Message-ID: Date: Fri, 9 Jun 2017 21:04:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 18:04:38 -0000 On 06/09/2017 08:51 PM, David Farmer wrote: > > > > > > That's not true at all. As an example: see if you can build a > > network that uses a /99 and satisfies the recommendations in > section > > 8 or BCP 204. > > > > > > Yes, to meet the specific RECOMMENDATIONS in BCP204 /64 is necessary. > > I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED. > > > It's not in the normative language, but it is part of the RFCs > recommendations section, see below. That comment, in non-RFC2119, is like "one possible way to do it". That is, we don't need to comply with non-normative language in a document that does employ normative language. > > It seems to me that extremely long prefixes like /120 or longer are > > likely unable to achieve the intent of BCP204 for any significant > number > > of hosts. However, anything in the range /112 or shorter should have > > plenty of address to achieve the intent of BCP204 for a quite > reasonable > > numbers of hosts, at least many hundreds of hosts. > > > > So, of the examples you provided, /123 is unlikely to achieve the > intent > > of BCP204, but /81 or /99, while they don't meet the specific > > RECOMMENDATIONS of BCP204 there doesn't seem to be any reason they > > couldn't achieve the fundamental intent of BCP204, granted with > without > > much sparseness or entropy in the assignments, but that's not > > specifically part of BCP204. > > Could you copy&paste the "specific recommendations" you're referring to? > > > Second paragraph, second and third sentences of section 8; > > This can be achieved either by allowing the host > to form new addresses autonomously (e.g., via SLAAC) or by providing > the host with a dedicated /64 prefix. The prefix MAY be provided > using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. > > Furthermore, I would concur that those are the only current standards > track ways to achieve the desired result and they require /64 either per > host or per subnet. Exactly: the document from the subject line is exactly about forcing the hardcoded /64 everywhere. > I haven't found any. And I see no reason for which the authors of bcp204 > should have cared about a specific prefix length. If the specific length was important, they should have cared. However, the aforementioned bcp talks about being able to get multiple addresses. The pool size is, for the most part, irrelevant. You can get such multiple addresses with /64, /60, /56/ or /48, or even /32. Pushing for the specific /64 value is not about a technical agument, but rather about trying to convert an historical actifact into a technical one. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 11:39:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DE0127F0E for ; Fri, 9 Jun 2017 11:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IypKZbknRxsg for ; Fri, 9 Jun 2017 11:39:43 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D7454127698 for ; Fri, 9 Jun 2017 11:39:43 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 09 Jun 2017 18:39:42 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B40FED788B; Fri, 9 Jun 2017 11:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=TtHtlT4iyjOs2OqgoTWYAiHVNm4=; b= pUX4NMs5PwR1vWuRa/fd0rVvFfPul1Yn+YKlyBSsXaOH29opbVijxUWt3E8jDql+ hFd4a8Zta2Ax6anXFXND6ZogXZhRpjDuLrki+XfVhY6kb72He0mt9hnhRbqsemzg 7jUZyebrnWjKWzauvDWYgcyg4LG61ZAxeYvt00LqOqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=M+P/FPVg/B6CE50Ri4ev7Mi j6e+1HEnvUSERurLS1A0n4jXKBjtcThBm8Ow60X18UqL25Tr3jLwX2EtHJu5abyI v4LQRVXeFZcdi3V1ltLKFPZrk08ubhsOMqBL0nLdzWQ2uiDphAr2AaVfrwBQquEU Ibs6ccBuAkYN1qXouFtc= Received: from h.hanazo.no (77.16.70.76.tmi.telenormobil.no [77.16.70.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 11717D788A; Fri, 9 Jun 2017 11:39:41 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9837FD0DF461; Fri, 9 Jun 2017 20:25:30 +0200 (CEST) From: otroan@employees.org Message-Id: <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B59FF463-93F8-46BA-A0A9-B90AD10B5D1F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Fri, 9 Jun 2017 20:25:29 +0200 In-Reply-To: <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> Cc: 6man WG To: Fernando Gont , Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 18:39:46 -0000 --Apple-Mail=_B59FF463-93F8-46BA-A0A9-B90AD10B5D1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 9 Jun 2017, at 14:24, Fernando Gont wrote: >=20 > On 06/09/2017 10:46 AM, otroan@employees.org wrote: >>=20 >>> On 6 Jun 2017, at 00:25, Brian E Carpenter = wrote: >>>=20 >>> On 05/06/2017 19:45, Lorenzo Colitti wrote: >>>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < >>>> brian.e.carpenter@gmail.com> wrote: >>>>=20 >>>>> None of that is the point. The point is to establish >>>>> that routing is classless >>>>=20 >>>>=20 >>>> Routing is already classless because BCP 198. >>>>=20 >>>>=20 >>>>> and /64 is a parameter of specific addressing schemes. >>>>>=20 >>>>=20 >>>> It *is* a parameter. The parameter's value is 64 for all unicast = addresses >>>> except those starting with 000. >>>=20 >>> The parameter's *current* value, yes. But should we really be fixing >>> the value of the parameter once and for all in the addressing = architecture? >>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC = design >>> assumes? >>=20 >> do we have a rationale for fixing the value in the IPv6-over-foo = documents (anymore)? >=20 > At the time of this writing, we should probably be in the camp of "If > you do slaac, better stick to 64, since it's know to work with legacy > implementations, and besides, allows for sparse allocation (reduced > collisions of IIDs when you pick a random one, resistance to address > scans, etc.). >=20 > There's no compelling technical argument for mandating /64 (i.e., such > specific value) if you do manual configuration or, for instance, > stateful DHCPv6. And the recommendation for /64 for slaac mostly has = to > do with backwards compatibility than with anything else. your goal is to remove the 64 bit boundary from RFC2464 et al and update = RFC4862? I intended the question for Brian, as he seemed to be of a different = view. Ole PS: you might want to look up "legacy" in a dictionary --Apple-Mail=_B59FF463-93F8-46BA-A0A9-B90AD10B5D1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZOugaAAoJEL7aWKiYQt92nU4P/01cC5HxVATNdALJLlUEt7qj +NUtAIPv9EXaFwh6DwnvOba8SkxJH+UtriIERSABc23+SSGrNZm/aLuZtcm2QEbj L4BH0fA7nSQd02nvysgM7pbrxjmJycHpp5Ihi2kz0dOM5kIyojmmY1dPUFsjlxpk NvSY65MEiM/E7zLsp8bkNtBKdNgA1rQELbhGB+7pPZu5RVQ9kHHsd9a+hzC8Ff8R lgumiWtYAXzOosVkxBo+f3Uc7GEf2qYHaoRKEyAoAIhl62qFDr/fsIHZcKulaG9t a02yQZNloQL2yRVlSm583pH7EgHAH9pp5+FFSOiqS/9xxlbFwmc5iJyHA7fqmJgN XfUHsaU7fM7iOtV9Ure3cFEYOF5vDVzmZJSRj/y+652rjenwQ2FcqLozQI7AOhpM +FnRe46D1IUfidEm1uj0IscoKrKCIJNh/3854owa2c8NDeNqBpfNERTekfoY/Dvl YFG2qDvYS7a7Zll0u6FMrs+clgV1U0aSw3xa/iI1VjgyMxx2zcIGvNMIkZMx4BxF ULUEG/LSP29xXjflUSdwPsDYiLQxF5oevBeyOR98oxceiuPnzloyzKuzBd38el3R U0a+hX7fM7W8e5rUlxW993bHIIWCk0w6qZxh9vZK6dKQGr5+91uDtNm7aVk528tK LspgB1ezWNhziuUmVEnR =iAOf -----END PGP SIGNATURE----- --Apple-Mail=_B59FF463-93F8-46BA-A0A9-B90AD10B5D1F-- From nobody Fri Jun 9 11:54:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71521129447 for ; Fri, 9 Jun 2017 11:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6oSn5Sc2CvQ for ; Fri, 9 Jun 2017 11:54:01 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D021A12871F for ; Fri, 9 Jun 2017 11:53:59 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.50.131.146]) (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 2EC3C800CF; Fri, 9 Jun 2017 20:54:14 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org, Brian E Carpenter Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> From: Fernando Gont Message-ID: Date: Fri, 9 Jun 2017 21:52:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 18:54:04 -0000 On 06/09/2017 09:25 PM, otroan@employees.org wrote: >>>>> It *is* a parameter. The parameter's value is 64 for all unicast addresses >>>>> except those starting with 000. >>>> >>>> The parameter's *current* value, yes. But should we really be fixing >>>> the value of the parameter once and for all in the addressing architecture? >>>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >>>> assumes? >>> >>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? >> >> At the time of this writing, we should probably be in the camp of "If >> you do slaac, better stick to 64, since it's know to work with legacy >> implementations, and besides, allows for sparse allocation (reduced >> collisions of IIDs when you pick a random one, resistance to address >> scans, etc.). >> >> There's no compelling technical argument for mandating /64 (i.e., such >> specific value) if you do manual configuration or, for instance, >> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to >> do with backwards compatibility than with anything else. > > your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862? No. I'm just saying that such specific value is an historical artifact, not a technical one. It's fine for the /64 to stay for slaac -- although the more clear we make it that its a parameter, rather some value that came from an oracle, the better. > I intended the question for Brian, as he seemed to be of a different view. > > Ole > > PS: you might want to look up "legacy" in a dictionary Agreed. I meant "implementations that expect /64", which are likely to be a lot (if not all) nowadays. (not sure why I used the term "legacy") Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 9 12:21:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B72128D69 for ; Fri, 9 Jun 2017 12:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iye2u57SgUPI for ; Fri, 9 Jun 2017 12:21:01 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 407C6128ACA for ; Fri, 9 Jun 2017 12:21:01 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 09 Jun 2017 19:20:59 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 95ECFD788D; Fri, 9 Jun 2017 12:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=mOcHK95qILAyUtoO3NGtuMpBUgA=; b= eOFFx2LIDCpsR3HDGC/TURPFm/a91f+SZccF+EDmPpt2P0UsncA50K4kOpsFOpTt YmFczwHPzgrZ/GUHpXrMMdsMk+zhfIo3AhenT8LSlaoWo3BJZZEKM7K5ssnQkhq1 fhmGef+F7vMi/2NZEFLaBkqUNdeicp9c3Yl3/+G9nf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=XCs5HZ9gME4YFgg7SbDijQd d58DE/cnWXdYliV4yv8fBUaQcuQ9DN0G+PxFH46NyOpHWBIDJz8+5kmYYRwVdlji YMBUQs3ADFKektIP9FL0bo1uKxLX8xn1u7z/Y7R401kJrNC/0L/ZM9CbyR2x4d9w ylO/4scBekS7mUXGUGOE= Received: from h.hanazo.no (77.16.70.76.tmi.telenormobil.no [77.16.70.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id BD3C9D788B; Fri, 9 Jun 2017 12:20:58 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 36F09D0E0F85; Fri, 9 Jun 2017 21:20:56 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_225DAE45-7C5D-4D53-886A-33BA3A630295"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Fri, 9 Jun 2017 21:20:55 +0200 In-Reply-To: Cc: Brian E Carpenter , 6man WG To: Fernando Gont References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 19:21:03 -0000 --Apple-Mail=_225DAE45-7C5D-4D53-886A-33BA3A630295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 9 Jun 2017, at 20:52, Fernando Gont wrote: >=20 > On 06/09/2017 09:25 PM, otroan@employees.org wrote: >>>>>> It *is* a parameter. The parameter's value is 64 for all unicast = addresses >>>>>> except those starting with 000. >>>>>=20 >>>>> The parameter's *current* value, yes. But should we really be = fixing >>>>> the value of the parameter once and for all in the addressing = architecture? >>>>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC = design >>>>> assumes? >>>>=20 >>>> do we have a rationale for fixing the value in the IPv6-over-foo = documents (anymore)? >>>=20 >>> At the time of this writing, we should probably be in the camp of = "If >>> you do slaac, better stick to 64, since it's know to work with = legacy >>> implementations, and besides, allows for sparse allocation (reduced >>> collisions of IIDs when you pick a random one, resistance to address >>> scans, etc.). >>>=20 >>> There's no compelling technical argument for mandating /64 (i.e., = such >>> specific value) if you do manual configuration or, for instance, >>> stateful DHCPv6. And the recommendation for /64 for slaac mostly has = to >>> do with backwards compatibility than with anything else. >>=20 >> your goal is to remove the 64 bit boundary from RFC2464 et al and = update RFC4862? >=20 > No. I'm just saying that such specific value is an historical = artifact, > not a technical one. >=20 > It's fine for the /64 to stay for slaac -- although the more clear we > make it that its a parameter, rather some value that came from an > oracle, the better. There are many reasons why there is a fixed split between what the = network gets and what the hosts gets. It's part of a tussle. As well as to allow for 8+8. I don't see that the particular tussle has = changed much over the last 20 years, nor the reasons for 8+8. Any credible opponent of the fixed 64 bit boundary must answer the = issues laid out in RFC7421. Also the players on network side of the tussle must give credible = reasons for why 64 bits isn't enough for them. Brian assured us the draft isn't about this. Hard to say from the draft = and it seems you are of a different opinon. Ole --Apple-Mail=_225DAE45-7C5D-4D53-886A-33BA3A630295 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZOvUXAAoJEL7aWKiYQt92AMwP/AhQ2ZzkM3cSf6w0kNGDnQYs mzGm7KYtpv+pMJwBiNnBv2h44y1kCYm/Lc3LOE++vBXwsqrV9LAFXWPcAAJfQKhO QjqiHOTk9ARHTJ1+cp8vvyHLmp4RTPvtT9YtLOnrCqF2D+MloU6I6RoCo8U8JJtL 3/3/Wvb52xRChVjZWITDMsCgD46Q+QofUsjWQa3Kuf2fPBIJj/mMkYe/lIeX/UQ4 qzRgr07J7FhhTwWm/Zg2Lh80vA8bq3gzbOTOSGKjHYwhRoNcCNjHMfvs1YdBOx5x MbQzdZ+82Gz4y36YycMsq+H8eQ1E37QotL6JGshJ7nLW87xGKaZz9a0KXrqwZXsf 7tOfH+NWHl2OZjmCuWPDRHa0cfAXu5RNeV9EEAaIk1bxCKSWVpxv5Ib7WoxZi2xL oAwozMWe/UgsvEjC0Nt0RujKVtb8RRsvedxBdSKT4Fs50dXdZe4OJL8TTJaB+8WW qgWKZC2ChOqMC2er2l35IOlVCFLc3SvFYJY48xED0fi8s60iWJ1gljGmF0kV1o03 98ns25aoV8+Mm+dLYP0/lyqg8itrAmeqaLfUvQc1o1cXDgf7retdF6RB+vvqtLLD owwBuPIbB3sRGEMqGVjQsdLRw7NCfwC0THo17tlfEg99V1rV0xcZD2wKFP4lGjYZ oGLQpehtd16NGBrAk2Dp =J7/E -----END PGP SIGNATURE----- --Apple-Mail=_225DAE45-7C5D-4D53-886A-33BA3A630295-- From nobody Fri Jun 9 12:31:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933012944A for ; Fri, 9 Jun 2017 12:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzJJ1D4zETl2 for ; Fri, 9 Jun 2017 12:30:56 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD740128ACA for ; Fri, 9 Jun 2017 12:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v59JUuSH038172; Fri, 9 Jun 2017 12:30:56 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v59JUnUC038114 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 9 Jun 2017 12:30:50 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Jun 2017 12:30:49 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 9 Jun 2017 12:30:49 -0700 From: "Manfredi, Albert E" To: David Farmer , Fernando Gont CC: Job Snijders , Erik Kline , 6man WG , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4Ng5/DxYTgHcokuMXsgWu2kKXaIciQIAgACE74CAAAUqAIAAMrCA//+Xg3A= Date: Fri, 9 Jun 2017 19:30:49 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 19:30:58 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERh dmlkIEZhcm1lcg0KDQo+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiBCQ1AyMDQgd2hlcmUgLzY0 IGlzIGEgTVVTVCBvciBldmVuIFJFQ09NTUVOREVELg0KPg0KPiBJdCdzIG5vdCBpbiB0aGUgbm9y bWF0aXZlIGxhbmd1YWdlLCBidXQgaXQgaXMgcGFydCBvZiB0aGUgUkZDcw0KPiByZWNvbW1lbmRh dGlvbnMgc2VjdGlvbiwgc2VlIGJlbG93Lg0KDQo+IFNlY29uZCBwYXJhZ3JhcGgsIHNlY29uZCBh bmQgdGhpcmQgc2VudGVuY2VzIG9mIHNlY3Rpb24gODsNCg0KwqAgwqBUaGlzIGNhbiBiZSBhY2hp ZXZlZCBlaXRoZXIgYnkgYWxsb3dpbmcgdGhlIGhvc3QNCsKgIMKgdG8gZm9ybSBuZXcgYWRkcmVz c2VzIGF1dG9ub21vdXNseSAoZS5nLiwgdmlhIFNMQUFDKSBvciBieSBwcm92aWRpbmcNCsKgIMKg dGhlIGhvc3Qgd2l0aCBhIGRlZGljYXRlZCAvNjQgcHJlZml4LsKgIFRoZSBwcmVmaXggTUFZIGJl IHByb3ZpZGVkDQrCoCDCoHVzaW5nIERIQ1B2NiBQRCwgU0xBQUMgd2l0aCBwZXItZGV2aWNlIFZM QU5zLCBvciBhbnkgb3RoZXIgbWVhbnMuDQoNCkkga2VlcCByZWFkaW5nIGxlc3MgaW50byB0aGlz IHN1cHBvc2VkbHkgbWFuZGF0b3J5IDY0LWJpdCBib3VuZGFyeSB0aGFuIHNvbWUgb3RoZXJzIHNl ZW0gdG8sIGVzcGVjaWFsbHkgZm9yIHRoZSBmdXR1cmUuDQoNClJGQyAyNDY0IChJUHY2IG92ZXIg RXRoZXJuZXQpIGlzIHNob3J0LCBzd2VldCwgYW5kIGR1ZSBmb3IgYSAtYmlzIHZlcnNpb24uIFRo ZSByYXRpb25hbGUgZm9yIDY0LWJpdCBJSURzIGlzIHNpbXBseSBvYnNvbGV0ZS4gVXNlIG9mIEVV SS02NCBoYXMgYmVlbiBkZXByZWNhdGVkLg0KDQogICBUaGUgSW50ZXJmYWNlIElkZW50aWZpZXIg W0FBUkNIXSBmb3IgYW4gRXRoZXJuZXQgaW50ZXJmYWNlIGlzIGJhc2VkDQogICBvbiB0aGUgRVVJ LTY0IGlkZW50aWZpZXIgW0VVSTY0XSBkZXJpdmVkIGZyb20gdGhlIGludGVyZmFjZSdzIGJ1aWx0 LQ0KICAgaW4gNDgtYml0IElFRUUgODAyIGFkZHJlc3MuDQoNCkkgc2VlIGEgbG90IG9mICI2NC1i aXQgSUlEcyBtYW5kYXRvcnkiIGhpbmdpbmcgb24gdGhpcyBvbmUgc2VudGVuY2UsIGFuZCBpdHMg cHJlbWlzZSBubyBsb25nZXIgaG9sZHMuIEF0IHRoZSB2ZXJ5IGxlYXN0LCA0OC1iaXQgSUlEcyBz aG91bGQgYmUgZmVhc2libGUgb3ZlciBFdGhlcm5ldCwgYW5kIHlvdSdkIGxvc2Ugbm8gcmFuZG9t bmVzcywgY29tcGFyZWQgd2l0aCBFVUktNjQuIElmIG5vdCBtYW55IG90aGVyIHBvc3NpYmlsaXRp ZXMuDQoNCkFuZCBSRkMgNDg2MiAoU0xBQUMpIGlzIHF1aXRlIGFnbm9zdGljIG9uIHRoaXMgbWF0 dGVyLCByZXF1aXJpbmcgdXNlIG9mIGEgbGluayBsb2NhbCBhZGRyZXNzIElJRCBhbmQgUkEtc3Vw cGxpZWQgcHJlZml4LCBhbmQgdGhlIHRvdGFsIG51bWJlciBvZiBiaXRzIG11c3QgPD0gMTI4Lg0K DQogICAzLiAgSWYgdGhlIGxlbmd0aCBvZiB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXIgaXMgTiBi aXRzLCB0aGUgcmlnaHQtDQogICAgICAgbW9zdCBOIGJpdHMgb2YgdGhlIGFkZHJlc3MgYXJlIHJl cGxhY2VkIGJ5IHRoZSBpbnRlcmZhY2UNCiAgICAgICBpZGVudGlmaWVyLg0KDQogICBJZiB0aGUg c3VtIG9mIHRoZSBsaW5rLWxvY2FsIHByZWZpeCBsZW5ndGggYW5kIE4gaXMgbGFyZ2VyIHRoYW4g MTI4LA0KICAgYXV0b2NvbmZpZ3VyYXRpb24gZmFpbHMgYW5kIG1hbnVhbCBjb25maWd1cmF0aW9u IGlzIHJlcXVpcmVkLg0KDQpTbyB3aGF0J3MgbGVmdD8gSG93IExMQXMgYXJlIGZvcm1lZC4gTExB cyBhcmUgZm9ybWVkIHVzaW5nIGEgd2VsbC1rbm93biBwcmVmaXggYW5kIEVVSS02NC4gU2FtZSBv bGQgc3RvcnksIExMQXMgYWxzbyBoaW5nZSBvbiBhbiBvYnNvbGVzY2VudCBSRkMgMjQ2NC4gVGhp cyBjYW4gYWxsIGNoYW5nZSwgd2l0aCBSRkMgMjQ2NC1iaXMuIFJGQyA0ODYyIHdvdWxkbid0IGV2 ZW4gbmVlZCB0byBjaGFuZ2UsIGlmIGFuIFJGQyAyNDY0LWJpcyB3ZXJlIHRvIHJlZGVmaW5lIGhv dyBJUHY2LW92ZXItRXRoZXJuZXQgSUlEcyBhcmUgZm9ybWVkLg0KDQpFdmVyeSBpbmZsZXhpYmxl IHN1cHBvc2VkICJydWxlIiBhYm91dCA2NC1iaXQgSUlEcyBzZWVtcyB0byBoaW5nZSBvbiBhbiBv YnNvbGV0ZSBub3Rpb24sIHdoaWNoIGNhbiwgc2hvdWxkLCBhbmQgcHJvYmFibHkgd2lsbCBiZSBy ZXZpc2VkIGluIGR1ZSBjb3Vyc2UuIEluIG15IHZpZXcsIHdlIHNob3VsZCBiZSBhbGxvd2luZyBm b3IgYW4gZWFzeSB0cmFuc2l0aW9uIGFmdGVyIFJGQyAyNDY0LWJpcywgd2l0aCB0aGlzIG5ldyBk cmFmdCwgaW5zdGVhZCBvZiBjZW1lbnRpbmcgdGhpcyA2NC1iaXQgYm91bmRhcnkuDQoNCkJlcnQN Cg0K From nobody Fri Jun 9 12:48:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A15126D85 for ; Fri, 9 Jun 2017 12:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR_H41GKZLvc for ; Fri, 9 Jun 2017 12:48:11 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFF61200CF for ; Fri, 9 Jun 2017 12:48:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v59JmAoS065092; Fri, 9 Jun 2017 12:48:10 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v59Jm3SG064699 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 9 Jun 2017 12:48:04 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Jun 2017 12:48:03 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 9 Jun 2017 12:48:03 -0700 From: "Manfredi, Albert E" To: "otroan@employees.org" CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4PSR/DxYTgHcokuMXsgWu2kKXaIc6j+AgABku4CAAAeiAIAAB9uA//+RVwA= Date: Fri, 9 Jun 2017 19:48:03 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 19:48:12 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of otroan@employees.org > Any credible opponent of the fixed 64 bit boundary must answer the issues > laid out in RFC7421. I agree with this comment. It would take some time to go through each examp= le cited, but I don't think it's impossible to do. It would be more difficu= lt to support IID longer than 64 bits, but shorter should be doable. Bert From nobody Fri Jun 9 13:56:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A8312946A for ; Fri, 9 Jun 2017 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWVXDRG9AYJK for ; Fri, 9 Jun 2017 13:55:56 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD8D1292F4 for ; Fri, 9 Jun 2017 13:55:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: ; Fri, 9 Jun 2017 20:55:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: <6d1acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> Date: Fri, 9 Jun 2017 21:55:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> <20170609125852.29C107B6EB8F@rock.dv.isc.org> <6d1 acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 20:55:59 -0000 Fernando Gont wrote: > On 06/09/2017 03:58 PM, Mark Andrews wrote: >> Just because you are not used to home routers that configure multiple >> subnets doesn't mean they don't exist. >> Because we will ship routers that do multiple subnets by default >> because that is what is needed to deal with situations like you >> describe above. And conversely, just because they exists doesn't mean that any ISP will = ship them - or ship them configured to anything more than a basic single = network. Besides, for this to work properly it's going to require VLANs and = multiple wireless SSIDs unless you limit the network to the ports on the = router. Good luck getting that to work with the average user. >> Uses will come up. I use 3 subnets today for the home. I would >> expect that I'll use more in the future. Once more than one becomes >> common people will design stuff that can make use of additional >> subnets. I can see uses for about 3 or 4 segments - note, segments rather than = subnets ! You are not clear whether you are talking about multiple = segments or a single network with multiple subnets. If it's the latter = then it adds almost zero security, if the former than it's beyond the = average user to deal with. > (you || me || we) !=3D users >=20 > network_knowledge(users) =3D=3D NULL Thanks - you've expressed it better than I would have. From nobody Fri Jun 9 14:02:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D47129482 for ; Fri, 9 Jun 2017 14:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR7HfuX9CZrH for ; Fri, 9 Jun 2017 14:01:58 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 96686128656 for ; Fri, 9 Jun 2017 14:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v59L1tkH016954; Fri, 9 Jun 2017 23:01:55 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wkvqR3cFHz3ZfH; Fri, 9 Jun 2017 23:01:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Carsten Bormann In-Reply-To: Date: Fri, 9 Jun 2017 23:01:54 +0200 Cc: 6man WG X-Mao-Original-Outgoing-Id: 518734914.04871-15f2f0ceb7795f0c762d49eec39adb8b Content-Transfer-Encoding: quoted-printable Message-Id: <4D7541A3-B0E9-4F53-8E4A-0752228CA626@tzi.org> References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> <20170609125852.29C107B6EB8F@rock.dv.isc.org> <6d1 acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> To: Simon Hobson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 21:02:01 -0000 On Jun 9, 2017, at 22:55, Simon Hobson wrote: >=20 > Besides, for this to work properly it's going to require VLANs and = multiple wireless SSIDs unless you limit the network to the ports on the = router. Good luck getting that to work with the average user. Apple has had these in their =E2=80=9CAirport=E2=80=9D product line for = about a decade. (Of course, =E2=80=9Caverage users=E2=80=9D aren=E2=80=99t taught about = VLAN tags; it =E2=80=9Cjust works=E2=84=A2=E2=80=9D :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jun 9 15:10:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C725B126DCA for ; Fri, 9 Jun 2017 15:10:39 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcNcjdFhbpeh for ; Fri, 9 Jun 2017 15:10:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918001252BA for ; Fri, 9 Jun 2017 15:10:37 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 244A5349315; Fri, 9 Jun 2017 22:10:34 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 12082160044; Fri, 9 Jun 2017 22:10:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E671C16006D; Fri, 9 Jun 2017 22:10:33 +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 aJmSCs_AQqyW; Fri, 9 Jun 2017 22:10:33 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2B2D9160044; Fri, 9 Jun 2017 22:10:33 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id F3F247B70921; Sat, 10 Jun 2017 08:10:29 +1000 (AEST) To: Simon Hobson Cc: 6man WG From: Mark Andrews References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> <20170609125852.29C107B6EB8F@rock.dv.isc.org> <6d1 acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) In-reply-to: Your message of "Fri, 09 Jun 2017 21:55:49 +0100." Date: Sat, 10 Jun 2017 08:10:29 +1000 Message-Id: <20170609221029.F3F247B70921@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 22:10:40 -0000 In message , Simon Hobso n writes: > Fernando Gont wrote: > > > On 06/09/2017 03:58 PM, Mark Andrews wrote: > >> Just because you are not used to home routers that configure multiple > >> subnets doesn't mean they don't exist. > > >> Because we will ship routers that do multiple subnets by default > >> because that is what is needed to deal with situations like you > >> describe above. > > And conversely, just because they exists doesn't mean that any ISP will > ship them - or ship them configured to anything more than a basic single > network. > > Besides, for this to work properly it's going to require VLANs and > multiple wireless SSIDs unless you limit the network to the ports on the > router. Good luck getting that to work with the average user. People can handle multiple SSIDs quite easily. We have had routers shipping with 2 SSIDs for many years now. Usually the second one in labeled "Something Guest". > >> Uses will come up. I use 3 subnets today for the home. I would > >> expect that I'll use more in the future. Once more than one becomes > >> common people will design stuff that can make use of additional > >> subnets. > > I can see uses for about 3 or 4 segments - note, segments rather than > subnets! You are not clear whether you are talking about multiple > segments or a single network with multiple subnets. If it's the latter > then it adds almost zero security, if the former than it's beyond the > average user to deal with. The home user is quite capable of doing multiple segments. It really isn't hard. Have a couple of cars that each do PD requests for a couple of /64s each when they arrive home as they connect over WiFi rather than using LTE possibly using a distinct WiFi SSID in the garage (another /64). The LTE border router in the car becomes a interior router when it connects to the WiFi. This is really no different to coming home with your mobile phone except you are connecting multiple subnets rather than individual addresses. What other equipement will request /64s as it comes into range or just request /64s when it connects? I don't know yet but I do know it will happen. 256 subnets is going to look very small when that happens. > > (you || me || we) != users > > > > network_knowledge(users) == NULL > > Thanks - you've expressed it better than I would have. Actually we are all users. Adding WEP passwords was once "too hard" for the ordinary user. There used to be a dozen parameters presented to users of WiFi networks. Now you choose from a simple list of SSIDs. Anything we do today will be common in a few years time. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 9 18:33:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7436126C89 for ; Fri, 9 Jun 2017 18:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmL9IJUxcS6J for ; Fri, 9 Jun 2017 18:33:12 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 754F5126C7A for ; Fri, 9 Jun 2017 18:33:12 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id f185so31267750pgc.0 for ; Fri, 09 Jun 2017 18:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:organization:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=cBuHSBYBnzCK8obEw2jnujyZ+HWPfKIxkF5a+XG6j8c=; b=aAWL4cVkd5RacBNnIpm9rzcjCqLkKsGYx7ZQmIpBe9zt2e8uZX3h5HJHv4es9Fz6qo wrlAzrtydDBCSm41gbhOrfjSAQ3kTvd+ZJkd6Hr0kaCqbyIhMwrIta4vnx+NLnVU5qtv QVNCbCGPlieyQvOGKQ7886MXUDvFH6ulxLLL0W4xugMziaIl3GlqVltFfp6RrEX60N5F YAXG+YG0i7F7r7Ep33+aL951UGDkfHXU3wGTHlkcSU713ul0rVM5ILumKBHhd/HIJTuk 5dX94OiCf73g8KtYarOHbiTgW29ZbSM5cD0vKZXWOQRttd+RQzXVaxhnO2b9scFt3eBQ P/qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=cBuHSBYBnzCK8obEw2jnujyZ+HWPfKIxkF5a+XG6j8c=; b=GrEfcypkV0obySD5NhxMnmZ0/CjyhgyOok4WSY8U2JzX7fM9lzSvHfPPAn+W44RQvE /OHOa8r6NMt2cpuEJa8ZSnGarUo+OgQOj72kJitJpaJ4BoPRAp17L8FkIZh7aN18rCMG yUwBQbf65gKxEDtI5mMxzmuVHt0IGiZTLDVjnw0n42JUzaCCAxV5/pQ0q+p2eEIAOv+W rp8FqxW/MK1MD02R0m5cLtA1dCjOwdzgcwrHal0UBgr1CDYZhvYl97o9+un++KG/oHiX sHQJHc7iRiEp09p1Zt3C9JpXSeIeDq2zInVbSxpnAq/ted2VOF582VdT6o6E4eH8Wb+N OoAQ== X-Gm-Message-State: AODbwcBJ3OUYf5qVQokCHP5mPu7WtkLgoTqpA8Zh8iWyxD/lMdqdgyUq t5VsYndQ+B/USRtD X-Received: by 10.99.152.70 with SMTP id l6mr45470366pgo.136.1497058391772; Fri, 09 Jun 2017 18:33:11 -0700 (PDT) Received: from [192.168.178.21] ([118.148.119.180]) by smtp.gmail.com with ESMTPSA id m123sm5435527pfc.51.2017.06.09.18.33.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 18:33:10 -0700 (PDT) From: Brian E Carpenter Subject: Tussles in IPv6 Land Organization: University of Auckland To: 6man Message-ID: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> Date: Sat, 10 Jun 2017 13:33:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 01:33:15 -0000 Hi, I wrote the text below a couple of months ago, but then got distracted. However, I do think it's important that as we argue about (for example) /64, to remember what's going on behind the apparent argument. Regards Brian Tussles in IPv6 Land Today (April 2017) we seem to have three very active tussles in the IPv6 technical community. 1. Is header insertion on the fly OK, or is it the work of the devil? 2. Is the fixed interface identifier length of 64 bits OK, or is it the work of the devil? 3. Which is the work of the devil: getting the DNS server address via Router Advertisments, or getting the DNS server address via DHCPv6? Each of these issues has generated several hundred emails recently. Clearly, they matter to some part of the community. Why? And why now? None of them are exactly new. Why they matter *now* seems clear. IPv6 is on the march. Although there are still IPv6 'deniers' it's become a bit like climate change denial: the temperature is up, the waters are rising. More and more operators are being forced to consider IPv6 not as a remote possibility, but as a requirement that will directly impact how they operate and how much it costs to operate successfully. To a significant extent the above three issues are tussles between operational needs and conceptual purity. To be specific: 1. Large data centres need to achieve throughput and parallelism. To do that they need to chain services together across very large numbers of nodes. The large address space of IPv6 is potentially very valuable for that, if it can be brought to bear: and an attractive way of doing so is segment routing. An attractive way of doing segment routing is using an IPv6 routing header. An attractive way of doing that within the data centre is by having the first-hop router insert the IPv6 routing header, so that the application servers don't need to know about it. So data centre operators like this idea. So router vendors like this idea too. Unfortunately, many people involved in the IPv6 design think it's a terrible idea (and a misreading of the IPv6 standard). That's because inserting stuff (any stuff, not just this header) in a packet changes its length and thereby breaks all known methods of determining the maximum packet size allowed on a given path across the Internet. So, header insertion is the work of the devil across the Internet and also the goose that might lay the golden egg inside a data centre. 2. The interface identifier length was fixed at 64 bits about 20 years ago. It was not an arbitrary choice then - it was designed to match the hardware address size of FireWire, then expected to be the network of the future. (It actually turned out that the network of the past, Ethernet, became the network of the future. But if we'd fixed on 48 bits for that reason, we'd be having the same tussle about 80+48 that we're having today about 64+64.) Network operators have two complaints about the boundary at 64 bits. Firstly, although in theory it could be different for different media (for example, 64 for FireWire and 48 for Ethernet) in practice it's been set at 64 for everything. Secondly, bitter experience with IPv4 25 years ago taught everybody (we thought) that routing should always be "classless" with no rigid rules about the length of routing prefixes. But the de facto rule in IPv6 is that leaf subnet prefixes MUST be 64 bits long. ISP operators would like that 64-bit boundary to float. Unfortunately, many people involved in the IPv6 design think it's a terrible idea (and a change to the IPv6 standard). There are several reasons for that - though the main one seems to be that having a 64 bit boundary everywhere makes portability (of code, and of computers) easier. Also, much software blindly assumes the 64 bit rule. But this has its own downside: suppose an ISP follows bad practice and gives a retail subscriber exactly one 64 bit prefix. If the subscriber needs to operate more than one subnet in their home or office, they simply can't do so unless the 64 bit rule is relaxed. That wastes considerable potential for IPv6 deployment. But - again, but - if the 64 bit rule was made flexible, perhaps some ISPs would decide to go further - say give a retail subscriber exactly one 80 bit prefix. This could generate a race to the bottom, where the really cheap and nasty ISPs give a subscriber, say, exactly one 120 bit prefix, wasting even more of IPv6's potential. On this argument, sticking to the 64 bit rule seems safest. So, the 64 bit boundary is the well-understood solution that works everywhere, or the spawn of the devil that blocks future flexibility for both routing and address space conservation. 3. An IPv6 host can get its DNS server's IPv6 address in two ways (let's call them Alpha and Omega). Therefore, a router can supply a DNS server's IPv6 address in two ways (also Alpha and Omega of course). So some host operating systems support Alpha or Omega alone; some routers support both, but others support either Alpha or Omega alone. So it is entirely possible for a host that only supports Alpha to roam to a network that only supports Omega (or vice versa), in which case the host can't get DNS service over IPv6 at all. Believe it or not, the fallback is then DNS service over IPv4, even to retrieve IPv6 addresses. Alpha is the work of the devil if you (a network operator) prefer to assign host addresses using Omega. And vice versa. However, some operators are pragmatic enough to support both Alpha and Omega in their routers, regardless of whether they prefer Alpha or Omega for assigning addresses to hosts. So this is an interesting tussle, because operators don't agree among themselves about the best approach; neither do router vendors; neither do host operating system developers. Feel free to assign the values "RA/RDNSS" and "Stateless DHCPv6" to Alpha and Omega either way round. It makes equal sense. -- From nobody Fri Jun 9 18:47:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526F8126CD6 for ; Fri, 9 Jun 2017 18:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKwkc5fKgmXX for ; Fri, 9 Jun 2017 18:47:33 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB673126C89 for ; Fri, 9 Jun 2017 18:47:33 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id x63so33690930pff.3 for ; Fri, 09 Jun 2017 18:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RMO2+DLBbMBndbx87vDnpfZL0B82Zq6RBSaa4po78m4=; b=Nw9FZAyoIwOBfHCE5qg205SVB5Rj6JfNEVsP/824gSaF/a+YbUKIdtKAJNP2I4CgwC 4+VF1uAvoJ144+O4jVfYuXCk6zpVQV/BqVnaWIL3bFKLTQ/OMV670uMHmmHUugOo0/YM W4LSgdLR15iAEi8YWgxDQw1JQVRs5ELmGeY+cw4+MaMW4n3Ke1ZeOmbO7NtgZ5t+DyzK 0fN2FN06wGkYlIRZXbCBmCREe4pw04ZKWcamTyqkEcHSafvhOa4Ya0UDERaP8GIm3bXa zluNXGDCHVTjbobiWZsyA066Vq4Nkv8HejR2L4G0B2t1kPnnavDz7uFMkRsy7f2cbZFw 6ZDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RMO2+DLBbMBndbx87vDnpfZL0B82Zq6RBSaa4po78m4=; b=p45knvpMr81XKvjehZyo4+YYjnX8aMe3sj6t2S1lTvG0BzKBPr0VB++KrdbR7Ebald gb5l+xkvrdWPJtTYnmGG4TuOIXj/PHkbk5WzemQjpQKNogPR1mvl0TaG2gH++Ux1E+ga fypFb5Cg/BI4wzknVu7PVWXq42ZLOzVkEogx93VkmsuFNgwr8KnKOkr5UQ1TZKJmRe7n pj41SlZAAICWupC6l3Oa8jI6Ytpot52EgNyGn2w0N91q0zjlm63vcnOT4X0gg+u70T+L rLceWmWTKd28kxl0KWJq4arWV4lsex8ktTQMAIbgv9GO0HletcsuKgHIrU7DWbLD7aQw IR+w== X-Gm-Message-State: AODbwcAyvyH+AYSj26egr6jbQVIae+taJ6YYRpXjVwCWMZR50QcnwjXM roKSDfmfKLQKc897 X-Received: by 10.84.179.193 with SMTP id b59mr43210587plc.3.1497059253197; Fri, 09 Jun 2017 18:47:33 -0700 (PDT) Received: from [192.168.178.21] ([118.148.119.180]) by smtp.gmail.com with ESMTPSA id h68sm1111517pfh.45.2017.06.09.18.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 18:47:32 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org, Fernando Gont Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> Date: Sat, 10 Jun 2017 13:47:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 01:47:35 -0000 On 10/06/2017 06:25, otroan@employees.org wrote: > >> On 9 Jun 2017, at 14:24, Fernando Gont wrote: >> >> On 06/09/2017 10:46 AM, otroan@employees.org wrote: >>> >>>> On 6 Jun 2017, at 00:25, Brian E Carpenter wrote: >>>> >>>> On 05/06/2017 19:45, Lorenzo Colitti wrote: >>>>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < >>>>> brian.e.carpenter@gmail.com> wrote: >>>>> >>>>>> None of that is the point. The point is to establish >>>>>> that routing is classless >>>>> >>>>> >>>>> Routing is already classless because BCP 198. >>>>> >>>>> >>>>>> and /64 is a parameter of specific addressing schemes. >>>>>> >>>>> >>>>> It *is* a parameter. The parameter's value is 64 for all unicast addresses >>>>> except those starting with 000. >>>> >>>> The parameter's *current* value, yes. But should we really be fixing >>>> the value of the parameter once and for all in the addressing architecture? >>>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >>>> assumes? >>> >>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? >> >> At the time of this writing, we should probably be in the camp of "If >> you do slaac, better stick to 64, since it's know to work with legacy >> implementations, and besides, allows for sparse allocation (reduced >> collisions of IIDs when you pick a random one, resistance to address >> scans, etc.). >> >> There's no compelling technical argument for mandating /64 (i.e., such >> specific value) if you do manual configuration or, for instance, >> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to >> do with backwards compatibility than with anything else. > > your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862? > I intended the question for Brian, as he seemed to be of a different view. It's hard to track this conversation, but anyway IMHO 2464bis should specify /64 as if the addressing architecture didn't even mention it. It has to specify something for SLAAC to work, and we have 20 years of deployed code based on /64. So we don't have the luxury of changing it, even if we want to. I'm not aware of any technical changes needed in 4862. Jinmei-san has convinced me off line that 4862 does logically require the IID length for link-local addresses and global-scope SLAAC addresses to be the same. I wish the text stated this explicitly, but that's an editorial issue. Apart from that, it leaves the IID length as a parameter and that's as it should be. Brian From nobody Fri Jun 9 18:53:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AF7126CD6 for ; Fri, 9 Jun 2017 18:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FdtsE50qHE8 for ; Fri, 9 Jun 2017 18:53:01 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4052126C7A for ; Fri, 9 Jun 2017 18:53:00 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id g83so842116qkb.3 for ; Fri, 09 Jun 2017 18:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mS9yxWuiTLhp+bOSM1juczS9xi3NkgWTs5MelDBKxhk=; b=bDbc8JcfXAb1nTqwgCoHxcpEg/w4SRVptsxw4Rcq2ocCD0Q2xzjQxctgWRba39cvYO 6IlLu66vxXnFQ9+CZj1TaT5pwbdtKlJRZTQ6MB33MKUxlauNc9BwaiWRQze8VNd+HVK7 GXR2zjbVMZM5zqb5NF7b6/BNtruclxF2AasUS2ScWMaAN3QGJkPlRaLTWYqLh5pLlQnp pl9vG6IgQd3oBjm8uKEIV3Byw4AbCR+KPqo9JpHXMnAeuOIFB67NZvg9OFBpeek+jlKX Zo6C2+R4n1up49zJZfKcoAkdmCoCdmWOAFSgrEmALJyd8ihD6pSIDZR3yI5Hu/nhHWnw KEhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mS9yxWuiTLhp+bOSM1juczS9xi3NkgWTs5MelDBKxhk=; b=Pg4y6l5+/5di0yEiTZLhSGFRvzXuf6JoKyKvLQOT36X67gqCpoB7+LsqvUYhcQnKyf DRn/ORFskFnoIUP/bhWPBBXGewnGJG0wK5DcbatstuKWink0CprkyBfLa0GsfyAXjj74 sk4vqnPWSrh1MpuqVG0exZB3bDwEQ1CJC31AszXvLo7a6eFANVesh5QqM5/fNot0Z2k0 zUuDQzxSFG+0S01V3Kl4TXbvJFNe3HSk8d5qDA4DTasFRFD9VmqbPJ/RwMZsrbSjSQb2 3ZEInHe7QJYdinkiESLjwmTZfSBvsxWDNC0j6AJgHS/dkiqD7/Jg91SXjiKcFge+3jmQ Ar3g== X-Gm-Message-State: AKS2vOz07+jNs4zoqHkYSD9pC2uvYdHdIj0Sieb6xcz/EmczwiJh7r0m +CtsYOWk18hXhLRtizDf6z0Pm7z5XQ== X-Received: by 10.55.139.5 with SMTP id n5mr14946707qkd.17.1497059580179; Fri, 09 Jun 2017 18:53:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.149 with HTTP; Fri, 9 Jun 2017 18:52:59 -0700 (PDT) Received: by 10.200.40.149 with HTTP; Fri, 9 Jun 2017 18:52:59 -0700 (PDT) In-Reply-To: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> From: Richard Hartmann Date: Sat, 10 Jun 2017 03:52:59 +0200 Message-ID: Subject: Re: Tussles in IPv6 Land To: Brian E Carpenter Cc: 6man List Content-Type: multipart/alternative; boundary="001a114f84267bfb5f055191584e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 01:53:02 -0000 --001a114f84267bfb5f055191584e Content-Type: text/plain; charset="UTF-8" Thank you for this write-up. I lost hope that any of these discussions will be resolved, or compromised on, at any point in the near to medium future, but if nothing else, this is a good place to point people to when they ask why we can't have nice things. Richard --001a114f84267bfb5f055191584e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for this write-up.

<= div dir=3D"auto">I lost hope that any of these discussions will be resolved= , or compromised on, at any point in the near to medium future, but if noth= ing else, this is a good place to point people to when they ask why we can&= #39;t have nice things.


Richard
--001a114f84267bfb5f055191584e-- From nobody Fri Jun 9 18:58:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDE9126E64 for ; Fri, 9 Jun 2017 18:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YYPaWUwvhZ8 for ; Fri, 9 Jun 2017 18:58:04 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 0B203126CD6 for ; Fri, 9 Jun 2017 18:58:04 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id f185so31358486pgc.0 for ; Fri, 09 Jun 2017 18:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KIYCPSAKgt7yQdgdj7TxtWl/CS8nzUd8PChkRY/8IjY=; b=P3ZUu6E4iS/qKUF7jSImM50tkFCNT2anm6V/OVLFSSktdCFoAWkgDA28sgSOn5oAPs uDw//stucdXSq19rbbP+dZCQ2aT4yHKF1ynXvcI43w4d/Zx2ZUgRPpQWo3CjQlPVQqZK wV3MPY6svgprPVjpRA+U5RKJbB9gNXjTCcY16Z1Hr7zgi8bwLMYcV7P2lEJyqtN/YHSX QyuHqbySp99sJJ7NM+voyFyiWWFk6hRucZaUbnlbCPNgSKWOoOpgoQmVRom4x0MFqqar VS7L8KIYK4Q6Oikq6/o+B4iSG/8I/qaOkGng2Diqz6PRPRJRKb+taA1Du3l82t4pxRpl vl3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KIYCPSAKgt7yQdgdj7TxtWl/CS8nzUd8PChkRY/8IjY=; b=eaqnF9wYcxxCOb3o8UpuLYqnPWmMZtoPgLOZc5BcOa9mXEny/BfjoLX5vaW5x1S0Y5 W6LWynjkr3GTAnD57jhDkk5zieUQ858/5LAqrDZkjkfKJr2ecGMPrJAkSFWYFi4rlgF4 gartW2hzUA0PbmUZEDzCLyakcoqJ6qSkOmucRkWtxGl/ML79CtCg9S8T1vO0MV73g8rp dmYVVqtMQYTYRx+Lf2EpXx2+LNFEAdiE2zgAqsAK/S8H2pTCgHHXPd8gOIfWVbEmP1r+ NOKKfMriAiFCKGPCCpn8ZkLwX0IghDF2GWa147NJ3mRqGOsDeDADYKPQB1Ub6rWINrD/ jAxA== X-Gm-Message-State: AODbwcDz75v2752jGPQ82gdyLlx6kW9OXj3h+gDIGN9k+p47UFavyE/4 cIujLP4K2CkaGe0x X-Received: by 10.98.178.79 with SMTP id x76mr19831926pfe.74.1497059883466; Fri, 09 Jun 2017 18:58:03 -0700 (PDT) Received: from [192.168.178.21] ([118.148.119.180]) by smtp.gmail.com with ESMTPSA id 204sm700705pfu.23.2017.06.09.18.58.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 18:58:02 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org Cc: Lorenzo Colitti , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> Date: Sat, 10 Jun 2017 13:58:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 01:58:06 -0000 On 09/06/2017 19:46, otroan@employees.org wrote: > >> On 6 Jun 2017, at 00:25, Brian E Carpenter wrote: >> >> On 05/06/2017 19:45, Lorenzo Colitti wrote: >>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> None of that is the point. The point is to establish >>>> that routing is classless >>> >>> >>> Routing is already classless because BCP 198. >>> >>> >>>> and /64 is a parameter of specific addressing schemes. >>>> >>> >>> It *is* a parameter. The parameter's value is 64 for all unicast addresses >>> except those starting with 000. >> >> The parameter's *current* value, yes. But should we really be fixing >> the value of the parameter once and for all in the addressing architecture? >> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design >> assumes? > > do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? My rationale is that a) RFC4862 describes it very carefully as a parameter. b) The addressing architecture describes it as a parameter ("n"), and then suddenly defines n=64 for no reason. c) It gives no reason because the true reason was the obsoleted EUI-64 mechanism. d) There is no physical reason for n to have the same value on different link media. e) Future link media might more appropriately use a different value. f) Therefore the addressing architecture should only define n=64 as a default recommendation for IPv6-over-foo documents. Brian From nobody Fri Jun 9 19:06:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA4126CD6 for ; Fri, 9 Jun 2017 19:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChlQD4YvVueb for ; Fri, 9 Jun 2017 19:06:08 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 D9FCE126C7A for ; Fri, 9 Jun 2017 19:06:08 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id v18so31354860pgb.1 for ; Fri, 09 Jun 2017 19:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Chlto2xbWG9ml1j1GWjbpHvpMbQGm5ITVffjbR/OTZo=; b=dNJrB1Rw2rVEUCFFZpqGPB1t0RMOv65YekaPmR9P8yZP9wF7lGXD2dudm8YskTVuE8 452nfC3cC2DVU5F+vzdQAYon0PI2fxMP2Yqy2b5BCWVKo3ksDc2HanWHjQi9PpMg0Uzu Z2HIpNt//j2ltbHMRnkn6Tli55FHQnIrjykPIAOAU00N0KqckUwKHLwESWzSsjkjMOwW QP71BVbZ99gj6Zc8ia2O/WWYVNfcwQhq9RlDOG28ECKmcPbz0kKsm2ZZBckPFWN9WaBN UkJztHfP1VOSuxDXGCHD7J/0VP82gq1AnPUpF5LLm7S1ED/ImahctDTbPW0t+IjX7oUk OCyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Chlto2xbWG9ml1j1GWjbpHvpMbQGm5ITVffjbR/OTZo=; b=i5hubPO++jEEdWzoCw8GiEmP/gE5qYTLnT8UH7QG7q+eieWXipl1AxTTHXNrOu5cyX RsnBpaK+M0yXbyl3EDHdmBpLZp9dKmndhGDMXsRybgSIzw4a3KXXg/7r91WgKb6Qj5K/ EPTsd9+BHFVEYE9a9vl3A6AQ7e4YJliqrFmoC4ABxOoKWRrw8jVXgTDaDtjXRTwi/O95 q+1rzaRLImcgr5Uncd8DVM0H3xCRQ/+/fnf61zOVdBuxctyloUZGghSCLkGM0j56ZcXY PnafVTqg5Zi/BC64+qNm9E3Cio3X7CcBhc20lZotosUSuQIu5AAvin//OQXl3tAFoGRN bYnw== X-Gm-Message-State: AODbwcDVo1xV78d2pIk0oLITu49PeN8bhCxNJ+YLVVoaHg3M+IWZvX7H IV7/6iCwhQnddRvg X-Received: by 10.84.232.200 with SMTP id x8mr43365441plm.189.1497060368185; Fri, 09 Jun 2017 19:06:08 -0700 (PDT) Received: from [192.168.178.21] ([118.148.119.180]) by smtp.gmail.com with ESMTPSA id i190sm4867654pfc.69.2017.06.09.19.06.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 19:06:07 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Tim Chown , Fernando Gont Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7d8cb121-33c0-47de-e1ed-e2c92430a728@gmail.com> Date: Sat, 10 Jun 2017 14:06:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 02:06:10 -0000 On 10/06/2017 00:45, Tim Chown wrote: >> On 9 Jun 2017, at 13:24, Fernando Gont wrote: >> >> At the time of this writing, we should probably be in the camp of "If >> you do slaac, better stick to 64, since it's know to work with legacy >> implementations, and besides, allows for sparse allocation (reduced >> collisions of IIDs when you pick a random one, resistance to address >> scans, etc.). >> >> There's no compelling technical argument for mandating /64 (i.e., such= >> specific value) if you do manual configuration or, for instance, >> stateful DHCPv6. And the recommendation for /64 for slaac mostly has t= o >> do with backwards compatibility than with anything else. >=20 > I think the term =E2=80=9Cmanual configuration=E2=80=9D for non-SLAAC c= ases is a little misleading. Many deployments, be they server deployments= , or point-to-point link configurations, are likely to be increasingly au= tomatically provisioned in some way; then there is no =E2=80=9Cmanual=E2=80= =9D configuration per se.=20 Yes. I think "static configuration" is closer to what is intended. Even that isn't quite correct. Maybe it just has to be "non-SLAAC"; the fact that schemes like ILNP also split at the /64 boundary seems to be mainly a coincidence. Brian From nobody Fri Jun 9 19:23:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC37126C7A for ; Fri, 9 Jun 2017 19:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHi1FFPKPT6P for ; Fri, 9 Jun 2017 19:23:51 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009C61270A0 for ; Fri, 9 Jun 2017 19:23:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5A2No8s055800; Fri, 9 Jun 2017 19:23:50 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5A2Nev3055691 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 9 Jun 2017 19:23:40 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Jun 2017 19:23:39 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 9 Jun 2017 19:23:39 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4PSR/DxYTgHcokuMXsgWu2kKXaIc6j+AgABku4CAAHuMAP//jhHQ Date: Sat, 10 Jun 2017 02:23:39 +0000 Message-ID: <9dec37c5b478458db6c46d9b29455476@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> In-Reply-To: <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 02:23:52 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > It's hard to track this conversation, but anyway IMHO 2464bis > should specify /64 as if the addressing architecture didn't > even mention it. It has to specify something for SLAAC to work, > and we have 20 years of deployed code based on /64. So we don't > have the luxury of changing it, even if we want to. But it can be changed, in a graceful manner. As you said in another post, t= he reason/excuse for the 64-bit IID length in RFC 2464 no longer applies. S= o here's what RFC 2464-bis could say: Each (updated) host must be capable of creating IIDs of variable lengths, f= rom 64 bits to 1 bit. The 64-bit IID is formed as it is now. To shorten the= IID, e.g. as required for SLAAC or other protocols, the host can use a num= ber of techniques. One such might be, truncate the upper bits first, until = 16 bits have been truncated, then truncate the upper bit and the lower bit,= alternating between one and the other, until the needed IID length is reac= hed. That's pretty much it for RFC 2464-bis. Then for RFC 4862, which would need essentially no change. Routers should c= ontinue to advertise 64-bit prefix lengths, for legacy hosts that can only = support 64-bit IIDs. Routers may also advertise prefixes longer than 64 bit= s, for use by updated hosts. A host creates its 128-bit interface address using the prefix length specif= ied in the RA, then appending the appropriate length IID, where the length = of the IID is 128-prefix length. I don't think we should need to state flat out that SLAAC can only work wit= h 64-bit IIDs, nor that Ethernet interfaces can only be identified by 64-bi= t IIDs. This need not be the case, with RFC 2464-bis (which I think is need= ed regardless). Bert From nobody Sat Jun 10 03:15:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A91205F1 for ; Sat, 10 Jun 2017 03:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XywQ1qU51z6q for ; Sat, 10 Jun 2017 03:15:23 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BE21201FA for ; Sat, 10 Jun 2017 03:15:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: ; Sat, 10 Jun 2017 10:15:11 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00) From: Simon Hobson In-Reply-To: <20170609221029.F3F247B70921@rock.dv.isc.org> Date: Sat, 10 Jun 2017 11:15:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> <20170609125852.29C107B6EB8F@rock.dv.isc.org> <6d1 acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> <20170609221029.F3F247B70921@rock.dv.isc.org> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 10:15:26 -0000 Carsten Bormann wrote: > Apple has had these in their =93Airport=94 product line for about a = decade. > (Of course, =93average users=94 aren=92t taught about VLAN tags; it = =93just works=99=94 :-) Really ? If you connect an airport to ${random_switch} and ${random_router} then = all the VLANs will work without any intervention ? It might work if = every piece of kit is from the same manufacturer (ie what Apple would = have you do), but in the general case there's a long way to go ! Mark Andrews wrote: >> Besides, for this to work properly it's going to require VLANs and >> multiple wireless SSIDs unless you limit the network to the ports on = the >> router. Good luck getting that to work with the average user. >=20 > People can handle multiple SSIDs quite easily. We have had routers > shipping with 2 SSIDs for many years now. Usually the second one in > labeled "Something Guest". Most chipsets only support 4 SSIDs, a few handle 16. I've never come = across one, but I could believe that some enterprise manufacturer might = handle more - at a price. That's a loooooong way from exceeding the 256 = segments possible with a /56 from your ISP. And there's the other issue - people will really really hate you if all = these SSIDs do materialise. I've already read comments in another list = where users in densely populated places (think these high-density = apartment blocks with gigabit connectivity we hear about in parts of = Asia) where they already struggle to select a WiFi network because the = list takes so long to display and scroll down that it refreshes (and = resets the scroll) before they can select their network. Now you propose = to multiply that by a few hundred ? >> I can see uses for about 3 or 4 segments - note, segments rather than >> subnets! You are not clear whether you are talking about multiple >> segments or a single network with multiple subnets. If it's the = latter >> then it adds almost zero security, if the former than it's beyond the >> average user to deal with. >=20 > The home user is quite capable of doing multiple segments. It > really isn't hard. I don't think you've dealt with the average home user, you wouldn't say = that otherwise. As I;ve said before, there's a reason ISPs use colour = coded sockets and cables for their routers - it's so they can say things = like "connect the yellow cable to ..." The average home user really is = incapable of doing this. > Have a couple of cars that each do PD requests for a couple of /64s > each when they arrive home as they connect over WiFi rather than > using LTE possibly using a distinct WiFi SSID in the garage (another > /64). The LTE border router in the car becomes a interior router > when it connects to the WiFi. And there's no security in that method. If I have ${random_IoTat_hub}, I don't want (and wouldn't allow) it to = connect to anything but it's own isolated segment and then control what = traffic it is allowed to send where. If it connects to the users general = WiFi then the IoT thing has full access to the rest of what's on that = segment and I don't have control of what it can and cannot do on it. So = as I read it, you are proposing to build a network system that gives the = false appearance of security - and thus is worse that no security at = all. Whether it requests it's own /64 is another matter - it's really not the = same as it having an isolated network segment. > What other equipement will request /64s as it comes into range or > just request /64s when it connects? I don't know yet but I do know > it will happen. 256 subnets is going to look very small when that > happens. >=20 >>> (you || me || we) !=3D users >>>=20 >>> network_knowledge(users) =3D=3D NULL >>=20 >> Thanks - you've expressed it better than I would have. >=20 > Actually we are all users. OK, change that to (you || me || we) !=3D average users. I've dealt with = them, really, no-one on this list is anything whatsoever like an average = user - and I strongly suspect that some on this list just don't = understand what a real average user is like != From nobody Sat Jun 10 06:14:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D291012940F for ; Sat, 10 Jun 2017 06:14:46 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HmEGZgA3dHJ for ; Sat, 10 Jun 2017 06:14:44 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D33CA129410 for ; Sat, 10 Jun 2017 06:14:43 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2017 13:14:42 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4A361D788B; Sat, 10 Jun 2017 06:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=k8jQflvuR8LG5RGsm1rsB7rFSMw=; b= mt0xDP3glSDfH7xYNnUJKmuhNJbFTN0lx3AxUcoSFvzndjQwmA8Bjc3HQtZcEMl6 wojtKBwcy/i1LLvHrYmRN3Gq9FM1m48t2rem1issL5g7UvOEIDSQr4y2pbMpM31v yjop7ipwo7LcOJkig6tTcZNZlv3wsRQhBBp/z2IRh4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=FRLChUcURIRyUnjYUagLAh6 srdlG24ubJWn9JZgZZ2zgX5wBPPl6HJ8BnWz4rj1xDc2NmRjilgSy3BhNEC5BZmg pzQURY6tbDM75jwk3FrHdRTBaTr1mn6cri2kcxuN9sKAkwHLCTdq/5gnHLwx5TsJ NlsPEjonIFlfJ8wc5NOE= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E1A5ED788A; Sat, 10 Jun 2017 06:14:41 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2FF25D0EA367; Sat, 10 Jun 2017 15:14:41 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0025C96A-CAF8-4D5B-9DF7-0242C89FA548"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Sat, 10 Jun 2017 15:14:40 +0200 In-Reply-To: <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> Cc: Fernando Gont , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 13:14:47 -0000 --Apple-Mail=_0025C96A-CAF8-4D5B-9DF7-0242C89FA548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >>>> do we have a rationale for fixing the value in the IPv6-over-foo = documents (anymore)? >>>=20 >>> At the time of this writing, we should probably be in the camp of = "If >>> you do slaac, better stick to 64, since it's know to work with = legacy >>> implementations, and besides, allows for sparse allocation (reduced >>> collisions of IIDs when you pick a random one, resistance to address >>> scans, etc.). >>>=20 >>> There's no compelling technical argument for mandating /64 (i.e., = such >>> specific value) if you do manual configuration or, for instance, >>> stateful DHCPv6. And the recommendation for /64 for slaac mostly has = to >>> do with backwards compatibility than with anything else. >>=20 >> your goal is to remove the 64 bit boundary from RFC2464 et al and = update RFC4862? >> I intended the question for Brian, as he seemed to be of a different = view. >=20 > It's hard to track this conversation, but anyway IMHO 2464bis should = specify > /64 as if the addressing architecture didn't even mention it. It has > to specify something for SLAAC to work, and we have 20 years of = deployed > code based on /64. So we don't have the luxury of changing it, even > if we want to. This is confusing. On one hand you argue we have 20 years of deployed code base and that we = cannot change it, on the other hand you want to remove the 64 bit = boundary from the addressing architecture, presumably with the goal of = changing it? The argument that SLAAC needs an standard-set per data-link type fixed = IID length is a tenuous argument. The only technical requirement for = SLAAC to work is that the the IID length is the same across all nodes on = a given link. If we remove the 64 bit boundary from 4291, then an update of 2464 will = likely result in the removal of any bit boundary there as well. > I'm not aware of any technical changes needed in 4862. Jinmei-san has > convinced me off line that 4862 does logically require the IID length > for link-local addresses and global-scope SLAAC addresses to be the = same. > I wish the text stated this explicitly, but that's an editorial issue. > Apart from that, it leaves the IID length as a parameter and that's > as it should be. RFC4862 says: Note that the address architecture [RFC4291 also defines the length of = the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. In many cases, the identifier will be derived from the interface's link-layer address. The IID length in the IPv6 architecture is fixed. And it has to be = consistent across 4291, 4862 and IPv6 over foo documents. Feel free to look at it as a parameter, and you can pick any value you = like from the 0-128 range as long as you pick 64. That's the current state. And that is what every implementation does. If = you want to _change_ that. Then you need to consider that in the light = of 7421 and of the wider consequences for the Internet. I am still confused what this draft proposes to change. Ole --Apple-Mail=_0025C96A-CAF8-4D5B-9DF7-0242C89FA548 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZO/DAAAoJEL7aWKiYQt92wDQP/3kBWWp7woHucthyOriyb4if YIKilOTgXFPuG8AtlpjfblcVuMsjwxL7VSBfM3UWUxnUvSiQcv92RJv9Yt8Mb/1N 2lkVlX2pjNQ2h8aRdVlM0ZuEMFy3RVzCKozjA3IyWSWcoPXdfSjFqgOGldmhFmbG OZ7EKQRYiAdJ3pTpHxHXiqb/vgU+oK/X6B5QtihUMgFQJpBp3raV3HDSVI/4jQbF W4pdLcVIcuq+MF64vRAN4SIrLjKRzwE4AJ/Mk53e7NdBVfyKyzG2IvxcmbtwHfuG Vdqah5d0mzpfAw6AS+QSDA0GTGe3JFzu3odjKmRvgW+5g0b0fmB5HLZ/aX1sGCpx AC2+Qi6CIcESORNdgvVTw9fO0LMesc6McG6DApxHQEQW+VhVvnAlrZRkxEFZ7jgq L+ArWGHVj+4A/B4zg5luirUb6L4wnhOr63GOWyvPlbTvGowAc990tjvAtUNpp2QV 53NiTyS7z8mX4xAN6510nAlDotJZUbHTuLB9Jpg9SYBGhMMAisHkL5zaQkVd6jH2 Lzl8eaoDdwirrbz54YePLumYBR6FNQN4Rs/zXnczaLF6q9kv3t3pHy3eUxZbk1m0 RhLzQBntYh8Ck5nEP3Zu0w6FgOICCLYHj+pAKQvl/GdK3zEwkkgGdTXVO/mV+GSH QTDi8bjXuVizCQnMTgJP =Mnm2 -----END PGP SIGNATURE----- --Apple-Mail=_0025C96A-CAF8-4D5B-9DF7-0242C89FA548-- From nobody Sat Jun 10 06:24:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39860127B60 for ; Sat, 10 Jun 2017 06:24:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pVDhhGBMEJ4 for ; Sat, 10 Jun 2017 06:24:34 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 88EDE12896F for ; Sat, 10 Jun 2017 06:24:34 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2017 13:24:34 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 31732D788D; Sat, 10 Jun 2017 06:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=s/fGaLY7ppn0DhA5EdtYCbQVdvc=; b= A3pmdVWh6XzwMhBz7A24m+XrSs6WNgKmngefmQG4ODhNT/9BIewbJjRoU8il5Y3N PyxFltJTmN803Che7QTMYStIkI26xLPW0JmIyaw8K0TKnhunW2YeJizG8sVYf8w7 0Pe4/BwbE6PijyuOqPVggRYtdd/J3j9etRIUMlZ66wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=LCFtSw8xWgQwdYGDn9s60vH SMdVSNICaZ+ppvTg4/jVQstZMRseDBhlrVA5/tXGKdCPBJX0muzSRDethPUQmm43 guq2oTpCPTL3xtvlwZVQYV/pFAS4oAvfifAwBjd3QYQySyWRvHi5BXpmok3j3wqJ VgTFvYD9roqeUZygfXMI= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B94CED788B; Sat, 10 Jun 2017 06:24:33 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E3035D0EE1F2; Sat, 10 Jun 2017 15:24:34 +0200 (CEST) From: otroan@employees.org Message-Id: <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2100C294-9725-41AB-BE39-DD93E4DE8B17"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Sat, 10 Jun 2017 15:24:34 +0200 In-Reply-To: <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> Cc: Lorenzo Colitti , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 13:24:36 -0000 --Apple-Mail=_2100C294-9725-41AB-BE39-DD93E4DE8B17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >> do we have a rationale for fixing the value in the IPv6-over-foo = documents (anymore)? >=20 > My rationale is that >=20 > a) RFC4862 describes it very carefully as a parameter. And explicitly says it must be consistent with the value defined in 4291 = and IPV6 over foo documents. > b) The addressing architecture describes it as a parameter ("n"), > and then suddenly defines n=3D64 for no reason. No reason? Please. Read RFC7421. > c) It gives no reason because the true reason was the obsoleted EUI-64 = mechanism. No, that's too simple a view of history. There were at least 3 driving reasons. 1) The compromise of choosing 128 bit addresses instead of 64 bit or = variable length. It was quite clear that 64 bits was plenty, so it made sense to tilt = the playing field to ensure that we wouldn't repeat the IPv4 mistakes = of not giving end-hosts enough addresses. This was done for only 1/8th = of the address space (later changed). 2) SLAAC 3) 8+8 > d) There is no physical reason for n to have the same value on = different link media. There is no technical reason why IID length is tied to the datalink = type. There was at some point when we thought it was a good idea to embed L2 = addresses in the network layer address. Even so, it would be trivial to make implementations deal with arbitrary = IID lengths. > e) Future link media might more appropriately use a different value. See above. has very little to do with data-linkt type. > f) Therefore the addressing architecture should only define n=3D64 as = a default > recommendation for IPv6-over-foo documents. I don't think that follows from the arguments laid out above. We can (if we want to), make SLAAC work with any IID length. Including = 0. I still don't understand what the goal is here. What problem are you = solving? What is the proposal? Ole --Apple-Mail=_2100C294-9725-41AB-BE39-DD93E4DE8B17 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZO/MSAAoJEL7aWKiYQt92dekQAK9YjUQaJqBhNfmWBQ2hGh4F TJL+Lrftuzv/7PLXjWt1sYvE6selbuiIE/Zb2G1UcHn+Lpc9mn/gm+b9OSzodKhl i4yb+dtsVd7pUWMRQL1ZGGnKTMP1qLVllPXuJkvyqhp8ow/gYCgS8EcHrXqsefHM m95Gz++D1VRwb5hZiMUmWLzt8uId0uFD/RvVlx6BTRyHNFrIqMI9o2fp/4SKvvVA xBQIDE8XaeQiU4aPxKgmEklHZC7Cpo0MwThWgU415gupi9jozUs4db7e4z64J++m B7nv+yF9EDJTyR2FF/9imtcQoqQTlj210SrL4Y+apZWRYNI3sJrDaseLQjLfPnAm y1DMCI/xQxRhTexp3+0TiAtljhq+MVPpnrIEon0II96OM60RSYzMuC4BW7lHVkaI 7bi/fcsMWWwSM7MtrGQwQZM3aeFYilsk5aE9ktAP6zKuX8Y9SxZ26+JWnDQ3DY/3 mmdExmqrieIy9cGE8NIrpQkjWXmJpK+9nv7p78jZOBss2H3fbpGEsnllNHrf/Q4O KTGGJJAmziSTCQLtuV0MydvVBPwUhVYJVEEv71KrHWsVik1GtQ90qeIDTVsfMljo dq0TjW4ZQtwbAu4BWoOdLmszY69azdtFyft9sYgi4qf6/G6cLZqJnoaV2zwuDG7A fign2H0NHnkb8wR8sX+V =GAHL -----END PGP SIGNATURE----- --Apple-Mail=_2100C294-9725-41AB-BE39-DD93E4DE8B17-- From nobody Sat Jun 10 07:01:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2055127333 for ; Sat, 10 Jun 2017 07:01:19 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VeZ7v4Lqed2 for ; Sat, 10 Jun 2017 07:01:17 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id B53621201F2 for ; Sat, 10 Jun 2017 07:01:17 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2017 14:01:17 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4196DD788B; Sat, 10 Jun 2017 07:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=/KuUwfLp1GysOT+JxqGZRvmmWNY=; b= hR8Rqk2sNVNDGbNx9IjWxY2qJ3gU2YlC4pGSMS/dNmpUmRd1GXBsM5CLHDcZU278 XOdNWQL0uTR/A36mcy9NhYCr9z7S2M3bZRMxOEQG6osumlTJL9gvzYmORzFFp0mW zkKLCl7/OenNdy3dX7pGF4sHBeML1H558rDyVyuHu40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=MZc+wYvrNmpVObOsDXyEx+e +P8alknFP6ZgIc3a0JJOUdlDjEC0RctMOEw7Rba0T8/mh+zvDQykXG/d0E+qejdo PREoOvJdZzwyfkumZaXxEwmQ/Ufx0ZUjnUnTEaKCao8rBus8PHehwVB08GIzOrFH F5o/vK95Q6t9aC/KdCgM= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E17EAD788A; Sat, 10 Jun 2017 07:01:16 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 09A09D0F9BE5; Sat, 10 Jun 2017 16:01:15 +0200 (CEST) From: otroan@employees.org Message-Id: <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_39887595-CBF0-4414-A073-A37D5DFB8598"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land Date: Sat, 10 Jun 2017 16:01:13 +0200 In-Reply-To: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> Cc: 6man WG To: Brian E Carpenter References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 14:01:20 -0000 --Apple-Mail=_39887595-CBF0-4414-A073-A37D5DFB8598 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, [...] > To a significant extent the above three issues are tussles between = operational needs > and conceptual purity. To be specific: By this labelling of the players in the tussle, you leave no doubt on = which side of the tussle you have taken. I don't know if that was = intended. It is of course not as simple as a conflict between operational need and = "ivory tower idealists". You want to ensure end-users get enough address space, you want that = operators can aggregate routing well, allow for innovation like = identifier, locator split... Content providers, applications writers, = lots of players have a stake in this. But it essentially boils down to the matter of control, power and money. > 2. The interface identifier length was fixed at 64 bits about 20 years = ago. It > was not an arbitrary choice then - it was designed to match the = hardware address > size of FireWire, then expected to be the network of the future. (It = actually > turned out that the network of the past, Ethernet, became the network = of the > future. But if we'd fixed on 48 bits for that reason, we'd be having = the same > tussle about 80+48 that we're having today about 64+64.) Network = operators have > two complaints about the boundary at 64 bits. Firstly, although in = theory it could > be different for different media (for example, 64 for FireWire and 48 = for Ethernet) > in practice it's been set at 64 for everything. Secondly, bitter = experience with > IPv4 25 years ago taught everybody (we thought) that routing should = always be > "classless" with no rigid rules about the length of routing prefixes. = But the de > facto rule in IPv6 is that leaf subnet prefixes MUST be 64 bits long. = ISP operators > would like that 64-bit boundary to float. Unfortunately, many people = involved > in the IPv6 design think it's a terrible idea (and a change to the = IPv6 standard). > There are several reasons for that - though the main one seems to be = that having > a 64 bit boundary everywhere makes portability (of code, and of = computers) easier. > Also, much software blindly assumes the 64 bit rule. But this has its = own downside: > suppose an ISP follows bad practice and gives a retail subscriber = exactly one > 64 bit prefix. If the subscriber needs to operate more than one subnet = in their > home or office, they simply can't do so unless the 64 bit rule is = relaxed. That > wastes considerable potential for IPv6 deployment. But - again, but - = if the > 64 bit rule was made flexible, perhaps some ISPs would decide to go = further - > say give a retail subscriber exactly one 80 bit prefix. This could = generate > a race to the bottom, where the really cheap and nasty ISPs give a = subscriber, > say, exactly one 120 bit prefix, wasting even more of IPv6's = potential. On this > argument, sticking to the 64 bit rule seems safest. >=20 > So, the 64 bit boundary is the well-understood solution that works = everywhere, > or the spawn of the devil that blocks future flexibility for both = routing > and address space conservation. "ISP operators would like the 64-bit boundary to float". Is that a true = statement? The draft we are discussing is clarifying that it within the = architecture to manually configure addresses with arbitrary length of = the onlink prefix. Some people definitely want the 64 bit boundary to = float. I'm unsure what the arguments are for that. And what problems it = solves. Now we do have real problems. - "Permission-less extension of the network. Where I want to extend a = network I do not control, where I connect to a network with /64 SLAAC, = or /64 to the host. The "natural" inclination then is to subnet the /64. = But this problem has many other solutions too. Unfortunately we haven't = made any of them stick. Perhaps we should restart the work on MLSR. - The assumption that on a multi-access link a host can use as many = addresses as it likes. Every address a host grabs has a real cost for = the network. TCAM space is limited. It's understandable that network = operators (and vendors) get cautious how this will play out. Perhaps ARO = would have been a better trade-off between the interests of operators = and hosts. - Multi-prefix multi-homing. The idea that the host by choosing source = address controls the exit circuit in a network doesn't sit well with = most operators. Neither is it possible to make it work without = essentially a session layer... Ole --Apple-Mail=_39887595-CBF0-4414-A073-A37D5DFB8598 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZO/uqAAoJEL7aWKiYQt92VgUP/3zJh2BV7OCKtSUJ+sVcvak5 hl6I300n8lkfsx1rI5QQXkqK1GuX1Tj0SvHlXGXdNi/lLWZkf2QHKpT5ZmSnXqAk CXKm08AjcSYuvqgrHGGpQHrHFvjh7XlbvztEOt8lAG4llcVFmGzKk5xSEW/2YOCU ZZ0L7ECfQaa39kavPNVZHHoIe8G8KQus4OTRGZmaWHEhvGiYZEL9Sb/i6KMqqcKx CiaCVYiEm/4ap7EoHj9EfoAVPWWmI/zzMnx2zKSpbOqJNA06inzZ1eG/uCyekCEV y6hoF83ToV/ZJvqkyjntjVymltJ5+xGfg9EWnMfagSBzko8KRcZU8McTiaqfZ1FB aJH6ljuNIApVFZ4/QOZgdW9KUwT/5AtBa2QbLpiOByZpBUYn56Uw/zcH8n1kcwWo Cucs01Hvhz94p2Hbhv5wzl0IdyFLY+keeFUzOLV6PBSA1baUtY7XGWDhV8l74S25 k4/qULJLQLggunn042Jq2BqlKvroGCvwkPdYnwKuqcL74T2IcfMSrh43AVxMm1UN xhdhF9aHJpuYZYUFS1NowADol5KPvl/3k9flR9/8iF1A32TvPQgKgo+OSyLbJDpl x1CbPdhObmFCETmgzSa1NEZhqE+jyCSDPNA2ejYSBcuu9hSDKJJn0vpeF3r4If4D Ww/+UrabHfnKL+egbdx8 =cGs5 -----END PGP SIGNATURE----- --Apple-Mail=_39887595-CBF0-4414-A073-A37D5DFB8598-- From nobody Sat Jun 10 07:02:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38285129456 for ; Sat, 10 Jun 2017 07:02:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a0hWtYeXSy5 for ; Sat, 10 Jun 2017 07:02:34 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id B1F831201F2 for ; Sat, 10 Jun 2017 07:02:34 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2017 14:02:34 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6D47ED788A; Sat, 10 Jun 2017 07:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=B2eVFlyDOyER1R6/6B6WdgBijK8=; b= MM7dn+jObREZOkz2fvnXpyyv85W7cqREQ6LoWqgJI9XYbC8Cv4maEgYAba7B6G0V 3MRT75+GUj7AMR6kDdSGyRIYkgbtO6HcnoJQFLVinWTx+z6FG39vea0yA4yETPVK T6i7uNucHj+vxxbu/B/53nrY7H/O4lHhk5uBPm1v/lY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=nYhEn7doay350WH+VwE4mYt G6RMwFXL+2eFnl5fx0jXLQZMZb8byIBzW53tq2arAodVSx7fV2fhBqcgBufUtp9w fPgZnQ/g5wqaqdX6xVm+/qZhgwwC3J4nwR7scomU0YSWBMTo163bZY+NxrBnkhrX MR+YPbU4kxhkTjSXdYCM= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 3F9C5D788B; Sat, 10 Jun 2017 07:02:34 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BCB83D0FA3C8; Sat, 10 Jun 2017 16:02:32 +0200 (CEST) From: otroan@employees.org Message-Id: <061960C0-CEEE-4D98-A4C9-A33165FA57D3@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2EE710A5-E582-4F88-ABEA-F957BC2F5BC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land Date: Sat, 10 Jun 2017 16:02:32 +0200 In-Reply-To: Cc: Brian E Carpenter , 6man WG To: Richard Hartmann References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 14:02:36 -0000 --Apple-Mail=_2EE710A5-E582-4F88-ABEA-F957BC2F5BC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Thank you for this write-up. >=20 > I lost hope that any of these discussions will be resolved, or = compromised on, at any point in the near to medium future, but if = nothing else, this is a good place to point people to when they ask why = we can't have nice things. It might be that the impasse is the best outcome there can be. Enumerate "nice things"? Ole --Apple-Mail=_2EE710A5-E582-4F88-ABEA-F957BC2F5BC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZO/v4AAoJEL7aWKiYQt92a5IP+gJEshP6SFAopSBLgXZ7LnPL LOALY5Rb0VPDFtz3PXyHJNimLKau/OjU4tVQz8N2/6g1s6xCCIxPvJ5z268je7HH 20wYpJkAkiaADXscwCpyZswgTZIr9FFoWzmrilpyYeaqFCLR3fsdDrvPgGL+ktt9 JXXTWBwq2wUyZFHQkErbWBqYRJ88J0AokzSDcvl3LM51oeDoaOKY7lrZNno32Yo8 poTUB1ye9nNeA9UdP35Dlivq4fHcedKd8JGeI3b8qAasUyIbnAWtzJHKGOK7AhSu n4DmIXUFFHa7QsKo0Twrl/k006VJZp24xMW6GghjWMq3qEHu0101Zrwyapo+GUJ1 iHE1E6qA/8piE7hAU0qD8qiK+bSPfh9knGn1eOEs/DGamoTyhSss8q3KHNKfuURa QF2+qrgAZJ9XyiV8Vm8Ugm7mgwvdHqhjmLG+lfJiErjk/IqXlu9OZcfuheDdwzXu cRlde6ssYgjZWZx+ClZIOGm+StxZL242gGkg5pIza6u6v2zLHePh2DHLqoYDp+/d n8KmNquPOXS9ABH2AwesIsAwuHelRHe7H02+zsHTyexcYBnhvPDbDKnIm3MPzQ1a T5bk7Uuex01iNpLdnfyNEGzVQGGPvNJVGKdVzYhSObjWvYyBakNQFLItRTDDPL0P y9iAnj4PsrU0ADjc7qd4 =EoAw -----END PGP SIGNATURE----- --Apple-Mail=_2EE710A5-E582-4F88-ABEA-F957BC2F5BC7-- From nobody Sat Jun 10 08:43:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477B8129432 for ; Sat, 10 Jun 2017 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZClEmGRZ88s4 for ; Sat, 10 Jun 2017 08:43:00 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19ADF1200E5 for ; Sat, 10 Jun 2017 08:42:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 97A2A3493CD; Sat, 10 Jun 2017 15:42:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 55AEE16003D; Sat, 10 Jun 2017 15:42:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3559E16004F; Sat, 10 Jun 2017 15:42:56 +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 RVkI78T5RnSs; Sat, 10 Jun 2017 15:42:56 +0000 (UTC) Received: from jmb.localhost (c-69-181-118-158.hsd1.ca.comcast.net [69.181.118.158]) by zmx1.isc.org (Postfix) with ESMTPSA id E9FA016003D; Sat, 10 Jun 2017 15:42:55 +0000 (UTC) Date: Sat, 10 Jun 2017 08:42:55 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: otroan@employees.org Cc: Brian E Carpenter , 6man WG Subject: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) In-Reply-To: <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 15:43:02 -0000 At Sat, 10 Jun 2017 15:24:34 +0200, otroan@employees.org wrote: > >> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? > > > > My rationale is that > > > > a) RFC4862 describes it very carefully as a parameter. > > And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents. It's actually subtle how RFC4862 ended up with the current text. It might help if we recall the discussion at that time: https://www.ietf.org/mail-archive/web/ipv6/current/msg01797.html Different people may interpret it in different ways, but my recollection is that - we actually thought it was quite unlikely to see a change to the IID length, not least because the addressing architecture spec (RFC3513 at that time) is "100% unambiguous" about it, i.e., 64 bits. - but, the addr-arch and link-type specific documents defined the length (seemingly) independently. RFC2462 referred to addr-arch in one place and referred to link-type specific docs in other place. RFC2462 also mentioned the magic number of 64. Since the relationship between the addr-arch and link-type is not explicit this could potentially lead to inconsistency between them (we only relied on the IETF human review process for consistency). - ideally we should have resolved this fragility at that point, but it was considered out of scope of rfc2462bis (and probably rightly so). - as a result, in rfc2462bis we decided to remove the reference to the magic number to avoid further possible conflict and specify link-type specific docs as the primary source of the IID length, while noting the addr-arch defines the length so it will be less likely to cause inconsistency if and when either of them is updated. And, as long as we use link-type specific documents as the primary source, it's natural to expect it might be different for different link types (no matter how unlikely it was deemed due to the constraint of addr-arch). So we also added notes to implementations not to assume a particular constant. In a nutshell, RFC4862 is not an appropriate source as a supporting material for either position on this matter, whether to keep fixing 64 or make it more variable even in practice. RFC4862 tried to keep itself as independent as possible from that discussion, while being sufficiently flexible in case the current practice (i.e. fixed 64) ever changes. I'd also note once again that this discussion has nothing to do with the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This operation configures a 128-bit IPv6 address with 120-bit on-link prefix. On-link prefixes have always been variable, and they have nothing to do with IID length or SLAAC. We don't have to update addr-arch or RFC4862 because of this. (draft-bourbaki-6man-classless-ipv6-00 seems to be confused on this point, and I suspect it increases the confusion and controversy in this whole thread). -- JINMEI, Tatuya From nobody Sat Jun 10 13:34:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F1E129421 for ; Sat, 10 Jun 2017 13:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm_A6IONT7VT for ; Sat, 10 Jun 2017 13:34:33 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 A0415126D85 for ; Sat, 10 Jun 2017 13:34:33 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id C1A6CB45 for ; Sat, 10 Jun 2017 20:34:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj5bZPI3E9Fd for ; Sat, 10 Jun 2017 15:34:32 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 7AC1CA67 for ; Sat, 10 Jun 2017 15:34:32 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id f19so14164269uab.9 for ; Sat, 10 Jun 2017 13:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LdwNbRSh/hwieia/hWiMby/qkC06flxHqz4xzzGQwkQ=; b=fkSgHBxgccjCvWn7Tg+dww1a7rgcK4Ielccat08C4AkrPtiNHTv5YvUAOACNvGn4Ye qS9s6TDSSaX7wCujI8324r3iOwY0uKToS8aHNh42E6d8Y89obchWdwCX//tIQUkbrfaD 7uDiYP0uj0+sMwlFr9+8yRtViJzkNYN0tIqNtlEdGarPQfmNUmu23sZ80uRzF8a3TEho 6HtMsJkQvhe7iMQdlAHlADRKNA8b9Ymi8Tps9+8GNgyX3SL5KmcWBlb5SvXGenGymlDP 9oK89Ebv5MnCo55eidOOLWyr7ntnAOMMK0bpj20+vP0RqVBMc1h0TXFy4MaYqY1AzgMJ Bdjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LdwNbRSh/hwieia/hWiMby/qkC06flxHqz4xzzGQwkQ=; b=i2reBhcU/h3jc5x74UMyIFu8KjhoA5gO5wb+mpGh6rl8l5AqAbEW8ygbYCGThWqtBC y2WjDk1rUpYd2hfbM/PVS40O+Ke8a6d3e3X5WOVirvlNOwrmDlXahiFAoFSx36XG6X9p HuNbO0lO3zOd2rVqF2pPRTFbpKzlYfICyTA1XezIlb0Dgoi/pXIXNzXBBffljEjx6yyH yfxaL6uRHoDQVjqwYbiZWJXZ0SlBayiqdo4LLN1k4zV8KWYD9KGZTKJX28AznqJhC3BU gE7GgqrpNn6924Do7UaAWyksL78VE7061zs/gnz2l/R4k8+M/dtnyMuR3WId44OSsYRl aOHw== X-Gm-Message-State: AODbwcBbNtfJJG1u5kGuuJirWMEku7e/AF+WdLsG2W1MOwyb2onJ580s DV4qKX3bjlLv9+odZ0NSkBpmD8Zgi5N2YD3My5fNRVc+I/ml8oLLPqNqHLWa7vAynV2KptZHmwb R/Na4o+FY+D6AZS0= X-Received: by 10.159.32.194 with SMTP id 60mr5496764uaa.142.1497126871610; Sat, 10 Jun 2017 13:34:31 -0700 (PDT) X-Received: by 10.159.32.194 with SMTP id 60mr5496758uaa.142.1497126871340; Sat, 10 Jun 2017 13:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Sat, 10 Jun 2017 13:34:30 -0700 (PDT) In-Reply-To: <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> From: David Farmer Date: Sat, 10 Jun 2017 15:34:30 -0500 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Ole Troan Cc: Lorenzo Colitti , 6man WG Content-Type: multipart/alternative; boundary="94eb2c0b646059b4470551a10359" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:34:36 -0000 --94eb2c0b646059b4470551a10359 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 8, 2017 at 7:10 AM, wrote: > > > > "Interface Identifiers should be 64 bit long except > > when the addresses are manually configured, > > > > In order to publish that text we need to agree on what it means. Can you > explain the semantics of the the interface identifier of a manually > configured IPv6 address? What are they used for? > > > > Note: the semantics are *not* the same as the prefix length of an IPv4 > address. The prefix length of an IPv4 address implies that that subnet is > reachable on, but the IID implies nothing about reachability. > > I'm not sure I understand your point. > > RFC4291: > > IPv6 nodes may have considerable or little knowledge of the internal > structure of the IPv6 address, depending on the role the node plays > (for instance, host versus router). At a minimum, a node may > consider that unicast addresses (including its own) have no internal > structure: > > | 128 bits | > +-----------------------------------------------------------------+ > | node address | > +-----------------------------------------------------------------+ > > A slightly sophisticated host (but still rather simple) may > additionally be aware of subnet prefix(es) for the link(s) it is > attached to, where different addresses may have different values for > n: > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ > To be truly honest I've never found that description helpful, in fact I think it is part of the problem. It confuses classic IPv4 subnet prefix(mask) terminology with IIDs and on-link prefixes for IPv6, which are subtly different. In my opinion, the IPv4 subnet prefix is not used in the generation of the IPv4 address per se, it is really only used to determine locality, in this way it is similar to an IPv6 on-link prefix, and has little to do with the IID length. However, the above quote by using subnet prefix terminology, ties the subnet prefix length and IID length directly together, also seeming to indicate that IIDs and on-link prefixes have to be congruent, but the IID and on-link prefix can be incongruent and therefore again using subnet prefix terminology really confuses the situation and I think this is the root of this conflict. Therefore when we say the IID is 64, the above seems says the subnet prefix is /64 and therefore the on-link prefix is also /64, but this is not suppose to be the case. I've been thinking about this for a while and I think the only way to resolve this conflict is to stop using "subnet prefix" in reference to IPv6 and only use it in reference to IPv4. I would propose substituting "addressing prefix" for "subnet prefix" in the above quotation from RFC4291 and add a separate discussion of on-link prefixes and then note the classic IPv4 subnet prefix length is equivalent to the on-link prefix length in IPv6. If this is done then the statement that the IID length MUST be 64 says nothing about the on-link prefix length. The IID is only used to generate an address, once the address has been generated the IID and its length are actually irrelevant, the address itself is 128 bits long, and only the on-link prefix and length is relevant in determining locality. So, I think if we stop using subnet prefix vocabulary with IPv6, we might find consensus and resolve this conflict. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c0b646059b4470551a10359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Thu, Jun 8, 2017 at 7:10 AM, <<= a href=3D"mailto:otroan@employees.org" target=3D"_blank">otroan@employees.o= rg> wrote:
>
> "Interface Identifiers should be 64 bit long except
> when the addresses are manually configured,
>
> In order to publish that text we need to agree on what it means. Can y= ou explain the semantics of the the interface identifier of a manually conf= igured IPv6 address? What are they used for?
>
> Note: the semantics are *not* the same as the prefix length of an IPv4= address. The prefix length of an IPv4 address implies that that subnet is = reachable on, but the IID implies nothing about reachability.

I'm not sure I understand your point.

RFC4291:

=C2=A0 =C2=A0IPv6 nodes may have considerable or little knowledge of the in= ternal
=C2=A0 =C2=A0structure of the IPv6 address, depending on the role the node = plays
=C2=A0 =C2=A0(for instance, host versus router).=C2=A0 At a minimum, a node= may
=C2=A0 =C2=A0consider that unicast addresses (including its own) have no in= ternal
=C2=A0 =C2=A0structure:

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0128 bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0+--------------------------------------------------------= ---------+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node address=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+--------------------------------------------------------= ---------+

=C2=A0 =C2=A0A slightly sophisticated host (but still rather simple) may =C2=A0 =C2=A0additionally be aware of subnet prefix(es) for the link(s) it = is
=C2=A0 =C2=A0attached to, where different addresses may have different valu= es for
=C2=A0 =C2=A0n:

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits=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= =A0128-n bits=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=A0subnet prefix=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface ID= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-------------------------------+------------------------= ---------+

To be truly honest I'= ;ve never found that description helpful, in fact I think it is part of the= problem. It confuses classic IPv4 subnet prefix(mask) terminology with IID= s and on-link prefixes for IPv6, which are subtly different.=C2=A0 In my op= inion, the IPv4 subnet prefix is not used in the generation of the IPv4 add= ress per se, it is really only used to determine locality, in this way it i= s similar to an IPv6 on-link prefix, and has little to do with the IID leng= th.
However, the above quote by using subnet prefix terminology, = ties the subnet prefix length and IID length directly together, also seemin= g to indicate that IIDs and on-link prefixes have to be congruent, but the = IID and on-link prefix can be incongruent and therefore again using subnet = prefix terminology really confuses the situation and I think this is the ro= ot of this conflict. Therefore when we say the IID is 64, the above seems s= ays the subnet prefix is /64 and therefore the on-link prefix is also /64, = but this is not suppose to be the case.

I've b= een thinking about this for a while and I think the only way to resolve thi= s conflict is to stop using "subnet prefix" in reference to IPv6 = and only use it in reference to IPv4.=C2=A0 I would propose substituting &q= uot;addressing prefix" for "subnet prefix" in the above quot= ation from RFC4291 and add a separate discussion of on-link prefixes and th= en note the classic IPv4 subnet prefix length is equivalent to the on-link = prefix length in IPv6.=C2=A0 If this is done then the statement that the II= D length MUST be 64 says nothing about the on-link prefix length. =C2=A0

The IID is only used to generate an address, on= ce the address has been generated the IID and its length are actually irrel= evant, the address itself is 128 bits long, and only the on-link prefix and= length is relevant in determining locality.=C2=A0

So, I think if we stop using subnet prefix vocabulary with IPv6, we = might find consensus and resolve this conflict.
=C2=A0
<= div>Thanks

--
=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<= br>David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu=
Networking & Telecommunication Services
Office of Informatio= n Technology
University of Minnesota=C2=A0=C2=A0
2218 University Ave= SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55= 414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c0b646059b4470551a10359-- From nobody Sat Jun 10 13:44:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1CB12944B for ; Sat, 10 Jun 2017 13:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxDQ1eWv8Bfh for ; Sat, 10 Jun 2017 13:44:36 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 CC264129431 for ; Sat, 10 Jun 2017 13:44:36 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id a70so35132487pge.3 for ; Sat, 10 Jun 2017 13:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nghmeaon2qNNHIOXTb0z9FZ450jazrnx/QzI76eH6k4=; b=RxFgkNJpArW6IkvNyMR13EvQXNxoGaCP6aQazv8dG/3kF7iIPpvU56/gmtzMRChEmo uo2CLtXSZzeQOeCTt70BYJcYbxNVRyTrLHBHN7rj6Rx5GzfzK8T7II1REkI9UyjkxG3W 20Ns6ClOup30aQalUqofQkyirNbwSJWg8zcw/0GULkvnOinxl70ttMGPi8uLVDyoxlkw oYt5panQ+TO33roR2EsSfuYCGbtb+U0UIhEie429dZlr4gdvUCZh6AAvK4rm8SXD0p43 cIjiTHC5JMtgclO/HLBaTTWuDPxDGxyJfHOuw04NqoWKZzhDJ+H2jBdwiR/lWm4SR6dw w8RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nghmeaon2qNNHIOXTb0z9FZ450jazrnx/QzI76eH6k4=; b=HJHAQ4HmZJnRPbT37JLcbNBTvMzQI66XbYYEiSVhPa87pw0KAww9fPq14gRpms0lSm rrBhacKMrNx7AJ0g5u0NjgOf/GV/mwXUsOhM0b1Rs7EnKVVjyGDqIG1zK5dW1fGqIEBr 37YO3O0I9p0rM2LnRCQFm1WSRY+QPlyMpBsQaHC4mld7U84dhjwuldaCYxSJzWP22WPj QRaAGlvQvEZJmAml/vFdl6GVwyA418MLcYoWCN/BD5WXL3Y8haBS6r3oxAEFXl0xD6nW bTBxrGkGFIAu5c9HJcKd3Gp7TWRPpN/FhO36PoOSnyjQ4Q/CyI3ovuJF1xC5kc7/d9MV 0WZQ== X-Gm-Message-State: AODbwcBcd/UWqbGkCJP1Tf3ZCwen3zZpdETPm1fHrq77qNdiJMpESMaf tU/8U5d8WrF36rwEzAc= X-Received: by 10.99.158.18 with SMTP id s18mr40564377pgd.113.1497127476490; Sat, 10 Jun 2017 13:44:36 -0700 (PDT) Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id o2sm9210404pgq.44.2017.06.10.13.44.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 13:44:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Fred Baker In-Reply-To: Date: Sat, 10 Jun 2017 13:44:34 -0700 Cc: Ole Troan , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:44:38 -0000 > On Jun 10, 2017, at 1:34 PM, David Farmer wrote: >=20 > I've been thinking about this for a while and I think the only way to = resolve this conflict is to stop using "subnet prefix" in reference to = IPv6 and only use it in reference to IPv4.=20 Very much agree. That's the reason RFC 7608 calls it a "prefix length". = Prefixes, of course, are a routing concept, and where you are in the = network affects your perception of the prefix length immensely. RIRs are = allocated prefixes by the IANA and in turn sub-allocate them to ISPs and = PI prefix holders. ISPs in turn allocate prefixes to customers, and = those customers and PI prefix holders end up at some point with LAN = subnet prefixes or prefixes on p2p links, and hosts think in terms of = /128. There may be other prefix lengths along the way. The only place it makes sense to me to talk about a specific length for = an IID is with SLAAC; if a network is allocating addresses manually or = using DHCP, they are in control and can do whatever they like - I dare = you to stop them. But the IID is the part that is never a prefix - the = last N bits of a /128, and by convention 64 bits.= From nobody Sat Jun 10 14:15:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B783712943C for ; Sat, 10 Jun 2017 14:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi23ptCClpKH for ; Sat, 10 Jun 2017 14:15:26 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ED7128CF0 for ; Sat, 10 Jun 2017 14:15:26 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A2B23E6067; Sat, 10 Jun 2017 23:15:24 +0200 (CEST) Date: Sat, 10 Jun 2017 23:15:24 +0200 (CEST) Message-Id: <20170610.231524.41691706.sthaug@nethelp.no> To: farmer@umn.edu Cc: otroan@employees.org, ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: sthaug@nethelp.no In-Reply-To: References: <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 21:15:29 -0000 I agree with the general comments about confusing classic IPv4 subnet prefix(mask) terminology with IIDs and on-link prefixes for IPv6. > The IID is only used to generate an address, once the address has been > generated the IID and its length are actually irrelevant, the address > itself is 128 bits long, and only the on-link prefix and length is relevant > in determining locality. An explicit statement that IID is only relevant for SLAAC would be very welcome. > So, I think if we stop using subnet prefix vocabulary with IPv6, we might > find consensus and resolve this conflict. That may well work for the people on this list. Unfortunately, I'm not optimistic about ACME Company's Joe network manager understanding it. Steinar Haug, AS2116 From nobody Sat Jun 10 16:23:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8212946B for ; Sat, 10 Jun 2017 16:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZusKGgR-hp38 for ; Sat, 10 Jun 2017 16:23:42 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 3E934129468 for ; Sat, 10 Jun 2017 16:23:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id C47055AE for ; Sat, 10 Jun 2017 23:23:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV5IXdb2UjTs for ; Sat, 10 Jun 2017 18:23:41 -0500 (CDT) Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 9397C9B0 for ; Sat, 10 Jun 2017 18:23:41 -0500 (CDT) Received: by mail-it0-f70.google.com with SMTP id x129so10733137ite.3 for ; Sat, 10 Jun 2017 16:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KLoozvI8RNgYEtEMrJV/B/lz8PvlE2QGuLN9s61LstY=; b=JlRmTTMYhw9BDwnnMdSIUQUr2xWF1YXezTm2+XCyc2JogYa1Y6Lr5KGuioNiC4SETm 9QGIsEvn4CjQldYc25NiP2V3AWAjG2OVsQzD3ddvIuEY0qpgyAtQ4ROnAICzKfGIqATs HtXfHDf1zhbQ8fV9tdWXW9XooEwjFcTc4LSaEF/FIhPLnwhfUmZMiYxcXSqpwse+Z4pk Q6x+lKMyw1K7SA3EVyrVOc3S7sJysALGk378y1J05a/KJxJ64xxnEYtkm6wTXMLtxJZB WV1KjrncjMT/BQMc533BISKMZClDUkjf4XbxRyodPgCSNHxJbkKIwPnHw+ixoAKdCFRj Ke4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KLoozvI8RNgYEtEMrJV/B/lz8PvlE2QGuLN9s61LstY=; b=Ba7UUa5L+cDtlLMn9bs3PtAsO11oYGTKPWWV/wjB6FXyiYKztf9JW1+RW4/nR2reTL 10uSAjWdIyIBT0lG3sLVO7IUTlFeGjKoH4LOX9n7+pxr4UcCDjOLaJxwY4MwG2rsh1iW PlRd6T1UdIYPyYM2uogcPUyBKVWDmh7YJm6SKlZjNaa+Eo8vT2BNjbCYM6OgfYRZ9+pe h7WVJ+ZYDtZqaY8tQfFYgngp0tngO8n9B9Rf+flKgG7RSr38cadii8eLD0ThsA1BoO2H lYO6aQx+HhPUOVz8FkjPHNkDL8Jl0HvSM+trffWi1hcMU99+6lzh/xiZ6p6SL31HiVUx ZvIA== X-Gm-Message-State: AODbwcAfqO0aBcA7CLAX0RWOkOuYgxUToDZbPhu2PYdOFqVNkPswTyHx XGnn7RTkwI7/NnIbCJhvMC3yAsn7jpC77ygDHRLzIGijJgZsbi927S+NVj7h2PDdvGry4zaRopA = X-Received: by 10.107.10.84 with SMTP id u81mr37495245ioi.206.1497137020726; Sat, 10 Jun 2017 16:23:40 -0700 (PDT) X-Received: by 10.107.10.84 with SMTP id u81mr37495241ioi.206.1497137020544; Sat, 10 Jun 2017 16:23:40 -0700 (PDT) Received: from [10.83.67.6] (mobile-166-175-58-7.mycingular.net. [166.175.58.7]) by smtp.gmail.com with ESMTPSA id 197sm1954335ity.5.2017.06.10.16.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 16:23:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: <20170610.231524.41691706.sthaug@nethelp.no> Date: Sat, 10 Jun 2017 18:23:36 -0500 Cc: otroan@employees.org, ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <954FD01E-135B-45DA-875A-3B1F1724D5C7@umn.edu> References: <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> <20170610.231524.41691706.sthaug@nethelp.no> To: sthaug@nethelp.no Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 23:23:44 -0000 > On Jun 10, 2017, at 16:15, sthaug@nethelp.no wrote: >> So, I think if we stop using subnet prefix vocabulary with IPv6, we might= >> find consensus and resolve this conflict. >=20 > That may well work for the people on this list. Unfortunately, I'm not > optimistic about ACME Company's Joe network manager understanding it. That is why I suggest noting that the classic IPv4 subnet prefix is most sim= ilar to the IPv6 on-link prefix, which both can be of any length, and both a= re directly related to routing, by determining what is locally reachable. Where as the IID length is a parameter defined as 64 bits and is related to (= automatic) addressing and is actually only tangentially related to routing.=20= So, I think we have been arguing about whether the equivalent of the IPv4 su= bnet prefix for IPv6 is fixed at /64 or not, and by tying the term subnet pr= efix to the definition of IID in RFC4291 and its predecessors we created an u= nnecessary conflict. Because the purpose of the IPv4 subnet prefix is more c= losely related to the IPv6 on-link prefix not the IID. Thanks David Farmer= From nobody Sat Jun 10 16:37:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFED126DCA for ; Sat, 10 Jun 2017 16:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX26BxiZtBp7 for ; Sat, 10 Jun 2017 16:37:50 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 C6D461275AB for ; Sat, 10 Jun 2017 16:37:50 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id f185so35626491pgc.0 for ; Sat, 10 Jun 2017 16:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x4XtnpJK7Lh80ZvN7BvDCE2vCXnzCXnQK6UhWq4oUYM=; b=bzv5RLfbCOMfdZ7GII0rLXI2JpXQ/FneCBmxieh5bnCWPS4ckyN4l17pII1xCCIt2X C9uH7/5LKV8NxbGSYiWThH1m9Zid7ScoUgH4jzwH1kIeCNn03L2TtOy86hTyjYfo5ALJ I2tYTUl66tJQXktzI/qrIQBlU9m/aQFXkBX7x4HDBKGBpXMp24mvDAeq62IvY3azlVQU wm9zOiySO9LU3I69ADwxDWfHCZDrsyFZp5wIKUJhKSCLQyMYYz06IybrR0rHKyA2dl+Z GstDFUTh0nu9sYIlY/NCfVKf0TWViQxYyZEnYp61rylL68TX2v9XXkxXSTo2erc50tDi 7OCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=x4XtnpJK7Lh80ZvN7BvDCE2vCXnzCXnQK6UhWq4oUYM=; b=b0XPFc5CFX5CzXp+7SRYuHN9+eCDhZNc4W/Cyxj8RXL2pn1kg25+BdhKBRR4l3NIAg lgdldthB+obONjP+m8sYpXzxsvgosT9uuXXJWu0uH50ko/8T420+7tWRaMBpHqrnyavg sUdVWSYDdUzgYfbU5dR2v9phFSkIoXVPpMTNsHhIBSKyASIJsNP28yKvg7y53zgx2YDl 4FGfytADf04P0PaCFacf2fuW4yKI57QajSmoBeYyhlbeakJFtMb1B4OmxpKpPo0J2Hct 1GwcO51nLXfh6hkEeoSag8RoBmlmEQFcGBq2FQue7h7zCAkjEt1PvST2Q/PAHLfCzoOi MHYg== X-Gm-Message-State: AODbwcC0CebnOjEC2UcsrgEUspDTQhZFVB6GBBAsu5U5xG4E96AyqwKr UQY0Qu4zXfE7XLlj X-Received: by 10.98.87.6 with SMTP id l6mr31360468pfb.233.1497137870130; Sat, 10 Jun 2017 16:37:50 -0700 (PDT) Received: from ?IPv6:2406:e001:541b:1:28cc:dc4c:9703:6781? ([2406:e001:541b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b86sm10997511pfc.27.2017.06.10.16.37.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 16:37:49 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org Cc: Fernando Gont , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 11 Jun 2017 11:37:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 23:37:52 -0000 On 11/06/2017 01:14, otroan@employees.org wrote: > Brian, > >>>>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? >>>> >>>> At the time of this writing, we should probably be in the camp of "If >>>> you do slaac, better stick to 64, since it's know to work with legacy >>>> implementations, and besides, allows for sparse allocation (reduced >>>> collisions of IIDs when you pick a random one, resistance to address >>>> scans, etc.). >>>> >>>> There's no compelling technical argument for mandating /64 (i.e., such >>>> specific value) if you do manual configuration or, for instance, >>>> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to >>>> do with backwards compatibility than with anything else. >>> >>> your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862? >>> I intended the question for Brian, as he seemed to be of a different view. >> >> It's hard to track this conversation, but anyway IMHO 2464bis should specify >> /64 as if the addressing architecture didn't even mention it. It has >> to specify something for SLAAC to work, and we have 20 years of deployed >> code based on /64. So we don't have the luxury of changing it, even >> if we want to. > > This is confusing. > On one hand you argue we have 20 years of deployed code base and that we cannot change it, on the other hand you want to remove the 64 bit boundary from the addressing architecture, presumably with the goal of changing it? This has two aspects for me: 1) It's simply out of place to define an arbitrary constant in something called "architecture". 2) By defining it globally we forbid using some other value on a future link-layer where a different value might be better. A 'should' could cover that, of course, which is why I accept the current 4291bis text. > The argument that SLAAC needs an standard-set per data-link type fixed IID length is a tenuous argument. The only technical requirement for SLAAC to work is that the the IID length is the same across all nodes on a given link. Yes, but for products to work out of the box without setting a value, you need a fixed value per link type. I can't see any practical alternative. > If we remove the 64 bit boundary from 4291, then an update of 2464 will likely result in the removal of any bit boundary there as well. No, for the out-of-the-box reason. I can't see any practical alternative to a fixed length per link type. >> I'm not aware of any technical changes needed in 4862. Jinmei-san has >> convinced me off line that 4862 does logically require the IID length >> for link-local addresses and global-scope SLAAC addresses to be the same. >> I wish the text stated this explicitly, but that's an editorial issue. >> Apart from that, it leaves the IID length as a parameter and that's >> as it should be. > > RFC4862 says: > Note that the address architecture [RFC4291 also defines the length of the interface identifiers for > some set of addresses, but the two sets of definitions must be > consistent. In many cases, the identifier will be derived from > the interface's link-layer address. > > The IID length in the IPv6 architecture is fixed. That is what the current standards say, yes. > And it has to be consistent across 4291, 4862 and IPv6 over foo documents. No, it only has to be consistent within a given link type (and that applies whether the link type is physical or virtual). It's an unnecessary restriction to say that it must be equal for all link types. > Feel free to look at it as a parameter, and you can pick any value you like from the 0-128 range as long as you pick 64. > That's the current state. And that is what every implementation does. If you want to _change_ that. Then you need to consider that in the light of 7421 and of the wider consequences for the Internet. > > I am still confused what this draft proposes to change. Nothing in any current implementation. Brian From nobody Sat Jun 10 16:51:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775F9129471 for ; Sat, 10 Jun 2017 16:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV81VuaLWqss for ; Sat, 10 Jun 2017 16:51:17 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 74F5E129468 for ; Sat, 10 Jun 2017 16:51:17 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id f127so10993950pgc.2 for ; Sat, 10 Jun 2017 16:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1SFTmsJCLSSy4DwB8l8HGgmuFgJ8zTFew+aA4yoE+5w=; b=FHygijdRHNRoyh71JCiLjFWJU+yHhXCbZPygndJ/sdKYMJjNvUPVZsZGR2moD50qrR zwDA2JjEYFeHb7za+LMrt10RlgZCBmM527e/udKlWvm6McGbzK/ZHR44Hv5goumqYAUg xxAZywBlVcFYs8/teyn2bkVAgY4T6ChJig4wp+Q58XIfWeeCiu0iy4uahACQUJnf8kMy Azb+Tv8+paj5izEn/5YQFxWkVLyj+DCLLuZOxNfyTrfP/un4ULGlIpctmpWWTEEt9gDo +mmD61pfbSdJKEkLoggy+5bMnyjYVQIi7ZHKpPWNp7KcJXjJRPSIuN4eyUsA0GpzkktL 58Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1SFTmsJCLSSy4DwB8l8HGgmuFgJ8zTFew+aA4yoE+5w=; b=VGaAub9VVwY/Rd6OEOzZnalOtWH8ItKG2rRnb12e9G3wAZtFJA9kZaj7FxcdNAwhJG dfowtFiSzWKRv9NPwzx64wuecqBCeA0bnfTp6WffJ2VSXiwTh4xLfyfpiFKGr65b6V48 acJUX8At382QGUq1aMBFDuW7QqCk6VfQQpzfY1kL56vMx3tDg5eh70hQNAV2sVliPzGv 7J4WEb30oSO/PXSV17nEM4oyrVgCM/bss8nt9gFk2KG0zdvKAqcfRrsKQXiyZXhIBBKv vdTy+BhXj/qZ/6qg5y0B3mx9t+gBkS08/eNnblbTws3i6TjByFzn2k9yjJV/0V4fk9zb M9/Q== X-Gm-Message-State: AODbwcBQTuR9+ujt/CIx4Ty4aAO2pkDxjTwR6nQA6sUJ9BSehJdsarQA 5EHVteKEiPd5Dizy X-Received: by 10.98.66.76 with SMTP id p73mr49266552pfa.180.1497138676738; Sat, 10 Jun 2017 16:51:16 -0700 (PDT) Received: from ?IPv6:2406:e001:541b:1:28cc:dc4c:9703:6781? ([2406:e001:541b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g78sm10297181pfb.122.2017.06.10.16.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 16:51:16 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org Cc: Lorenzo Colitti , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> Date: Sun, 11 Jun 2017 11:51:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 23:51:19 -0000 On 11/06/2017 01:24, otroan@employees.org wrote: > Brian, > >>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)? >> >> My rationale is that >> >> a) RFC4862 describes it very carefully as a parameter. > > And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents. Correct. The second (consistent with IPv6/foo) is necessary. The first is an artificial constraint IMHO. > >> b) The addressing architecture describes it as a parameter ("n"), >> and then suddenly defines n=64 for no reason. > > No reason? Please. > Read RFC7421. I was thinking of rfc4291bis at that point. Of course, RFC4291 provides a historical reason: compatibility with modified EUI-64. That's gone from rfc4291bis. >> c) It gives no reason because the true reason was the obsoleted EUI-64 mechanism. > > No, that's too simple a view of history. > There were at least 3 driving reasons. > > 1) The compromise of choosing 128 bit addresses instead of 64 bit or variable length. > It was quite clear that 64 bits was plenty, so it made sense to tilt the playing field to ensure that we wouldn't repeat the IPv4 mistakes of not giving end-hosts enough addresses. This was done for only 1/8th of the address space (later changed). I'd say stub networks, not end hosts, but yes. And the privacy argument now strengthens that. There are a lot of reasons why we need much more than 8 bits. Whether we need more than about 40 is an open question, however. > 2) SLAAC Of course. Again, enough bits are needed. > 3) 8+8 Which is really 6+2+8. But again, what's important is having enough bits, not any specific number. >> d) There is no physical reason for n to have the same value on different link media. > > There is no technical reason why IID length is tied to the datalink type. I believe there is: so that SLAAC can work with devices out of the box, without having to set the IID length. > There was at some point when we thought it was a good idea to embed L2 addresses in the network layer address. > Even so, it would be trivial to make implementations deal with arbitrary IID lengths. > >> e) Future link media might more appropriately use a different value. > > See above. has very little to do with data-linkt type. That's correct. By dropping modified EUI-64 we have removed a noticeable dependency. But who's to say there won't be a future link type whose deployment scenario is better suited by, say, 80 bit prefixes and 48 bit IIDs? I have no idea about that. > >> f) Therefore the addressing architecture should only define n=64 as a default >> recommendation for IPv6-over-foo documents. > > I don't think that follows from the arguments laid out above. > We can (if we want to), make SLAAC work with any IID length. Including 0. > > I still don't understand what the goal is here. What problem are you solving? What is the proposal? Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do. Regards Brian From nobody Sat Jun 10 17:00:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86950129476 for ; Sat, 10 Jun 2017 17:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld2TgXagyCfM for ; Sat, 10 Jun 2017 17:00:28 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22881129468 for ; Sat, 10 Jun 2017 17:00:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5B00RdE031863; Sat, 10 Jun 2017 17:00:27 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5B00Ivd031473 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 10 Jun 2017 17:00:18 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (137.136.239.220) by XCH15-06-09.nw.nos.boeing.com (137.136.239.172) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 17:00:17 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 17:00:18 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVg Date: Sun, 11 Jun 2017 00:00:17 +0000 Message-ID: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 00:00:29 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> If we remove the 64 bit boundary from 4291, then an update of 2464 >> will likely result in the removal of any bit boundary there as well. > > No, for the out-of-the-box reason. I can't see any practical > alternative to a fixed length per link type. I think there are practical alternatives, so I too would suggest not to sta= te flatly that SLAAC requires fixed length IIDs. Anything that requires RAs= to work can make adjustments to its IID, in real time. ULAs and link local would need to create IIDs with no knowledge of the outs= ide world. But not SLAAC. Bert From nobody Sat Jun 10 17:19:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7C129481 for ; Sat, 10 Jun 2017 17:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOJ3xF6NltXV for ; Sat, 10 Jun 2017 17:19:03 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62516129483 for ; Sat, 10 Jun 2017 17:19:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5B0J2Vf051862; Sat, 10 Jun 2017 17:19:02 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5B0Ix5M051824 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 10 Jun 2017 17:18:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 17:18:58 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 17:18:59 -0700 From: "Manfredi, Albert E" To: David Farmer CC: "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kClngy9O72egk+O0dQc6kfgF6IeyDQw Date: Sun, 11 Jun 2017 00:18:58 +0000 Message-ID: <28bbbd684570419fa654e8db7445e2bd@XCH15-06-11.nw.nos.boeing.com> References: <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> <20170610.231524.41691706.sthaug@nethelp.no> <954FD01E-135B-45DA-875A-3B1F1724D5C7@umn.edu> In-Reply-To: <954FD01E-135B-45DA-875A-3B1F1724D5C7@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 00:19:04 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer > That is why I suggest noting that the classic IPv4 subnet prefix > is most similar to the IPv6 on-link prefix, which both can be of > any length, and both are directly related to routing, by > determining what is locally reachable. I see many taking this view, but the subtlety gets lost to me. In IPv4, I'm= given, say, five class C blocks to use on a platform. The service which as= signed me those five class C blocks assumes the prefix is 24 bits wide, whe= n they route packets to these platforms. Then I create 60 subnets out of th= ese five class C blocks, and what I consider "prefix" becomes 26, 28, or ot= her width. How is this different from the way "subnet prefix" is applied to= IPv6? > So, I think we have been arguing about whether the equivalent of the > IPv4 subnet prefix for IPv6 is fixed at /64 or not, and by tying the > term subnet prefix to the definition of IID in RFC4291 and its > predecessors we created an unnecessary conflict. Because the purpose > of the IPv4 subnet prefix is more closely related to the IPv6 on-link > prefix not the IID. Even assuming the fixed length IID, I'm not terribly taken with this argume= nt. If the IPv6 ISP assigns me a /56, that ISP's definition of "prefix" wil= l be 56 bits. When I use that /56 block, my definition of "prefix" will bec= ome /64. Not all that different from IPv4, as described above? Bert From nobody Sat Jun 10 18:46:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A6E1294B3 for ; Sat, 10 Jun 2017 18:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh-0Mv1Wo9-8 for ; Sat, 10 Jun 2017 18:46:56 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 2B77A1294B2 for ; Sat, 10 Jun 2017 18:46:56 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id a70so35907641pge.3 for ; Sat, 10 Jun 2017 18:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=o01fn6xL7GDlhAHTw+UGxBEmskydOSurPQqYeWdrAxw=; b=exfc3Ax2P98l4utOA05BnN4KMv126gCrar6WPaz2Y4CYtw8QrY1x0Pr0rkQifVgibZ IdXsSfOAtlyFxjrhuOduWyQRP+P9mr1NWrG0yeEt2XqFtHIsff++DGn3jtQSMb6T1omn /7/lVvR1/eUblLthZrFQX+fx6c3Moh9MGhICFLTjgdwxpsZ1GuiSMzAa2aHATp3foHjo Q3DN1ThM6UEmHlH48/FQHhk8awvMkJU3/3xT7fbjcQ2uaXoJh3sL0KHIDtJv4nEOykUy 8CUgRkGGOJxQddjhRsOSce4vJdSTwi96ZCEAybM140MiXgu18J2le3fogOzxF04Lqrnk dfMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=o01fn6xL7GDlhAHTw+UGxBEmskydOSurPQqYeWdrAxw=; b=b3sKO8G/wtWj3LIc4RtqXjPx2OH9Zy0Dk9ObKs7NpSPz28Auif9RbevbXLkQlfoIEY ooxJdqb0WrTf1bqQbnb8W0NJ/G7ZnHL8q4jas75XA6DsdGUSYF9GjGR/GEz9gWJMOtaU Es4hMGb8m4HfQyJzjQA3mWM7Zo0LDOcaWn9o3NftG8Zs+VtMfIDRh3lfa+XCuUaZJJO+ KJKRY3E4fcnr5lVzq65TX5bUVsyLfAnekYxcpT/3WHW7gATrGN8YCNHC5D3bqgo5Pp3f ytUdnD9wBT0YBUaXNX+6TRVqmA5ktnEmn/ARN++2K08zX5+yaFqcUDmveqI96t3K/P2B za2Q== X-Gm-Message-State: AODbwcCtwCWZfbWSBRGCrQpvXb3ufH8iirfru894crpcbgDpOFMA0deM rn00uCUFnYHQ0sl6 X-Received: by 10.98.27.215 with SMTP id b206mr15844286pfb.123.1497145615533; Sat, 10 Jun 2017 18:46:55 -0700 (PDT) Received: from ?IPv6:2406:e001:541b:1:28cc:dc4c:9703:6781? ([2406:e001:541b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r73sm10664292pfk.114.2017.06.10.18.46.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 18:46:54 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> Date: Sun, 11 Jun 2017 13:46:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 01:46:58 -0000 On 11/06/2017 12:00, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >>> If we remove the 64 bit boundary from 4291, then an update of 2464 >>> will likely result in the removal of any bit boundary there as well. >> >> No, for the out-of-the-box reason. I can't see any practical >> alternative to a fixed length per link type. > > I think there are practical alternatives, so I too would suggest not to state flatly that SLAAC requires fixed length IIDs. Anything that requires RAs to work can make adjustments to its IID, in real time. It cannot adjust its IID length when assigning itself a link-local address *before* receiving any RA/PIO messages. But whatever length N of IID it uses to generate its LL address must match the the prefix length 128-N in a later RA/PIO with A=1. Otherwise, SLAAC fails. (see Section 5.5.3 bullet d of RFC4862, as Jinmei-san kindly explained to me.) So in fact the only thing that works is if the equipment assumes the same IID length as the router announces (as 128-N). Therefore, N must be predefined. > ULAs and link local would need to create IIDs with no knowledge of the outside world. But not SLAAC. ULAs have nothing to do with it; SLAAC doesn't care whether a prefix is ULA or globally reachable. And LL is *not* independent of SLAAC. Regards Brian From nobody Sat Jun 10 22:29:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A011E1273E2 for ; Sat, 10 Jun 2017 22:29:55 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO985Z6_GbBj for ; Sat, 10 Jun 2017 22:29:54 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B270126B72 for ; Sat, 10 Jun 2017 22:29:54 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id l89so40969262pfi.2 for ; Sat, 10 Jun 2017 22:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Oesm3D4RW29rVA2SuSpSTVI0jP2wNtIPzNblW6PobAI=; b=W/d6WbksHXL98+RX3rJ2kZwQa8sH/i1AOTAgvUiALevfKJ7v8WxO1iUZRHZ8B1KZBa njvjjAtEiv8L0ydjQt+isMbGO3PS0DhDR1HbwwEfQhM1UAxUP52g2ZO08opFRu3dDd+m 2KINEKXdWyJ97S0FZr0kEMRgrDdqJNQnh5rqcgvWGWWX3Y/8XhLXxo+fqNJYcSrITpiS ObRQh1zt3+byniNzBlTCmoNNxORiheDHVFrsmduIiG3Exu6AWON9YcJaUTROk+c+F0GZ UZLmv7SHIpWewdr/Hpyz+xmoETBsFQVF08VaSSsrr6ew3r3OAwGadbbeTUSmFbJW8Z18 c4qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Oesm3D4RW29rVA2SuSpSTVI0jP2wNtIPzNblW6PobAI=; b=XUPfG7er477O24IaCpL0K1Nh6oO3fVG31qZMPZgJrRVH2y2VQwUyCx2tDb05BoEJV4 4zfTyfno8HkLnfAI9dSBdJtdEshNGahj+QtSWIEJTo+1ed2elGolLLDbs64orhr9KQmZ N1ajDvGk7DSX93k6Gx7pZN+73yA59xkEL8whkzRrUDC1uVoynT34FqQxfPFlGUzZFTtF 9Upp6H0WJ0Q9mScx3FRQMOpZn5Q7EW7M7Dv9NVH3veYeddI/eUwGPFFo4mib4iAiw6zY 32TAWAYdd0bs8Ed5QFROmwoQZl2J9ErRQix8HI4G+IHeID6/pwsRo80b7TSh9l7a2/s1 fuVg== X-Gm-Message-State: AODbwcCexQgTOSKdVBdwg6UedZimHxLoDU3GndvL4LNzbX0r0GIqJz/Y LpQQPvNIZ+U1bfpw X-Received: by 10.99.227.81 with SMTP id o17mr51173834pgj.41.1497158993419; Sat, 10 Jun 2017 22:29:53 -0700 (PDT) Received: from ?IPv6:2406:e001:541b:1:28cc:dc4c:9703:6781? ([2406:e001:541b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c4sm11540140pfg.31.2017.06.10.22.29.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 22:29:52 -0700 (PDT) Subject: Re: Tussles in IPv6 Land To: otroan@employees.org Cc: 6man WG References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 11 Jun 2017 17:29:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 05:29:56 -0000 On 11/06/2017 02:01, otroan@employees.org wrote: > Brian, > > [...] > >> To a significant extent the above three issues are tussles between operational needs >> and conceptual purity. To be specific: > > By this labelling of the players in the tussle, you leave no doubt on which side of the tussle you have taken. I don't know if that was intended. No. I might even be on different sides for different tussles. But yes, the language is editorial, not objective. And I don't claim it's a complete or correct analysis. Sorry, no time today to write more. Brian > > It is of course not as simple as a conflict between operational need and "ivory tower idealists". > You want to ensure end-users get enough address space, you want that operators can aggregate routing well, allow for innovation like identifier, locator split... Content providers, applications writers, lots of players have a stake in this. > > But it essentially boils down to the matter of control, power and money. > >> 2. The interface identifier length was fixed at 64 bits about 20 years ago. It >> was not an arbitrary choice then - it was designed to match the hardware address >> size of FireWire, then expected to be the network of the future. (It actually >> turned out that the network of the past, Ethernet, became the network of the >> future. But if we'd fixed on 48 bits for that reason, we'd be having the same >> tussle about 80+48 that we're having today about 64+64.) Network operators have >> two complaints about the boundary at 64 bits. Firstly, although in theory it could >> be different for different media (for example, 64 for FireWire and 48 for Ethernet) >> in practice it's been set at 64 for everything. Secondly, bitter experience with >> IPv4 25 years ago taught everybody (we thought) that routing should always be >> "classless" with no rigid rules about the length of routing prefixes. But the de >> facto rule in IPv6 is that leaf subnet prefixes MUST be 64 bits long. ISP operators >> would like that 64-bit boundary to float. Unfortunately, many people involved >> in the IPv6 design think it's a terrible idea (and a change to the IPv6 standard). >> There are several reasons for that - though the main one seems to be that having >> a 64 bit boundary everywhere makes portability (of code, and of computers) easier. >> Also, much software blindly assumes the 64 bit rule. But this has its own downside: >> suppose an ISP follows bad practice and gives a retail subscriber exactly one >> 64 bit prefix. If the subscriber needs to operate more than one subnet in their >> home or office, they simply can't do so unless the 64 bit rule is relaxed. That >> wastes considerable potential for IPv6 deployment. But - again, but - if the >> 64 bit rule was made flexible, perhaps some ISPs would decide to go further - >> say give a retail subscriber exactly one 80 bit prefix. This could generate >> a race to the bottom, where the really cheap and nasty ISPs give a subscriber, >> say, exactly one 120 bit prefix, wasting even more of IPv6's potential. On this >> argument, sticking to the 64 bit rule seems safest. >> >> So, the 64 bit boundary is the well-understood solution that works everywhere, >> or the spawn of the devil that blocks future flexibility for both routing >> and address space conservation. > > "ISP operators would like the 64-bit boundary to float". Is that a true statement? > The draft we are discussing is clarifying that it within the architecture to manually configure addresses with arbitrary length of the onlink prefix. Some people definitely want the 64 bit boundary to float. I'm unsure what the arguments are for that. And what problems it solves. > > Now we do have real problems. > - "Permission-less extension of the network. Where I want to extend a network I do not control, where I connect to a network with /64 SLAAC, or /64 to the host. The "natural" inclination then is to subnet the /64. But this problem has many other solutions too. Unfortunately we haven't made any of them stick. Perhaps we should restart the work on MLSR. > - The assumption that on a multi-access link a host can use as many addresses as it likes. Every address a host grabs has a real cost for the network. TCAM space is limited. It's understandable that network operators (and vendors) get cautious how this will play out. Perhaps ARO would have been a better trade-off between the interests of operators and hosts. > - Multi-prefix multi-homing. The idea that the host by choosing source address controls the exit circuit in a network doesn't sit well with most operators. Neither is it possible to make it work without essentially a session layer... > > Ole > From nobody Sun Jun 11 01:41:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614751294D3 for ; Sun, 11 Jun 2017 01:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyf-UDpQ6LUY for ; Sun, 11 Jun 2017 01:41:15 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3541294D4 for ; Sun, 11 Jun 2017 01:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1497170473; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=U43vg5+EVxnaDptECa4EHpwSXITdFlleWh85ucaDLNo=; b=gOOEkLCqowGakwbo0iFzR66Nf/HRfiHY3p2UEL6Q9wsWet6QLMeHSiqi2nN4zytahzUIg+5u0duacuDqwslKGDFH5f9XuMnPVDuaPMIuNK52Yocg37y4Binn0FG+RCVZL0OOR5ZgNealeKEGlxz0g4JyZhLAhfFnzHzuJRqK92Q= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0116.outbound.protection.outlook.com [213.199.154.116]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-118-mtpcxIbWOdaijXQWOZoRlA-1; Sun, 11 Jun 2017 09:41:10 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1154.eurprd07.prod.outlook.com (10.163.188.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Sun, 11 Jun 2017 08:41:09 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d2f:d4cd:c3bf:b708]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d2f:d4cd:c3bf:b708%15]) with mapi id 15.01.1178.006; Sun, 11 Jun 2017 08:41:09 +0000 From: Tim Chown To: Brian E Carpenter CC: "otroan@employees.org" , 6man WG Subject: Re: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS4YmXBYPVQDWE6kuzftWPLNlLDKIeIPaAgAEDcYCAADV2AA== Date: Sun, 11 Jun 2017 08:41:08 +0000 Message-ID: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:9cf8:3e44:26e9:a6f7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1154; 7:TCPNeacX/edwqnsJL+Zh4EN3y4vWpKgIa7IMwtfb08cujwGB3POEE52mUBzqa8k9gj4mXBAwMu592pR2JGxBF3iD8ku30Xpb0G1p9PYdC5Pm025m1YmWheYkWj8SLTU+OksgiUJsOE5NzVQ2g7ik+kGBbw3YCI/bbk+C0bcJ/V5xMdI75Do5CMLVdxPI1VAVTiBebj7CqTow7WiuIcgTINkdc+cWd99I3Xho203JACRG4aO+1mQ7176fCGyw4CF8exgzhVeUNH8qDv+l92vrarNQ19HRCQVRSSJbU+6s5N2iHCN/4kSQZGc5Z5Jbhp2NM+iNVcl5lmjrdvGNd73iHQ==; 20:1EQ8npjtzHXlaPW3kc/y/iLp9JUMSfMJpe9qknmzkdKNjY6+Bog0uPkHW6HPfFIb7sUlRzp5qv4NMVOzW8Mk0QFacpXTlO8viNwQ4L4qX7LcEohzTy/9lMbS6bJ0dONT8bQybxxpvg5yYWPBIDtgJa+EfYRo+wo9ZjErXnrKB9k= x-ms-office365-filtering-correlation-id: 04c63efe-af40-44aa-3541-08d4b0a59b93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1154; x-ms-traffictypediagnostic: AM3PR07MB1154: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1154; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1154; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39830400002)(39410400002)(85664002)(24454002)(6436002)(57306001)(6246003)(38730400002)(4326008)(53936002)(110136004)(74482002)(5660300001)(229853002)(102836003)(76176999)(50986999)(6512007)(99286003)(54906002)(53546009)(6306002)(33656002)(36756003)(25786009)(6116002)(189998001)(82746002)(42882006)(2950100002)(6916009)(2906002)(8936002)(3660700001)(50226002)(478600001)(3280700002)(8676002)(81166006)(966005)(2900100001)(305945005)(14454004)(72206003)(6506006)(86362001)(5250100002)(83716003)(39060400002)(7736002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1154; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <10122E1E37219645BB900C4A31030617@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2017 08:41:08.6197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1154 X-MC-Unique: mtpcxIbWOdaijXQWOZoRlA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 08:41:19 -0000 PiBPbiAxMSBKdW4gMjAxNywgYXQgMDY6MjksIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMTEvMDYvMjAxNyAwMjowMSwgb3Ry b2FuQGVtcGxveWVlcy5vcmcgd3JvdGU6DQo+PiBCcmlhbiwNCj4+IA0KPj4gWy4uLl0NCj4+IA0K Pj4+IFRvIGEgc2lnbmlmaWNhbnQgZXh0ZW50IHRoZSBhYm92ZSB0aHJlZSBpc3N1ZXMgYXJlIHR1 c3NsZXMgYmV0d2VlbiBvcGVyYXRpb25hbCBuZWVkcw0KPj4+IGFuZCBjb25jZXB0dWFsIHB1cml0 eS4gVG8gYmUgc3BlY2lmaWM6DQo+PiANCj4+IEJ5IHRoaXMgbGFiZWxsaW5nIG9mIHRoZSBwbGF5 ZXJzIGluIHRoZSB0dXNzbGUsIHlvdSBsZWF2ZSBubyBkb3VidCBvbiB3aGljaCBzaWRlIG9mIHRo ZSB0dXNzbGUgeW91IGhhdmUgdGFrZW4uIEkgZG9uJ3Qga25vdyBpZiB0aGF0IHdhcyBpbnRlbmRl ZC4NCj4gDQo+IE5vLiBJIG1pZ2h0IGV2ZW4gYmUgb24gZGlmZmVyZW50IHNpZGVzIGZvciBkaWZm ZXJlbnQgdHVzc2xlcy4gQnV0IHllcywgdGhlDQo+IGxhbmd1YWdlIGlzIGVkaXRvcmlhbCwgbm90 IG9iamVjdGl2ZS4gQW5kIEkgZG9uJ3QgY2xhaW0gaXQncyBhIGNvbXBsZXRlDQo+IG9yIGNvcnJl Y3QgYW5hbHlzaXMuIFNvcnJ5LCBubyB0aW1lIHRvZGF5IHRvIHdyaXRlIG1vcmUuDQoNCldoaWxl IHRoZXJl4oCZcyBvbmUgb3IgdHdvIHBvaW50cy9jbGFpbXMgdGhhdCBjb3VsZCBiZSBkZWJhdGVk IGltcHJvdmVkLCB5b3VyIGVtYWlsIGNvbWVzIGFjcm9zcyBvdmVyYWxsIGFzIGEgbmljZSBuZXV0 cmFsIHdyaXRlLXVwIG9mIHRoZSB0dXNzbGVzLiANCg0KSeKAmWQgc3VnZ2VzdCAoMykgaXMgYSBz dWItY2FzZSBvZiDigJxvcGVyYXRlIHRocm91Z2ggREhDUHY2IG9ubHnigJ0sIGluY2x1ZGluZyB0 aGUgbGFjayBvZiBhIERIQ1B2NiBkZWZhdWx0IGdhdGV3YXkgb3B0aW9uLCB0aG91Z2ggdGhhdOKA mXMgcGVyaGFwcyBub3Qgc28gbXVjaCBhIGN1cnJlbnQgaG90IHRvcGljIGJ1dCBvbmUgdGhhdOKA mXMgYmVlbiBidWJibGluZyB1bmRlciBmb3IgbWFueSB5ZWFycy4gT3IgYXQgbGVhc3QgdGhlIFJG QzgxMDYgdnMgc3RhdGVsZXNzIERIQ1AgZGViYXRlIGlzIHBvbGFyaXNlZCBhbmQgcGVyaGFwcyBq YW1tZWQgYmVjYXVzZSBvZiB0aGF0IHVuZGVybHlpbmcgdHVzc2xlLg0KDQpJ4oCZZCBhbHNvIHNh eSB0aGF0IGNhc2UgKDMpIGlzIG1hZGUgbW9yZSBjcml0aWNhbCBpbiBhbiBJUHY2LW9ubHkgZW52 aXJvbm1lbnQsIHdoZXJlIHlvdSBjYW7igJl0IGZhbGwgYmFjayBvbiBJUHY0IChESENQdjQpIHRv IGdldCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uLg0KDQpUaW0NCg0KPiAgICBCcmlhbg0KPiAN Cj4+IA0KPj4gSXQgaXMgb2YgY291cnNlIG5vdCBhcyBzaW1wbGUgYXMgYSBjb25mbGljdCBiZXR3 ZWVuIG9wZXJhdGlvbmFsIG5lZWQgYW5kICJpdm9yeSB0b3dlciBpZGVhbGlzdHMiLg0KPj4gWW91 IHdhbnQgdG8gZW5zdXJlIGVuZC11c2VycyBnZXQgZW5vdWdoIGFkZHJlc3Mgc3BhY2UsIHlvdSB3 YW50IHRoYXQgb3BlcmF0b3JzIGNhbiBhZ2dyZWdhdGUgcm91dGluZyB3ZWxsLCBhbGxvdyBmb3Ig aW5ub3ZhdGlvbiBsaWtlIGlkZW50aWZpZXIsIGxvY2F0b3Igc3BsaXQuLi4gQ29udGVudCBwcm92 aWRlcnMsIGFwcGxpY2F0aW9ucyB3cml0ZXJzLCBsb3RzIG9mIHBsYXllcnMgaGF2ZSBhIHN0YWtl IGluIHRoaXMuDQo+PiANCj4+IEJ1dCBpdCBlc3NlbnRpYWxseSBib2lscyBkb3duIHRvIHRoZSBt YXR0ZXIgb2YgY29udHJvbCwgcG93ZXIgYW5kIG1vbmV5Lg0KPj4gDQo+Pj4gMi4gVGhlIGludGVy ZmFjZSBpZGVudGlmaWVyIGxlbmd0aCB3YXMgZml4ZWQgYXQgNjQgYml0cyBhYm91dCAyMCB5ZWFy cyBhZ28uIEl0DQo+Pj4gd2FzIG5vdCBhbiBhcmJpdHJhcnkgY2hvaWNlIHRoZW4gLSBpdCB3YXMg ZGVzaWduZWQgdG8gbWF0Y2ggdGhlIGhhcmR3YXJlIGFkZHJlc3MNCj4+PiBzaXplIG9mIEZpcmVX aXJlLCB0aGVuIGV4cGVjdGVkIHRvIGJlIHRoZSBuZXR3b3JrIG9mIHRoZSBmdXR1cmUuIChJdCBh Y3R1YWxseQ0KPj4+IHR1cm5lZCBvdXQgdGhhdCB0aGUgbmV0d29yayBvZiB0aGUgcGFzdCwgRXRo ZXJuZXQsIGJlY2FtZSB0aGUgbmV0d29yayBvZiB0aGUNCj4+PiBmdXR1cmUuIEJ1dCBpZiB3ZSdk IGZpeGVkIG9uIDQ4IGJpdHMgZm9yIHRoYXQgcmVhc29uLCB3ZSdkIGJlIGhhdmluZyB0aGUgc2Ft ZQ0KPj4+IHR1c3NsZSBhYm91dCA4MCs0OCB0aGF0IHdlJ3JlIGhhdmluZyB0b2RheSBhYm91dCA2 NCs2NC4pIE5ldHdvcmsgb3BlcmF0b3JzIGhhdmUNCj4+PiB0d28gY29tcGxhaW50cyBhYm91dCB0 aGUgYm91bmRhcnkgYXQgNjQgYml0cy4gRmlyc3RseSwgYWx0aG91Z2ggaW4gdGhlb3J5IGl0IGNv dWxkDQo+Pj4gYmUgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgbWVkaWEgKGZvciBleGFtcGxlLCA2 NCBmb3IgRmlyZVdpcmUgYW5kIDQ4IGZvciBFdGhlcm5ldCkNCj4+PiBpbiBwcmFjdGljZSBpdCdz IGJlZW4gc2V0IGF0IDY0IGZvciBldmVyeXRoaW5nLiBTZWNvbmRseSwgYml0dGVyIGV4cGVyaWVu Y2Ugd2l0aA0KPj4+IElQdjQgMjUgeWVhcnMgYWdvIHRhdWdodCBldmVyeWJvZHkgKHdlIHRob3Vn aHQpIHRoYXQgcm91dGluZyBzaG91bGQgYWx3YXlzIGJlDQo+Pj4gImNsYXNzbGVzcyIgd2l0aCBu byByaWdpZCBydWxlcyBhYm91dCB0aGUgbGVuZ3RoIG9mIHJvdXRpbmcgcHJlZml4ZXMuIEJ1dCB0 aGUgZGUNCj4+PiBmYWN0byBydWxlIGluIElQdjYgaXMgdGhhdCBsZWFmIHN1Ym5ldCBwcmVmaXhl cyBNVVNUIGJlIDY0IGJpdHMgbG9uZy4gSVNQIG9wZXJhdG9ycw0KPj4+IHdvdWxkIGxpa2UgdGhh dCA2NC1iaXQgYm91bmRhcnkgdG8gZmxvYXQuIFVuZm9ydHVuYXRlbHksIG1hbnkgcGVvcGxlIGlu dm9sdmVkDQo+Pj4gaW4gdGhlIElQdjYgZGVzaWduIHRoaW5rIGl0J3MgYSB0ZXJyaWJsZSBpZGVh IChhbmQgYSBjaGFuZ2UgdG8gdGhlIElQdjYgc3RhbmRhcmQpLg0KPj4+IFRoZXJlIGFyZSBzZXZl cmFsIHJlYXNvbnMgZm9yIHRoYXQgLSB0aG91Z2ggdGhlIG1haW4gb25lIHNlZW1zIHRvIGJlIHRo YXQgaGF2aW5nDQo+Pj4gYSA2NCBiaXQgYm91bmRhcnkgZXZlcnl3aGVyZSBtYWtlcyBwb3J0YWJp bGl0eSAob2YgY29kZSwgYW5kIG9mIGNvbXB1dGVycykgZWFzaWVyLg0KPj4+IEFsc28sIG11Y2gg c29mdHdhcmUgYmxpbmRseSBhc3N1bWVzIHRoZSA2NCBiaXQgcnVsZS4gQnV0IHRoaXMgaGFzIGl0 cyBvd24gZG93bnNpZGU6DQo+Pj4gc3VwcG9zZSBhbiBJU1AgZm9sbG93cyBiYWQgcHJhY3RpY2Ug YW5kIGdpdmVzIGEgcmV0YWlsIHN1YnNjcmliZXIgZXhhY3RseSBvbmUNCj4+PiA2NCBiaXQgcHJl Zml4LiBJZiB0aGUgc3Vic2NyaWJlciBuZWVkcyB0byBvcGVyYXRlIG1vcmUgdGhhbiBvbmUgc3Vi bmV0IGluIHRoZWlyDQo+Pj4gaG9tZSBvciBvZmZpY2UsIHRoZXkgc2ltcGx5IGNhbid0IGRvIHNv IHVubGVzcyB0aGUgNjQgYml0IHJ1bGUgaXMgcmVsYXhlZC4gVGhhdA0KPj4+IHdhc3RlcyBjb25z aWRlcmFibGUgcG90ZW50aWFsIGZvciBJUHY2IGRlcGxveW1lbnQuIEJ1dCAtIGFnYWluLCBidXQg LSBpZiB0aGUNCj4+PiA2NCBiaXQgcnVsZSB3YXMgbWFkZSBmbGV4aWJsZSwgcGVyaGFwcyBzb21l IElTUHMgd291bGQgZGVjaWRlIHRvIGdvIGZ1cnRoZXIgLQ0KPj4+IHNheSBnaXZlIGEgcmV0YWls IHN1YnNjcmliZXIgZXhhY3RseSBvbmUgODAgYml0IHByZWZpeC4gVGhpcyBjb3VsZCBnZW5lcmF0 ZQ0KPj4+IGEgcmFjZSB0byB0aGUgYm90dG9tLCB3aGVyZSB0aGUgcmVhbGx5IGNoZWFwIGFuZCBu YXN0eSBJU1BzIGdpdmUgYSBzdWJzY3JpYmVyLA0KPj4+IHNheSwgZXhhY3RseSBvbmUgMTIwIGJp dCBwcmVmaXgsIHdhc3RpbmcgZXZlbiBtb3JlIG9mIElQdjYncyBwb3RlbnRpYWwuIE9uIHRoaXMN Cj4+PiBhcmd1bWVudCwgc3RpY2tpbmcgdG8gdGhlIDY0IGJpdCBydWxlIHNlZW1zIHNhZmVzdC4N Cj4+PiANCj4+PiBTbywgdGhlIDY0IGJpdCBib3VuZGFyeSBpcyB0aGUgd2VsbC11bmRlcnN0b29k IHNvbHV0aW9uIHRoYXQgd29ya3MgZXZlcnl3aGVyZSwNCj4+PiBvciB0aGUgc3Bhd24gb2YgdGhl IGRldmlsIHRoYXQgYmxvY2tzIGZ1dHVyZSBmbGV4aWJpbGl0eSBmb3IgYm90aCByb3V0aW5nDQo+ Pj4gYW5kIGFkZHJlc3Mgc3BhY2UgY29uc2VydmF0aW9uLg0KPj4gDQo+PiAiSVNQIG9wZXJhdG9y cyB3b3VsZCBsaWtlIHRoZSA2NC1iaXQgYm91bmRhcnkgdG8gZmxvYXQiLiBJcyB0aGF0IGEgdHJ1 ZSBzdGF0ZW1lbnQ/DQo+PiBUaGUgZHJhZnQgd2UgYXJlIGRpc2N1c3NpbmcgaXMgY2xhcmlmeWlu ZyB0aGF0IGl0IHdpdGhpbiB0aGUgYXJjaGl0ZWN0dXJlIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSBh ZGRyZXNzZXMgd2l0aCBhcmJpdHJhcnkgbGVuZ3RoIG9mIHRoZSBvbmxpbmsgcHJlZml4LiBTb21l IHBlb3BsZSBkZWZpbml0ZWx5IHdhbnQgdGhlIDY0IGJpdCBib3VuZGFyeSB0byBmbG9hdC4gSSdt IHVuc3VyZSB3aGF0IHRoZSBhcmd1bWVudHMgYXJlIGZvciB0aGF0LiBBbmQgd2hhdCBwcm9ibGVt cyBpdCBzb2x2ZXMuDQo+PiANCj4+IE5vdyB3ZSBkbyBoYXZlIHJlYWwgcHJvYmxlbXMuDQo+PiAt ICJQZXJtaXNzaW9uLWxlc3MgZXh0ZW5zaW9uIG9mIHRoZSBuZXR3b3JrLiBXaGVyZSBJIHdhbnQg dG8gZXh0ZW5kIGEgbmV0d29yayBJIGRvIG5vdCBjb250cm9sLCB3aGVyZSBJIGNvbm5lY3QgdG8g YSBuZXR3b3JrIHdpdGggLzY0IFNMQUFDLCBvciAvNjQgdG8gdGhlIGhvc3QuIFRoZSAibmF0dXJh bCIgaW5jbGluYXRpb24gdGhlbiBpcyB0byBzdWJuZXQgdGhlIC82NC4gQnV0IHRoaXMgcHJvYmxl bSBoYXMgbWFueSBvdGhlciBzb2x1dGlvbnMgdG9vLiBVbmZvcnR1bmF0ZWx5IHdlIGhhdmVuJ3Qg bWFkZSBhbnkgb2YgdGhlbSBzdGljay4gUGVyaGFwcyB3ZSBzaG91bGQgcmVzdGFydCB0aGUgd29y ayBvbiBNTFNSLg0KPj4gLSBUaGUgYXNzdW1wdGlvbiB0aGF0IG9uIGEgbXVsdGktYWNjZXNzIGxp bmsgYSBob3N0IGNhbiB1c2UgYXMgbWFueSBhZGRyZXNzZXMgYXMgaXQgbGlrZXMuIEV2ZXJ5IGFk ZHJlc3MgYSBob3N0IGdyYWJzIGhhcyBhIHJlYWwgY29zdCBmb3IgdGhlIG5ldHdvcmsuIFRDQU0g c3BhY2UgaXMgbGltaXRlZC4gSXQncyB1bmRlcnN0YW5kYWJsZSB0aGF0IG5ldHdvcmsgb3BlcmF0 b3JzIChhbmQgdmVuZG9ycykgZ2V0IGNhdXRpb3VzIGhvdyB0aGlzIHdpbGwgcGxheSBvdXQuIFBl cmhhcHMgQVJPIHdvdWxkIGhhdmUgYmVlbiBhIGJldHRlciB0cmFkZS1vZmYgYmV0d2VlbiB0aGUg aW50ZXJlc3RzIG9mIG9wZXJhdG9ycyBhbmQgaG9zdHMuDQo+PiAtIE11bHRpLXByZWZpeCBtdWx0 aS1ob21pbmcuIFRoZSBpZGVhIHRoYXQgdGhlIGhvc3QgYnkgY2hvb3Npbmcgc291cmNlIGFkZHJl c3MgY29udHJvbHMgdGhlIGV4aXQgY2lyY3VpdCBpbiBhIG5ldHdvcmsgZG9lc24ndCBzaXQgd2Vs bCB3aXRoIG1vc3Qgb3BlcmF0b3JzLiBOZWl0aGVyIGlzIGl0IHBvc3NpYmxlIHRvIG1ha2UgaXQg d29yayB3aXRob3V0IGVzc2VudGlhbGx5IGEgc2Vzc2lvbiBsYXllci4uLg0KPj4gDQo+PiBPbGUN Cj4+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAN Cg0K From nobody Sun Jun 11 11:30:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D23129AC4 for ; Sun, 11 Jun 2017 11:30:02 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeOaSY_aIZxs for ; Sun, 11 Jun 2017 11:30:00 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id BA8A31292F4 for ; Sun, 11 Jun 2017 11:30:00 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2017 18:29:59 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1CF67D788D; Sun, 11 Jun 2017 11:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=ylITAeGi91uSGUndgB6y7IjfAh0=; b= nhqTg3zFwAwpY9TeNaHxM0TvC7f9oj+n1ls0PJbj3NnYGHY/eraSYT2jQ8qa1Zl0 eUH410y1mm1o2PYujrG0V6W1nlldxbIzcMWWTmEETcbdYGhzqrbJEh3FECkYP6CF 2jG/5OCoO5RGJgSe984Jq4Je26pFjRslMDCXYRGS9+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=Sa2eih2t3aDY+VyWTJBKQ9M jLmhj5Y9P394tAAs1+UojIbpyzI3v5QOdhnHYHhxOr0ODcPFV7pLB0E7WL1idLHq 3hRYUyP+lsJL/isHXZQUxsXk67qwC/AiNWUcGqUuyQqPMfHhuqedd0F/L4hfUNx8 jHrKN7gtVwJ4JAQdPlOI= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B47F3D788B; Sun, 11 Jun 2017 11:29:58 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 65C0FD19B74C; Sun, 11 Jun 2017 20:29:56 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_038BFFEC-5763-44A0-A171-9F5257D90EE3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Sun, 11 Jun 2017 20:29:55 +0200 In-Reply-To: <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> Cc: "Manfredi, Albert E" , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:30:03 -0000 --Apple-Mail=_038BFFEC-5763-44A0-A171-9F5257D90EE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >>>> If we remove the 64 bit boundary from 4291, then an update of 2464 >>>> will likely result in the removal of any bit boundary there as = well. >>>=20 >>> No, for the out-of-the-box reason. I can't see any practical >>> alternative to a fixed length per link type. >>=20 >> I think there are practical alternatives, so I too would suggest not = to state flatly that SLAAC requires fixed length IIDs. Anything that = requires RAs to work can make adjustments to its IID, in real time. >=20 > It cannot adjust its IID length when assigning itself a link-local = address *before* > receiving any RA/PIO messages. But whatever length N of IID it uses to = generate its > LL address must match the the prefix length 128-N in a later RA/PIO = with A=3D1. > Otherwise, SLAAC fails. >=20 > (see Section 5.5.3 bullet d of RFC4862, as Jinmei-san kindly explained = to me.) >=20 > So in fact the only thing that works is if the equipment assumes the = same IID length > as the router announces (as 128-N). Therefore, N must be predefined. As I said the argument is tenuous. This is a trivial change, if we were to go down this route. The fixed = constant is a fundamental part of the IPv6 architecture. If we remove it = from there, then it is a natural consequence to remove it from the IPv6 = over foo documents and tweak SLAAC. The changes to SLAAC could be in two paragraphs: - LL generation. Fix IID length to 118 _or_ make IID length = implementation specific. The on-link prefix for LL is regardless fe80::/10. - IID length =3D 128 - length of advertised prefix. Host is required to = generate IID of suitable length per advertised prefix. (or just generate a 128 bit IID, and chop of the bits needed. To summarize: - There is no technical reason why SLAAC cannot be made ot work with = arbitrary prefix lengths. (including very long prefixes, although it might take a while to find = a non-duplicate if the addressing model moves from sparse to dense). - There is no technical reason to have a fixed IID length defined by = data-link type. - Removing the constant from the addressing architecture will likely = set these changes into motion. (i.e. I don't think a position where one wants to remove the 64 bit = constant from 4291 and expect the 64 bit boundary to stay in IPv6 over foo is tenable.) If that's what we want. I believe we have to think quite hard about it = and we need to consider the consequences quite hard. Ole --Apple-Mail=_038BFFEC-5763-44A0-A171-9F5257D90EE3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZPYwkAAoJEL7aWKiYQt92nEsP/Aw3a2TDd8p7IHlrtV/XXNBL 9zTK2JpCylIKOPRvh3F4Ankx/sw6L5k/D/R1iSNX6fcVB9o36BbHaQu3npf0Xq/H DfiQhu675xVxatwyY1M+mFQgPNzDYLuLfBYmIu6o40L0louhLehqrQ/QL6wbbjb5 qrloGiy6g3VYhVoKRriUuWBuU259dRCRxNj3Ec/ss90LW+L2WoCsK0CJYKc/Dmwn pFN4dm5Y94pF8i4MAtdmfdGZZtU4iym2lfALHha+XjbWQmrLJwjyUKiAgo5NW01H EvtkyG8EyAuznPVl0XH/jWoKWa67bw35Gwk9+C0jwdTaC0FBbUIb5LSHH3X9+5wZ 9ZEGXSIZyO77q3ougWUTIC9c5Luz948qfe8xIbwBY/oxzo+BC1VEGx+o/POho+uo mAFpUeXcW+XsnegA8MYy99ZadBvWAGz+pGN+b8EG9C5Lj/Zp6z6hDuTXP7JAacc1 bKQ91p9P9H1YvFdP6VO/0IBhxDOiUP0MdmrZaIQlufaPy/TkVp2oqrPEUjEbzYrE xinjt9yQ4niFpshsJWZDB+rhIRZslugdypWmMA0q2elzvYm+fs704X6p3C80IApm sPuD+dg8SBNC4TnPgbxg2aKI5LmZUR8yiAvFe8rjHOLXZLecJLsFfNrUdkIo6N0O 9ltLyROo4Pic8NX/2QcI =kbAz -----END PGP SIGNATURE----- --Apple-Mail=_038BFFEC-5763-44A0-A171-9F5257D90EE3-- From nobody Sun Jun 11 15:15:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB738127599 for ; Sun, 11 Jun 2017 15:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBPAQ7YzmMws for ; Sun, 11 Jun 2017 15:14:58 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAC5126557 for ; Sun, 11 Jun 2017 15:14:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5BMEvd5036664; Sun, 11 Jun 2017 15:14:57 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5BMEsmG036660 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 11 Jun 2017 15:14:55 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 11 Jun 2017 15:14:53 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sun, 11 Jun 2017 15:14:54 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAANnBYA== Date: Sun, 11 Jun 2017 22:14:54 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> In-Reply-To: <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 22:15:00 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPj4gSSB0aGluayB0aGVyZSBhcmUg cHJhY3RpY2FsIGFsdGVybmF0aXZlcywgc28gSSB0b28gd291bGQgc3VnZ2VzdA0KPj4gbm90IHRv IHN0YXRlIGZsYXRseSB0aGF0IFNMQUFDIHJlcXVpcmVzIGZpeGVkIGxlbmd0aCBJSURzLg0KPj4g QW55dGhpbmcgdGhhdCByZXF1aXJlcyBSQXMgdG8gd29yayBjYW4gbWFrZSBhZGp1c3RtZW50cyB0 byBpdHMNCj4+IElJRCwgaW4gcmVhbCB0aW1lLg0KPg0KPiBJdCBjYW5ub3QgYWRqdXN0IGl0cyBJ SUQgbGVuZ3RoIHdoZW4gYXNzaWduaW5nIGl0c2VsZiBhDQo+IGxpbmstbG9jYWwgYWRkcmVzcyAq YmVmb3JlKiByZWNlaXZpbmcgYW55IFJBL1BJTyBtZXNzYWdlcy4NCg0KVHJ1ZS4gQ2xlYXJseS4N Cg0KPiBCdXQgd2hhdGV2ZXIgbGVuZ3RoIE4gb2YgSUlEIGl0IHVzZXMgdG8gZ2VuZXJhdGUgaXRz IExMDQo+IGFkZHJlc3MgbXVzdCBtYXRjaCB0aGUgdGhlIHByZWZpeCBsZW5ndGggMTI4LU4gaW4g YSBsYXRlcg0KPiBSQS9QSU8gd2l0aCBBPTEuIE90aGVyd2lzZSwgU0xBQUMgZmFpbHMuIChzZWUg U2VjdGlvbiA1LjUuMw0KPiBidWxsZXQgZCBvZiBSRkM0ODYyLCBhcyBKaW5tZWktc2FuIGtpbmRs eSBleHBsYWluZWQgdG8gbWUuKQ0KDQpTZWN0aW9uIDUuNS4zIHN0YXRlcyB0aGF0IHRoZSBwcmVm aXggbGVuZ3RoIG9mIGEgdmFsaWQgcHJlZml4IG11c3QgYmUgMTI4LU4gYml0cyB3aWRlLCB3aGVy ZSBOIGlzIHRoZSBudW1iZXIgb2YgYml0cyBvZiB0aGUgSUlELiBUaGVuIGl0IHN0YXRlcyB0aGF0 IGl0J3MgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBzeXN0ZW0gYWRtaW4gdG8gZW5zdXJlIHRo YXQgcHJlZml4IGxlbmd0aHMgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgSUlEcyBmb3IgdGhhdCBs aW5rIHR5cGUuDQoNCk5vdywgd2hhdCBwcmV2ZW50cyBhIGxpbmsgdHlwZSBmcm9tIGhhdmluZyBt dWx0aXBsZSBhdmFpbGFibGUgSUlEIGxlbmd0aHMsIHJlYWR5IHRvIGdvLCB0byBtYXRjaCB2YXJ5 aW5nIHByZWZpeCBsZW5ndGhzIHRoYXQgbWlnaHQgYmUgYXZhaWxhYmxlPyBUaGUgYmFzaWMgcnVs ZXMgYXJlIHRoZSBzYW1lLiBUaGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgd2UgYXJlIG5vIGxv bmdlciBoZWxkIHRvIGp1c3Qgb25lIGxlbmd0aCBvZiBJSUQgKGZvciB0aGUgbGluayB0eXBlKS4g U28gaXQgYmVjb21lcyBhbHNvIHRoZSBob3N0J3MgcmVzcG9uc2liaWxpdHksIHRvIHVzZSBhbiBJ SUQgbGVuZ3RoIGNvbnNpc3RlbnQgd2l0aCB0aGUgbGVuZ3RoIG9mIHByZWZpeCBvZmZlcmVkLiAN Cg0KPiBTbyBpbiBmYWN0IHRoZSBvbmx5IHRoaW5nIHRoYXQgd29ya3MgaXMgaWYgdGhlIGVxdWlw bWVudA0KPiBhc3N1bWVzIHRoZSBzYW1lIElJRCBsZW5ndGggYXMgdGhlIHJvdXRlciBhbm5vdW5j ZXMgKGFzIDEyOC1OKS4NCj4gVGhlcmVmb3JlLCBOIG11c3QgYmUgcHJlZGVmaW5lZC4NCg0KVGhh dCdzIHRoZSB3YXkgaXQgd29ya3Mgbm93LCBidXQgaXQncyBoYXJkbHkgdGhlIG9ubHkgd2F5IGl0 IGNhbiBiZSBtYWRlIHRvIHdvcmsuIFNpbWlsYXJseSwgSVB2NCBkaWQgbm90IGhhdmUgdG8gcmVt YWluIGNsYXNzZnVsLCBiZWNhdXNlIHRoYXQncyB0aGUgd2F5IGl0IGhhZCBiZWVuLiBJUCBzdGFj a3Mgd2VyZSB1cGdyYWRlZCwgYW5kIENJRFIgYmVjYW1lIHRoZSBydWxlLg0KDQo+PiBVTEFzIGFu ZCBsaW5rIGxvY2FsIHdvdWxkIG5lZWQgdG8gY3JlYXRlIElJRHMgd2l0aCBubw0KPj4ga25vd2xl ZGdlIG9mIHRoZSBvdXRzaWRlIHdvcmxkLiBCdXQgbm90IFNMQUFDLg0KPg0KPiBVTEFzIGhhdmUg bm90aGluZyB0byBkbyB3aXRoIGl0OyBTTEFBQyBkb2Vzbid0IGNhcmUgd2hldGhlciBhDQo+IHBy ZWZpeCBpcyBVTEEgb3IgZ2xvYmFsbHkgcmVhY2hhYmxlLg0KDQpJIHRoaW5rIHlvdSBtaXNzZWQg bXkgcG9pbnQuIFdoZW4gdGhlIGhvc3QgZm9ybXMgZWl0aGVyIGEgVUxBIG9yIGEgTExBLCB0aGUg aG9zdCBtdXN0IGRvIHNvIHdpdGggbm8ga25vd2xlZGdlIG9mIGFueXRoaW5nIGV4dGVybmFsIHRv IGl0c2VsZi4gU28gc3VyZSwgdGhlIElJRCBpbiB0aG9zZSB0d28gZXhhbXBsZXMgaGFzIHRvIGJl IHByZWRpY3RhYmxlLiBJbnN0ZWFkLCB0aGVyZSBpcyBubyB2YWxpZCByZWFzb24gZm9yIHRoZSBJ SUQgdXNlZCBpbiBTTEFBQyB0byBoYXZlIHRvIGJlIGZvcm1lZCBpbmRlcGVuZGVudGx5IHRoYXQg d2F5LCBvdGhlciB0aGFuICJ0aGF0J3MgaG93IGl0J3MgZG9uZSBub3cuIg0KDQpPbmNlIHdlIGFy ZSBmcmVlZCBmcm9tIHRoZSBJUFgtbGVnYWN5IG5vdGlvbiBvZiB0aGUgSUlEIGJlaW5nIGZvcm1l ZCBmcm9tIHRoZSBoYXJkd2FyZSBhZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2UsIGFsbCB0aGVzZSBw cmVjb25jZWl2ZWQgcmVzdHJpY3Rpb25zLCBkZXJpdmVkIGZyb20gdGhhdCBkZXByZWNhdGVkIG5v dGlvbiwgY2FuIGJlIGVsaW1pbmF0ZWQuIFZhcmlhYmxlIGxlbmd0aCBJSURzIGFyZSBpZGVhbCBm b3IgYSBzeXN0ZW0gd2l0aCB2YXJpYWJsZSBsZW5ndGggcHJlZml4ZXMuIFdoeSBzaG91bGQgd2Ug ZGVwcmVjYXRlIElQdjYgdG8gc29tZXRoaW5nIGxlc3MgZmxleGlibGUgdGhhdCBpdCBjYW4gYmU/ DQoNCkJlcnQNCg0K From nobody Sun Jun 11 16:17:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541112945C for ; Sun, 11 Jun 2017 16:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN-71KyNb7Jr for ; Sun, 11 Jun 2017 16:17:07 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A4B12945B for ; Sun, 11 Jun 2017 16:17:07 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 83so45235242pfr.0 for ; Sun, 11 Jun 2017 16:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p5zq6B/0DKtB4NfkmsLn0fAslboX/Z/VyhXSj/HsbRw=; b=WIsEoQnp5B8ESWaLf/8saTpXu//BZnfnvivz+QvP1RR5ScrK6WySVPP9BaeaKJxBOC Px+SYYLyCm09vPV5cY0aHwR+Gx1Y2JIkFkcF6VXJ8GPQTKy/DdMwja3xRNUjNt2Lp1fd mlLlS/OME0L3o9chnwjie/Zb6DZ3xkKmEKY0u257RCTSwu6Xt/QlcDCLCGmnlJMnyO34 TrKjAwUDwY/ckr8H7mD1PaP7jqH5qtx/duuOmnWA69M0/14xPpNzhuIeeh28stJzzzQL Fg62KMNrcMEjz8ZZPYiw+e+YXPbxt6RMDnmrgoMtflOwcsQXevCWlpwAyYEBCa9ZnoOL wCnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=p5zq6B/0DKtB4NfkmsLn0fAslboX/Z/VyhXSj/HsbRw=; b=GnCPKMO5znIrsOKepKn2jsG+rezSINO2aTGDmNSlHyce/QZ8OeFoGBaPcntj2UYVPr jkFB7T+uyDFGCVlJc07rTChnBAkSyfkY3yrDg0xkiqPhVY0sWQfMS9pdW3PtgI44S/69 D8wMSmOhYwnXSdlFaEVL6nUcjUbf7JXeLGZ2wvt5Zsvg5hEJplSowU2Kh8NE1oGxj//m MZEPffL2oGgifGlUhrBuUTY5pCFxYme4MiyphfEymSZ67o+OR6nIGU0d14PI5AqDSrQd Tla6x+yKfB2RZ4UyIrCb1zkVVWWb116lPFUUhweI/D4rZ0LM836K+cqWW3A013YHKcui WerQ== X-Gm-Message-State: AODbwcAZ9OCw8JeDyBDVoIaNAK6ff8D3FG/ERnUOsep0DizIRHuCqEm1 WPtzk/oIrHwjd6cz X-Received: by 10.84.130.99 with SMTP id 90mr53062292plc.165.1497223026733; Sun, 11 Jun 2017 16:17:06 -0700 (PDT) Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id i68sm16454463pfi.72.2017.06.11.16.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 16:17:05 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0f8b7aa0-b9bb-4d6f-f8fa-597faead2108@gmail.com> Date: Mon, 12 Jun 2017 11:17:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 23:17:09 -0000 On 12/06/2017 10:14, Manfredi, Albert E wrote: > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >>> I think there are practical alternatives, so I too would suggest >>> not to state flatly that SLAAC requires fixed length IIDs. >>> Anything that requires RAs to work can make adjustments to its >>> IID, in real time. >> >> It cannot adjust its IID length when assigning itself a >> link-local address *before* receiving any RA/PIO messages. > > True. Clearly. > >> But whatever length N of IID it uses to generate its LL >> address must match the the prefix length 128-N in a later >> RA/PIO with A=1. Otherwise, SLAAC fails. (see Section 5.5.3 >> bullet d of RFC4862, as Jinmei-san kindly explained to me.) > > Section 5.5.3 states that the prefix length of a valid prefix must be 128-N bits wide, where N is the number of bits of the IID. Then it states that it's the responsibility of the system admin to ensure that prefix lengths are consistent with the IIDs for that link type. > > Now, what prevents a link type from having multiple available IID lengths, ready to go, to match varying prefix lengths that might be available? The basic rules are the same. The only difference is that we are no longer held to just one length of IID (for the link type). So it becomes also the host's responsibility, to use an IID length consistent with the length of prefix offered. > >> So in fact the only thing that works is if the equipment >> assumes the same IID length as the router announces (as 128-N). >> Therefore, N must be predefined. > > That's the way it works now, but it's hardly the only way it can be made to work. Similarly, IPv4 did not have to remain classful, because that's the way it had been. IP stacks were upgraded, and CIDR became the rule. > >>> ULAs and link local would need to create IIDs with no >>> knowledge of the outside world. But not SLAAC. >> >> ULAs have nothing to do with it; SLAAC doesn't care whether a >> prefix is ULA or globally reachable. > > I think you missed my point. When the host forms either a ULA or a LLA, the host must do so with no knowledge of anything external to itself. Absolutely not, for a ULA. A ULA is simply a global scope address which happens to lie under a ULA prefix, which is today just another /64 that comes from a completely standard PIO. A host could form a ULA using SLAAC, in which case the prefix comes from a completely standard PIO with A=1. (A host could also receive a ULA via DHCPv6, or it could even be manually configured, but in those cases it's just like any other global scope /128.) Brian > So sure, the IID in those two examples has to be predictable. Instead, there is no valid reason for the IID used in SLAAC to have to be formed independently that way, other than "that's how it's done now." > > Once we are freed from the IPX-legacy notion of the IID being formed from the hardware address of the interface, all these preconceived restrictions, derived from that deprecated notion, can be eliminated. Variable length IIDs are ideal for a system with variable length prefixes. Why should we deprecate IPv6 to something less flexible that it can be? > > Bert > From nobody Sun Jun 11 16:23:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFBD129463 for ; Sun, 11 Jun 2017 16:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3E6-isjBFRr for ; Sun, 11 Jun 2017 16:23:13 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C808127010 for ; Sun, 11 Jun 2017 16:23:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5BNNDnU048175; Sun, 11 Jun 2017 16:23:13 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5BNN88q048163 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 11 Jun 2017 16:23:08 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 11 Jun 2017 16:23:08 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sun, 11 Jun 2017 16:23:08 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAANnBYIAAjriA//+LfXA= Date: Sun, 11 Jun 2017 23:23:07 +0000 Message-ID: <711b79a837d24621b241c2fa17c51757@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <0f8b7aa0-b9bb-4d6f-f8fa-597faead2108@gmail.com> In-Reply-To: <0f8b7aa0-b9bb-4d6f-f8fa-597faead2108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 23:23:15 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPj4gSSB0aGluayB5b3UgbWlzc2Vk IG15IHBvaW50LiBXaGVuIHRoZSBob3N0IGZvcm1zIGVpdGhlciBhIFVMQSBvciBhDQo+PiBMTEEs IHRoZSBob3N0IG11c3QgZG8gc28gd2l0aCBubyBrbm93bGVkZ2Ugb2YgYW55dGhpbmcgZXh0ZXJu YWwgdG8NCj4+IGl0c2VsZi4NCj4NCj4gQWJzb2x1dGVseSBub3QsIGZvciBhIFVMQS4gQSBVTEEg aXMgc2ltcGx5IGEgZ2xvYmFsIHNjb3BlIGFkZHJlc3MNCj4gd2hpY2ggaGFwcGVucyB0byBsaWUg dW5kZXIgYSBVTEEgcHJlZml4LCB3aGljaCBpcyB0b2RheSBqdXN0IGFub3RoZXINCj4gLzY0IHRo YXQgY29tZXMgZnJvbSBhIGNvbXBsZXRlbHkgc3RhbmRhcmQgUElPLg0KDQpZb3UncmUgcmlnaHQu IEkgdGhvdWdodCBvZiB0aGF0IHRvbyBsYXRlLiBTaG91bGQgbm90IGhhdmUgdXNlZCBVTEFzIGFz IGV4YW1wbGVzIG9mIGFkZHJlc3NlcyB0aGF0IGhhdmUgdG8gYmUgZm9ybWVkIGluZGVwZW5kZW50 bHkgYnkgYSBob3N0Lg0KDQpCZXJ0DQoNCg== From nobody Sun Jun 11 18:03:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2601312947E for ; Sun, 11 Jun 2017 18:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZrpJADkeSa0 for ; Sun, 11 Jun 2017 18:03:09 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA21129471 for ; Sun, 11 Jun 2017 18:03:08 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.165.196.85]) (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 E53E582ABD; Mon, 12 Jun 2017 03:03:57 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fred Baker , David Farmer Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> From: Fernando Gont Message-ID: Date: Mon, 12 Jun 2017 03:40:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 01:03:14 -0000 On 06/10/2017 11:44 PM, Fred Baker wrote: [....] > > The only place it makes sense to me to talk about a specific length > for an IID is with SLAAC; +1 However, we seem to be enforcing /64 for everything, including non-slaac. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jun 11 18:04:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32834129B48 for ; Sun, 11 Jun 2017 18:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwfilzDUSiDx for ; Sun, 11 Jun 2017 18:04:02 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DABC129B44 for ; Sun, 11 Jun 2017 18:04:02 -0700 (PDT) Received: from [192.168.0.185] (unknown [105.165.196.85]) (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 3A39782ABA; Mon, 12 Jun 2017 03:04:52 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" , Brian E Carpenter Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: Fernando Gont Message-ID: <6e69030c-021e-df61-77e8-78383833ff44@si6networks.com> Date: Mon, 12 Jun 2017 04:02:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 01:04:10 -0000 On 06/12/2017 01:14 AM, Manfredi, Albert E wrote: [...] >>> ULAs and link local would need to create IIDs with no knowledge >>> of the outside world. But not SLAAC. >> >> ULAs have nothing to do with it; SLAAC doesn't care whether a >> prefix is ULA or globally reachable. > > I think you missed my point. When the host forms either a ULA or a > LLA, the host must do so with no knowledge of anything external to > itself. So sure, the IID in those two examples has to be predictable. > Instead, there is no valid reason for the IID used in SLAAC to have > to be formed independently that way, other than "that's how it's done > now." Agreed for LLAs. But... what's special about ULAs? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 12 01:51:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D10124BFA for ; Mon, 12 Jun 2017 01:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqUd9l-a0e4o for ; Mon, 12 Jun 2017 01:51:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B03C1201FA for ; Mon, 12 Jun 2017 01:51:40 -0700 (PDT) Received: from [192.168.0.171] (unknown [197.181.50.153]) (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 17823827B8; Mon, 12 Jun 2017 10:52:29 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , otroan@employees.org Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> From: Fernando Gont Message-ID: <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> Date: Mon, 12 Jun 2017 03:47:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:51:42 -0000 On 06/11/2017 02:51 AM, Brian E Carpenter wrote: [...] >>> d) There is no physical reason for n to have the same value on different link media. >> >> There is no technical reason why IID length is tied to the datalink type. > > I believe there is: so that SLAAC can work with devices out of the box, without > having to set the IID length. Not sure I follow. Router advertised Prefix/N (where N is nowadays hardcoded to be "64", but need not). Host eploys RFC7217, and grabs 128-N random bits from F() to generate the IID/address. Why does N need to be set on a per-link-type basis? >> There was at some point when we thought it was a good idea to embed L2 addresses in the network layer address. >> Even so, it would be trivial to make implementations deal with arbitrary IID lengths. >> >>> e) Future link media might more appropriately use a different value. >> >> See above. has very little to do with data-linkt type. > > That's correct. By dropping modified EUI-64 we have removed a > noticeable dependency. But who's to say there won't be a future > link type whose deployment scenario is better suited by, say, > 80 bit prefixes and 48 bit IIDs? I have no idea about that. Well, on such links the local router would advertise a /80 rather than a /64. Why should the clients need to worry about this? >>> f) Therefore the addressing architecture should only define n=64 as a default >>> recommendation for IPv6-over-foo documents. >> >> I don't think that follows from the arguments laid out above. >> We can (if we want to), make SLAAC work with any IID length. Including 0. >> >> I still don't understand what the goal is here. What problem are you solving? What is the proposal? > > Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do. +1 Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 12 01:52:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B8D12946B for ; Mon, 12 Jun 2017 01:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSF9S-nnjm08 for ; Mon, 12 Jun 2017 01:51:44 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36945126B7E for ; Mon, 12 Jun 2017 01:51:44 -0700 (PDT) Received: from [192.168.0.171] (unknown [197.181.50.153]) (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 2394382827; Mon, 12 Jun 2017 10:52:34 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , "Manfredi, Albert E" Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: Fernando Gont Message-ID: <69a56022-98fa-6ff9-add9-0345410ec171@si6networks.com> Date: Mon, 12 Jun 2017 03:55:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:51:45 -0000 On 06/11/2017 04:46 AM, Brian E Carpenter wrote: > On 11/06/2017 12:00, Manfredi, Albert E wrote: >> -----Original Message----- From: ipv6 >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> >>>> If we remove the 64 bit boundary from 4291, then an update of >>>> 2464 will likely result in the removal of any bit boundary >>>> there as well. >>> >>> No, for the out-of-the-box reason. I can't see any practical >>> alternative to a fixed length per link type. >> >> I think there are practical alternatives, so I too would suggest >> not to state flatly that SLAAC requires fixed length IIDs. Anything >> that requires RAs to work can make adjustments to its IID, in real >> time. > > It cannot adjust its IID length when assigning itself a link-local > address *before* receiving any RA/PIO messages. link-local could be considered a special case... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 12 01:52:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787F412946B for ; Mon, 12 Jun 2017 01:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bENDxFvYQCl for ; Mon, 12 Jun 2017 01:51:48 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83AD126B7E for ; Mon, 12 Jun 2017 01:51:47 -0700 (PDT) Received: from [192.168.0.171] (unknown [197.181.50.153]) (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 3CA8D827B8; Mon, 12 Jun 2017 10:52:39 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org, Brian E Carpenter Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: Fernando Gont Message-ID: Date: Mon, 12 Jun 2017 04:00:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:51:49 -0000 On 06/11/2017 09:29 PM, otroan@employees.org wrote: > Brian, > >>>>> If we remove the 64 bit boundary from 4291, then an update of 2464 >>>>> will likely result in the removal of any bit boundary there as well. >>>> >>>> No, for the out-of-the-box reason. I can't see any practical >>>> alternative to a fixed length per link type. >>> >>> I think there are practical alternatives, so I too would suggest not to state flatly that SLAAC requires fixed length IIDs. Anything that requires RAs to work can make adjustments to its IID, in real time. >> >> It cannot adjust its IID length when assigning itself a link-local address *before* >> receiving any RA/PIO messages. But whatever length N of IID it uses to generate its >> LL address must match the the prefix length 128-N in a later RA/PIO with A=1. >> Otherwise, SLAAC fails. >> >> (see Section 5.5.3 bullet d of RFC4862, as Jinmei-san kindly explained to me.) >> >> So in fact the only thing that works is if the equipment assumes the same IID length >> as the router announces (as 128-N). Therefore, N must be predefined. > > As I said the argument is tenuous. > This is a trivial change, if we were to go down this route. The fixed constant is a fundamental part of the IPv6 architecture. If we remove it from there, then it is a natural consequence to remove it from the IPv6 over foo documents and tweak SLAAC. > > The changes to SLAAC could be in two paragraphs: > - LL generation. Fix IID length to 118 _or_ make IID length implementation specific. > The on-link prefix for LL is regardless fe80::/10. In practice, it's /64. BSDs assume fe80::/64, and use some of the assummed-to-be-zero words in that prefix to store e.g. interface index. > - IID length = 128 - length of advertised prefix. Host is required to generate IID of suitable length per advertised prefix. > (or just generate a 128 bit IID, and chop of the bits needed. > > > To summarize: > - There is no technical reason why SLAAC cannot be made ot work with arbitrary prefix lengths. > (including very long prefixes, although it might take a while to find a non-duplicate if the addressing model > moves from sparse to dense). +1 > - There is no technical reason to have a fixed IID length defined by data-link type. +1 > - Removing the constant from the addressing architecture will likely set these changes into motion. > (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary > to stay in IPv6 over foo is tenable.) Me, I don't think there's a reason to keep the 64 bit constant in ipv6-over-foo documents. Actually, with RFC8064 in place, there's no reason why the IID should be link-type dependent. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 12 04:05:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0238C12943F for ; Mon, 12 Jun 2017 04:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2jydIPP_Gox for ; Mon, 12 Jun 2017 04:05:28 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE77126B7F for ; Mon, 12 Jun 2017 04:05:28 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id p62so46631854vkp.0 for ; Mon, 12 Jun 2017 04:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gBTHJ/3GXdNaE256B2J0UeJJMiyGQZIIKXPKBlvEltU=; b=Ivg8Rm7G+QcTsCbmLwAdsmahPUAIDKiGeJVVIahvpokp+d0qjTnC6PsZ0A0it6qDYt bq5hy0bHBlC+2rMBVNGXIveQ4W+QNF7z0h7+NYrEVXSPkO2DV2BPi5lu7IJvMt9uIx3y 0Vi3QLif3pCfTHV+62a+IhtB1EL2JUAjaBvs00RKn1p5hPFims+MMrF6r2zYe8sxt8hx vJkXOgytWZg5bMyec4d9OBpY7IjY7VTLgr4myq5Vu6Dj+vCNnXNsQ1Z/kqrMPtq1dBjB Kj6WHZatV+HxmWq5sHHnPW8XSZp9U9bhD5JccJ+lJrnswM559g+dx1frhINh5WsRK+FY y24g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gBTHJ/3GXdNaE256B2J0UeJJMiyGQZIIKXPKBlvEltU=; b=JA3j7Xy3UcxW/ay8YoD2Z8iYjLuzlzVEpfjMULEXKzvCQPncLO7Gr/Q1S+7Zz9BOsh nwaPEKTFv1IrdNaSUXrK29ZJnI7Dlz6Os9BgGM08wXsD/o/n3gqruU1pQrf3pHXT+Rra ngWPnfDSPUj4JQ4NdlXdnF9QJzqtk+uVN8DqE08097he7UEnaLlU2t+uhhoKYWXxjitT +AzFE76SZAbEkjzbW+x8kw21NJKn2INdQ0kYkb9NNZ2Qo+T8nS8Y8EBHWCt5pbxRnjAz Twlx3T7yNPZcRrqKCGPuzioYry5mkdhqMRbbZTthHi6o3VMmQJ49BE/cpR4PNFUbf2MF VvNw== X-Gm-Message-State: AODbwcA6O+KzESoe7j1d9CPeBvDGmrSH72vOD621XbrYnuei1g6t2z9/ O2OAYnzzl44Ful+ymkum5OhUZapmg2x/ X-Received: by 10.31.69.138 with SMTP id s132mr25329337vka.13.1497265527369; Mon, 12 Jun 2017 04:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Mon, 12 Jun 2017 04:05:06 -0700 (PDT) In-Reply-To: <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Mon, 12 Jun 2017 20:05:06 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Ole Troan Cc: IETF IPv6 Mailing List , "Brian E. Carpenter" Content-Type: multipart/alternative; boundary="001a114dd2d2e5166e0551c14bb8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 11:05:30 -0000 --001a114dd2d2e5166e0551c14bb8 Content-Type: text/plain; charset="UTF-8" On Jun 10, 2017 23:01, wrote: > To a significant extent the above three issues are tussles between operational needs > and conceptual purity. To be specific: By this labelling of the players in the tussle, you leave no doubt on which side of the tussle you have taken. I don't know if that was intended. Ole is right. To me it is especially telling that this description of the tussle did not even mention functionality at all. Brian, please don't forget that networks are built to serve customers, not operators. Those customers are using hosts that are connected to the edge of the network. The /64 boundary has nothing to do with purity and everything to do with functionality. It is a way to ensure that networks will always have enough space for the edges of the network to use IPv6 addresses in new and innovative ways. /64 subnets are - I'd argue, deliberately - large enough to ensure that any number of schemes can be developed to use them in the future. Any limitation to subnet size, even to something that looks absurdly huge compared to IPv4, such as 32 bits, will remove that ability. Today's operational needs would have to be very pressing indeed for it to make sense for us to give up that future ability. --001a114dd2d2e5166e0551c14bb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 10, 2017 23:01, <otroan@employees.org> wrote:
> To a significant extent the above three issues are tussles between ope= rational needs
> and conceptual purity. To be specific:

By this labelling of the players in the tussle, you leave no doubt on= which side of the tussle you have taken. I don't know if that was inte= nded.

Ole is right. To me it is especially telling that this descripti= on of the tussle did not even mention functionality at all.

Brian, please don't forget that n= etworks are built to serve customers, not operators. Those customers are us= ing hosts that are connected to the edge of the network. The /64 boundary h= as nothing to do with purity and everything to do with functionality. It is= a way to ensure that networks will always have enough space for the edges = of the network to use IPv6 addresses in new and innovative ways.

/64 subnets are - I'd argue, d= eliberately - large enough to ensure that any number of schemes can be deve= loped to use them in the future. Any limitation to subnet size, even to som= ething that looks absurdly huge compared to IPv4, such as 32 bits, will rem= ove that ability. Today's operational needs would have to be very press= ing indeed for it to make sense for us to give up that future ability.
--001a114dd2d2e5166e0551c14bb8-- From nobody Mon Jun 12 05:45:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F75712EAB9 for ; Mon, 12 Jun 2017 05:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRssImEZ88Ej for ; Mon, 12 Jun 2017 05:45:13 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 0A10B12EABA for ; Mon, 12 Jun 2017 05:45:00 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id u19so123783026qta.3 for ; Mon, 12 Jun 2017 05:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pvgbpap/2A04KY3m5Omk0YU97Sl3OpACQwBx0RgZGCA=; b=ivHAJh4T/cWBTKdfjkxRu8pZbyKgMoQABe7/XvpW6CC0SucBrV7a/HzDfqj3OnY1GF l8jX6K9jNNRmQFoZ3tWwxWNdaguQWMD1u63zr/RmRDuo+8iUE3pXbYDFxgWtZeCeeSWV jkRJGlagyq58pO3Oym0ls6EZKdQkNHwZkU2WFKUlUUU2pFrUnj564bdehBdybPAdDtBG iRS2LMbXKs4qcIjFMHPXyoDsV/hxcmooIfufZXbrlSOl/XIo0tllfmNOkiffPcPPNL1f v4+8PPg5MfkmnBJhPGXuns5yN7M8cM4VEwXGmW0fAXSA7heAItq2DUQ+aGNHTAtFD1va x0pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pvgbpap/2A04KY3m5Omk0YU97Sl3OpACQwBx0RgZGCA=; b=boEzqSiDw2b9TlPaleoYu3ncuFVwocKaB7Cc4bAmiKPLCiUQQ6+JpDQ/ONX7S0lc7G z5m7jmJMBCQd+U/yUxsvxTo96bqraFrPNo9glCXB5AEudSNpMwTbZU5g7dgmDcb+fcff ZSjwP47cD/KOvJqb5H1l91SXJnY4kAxGRIuhB1l3l7zwF5uPi8tT3VZP5T0x1GaVvUG2 U7nOmz0QxlI7ASWl+IkEMPPIfb+CRezyFt91R/83i5aPBAWZqHHNc7bCfwD1rqGTI1lS c7FSsUwBq3BpFqj3x7idMA3exYkgMnSmyQh6/KJq238Vfn7al6kW/NSmUME/+vvW1jx9 /tbg== X-Gm-Message-State: AODbwcCZ0p+PU+q7Q0TtP6z+OtzUr197fxxPpnZEY7kHd2GuZC6mRHvA 1YnKcJFcrdNejmRHSGE688cdToCcwu1Z X-Received: by 10.200.57.119 with SMTP id t52mr42483895qtb.171.1497271499101; Mon, 12 Jun 2017 05:44:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.149 with HTTP; Mon, 12 Jun 2017 05:44:38 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Richard Hartmann Date: Mon, 12 Jun 2017 14:44:38 +0200 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 12:45:15 -0000 On Mon, Jun 12, 2017 at 1:05 PM, Lorenzo Colitti wrote: > Ole is right. To me it is especially telling that this description of the > tussle did not even mention functionality at all. The problem statement is still valid. Also, it _does_ make sense to take motivations and sentiments into account. We can argue about technical merit all day long; if we're not somewhat aware of the intrinsic motivations of all/most involved, we might be arguing past each other for years. Blocking DHCPv6 (in part) to protect the /64 boundary as SLAAC can't do anything else is logically consistent, but if it's not stated publicly, becomes harder to engage on the technical level. Finally, sometimes, there is just no middle ground for consensus, leading to a stand-off. > Brian, please don't forget that networks are built to serve customers, not > operators. Those customers are using hosts that are connected to the edge of > the network. The /64 boundary has nothing to do with purity and everything > to do with functionality. It is a way to ensure that networks will always > have enough space for the edges of the network to use IPv6 addresses in new > and innovative ways. > > /64 subnets are - I'd argue, deliberately - large enough to ensure that any > number of schemes can be developed to use them in the future. Any limitation > to subnet size, even to something that looks absurdly huge compared to IPv4, > such as 32 bits, will remove that ability. Today's operational needs would > have to be very pressing indeed for it to make sense for us to give up that > future ability. This is a cyclic point as we're merely moving the "edge" around. It's not unlikely to assume that a user will have have a /64 on their device but need to subnet so their health data is not accessible from their social life live stream or a music player. Now they have space large enough to ensure that any number of schemes can be developed, but can not develop any such schemes as their hosts rely on, or even mandate, a fixed boundary of /64. And yes, the logical conclusion is a race to the bottom of sorts, arriving at a /128 in the end. But this is already possible with a /64: Simply disallow traffic from more than one IP per user/device/whatever and they have a /128 for all intents and purposes. This works with SLAAC as well as DHCPv6 so nothing is, in theory, stopping operators from doing this today. All cases above lead to NAT if you push them to the max. This, in turn means that even if we only have NAT on a small-but-substantial part of end user devices, everything else would need to adapt to this. While it's possible to hold end users systems and thus their users hostage by disallowing technologies, the users would become pawns in a proxy war. But if this could work today and it's not implemented this way, I would argue that /64 and SLAAC are not the only things which stand in between nice things and NAT; there seem to be other considerations in play which work towards good functionality and they are not all purity. But again, sometimes, there is just no middle ground for consensus, leading to a stand-off. Richard From nobody Mon Jun 12 08:21:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5B512706D for ; Mon, 12 Jun 2017 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T15FczBtZL7 for ; Mon, 12 Jun 2017 08:20:58 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 57BE412878D for ; Mon, 12 Jun 2017 08:20:58 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id v111so101196166wrc.3 for ; Mon, 12 Jun 2017 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UYPNFMDwzp2TeIRfZI8V7W4gIhRYEW0JYnUfd7Eo1G0=; b=BXg5sGzgMRQT5dBo5ntlD5d17GeCAlu0tx6KQNWbBAahMK/zO7EIJchLc3tJfzBo1/ CvTdNmuR7NNKHX64YeEVzMeQ7kr+z48/kJ65XdGKfSQMhhX0ZZS+w6+Ro2++zVEncrav DKuwN63jMkWX/LVcYzy9xqORHq4gQGgjlsulns8tKTT3iVSGnbBzI3oVVAIU/AsANdgi 6ZH8bbVymWX8qYQ4e7yUxIMx8iLMh9PFocAABN3tN/xG9hOLBydu61pZTJ71gQovm0zE 33RiCZvsA9LblRvy7WIhDzUjvGUfQT/Vg4Ldizzzq0Lcm2XFa/heBGKYzdG7YBuVXfJC 90Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UYPNFMDwzp2TeIRfZI8V7W4gIhRYEW0JYnUfd7Eo1G0=; b=pdDJikiZBChX38dCKRdN4eFcIdYcNMJapPhLV+xsLKvMqu2+8WOiGJiuZHHU45lmYV yF2eJLASw5aIX7zcqWhmnmoXl+t7sOCx9Hq5tMcp0+buHSJ5TPrV3Xb8azplYcwZcjBt HwQGGBRAXakD8f0nxJm7cVWoPb8PG5oXiW0+gKN8ldT3n4vAvnp2Euwyjkt+LHnZdQBG oa0ARaQyGsuGSVYJoRdXeD80i1tYO44X84JvGMpgHnKZHAg+42Yh8iZ5e6w2DAr5GyUg vUQkOTuKM6acF3mZgsaKBd17vMaZQUKCQAzq65hYSUNf+TbR6jfRB9HUsLe0X7Sj4AGT 5rbg== X-Gm-Message-State: AODbwcBh1DA3lMkEQ9X23rhdjN8KMNfHZwXQ5qrfZwLa5s2aYv55Sg1z 076u+rq+htaEltKAk/g+M0aHbpsDgYQC X-Received: by 10.223.166.196 with SMTP id t62mr7035492wrc.52.1497280856683; Mon, 12 Jun 2017 08:20:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Mon, 12 Jun 2017 08:20:56 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Tom Herbert Date: Mon, 12 Jun 2017 08:20:56 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:21:02 -0000 On Mon, Jun 12, 2017 at 4:05 AM, Lorenzo Colitti wrote: > On Jun 10, 2017 23:01, wrote: > >> To a significant extent the above three issues are tussles between >> operational needs >> and conceptual purity. To be specific: > > By this labelling of the players in the tussle, you leave no doubt on which > side of the tussle you have taken. I don't know if that was intended. > > > Ole is right. To me it is especially telling that this description of the > tussle did not even mention functionality at all. > > Brian, please don't forget that networks are built to serve customers, not > operators. Those customers are using hosts that are connected to the edge of > the network. The /64 boundary has nothing to do with purity and everything > to do with functionality. It is a way to ensure that networks will always > have enough space for the edges of the network to use IPv6 addresses in new > and innovative ways. > Lorenzo, ILA is an innovative way to use IPv6 addresses, but as I described it can't use this in a mobile network if every UE gets a /64. In this case too much space is given the end host which probably a low end device like a smart phone that really doesn't need it. > /64 subnets are - I'd argue, deliberately - large enough to ensure that any > number of schemes can be developed to use them in the future. Any limitation > to subnet size, even to something that looks absurdly huge compared to IPv4, > such as 32 bits, will remove that ability. Today's operational needs would > have to be very pressing indeed for it to make sense for us to give up that > future ability. > But that begs the question, why is /64 the one size fits all answer? What if in the future that number proves to be the wrong choices? Flexibility seems like a better way to future proof this. Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jun 12 08:31:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1AD126BF3 for ; Mon, 12 Jun 2017 08:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lxjp_qkTWzhL for ; Mon, 12 Jun 2017 08:31:22 -0700 (PDT) Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (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 2BB3B120227 for ; Mon, 12 Jun 2017 08:31:21 -0700 (PDT) X-OneUnified-MailScanner-Watermark: 1497886276.70021@ScQrv5D+NNoxfO2TiYwEBg X-OneUnified-MailScanner-From: ray@oneunified.net X-OneUnified-MailScanner: Found to be clean X-OneUnified-MailScanner-ID: v5CFVCU9030370 X-OneUnified-MailScanner-Information: Please contact the ISP for more information Received: from BM1QVSL12420 (mail1.oneunified.net [63.85.42.215]) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id v5CFVCU9030370; Mon, 12 Jun 2017 15:31:13 GMT From: "Raymond Burkholder" To: "'Tom Herbert'" , "'Lorenzo Colitti'" Cc: "'IETF IPv6 Mailing List'" References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: Subject: RE: Tussles in IPv6 Land Date: Mon, 12 Jun 2017 12:31:13 -0300 Message-ID: <033901d2e390$ed5b38e0$c811aaa0$@oneunified.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJeUNiyRZH+LK1AoPS+n2iHiI1h8AHEfMw/AS8/2UsCUdreDqDgUe5Q Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:31:24 -0000 > Lorenzo, Taken, probably, out of context: > > ILA is an innovative way to use IPv6 addresses, but as I described it can't use > this in a mobile network if every UE gets a /64. In this case too much space is > given the end host which probably a low end device like a smart phone that > really doesn't need it. Out of curiosity, when a smartphone is used in tethered mode, ie, devices are hanging off it via the built in hot-spot, do the devices get an address out of the smartphone /64, or should the phone have a /60 or maybe /56 to handoff to those devices? Say, as LTE gets more predominant, powerful, and bandwidth capable, maybe with rural/farming areas getting into more IoT stuff, maybe have a router hanging off that tethered hotspot? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nobody Mon Jun 12 08:57:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87987129408 for ; Mon, 12 Jun 2017 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM-mbzMTEZCG for ; Mon, 12 Jun 2017 08:57:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7E127444 for ; Mon, 12 Jun 2017 08:57:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 28588908C2F; Mon, 12 Jun 2017 11:55:53 -0400 (EDT) Date: Mon, 12 Jun 2017 11:55:53 -0400 From: John Leslie To: Lorenzo Colitti Cc: Ole Troan , IETF IPv6 Mailing List Subject: Re: Tussles in IPv6 Land Message-ID: <20170612155553.GA20648@verdi> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:57:57 -0000 Lorenzo Colitti wrote: > > Brian, please don't forget that networks are built to serve customers, > not operators. I choose not to argue about the design. But please understand that networks MUST be managed by operators. It is inevitable that operators will modify the design to suit their needs (as they perceive them). If you wish to change the behavior of operators, this is the wrong list to reach them. -- John Leslie From nobody Mon Jun 12 10:23:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74F3129456 for ; Mon, 12 Jun 2017 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqbmCXCiLO54 for ; Mon, 12 Jun 2017 10:23:04 -0700 (PDT) Received: from atl4mhob14.registeredsite.com (atl4mhob14.registeredsite.com [209.17.115.52]) (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 E8DCF12945E for ; Mon, 12 Jun 2017 10:23:03 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob14.registeredsite.com (8.14.4/8.14.4) with ESMTP id v5CHN22R031147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Jun 2017 13:23:02 -0400 Received: (qmail 7646 invoked by uid 0); 12 Jun 2017 17:23:02 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 12 Jun 2017 17:23:00 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 12 Jun 2017 13:22:55 -0400 Subject: Re: Tussles in IPv6 Land From: Lee Howard To: Lorenzo Colitti , Ole Troan CC: IETF IPv6 Mailing List Message-ID: Thread-Topic: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3580118578_6188643" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 17:23:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3580118578_6188643 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit From: ipv6 on behalf of Lorenzo Colitti Date: Monday, June 12, 2017 at 7:05 AM To: Ole Troan Cc: IETF IPv6 Mailing List Subject: Re: Tussles in IPv6 Land > > > Brian, please don't forget that networks are built to serve customers, not > operators. What networks? Enterprise operators build networks to do business. Mobile network operators build networks to serve people using mobile devices. Residential access providers build networks to serve people at home. Community network operators build networks to serve the community. Universities build networks to enable students and faculty to do research, and also to attract students to the university. Content delivery network operators build networks to serve companies. Transit network operators build networks to transit and connect other networks. As Brian points out, these operators may have different needs. Lee --B_3580118578_6188643 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


From: ipv6 <ipv6-bounces@ietf.org> on behalf of Lorenzo Colitti <lorenzo@google.com>
Date: Monday, June 12, 2017 at 7:05 AM
To: Ole Troan <otroan@employees.org>
Cc= : IETF IPv6 Mailing List <ipv6@iet= f.org>
Subject: Re: Tussles= in IPv6 Land



Brian, please don't forget that networks are built to serve customers= , not operators.

W= hat networks?

Enterprise operators build networks t= o do business. 
Mobile network operators build networks to se= rve people using mobile devices.
Residential access providers buil= d networks to serve people at home.
Community network operators bu= ild networks to serve the community.
Universities build networks t= o enable students and faculty to do research, and also to attract students t= o the university.
Content delivery network operators build network= s to serve companies.
Transit network operators build networks to = transit and connect other networks.

As Brian points= out, these operators may have different needs.

Lee=



--B_3580118578_6188643-- From nobody Mon Jun 12 10:43:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBD812951E for ; Mon, 12 Jun 2017 10:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnrahevwT6p6 for ; Mon, 12 Jun 2017 10:43:14 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A043912945E for ; Mon, 12 Jun 2017 10:43:14 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id v7so21793978ywc.2 for ; Mon, 12 Jun 2017 10:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kKA9j6dDC+D+ITdNzLmrHb9DmpQ8+um0QcYyxDnZJds=; b=J6jRdH0o0oQAlGS4g+hjCX4WWPhALHPudLPX9eunkjy0oA99Xv+daMjZOAHVa+KtZQ 4fAEAPuNKunXubPUmOLO2WzyC5vX34qY761GoNDBexIhAmXYEm2yD+NdjDG83+azhvnt gr8AMyN7kJnX0nCSQcu1HyN05/hPFFtUSGUTtelQbWpf1AKGANLXMviSxkj6ADTeN8PD hz1Ap8uRAxXYmjJyBgEYl57lAy3as/pn00pW9VbUH9jJ66CyT5e6DLQTzOH9etoinJ8g QPfsTJjQvArE3CQUa8cSJY2+sqD3PE+4tEV9LgBg9upZB3vNu/fK817JOS4FRjcpeF+1 e5fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kKA9j6dDC+D+ITdNzLmrHb9DmpQ8+um0QcYyxDnZJds=; b=jcsO5dk/GMjkOKXbFoz9VzfbIMxXNxpbSUGkG0f+V2Aoi8jziLFSWdDWpDMkhJCXe0 PE40rnawFi92K7js/S/BmfXkLuHzMc4xyYHyJH6aodm0yBkH5sccAxRbGPfmsKVPbPJV BHbjpICuDOTz+i/2ExyHNnghZM/L2GnQtjk+3UY/wogwdoGKdUZUDsdUNi0+/FaTsZio X2O0poEC+sRl0xQpeOQ9xjn4Q6hA9gkD7hPsIkVtsfZdrlxGFtcpoeXkgvByc043yYQo rbmjviif3VFToIo9w8Pz9KK1sOSq3pKU7cffsCK1aD2uENl24mrJx9+BfWQ11D9IG7qF Yksw== X-Gm-Message-State: AKS2vOzAcfOsMRjj3PqRpTh99bK+ndUNyo5ShEQkSN+N4UlIdXKtlpot H0rEfkAxwLKAWkK9aaEBUVVDvJoHKw+sJ8E= X-Received: by 10.55.74.147 with SMTP id x141mr37469736qka.37.1497289393766; Mon, 12 Jun 2017 10:43:13 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Mon, 12 Jun 2017 10:43:12 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 12 Jun 2017 10:43:12 -0700 X-Google-Sender-Auth: mvZ9LCttP_jrQR4j8YpUmSq7bgc Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: David Farmer Cc: Ole Troan , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 17:43:17 -0000 At Sat, 10 Jun 2017 15:34:30 -0500, David Farmer wrote: > > A slightly sophisticated host (but still rather simple) may > > additionally be aware of subnet prefix(es) for the link(s) it is > > attached to, where different addresses may have different values for > > n: > > > > | n bits | 128-n bits | > > +-------------------------------+---------------------------------+ > > | subnet prefix | interface ID | > > +-------------------------------+---------------------------------+ > > > > To be truly honest I've never found that description helpful, in fact I > think it is part of the problem. It confuses classic IPv4 subnet > prefix(mask) terminology with IIDs and on-link prefixes for IPv6, which are > subtly different. In my opinion, the IPv4 subnet prefix is not used in the > generation of the IPv4 address per se, it is really only used to determine > locality, in this way it is similar to an IPv6 on-link prefix, and has > little to do with the IID length. > However, the above quote by using subnet prefix terminology, ties the > subnet prefix length and IID length directly together, also seeming to > indicate that IIDs and on-link prefixes have to be congruent, but the IID > and on-link prefix can be incongruent and therefore again using subnet > prefix terminology really confuses the situation and I think this is the > root of this conflict. Therefore when we say the IID is 64, the above seems > says the subnet prefix is /64 and therefore the on-link prefix is also /64, > but this is not suppose to be the case. Agreed. > I've been thinking about this for a while and I think the only way to > resolve this conflict is to stop using "subnet prefix" in reference to IPv6 > and only use it in reference to IPv4. I would propose substituting > "addressing prefix" for "subnet prefix" in the above quotation from RFC4291 > and add a separate discussion of on-link prefixes and then note the classic > IPv4 subnet prefix length is equivalent to the on-link prefix length in > IPv6. If this is done then the statement that the IID length MUST be 64 > says nothing about the on-link prefix length. Also agreed. The term "subnet prefix" in RFC4291 and rfc4291bis is so confusing that we've been having unnecessary controversy. Although I'm still not 100% sure about the real goal of draft-bourbaki-6man-classless-ipv6-00, one thing we could do for rfc4291bis is to resolve this terminology confusion either by changing the term and/or by adding more explanation. IMO this can be done without changing the addressing architecture itself (so it's within the scope of rfc4291bis), and I believe it can be accepted by most of us, whether they prefer "operational needs" or "conceptual purity". Whether we should keep fixing the IID length for 7/8-ish of unicast addresses at 64 bits or keep letting link-layer docs specify that value is an interesting discussion. But that can and actually should be done separately and probably be better deferred until we complete rfc4291bis, since there will be real controversy in that discussion. -- JINMEI, Tatuya From nobody Mon Jun 12 10:47:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46512EAB2 for ; Mon, 12 Jun 2017 10:47:07 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqtTJ8aZW1b3 for ; Mon, 12 Jun 2017 10:47:05 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70174129C67 for ; Mon, 12 Jun 2017 10:47:05 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id k71so47958739pgd.2 for ; Mon, 12 Jun 2017 10:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Jvio9S7g02Xq1WwZhKe6DWuw3/3Vrab23aNRyNdC7Z0=; b=NVBHbK8TQN7Hn2k+3W4w0lLoLX2c+d2F/dKwEssSBw3JLTcQVti+2H2aOnpVgUnDWa S/l9CqYy7qw1QfmH03/L0nnX1ngGzddDq2wH8vjMsepZ+SyMdgbNALoikIggphVYLC6M KMRAwKMsgmARa2Z1NBGm8/D5HM5EGgDCDB1J+YGPRT0qGBMP+9Pip/wLEeugI/xaiZiX 04H/qj3rDvkRlgVxmtAkKBEKJAXHqEC2PsO8zylzoMY0knCeR6x5eOkg80SkPrZTgX/B wajcOlsvM72KIJrlDVXy3xa0P3UhuKkybjxxu1AFb9lOhBYnUcaGIYQ41TndsTI04hJs T2Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Jvio9S7g02Xq1WwZhKe6DWuw3/3Vrab23aNRyNdC7Z0=; b=cDmdEdfuBo5MwqmTUrwr1ppP07xQMlgqnqrbo62LsDl/gEfLV/nAhdNV4bK1O9vIyw A5eVtn3OKqQ/7dsYvL0BziWYVgjpSWFeMwBI6fAzeWom6lkCSyxShWndVxdSBjndsc38 BK+TYEAPNaOSf552vIPeJQ7GjKcAfVgWKJdR7eK4OA4CrCHO6M4b1XlbTyrRrLyFaywc 6oY+Why/B2extF+E6eWRQUNJ95J4xdGrR8+hZ0t/jD1WB91KMX8JLxuwNfUr/q6n1C+q ts3v57VhXSdyu5PYAQwyudwbUzLY+iv8v56/hgtqNvUJ861jRqk0cFyHmr6gdTuPnKjT wWvA== X-Gm-Message-State: AODbwcBBlBGFmyzA+LoftpODx2PHQQQQx5tpzcdSAnY84xT+NbsM5u5f CR0qMC335lbQ94wTgcqyIA== X-Received: by 10.84.209.238 with SMTP id y101mr57352821plh.290.1497289624665; Mon, 12 Jun 2017 10:47:04 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:88a8:6672:5d6f:76a2? ([2620:0:10e7:10:88a8:6672:5d6f:76a2]) by smtp.gmail.com with ESMTPSA id 84sm18493755pfq.125.2017.06.12.10.47.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 10:47:04 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_252DD316-226A-47E8-9A2B-34CAE00912B6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land Date: Mon, 12 Jun 2017 10:47:02 -0700 References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> To: IETF IPv6 Mailing List In-Reply-To: Message-Id: <450A257A-CBF2-419C-AD27-B72B0F2CEA6F@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 17:47:07 -0000 --Apple-Mail=_252DD316-226A-47E8-9A2B-34CAE00912B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 12, 2017, at 10:22, Lee Howard wrote: >>=20 >> Brian, please don't forget that networks are built to serve = customers, not operators. >=20 >=20 > What networks? >=20 > Enterprise operators build networks to do business.=20 > Mobile network operators build networks to serve people using mobile = devices. > Residential access providers build networks to serve people at home. > Community network operators build networks to serve the community. > Universities build networks to enable students and faculty to do = research, and also to attract students to the university. > Content delivery network operators build networks to serve companies. > Transit network operators build networks to transit and connect other = networks. Home networks are designed using ad-hoc methodologies by people without = any understanding or skill in network operations. > As Brian points out, these operators may have different needs. For one very crucial category of network, calling the people who build = them =E2=80=9Coperators=E2=80=9D is an abuse of the technical language. --james woodyatt > --Apple-Mail=_252DD316-226A-47E8-9A2B-34CAE00912B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 12, 2017, at 10:22, Lee Howard <lee@asgard.org> = wrote:

Brian, = please don't forget that networks are built to serve customers, not = operators.

What networks?

Enterprise operators build networks to = do business. 
Mobile network operators build = networks to serve people using mobile devices.
Residential access providers build networks to serve people = at home.
Community network operators build networks = to serve the community.
Universities build networks = to enable students and faculty to do research, and also to attract = students to the university.
Content delivery = network operators build networks to serve companies.
Transit network operators build networks to transit and = connect other networks.

Home networks are designed using ad-hoc = methodologies by people without any understanding or skill in network = operations.

As Brian = points out, these operators may have different = needs.

For one = very crucial category of network, calling the people who build them = =E2=80=9Coperators=E2=80=9D is an abuse of the technical = language.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_252DD316-226A-47E8-9A2B-34CAE00912B6-- From nobody Mon Jun 12 10:53:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB41129564 for ; Mon, 12 Jun 2017 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEq1M5t9z7lp for ; Mon, 12 Jun 2017 10:53:44 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 AD39512952E for ; Mon, 12 Jun 2017 10:53:44 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id u19so135783923qta.3 for ; Mon, 12 Jun 2017 10:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2sdxKC6f1Xs3J1hLgftpRUiXb0lbP6Q4A35IvYxhQSE=; b=uRB+bz3ijtA22XSuPZfisIXi9985OLIXQwhvCZsWJvpM/blLGnV3Tv0IgpBAif+VIJ YQn5YTTgNXZDU4/iewahZD+bVBMPDB/5PwMetNPk+xHcyxSxhHfzYe86ZedG93LEwcYP ldAV2Tj9ZWaAOFS7M/Ax892B70Nd7u7162jemHTbMP6zuvz6iGBVR8op2m20PUIlqJkR 5OHDHOH9i2t9VJBc9bIyNrXKVnnXWT0suNvQdkIgNeF6yfOB/QPveEIuFPl22tLMsJmQ IZBz4vL18hmUwrjSWnq0ejNxL0SNC6tDhjpQnKGl38AibTWdWKrY3olCejqqfuQ1yZQ0 PZtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2sdxKC6f1Xs3J1hLgftpRUiXb0lbP6Q4A35IvYxhQSE=; b=lpMyHOFt18GyrSXXwzFfYhwD3MTlLAGB4XNqy5u5FPgCzPU0JX+nHACNZrFVT4yDse B2/AVpefeBLhbvM8HwNsPTwEgRBQDsZ+oDjDuP1jpLj7OyuEIp1DPbc9zKvbbHblD1vK XP+okfY/DThWcYX6OWJgqDrvuY858dfSFw5Cul/gLTJ3/fvn8XUnvHTkPPXur7AhDBzR ziVF19Fvm9lItC5GczfsDGL0XsjpOLAC2vEGta/geEMOc4tlx+pH+UW2QlqaGjDyQZ8Q x40ASiTh8kX9C0D50xWrSaHoTbYli+S+bA7lMSDRePTtLVMj73DikuV3avGCPT9BnZ2F uCIQ== X-Gm-Message-State: AKS2vOyZ9PTtNg7dIHBNsKcM+5bY7lDmJL8BJ4wfeTQic8azczt5XS+i 3IYhXxnDnotIMtvdcxVeakdBIgSmVQ== X-Received: by 10.200.57.228 with SMTP id v91mr15544180qte.116.1497290023755; Mon, 12 Jun 2017 10:53:43 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Mon, 12 Jun 2017 10:53:42 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 12 Jun 2017 10:53:42 -0700 X-Google-Sender-Auth: 8MK-Pw47CmTWG-PrHWbo6EyoPkg Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fred Baker Cc: David Farmer , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 17:53:46 -0000 At Sat, 10 Jun 2017 13:44:34 -0700, Fred Baker wrote: > The only place it makes sense to me to talk about a specific length > for an IID is with SLAAC; if a network is allocating addresses > manually or using DHCP, they are in control and can do whatever they > like - I dare you to stop them. But the IID is the part that is > never a prefix - the last N bits of a /128, and by convention 64 > bits. I'm afraid this is not really a correct description of the current specification (if you're actually proposing to change the current specifications on this, it would be more helpful if you could clarify it's a proposal, not an explanation of the current spec). It's subtle, but I suspect this subtlety is part of the controversy we've seen that should actually be unnecessary to have. If the address is manually configured or configured using DHCPv6 with some "prefix", that prefix is actually an on-link prefix and has nothing to do with IID. The IID length would still be defined by the link-type specification, and since that should be consistent with the addressing architecture, it *must* be 64 bits in practice. But that doesn't matter for actual operation - when the address is configured manually or using DHCPv6, only on-link prefix matters in the actual host behavior, and it can have an arbitrary length. -- JINMEI, Tatuya From nobody Mon Jun 12 11:14:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E061B12EB55 for ; Mon, 12 Jun 2017 11:14:31 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwfYVyYfbZOO for ; Mon, 12 Jun 2017 11:14:30 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 1AB4012EB4F for ; Mon, 12 Jun 2017 11:14:30 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id v104so105369543wrb.0 for ; Mon, 12 Jun 2017 11:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zq9fE8J3XxXTff+9EPaVx7VpDdx5UKGsDrer2jfcqCw=; b=uD9RYil5SQ2ejxiS7+RJbDykhxZybq0boiNBjbqJWhnRuFxzqdq/nqVqWnrPWmaE0L 5TzVu2HdRGKrxcoi3BA54OELnLWYPRQDM8EmqpAQJhaR5IgYIkFkCB+2LMD8fwKUEWwb WpGnlddglRu3PR4Cwxj5KE2hQ0hkit6ildtpKFhwncTlCzQJaxzHs3SIlEf+mxYjAc6b AbC5DHQOthBCsaMvNUoj7Cs1uA9B63dMEH37UWSDdCP4FHZogRnMHsnAtaxbVaZ/zNpA EKvVjjl99hU7SFysY/r+5DLs0TRYnsY4ggYlstUCB0j7csrONzLq4uQQB9CAF4rxRDwj hONA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=zq9fE8J3XxXTff+9EPaVx7VpDdx5UKGsDrer2jfcqCw=; b=MgBmDXljEkNL4n1ckOy9KKYl6ZHURIeLl9ZKEnpmLwnSHeow4uz36YytQVJFMM1oir KZ+szjbo0NMjqgEbiXlk/vZG99iiO/v0AEh6GvlfBhpN9pQLFfR2sRCJXKNXhkax1EUz rLxKRBiyas/JXVpQ9wLVE9tIifcwe4dNV+XA0r/tjsZpwSjIqIEXt2UgsyrAp6d6m/gr kOrPMJSh79SkEUO8cCUsJya1XjQAINYs8Ro9DPqI5ZszVqeBr3/7vow9+DXt5CcanK0a MF/uQxO6/LkBQurCM/vhjF/agjAkzL+J5X3Vk5sAsnbjPbToZV9dsHKcBXZPmPwOCRTE sQJw== X-Gm-Message-State: AKS2vOz3y9z4t191urZjFZXxYJx1/xBuvauaBQeALxUiI+a0ZrpFky1G axop+J1Cuvo7nMpjSFUlool03JqxLA== X-Received: by 10.223.171.29 with SMTP id q29mr181762wrc.12.1497291268044; Mon, 12 Jun 2017 11:14:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.210 with HTTP; Mon, 12 Jun 2017 11:14:27 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Behcet Sarikaya Date: Mon, 12 Jun 2017 13:14:27 -0500 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Lorenzo Colitti , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c1b4d9c2864c40551c74ae1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:14:32 -0000 --94eb2c1b4d9c2864c40551c74ae1 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 10:20 AM, Tom Herbert wrote: > On Mon, Jun 12, 2017 at 4:05 AM, Lorenzo Colitti > wrote: > > On Jun 10, 2017 23:01, wrote: > > > >> To a significant extent the above three issues are tussles between > >> operational needs > >> and conceptual purity. To be specific: > > > > By this labelling of the players in the tussle, you leave no doubt on > which > > side of the tussle you have taken. I don't know if that was intended. > > > > > > Ole is right. To me it is especially telling that this description of the > > tussle did not even mention functionality at all. > > > > Brian, please don't forget that networks are built to serve customers, > not > > operators. Those customers are using hosts that are connected to the > edge of > > the network. The /64 boundary has nothing to do with purity and > everything > > to do with functionality. It is a way to ensure that networks will always > > have enough space for the edges of the network to use IPv6 addresses in > new > > and innovative ways. > > > Lorenzo, > > ILA is an innovative way to use IPv6 addresses, but as I described it > can't use this in a mobile network if every UE gets a /64. In this > case too much space is given the end host which probably a low end > device like a smart phone that really doesn't need it. > > Tom, please don't forget that UE in 3GPP network (not even in 5G) can act as delegating router and delegate prefixes, check RFC 6459. Cameron describes a place where this is used in practice in RFC 7278. So do not underestimate UE :) Behcet > > /64 subnets are - I'd argue, deliberately - large enough to ensure that > any > > number of schemes can be developed to use them in the future. Any > limitation > > to subnet size, even to something that looks absurdly huge compared to > IPv4, > > such as 32 bits, will remove that ability. Today's operational needs > would > > have to be very pressing indeed for it to make sense for us to give up > that > > future ability. > > > But that begs the question, why is /64 the one size fits all answer? > What if in the future that number proves to be the wrong choices? > Flexibility seems like a better way to future proof this. > > Tom > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c1b4d9c2864c40551c74ae1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 10:20 AM, Tom Herbert <tom@herbertland.com> wrote:
On Mon, Jun 12, 2017 at 4:05= AM, Lorenzo Colitti <lorenzo@goog= le.com> wrote:
> On Jun 10, 2017 23:01, <otr= oan@employees.org> wrote:
>
>> To a significant extent the above three issues are tussles between=
>> operational needs
>> and conceptual purity. To be specific:
>
> By this labelling of the players in the tussle, you leave no doubt on = which
> side of the tussle you have taken. I don't know if that was intend= ed.
>
>
> Ole is right. To me it is especially telling that this description of = the
> tussle did not even mention functionality at all.
>
> Brian, please don't forget that networks are built to serve custom= ers, not
> operators. Those customers are using hosts that are connected to the e= dge of
> the network. The /64 boundary has nothing to do with purity and everyt= hing
> to do with functionality. It is a way to ensure that networks will alw= ays
> have enough space for the edges of the network to use IPv6 addresses i= n new
> and innovative ways.
>
Lorenzo,

ILA is an innovative way to use IPv6 addresses, but as I described it
can't use this in a mobile network if every UE gets a /64. In this
case too much space is given the end host which probably a low end
device like a smart phone that really doesn't need it.


Tom, please don't for= get that UE in 3GPP network (not even in 5G) can act as delegating router a= nd delegate prefixes, check RFC 6459. Cameron describes a place where this = is used in practice in RFC 7278.

So do not underes= timate UE :)

Behcet=C2=A0
= > /64 subnets are - I'd argue, deliberately - large enough to ensure= that any
> number of schemes can be developed to use them in the future. Any limi= tation
> to subnet size, even to something that looks absurdly huge compared to= IPv4,
> such as 32 bits, will remove that ability. Today's operational nee= ds would
> have to be very pressing indeed for it to make sense for us to give up= that
> future ability.
>
But that begs the question, why is /64 the one size fits all answer?=
What if in the future that number proves to be the wrong choices?
Flexibility seems like a better way to future proof this.

Tom

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

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

--94eb2c1b4d9c2864c40551c74ae1-- From nobody Mon Jun 12 11:41:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7142B126E3A for ; Mon, 12 Jun 2017 11:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AQ1H9VcBmGT for ; Mon, 12 Jun 2017 11:41:33 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2FC129530 for ; Mon, 12 Jun 2017 11:41:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5CIfRIt064075; Mon, 12 Jun 2017 11:41:28 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5CIfM7o063646 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 12 Jun 2017 11:41:22 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 11:41:21 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 11:41:21 -0700 From: "Manfredi, Albert E" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS46TUngy9O72egk+O0dQc6kfgF6IhiLbQ Date: Mon, 12 Jun 2017 18:41:21 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:41:35 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of [Tatuya Jinmei] > If the address is manually configured or configured using > DHCPv6 with some "prefix", that prefix is actually an on-link > prefix and has nothing to do with IID. The IID length would > still be defined by the link-type specification, and since that > should be consistent with the addressing architecture, it *must* > be 64 bits in practice. Some of us are saying that the above need not be the case. It is simple eno= ugh to create RFC 2464-bis, where this old notion is discarded, and where h= osts with Ethernet (or other interfaces too, for that matter) can generate = IID lengths that can vary from 64 bits (or actually even 128 bits) to 1 or = to 0 bits, if need be. They can do so in real time, in response to the pref= ix length received in a RA. (We can argue about what algorithm makes sense = to create these other IID lengths. Doesn't seem very difficult.) And becaus= e the rationale used for 64-bit IIDs, in RFC 2464, is no longer believed to= be good, that says a -bis version is warranted. Said another way, the premise upon which RFC 2464 is written is no longer v= alid. Therefore, what derived from this premise needs to be re-evaluated. S= LAAC should not be used as a reason for fixed length IIDs, much less a 64-b= it boundary, in this draft. So, even before an RFC 2464-bis is written, the language that states that 6= 4-bit IIDs are "mandatory" can be softened. It just does not sound credible= or defensible these days. Bert From nobody Mon Jun 12 11:50:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23B21296C6 for ; Mon, 12 Jun 2017 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z20WQl57iYo for ; Mon, 12 Jun 2017 11:50:20 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD29129534 for ; Mon, 12 Jun 2017 11:50:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5CIoJMW063984; Mon, 12 Jun 2017 11:50:19 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5CIoAmZ063877 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 12 Jun 2017 11:50:10 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 11:50:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 11:50:09 -0700 From: "Manfredi, Albert E" To: "sarikaya@ieee.org" CC: IETF IPv6 Mailing List Subject: RE: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS42u/G45s2ZsNIEKc6H7KhyhgfKIhzXoAgAAwe4D//5NGEA== Date: Mon, 12 Jun 2017 18:50:09 +0000 Message-ID: <0dfc437f7d9b4aa29e72dac73f71e696@XCH15-06-11.nw.nos.boeing.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:50:22 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJl aGNldCBTYXJpa2F5YQ0KDQo+IFRvbSwgcGxlYXNlIGRvbid0IGZvcmdldCB0aGF0IFVFIGluIDNH UFAgbmV0d29yayAobm90IGV2ZW4gaW4gNUcpDQo+IGNhbiBhY3QgYXMgZGVsZWdhdGluZyByb3V0 ZXIgYW5kIGRlbGVnYXRlIHByZWZpeGVzLCBjaGVjayBSRkMgNjQ1OS4NCj4gQ2FtZXJvbiBkZXNj cmliZXMgYSBwbGFjZSB3aGVyZSB0aGlzIGlzIHVzZWQgaW4gcHJhY3RpY2UgaW4gUkZDIDcyNzgu DQoNCkJ1dCB0aGlzIGludm9sdmVzIHRoZSBJU1AsIHdoZW4gdGhlIElTUCBuZWVkIG5vdCBiZSBp bnZvbHZlZC4gQSBzbWFydHBob25lIHRoYXQgaGFzIGJlZW4gYXNzaWduZWQgYSAvNjQgd291bGQg aGF2ZSB0byBlaXRoZXIgdXNlIElQdjQsIG9yIGJlZyB0aGUgSVNQIGZvciBtb3JlIHByZWZpeGVz ICh3aXRoIGNvbnNlcXVlbmNlcyB0byBJUHY2IG1lc3NhZ2Ugcm91dGluZyksIGlmIGl0IHdhbnRz IHRvIGJlY29tZSBhIFdpRkkgaG90cG90Lg0KDQpXaHkgc2hvdWxkIGl0IGJlIGVhc2llciwgZm9y IGEgdXNlciwgdG8gY3JlYXRlIFdpRmkgaG90c3BvdHMgaW4gSVB2NCB0aGFuIGl0IGlzIGluIElQ djY/DQoNCkJlcnQNCg0K From nobody Mon Jun 12 12:04:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF581298BA for ; Mon, 12 Jun 2017 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOdMEnZjxLzV for ; Mon, 12 Jun 2017 12:04:27 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 C6F66129A96 for ; Mon, 12 Jun 2017 12:04:24 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id c10so138553160qtd.1 for ; Mon, 12 Jun 2017 12:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=pEkMawd1LTY86FgHt2T1CUG0+Np2S75FJUUmWsEBArU=; b=QWwCSXNLZN1jyAK32LhlweEWaLXw2WOWrIq9+kiGJqwJM1tAdmuKMY30HMBnD5d+x1 vnbDj9jh2FJk1IsFEmw5p/6FeSmgiCMq9f6mEsa0EG7lOzv9fxHq7ybOkVtNHoS4g32V kK1d/UgCf7tWKortdfnQXoxkFvSTt9N7zh73mwpz4RLTvj67TKqD5bAxZF7cNziFSDty E1oK/VbBNdS7PLTtd2N8Hruz7pBgC4MM/eMt7kcYygvdlAgqlkZhdtpR9ss6S/xSZLeT CReneehlMdVGZwiRPg5K6dht2C47eR/aGBM9hE9S/Psv309gHlNkUV9Fti2Ni9voBO2Z ar8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=pEkMawd1LTY86FgHt2T1CUG0+Np2S75FJUUmWsEBArU=; b=k/U274VP1vKIP0RhilrDU3/q3ovvPJ/++af9LHt33DWwuseMhey3vC0zC2Bn6R+X0A FfnmUSAsVdjRFGZtYapXfEAHaedtKGg33pPi7S97nOggD6l14ri/gZEuk9x7ZsrqZQ2f o/qyN5bj0EdMSuf7W7YLWw1wUupqLTmoGWZ90a7rzEJgBm3pZE6IUH+N6vwLRA5aWTWO Uto7Kh1CWPL8tbjbz09/79b6gCFLs/hOTPBruwBI8WUNUaf9yFDXcBI1l6I4ZHPMWCUj +PsY9QyvNB+xZR/zYNLvjquHDz7D5KZHdg1ZQYpwlZZy/iQGnbNayAhzFLuTjZD76wOt ii0Q== X-Gm-Message-State: AKS2vOwXNC3m/ojUcEMGbNLf8WBJbWUDgSBjAKcDQvHA9OB8kYqBFwrY HgUR0QMJWJ4mL8cfLI/t2YMlBm8otg== X-Received: by 10.237.37.169 with SMTP id x38mr44677083qtc.133.1497294263765; Mon, 12 Jun 2017 12:04:23 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Mon, 12 Jun 2017 12:04:22 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 12 Jun 2017 12:04:22 -0700 X-Google-Sender-Auth: qo2VbW-CVpfEj3NMKjd85ici5OY Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 19:04:31 -0000 At Mon, 12 Jun 2017 18:41:21 +0000, "Manfredi, Albert E" wrote: > > If the address is manually configured or configured using > > DHCPv6 with some "prefix", that prefix is actually an on-link > > prefix and has nothing to do with IID. The IID length would > > still be defined by the link-type specification, and since that > > should be consistent with the addressing architecture, it *must* > > be 64 bits in practice. > Some of us are saying that the above need not be the case. I know. I just pointed out that it would be an update to the current spec, and that when someone sas something like that, that person should be clearer whether it's a proposal of an update or explanation of the current spec: >> I'm afraid this is not really a correct description of the current >> specification (if you're actually proposing to change the current >> specifications on this, it would be more helpful if you could >> clarify it's a proposal, not an explanation of the current spec). >> It's subtle, but I suspect this subtlety is part of the controversy >> we've seen that should actually be unnecessary to have. I have no problem with having a discussion on update proposals like below. Of course, however, I may or may not agree on specific proposals, depending their details. I'm also not so optimistic about how "simple" it is. I'd expect a lot of controversy and long discussions. > It is simple enough to create RFC 2464-bis, where this old notion is disc= arded, and where hosts with Ethernet (or other interfaces too, for that mat= ter) can generate IID lengths that can vary from 64 bits (or actually even = 128 bits) to 1 or to 0 bits, if need be. They can do so in real time, in re= sponse to the prefix length received in a RA. (We can argue about what algo= rithm makes sense to create these other IID lengths. Doesn't seem very diff= icult.) And because the rationale used for 64-bit IIDs, in RFC 2464, is no = longer believed to be good, that says a -bis version is warranted. > > Said another way, the premise upon which RFC 2464 is written is no longer= valid. Therefore, what derived from this premise needs to be re-evaluated.= SLAAC should not be used as a reason for fixed length IIDs, much less a 64= -bit boundary, in this draft. And, ... > So, even before an RFC 2464-bis is written, the language that states that= 64-bit IIDs are "mandatory" can be softened. It just does not sound credib= le or defensible these days. ... perhaps, but it's still an update to the current specification. Unless and until we have an update RFC I doubt we can say the softened behavior is part of the formal protocol specification. That is, developers will still refer to RFC2464, RFC4862, RFC4291 (or its bis if published), and I don't think we can blame if they use a fixed 64-bit IID length for an ethernet interface, even if they use it for RFC7217. -- JINMEI, Tatuya From nobody Mon Jun 12 12:18:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ACA129A92 for ; Mon, 12 Jun 2017 12:18:04 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of2QrT3TTc5v for ; Mon, 12 Jun 2017 12:18:00 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 DB59B1296B0 for ; Mon, 12 Jun 2017 12:17:59 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id v104so107461182wrb.0 for ; Mon, 12 Jun 2017 12:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Tb03zlBQ7TyG75X1ZVNfpWpnztsv8NEOKNVkzZNFZ6Q=; b=nSUnHf5JnJC1URGV6mYmU/B4VA2GLUd0Z2gdWoJAK4Y52NQx1YaPDpXrg0okmez8Bj bEwy8wu1kDCeMM1mLVfFiwC5aJC00fDAATHpPcNSJUY16N0lm/FQ+wQECfHzIwiR+rEq ogdMJtIt3Ol5zVdX6RbEfgDoH0+5DhC4CxMIxh+QvkW5rqbKWU1OiX4lT8ZVRCHjaqWp HLq0fhjPBMkENKEo7c5wjZqrQPzHQtQQeWuu2ZUnNEXhrV+aQ9ieiybxqDIAkd5ltHDu MlSO+u5lMv5yySeZPlaQA89bGhDUqtph9F0y7dAzFNhcgsq9Y186TgD8qI230XacDeu+ 5Unw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Tb03zlBQ7TyG75X1ZVNfpWpnztsv8NEOKNVkzZNFZ6Q=; b=jdr2Bf5w/3t3fDxGeT8z3sfjgMyE4ED9hItfbagNcZUF4gQdofJcCI9DkhuBVamoSu Fs64XWu+QOMKEMTsrIIhjpc++Jh8v0W7hBGbxtbJoiS7axylR5DfpNAcFgtHGWrFXOtj JCRzd/RLPfiADMlFg6qkWAdrK5nUZpsAwu1N8Ne/SwqvL+llwawesb9UHsgjz9DfYvkx eBQuRc+Z09pKwOa0tszm1NnSAAh1pixV0KddXIla59JZGaoM6coAwdivvQaqJ+lf+M1D M3gKGoF+3mdO0J5t8lwpqe600KLMJiUbnjP+I86UGcV6HQrF4D15K84zhNGY3A83A3Ab orsA== X-Gm-Message-State: AKS2vOz1pVH/v8siXnzrYdmxKArmWEHQiYp6qQzE70JbYZsboGYqaF0J HPjL4tLgnREGqhtA0HkgQ1KGwFSiSQ== X-Received: by 10.223.171.29 with SMTP id q29mr315499wrc.12.1497295078062; Mon, 12 Jun 2017 12:17:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.210 with HTTP; Mon, 12 Jun 2017 12:17:57 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <0dfc437f7d9b4aa29e72dac73f71e696@XCH15-06-11.nw.nos.boeing.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <0dfc437f7d9b4aa29e72dac73f71e696@XCH15-06-11.nw.nos.boeing.com> From: Behcet Sarikaya Date: Mon, 12 Jun 2017 14:17:57 -0500 Message-ID: Subject: Re: Tussles in IPv6 Land To: "Manfredi, Albert E" Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c1b4d9c407fea0551c82d8d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 19:18:04 -0000 --94eb2c1b4d9c407fea0551c82d8d Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 1:50 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Behcet Sarikaya > > > Tom, please don't forget that UE in 3GPP network (not even in 5G) > > can act as delegating router and delegate prefixes, check RFC 6459. > > Cameron describes a place where this is used in practice in RFC 7278. > > But this involves the ISP, when the ISP need not be involved. A smartphone > that has been assigned a /64 would have to either use IPv4, or beg the ISP > for more prefixes (with consequences to IPv6 message routing), if it wants > to become a WiFI hotpot. > > Why should it be easier, for a user, to create WiFi hotspots in IPv4 than > it is in IPv6? > > In my mail, I said, 3GPP network which regulates smart phone's LTE interface, not an ISP network. I guess you are talking about Wi-Fi interface. Regards, Behcet > Bert > > --94eb2c1b4d9c407fea0551c82d8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 1:50 PM, Manfredi, Albert E &= lt;albert= .e.manfredi@boeing.com> wrote:
From: ipv6= [mailto:ipv6-bounces@ietf.org= ] On Behalf Of Behcet Sarikaya

> Tom, please don't forget that UE in 3GPP network (not even in 5G)<= br> > can act as delegating router and delegate prefixes, check RFC 6459. > Cameron describes a place where this is used in practice in RFC 7278.<= br>
But this involves the ISP, when the ISP need not be involved. A smar= tphone that has been assigned a /64 would have to either use IPv4, or beg t= he ISP for more prefixes (with consequences to IPv6 message routing), if it= wants to become a WiFI hotpot.

Why should it be easier, for a user, to create WiFi hotspots in IPv4 than i= t is in IPv6?


In my mail, I said, 3GPP network which= regulates smart phone's LTE interface, not an ISP network. I guess you= are talking about Wi-Fi interface.

Regards,
=

Behcet=C2=A0
Bert


--94eb2c1b4d9c407fea0551c82d8d-- From nobody Mon Jun 12 13:13:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1491294EE for ; Mon, 12 Jun 2017 13:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U-iF6tjYxuL for ; Mon, 12 Jun 2017 13:13:19 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 D3F5E129649 for ; Mon, 12 Jun 2017 13:13:19 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id l89so55981043pfi.2 for ; Mon, 12 Jun 2017 13:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SB+U1ss8XL29yYZf+Uvv06i+WEgdbDCr9NC6+6bEFTU=; b=nCckXkXrwJX5qwG6dG179Hch/nAZv46qxxf71zrkEakHJE+sPfssTk9ILF+ichk/TN 2HgEOIPofzv0j8V2sCy/2VdLg+DpbVvYjQUEigfYyMNW5t253FUrHTkluxpFU479jptL kikZb+7xZurbCKV5P6hcObiqAlytewL+I9aLzHfwHFwpozr1nBR5soudxrcXC8+OjZZE +4+dpq1rBYBSNZN1QICb7cGLN0z9jpbBBjSYM/HMaw8sKuBwtelogm8kuMgXsMW2JL8u 6hPAVxV7t11oeQno2Jhaf9S27QFwUy7d+nlJVJzEsujZbX2dGTVv2dtxhK9FaXPNOKtP r9lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SB+U1ss8XL29yYZf+Uvv06i+WEgdbDCr9NC6+6bEFTU=; b=f/GrDfL5oax1iKoW+2FuLOx8YSJ3Nmaa8UtLWT5N2ZqjR9joWTBUgMLJqTdVXNBrc7 /2aN8XfYiaKPPgFp0hbGrbcve9XynEE87N6xEFsr/78CTqwnXQffDVLiDt0ZTH+Lvt1y e1O9AnEMeuvOLjGS+ph4ak5BdpG77u0A8v4mFlo08rY8FjIS12MQm6hD5W67ykKC1Ecb xtThAa1OnWMhAxsVWJKydBnFfyZyTuyRs+/ob0hiOW9e9kaEL3hmjcXg4PiFSzpWSpQR ZBH+Z5u0mj6VaAO3T9txH8xd6Mk7/gLrfSpy4Lvy35l5u2ZUEnFHPkke4jhS+2AXTMVU Er8w== X-Gm-Message-State: AODbwcB06InyfT79NAHD51S7de1Vni80U+wBwiXN+xuzD4KM+7yUAiag 8j6cuaHz31Gu2g== X-Received: by 10.84.129.99 with SMTP id 90mr48550501plb.62.1497298399447; Mon, 12 Jun 2017 13:13:19 -0700 (PDT) Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id l3sm10703353pfk.34.2017.06.12.13.13.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 13:13:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land From: Fred Baker In-Reply-To: <450A257A-CBF2-419C-AD27-B72B0F2CEA6F@google.com> Date: Mon, 12 Jun 2017 13:13:17 -0700 Cc: IETF IPv6 Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <88B2DD15-67D1-4EDF-9D82-DF4FE3C51FEC@gmail.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <450A257A-CBF2-419C-AD27-B72B0F2CEA6F@google.com> To: james woodyatt X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:13:21 -0000 > On Jun 12, 2017, at 10:47 AM, james woodyatt wrote: >=20 > Home networks are designed using ad-hoc methodologies by people = without any understanding or skill in network operations. >=20 >> As Brian points out, these operators may have different needs. >=20 > For one very crucial category of network, calling the people who build = them =E2=80=9Coperators=E2=80=9D is an abuse of the technical language. You might benefit from reading = https://medium.com/@SeanBlanda/the-other-side-is-not-dumb-2670c1294063. = I would actually recommend it to each of us.= From nobody Mon Jun 12 13:17:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEFB1296B0 for ; Mon, 12 Jun 2017 13:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRP6ebNrYCnn for ; Mon, 12 Jun 2017 13:17:45 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B06129649 for ; Mon, 12 Jun 2017 13:17:45 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 15so28449045pfc.1 for ; Mon, 12 Jun 2017 13:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7tHUhNLp69WqNT9x9kACDh+deEZgpkspuTr3eKPTwPQ=; b=UUMf0tqs4lchA9z9IJFfSCp0/YhCoLJDDeYGfcbG+dqgV78sOY5lM47LzOtkF5YbuJ ghe4fRHhf8q6HmoO3DDaPoANhPaG/MltPQsqlWs9u9W8XKGzAUaGTucksFnSGFpvwBNi PrV8RJIiGbuHjWBJa2cW+EZ85WTRZyNLF8gq1vT7Jv6/RoYm9pMc5K7SPMFHpmVB3PJW HbIXZcDuX2CSXF09GGUgq/D7G0MuY5guyVYL0JkzKTAV4/lEHnMcnKlaOk19RbrPzYWF ZJhwk4uvvVNowtd5QNW7qM+zhc8H0hpAZ1Rh5B/9OHfUojTb/CmuSDL2SGH5ZZkuq9Kc +cNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7tHUhNLp69WqNT9x9kACDh+deEZgpkspuTr3eKPTwPQ=; b=KcuT2YSglBAu1B5qJf6/6PstPnTEhrkn2OzTdROySRNYSJ8KXwGIa/X/ULkR6h2YHv xRoW6ARUbNqNjvRJ35BJVyJIVkHZ1aVTO1RpLUlNFzv0LtacJevFI9gifgRzql9RjgSx nyB0hjRPfkzUXb7ci1l4rcJxbQLbuaQDYAH3d+3SL00LhIebLb5f05ljETOi+mB2QJ8A eCq2hqmFDPqKgsM7nUa48tE5hKLNMKfEeoRFvmbVdA9B6WeCfXBU9B0uUnxBTcOFv9vi un0zqe+VwyCHPwaQRFqmJEP5f6ihDpbMJT7+y3v57q7fEP/GLcxM9Os8MIQkYdRmSjp4 Pqzw== X-Gm-Message-State: AODbwcA6xE2Yp4EG22viJhNjhCm+XIIKv/JrmMXnwkpkUZ9moKPK0AAS auQ8CsmTLjvourh7pKI= X-Received: by 10.98.178.79 with SMTP id x76mr31775068pfe.74.1497298665209; Mon, 12 Jun 2017 13:17:45 -0700 (PDT) Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id 204sm15531129pfu.23.2017.06.12.13.17.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 13:17:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Fred Baker In-Reply-To: Date: Mon, 12 Jun 2017 13:17:42 -0700 Cc: David Farmer , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <63D8F7F8-7333-4EBE-9373-A1DFA20DEEB6@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:17:47 -0000 > On Jun 12, 2017, at 10:53 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > The IID length would still be defined by the > link-type specification, and since that should be consistent with the > addressing architecture, it *must* be 64 bits in practice. There I disagree, and if I were making a proposal, and if the link layer = address were to be relevant to it, my proposal would be that the IID be = the link layer address. In an 802.3 or 802.11 network, that is a 48 bit = value, in an 802.15.4 network it is 64 bits, and I imagine there are = other networks with still other link layer address formats. The only = reason to specify a universal IID length is for a universal algorithm = that has a specific requirement. The only one I know of is SLAAC.= From nobody Mon Jun 12 13:54:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308D8129A90 for ; Mon, 12 Jun 2017 13:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epoEIqLXAurN for ; Mon, 12 Jun 2017 13:54:00 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 4336B129AB0 for ; Mon, 12 Jun 2017 13:54:00 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w1so142404731qtg.2 for ; Mon, 12 Jun 2017 13:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DDgiG5bOO38Igs9T2YZ4BNcO3cZ9HESy5sPUGL9cd8k=; b=IDztw33gZN3lzh+Gulr5CObwI4ifen7tfE7UylLYZRqCw6kguIxGEoMEfbknlau/Qc jcngoSK0zJG43TGO4orPohGDonIhjIkPm4pXXIUMojFnSRDXNDRMlt6ylor4HVBQ3OIs b65K4+6LKFfbyBuvqtw1kEldF6Xq2vObAH8CqdPlbwH+lcvCe5jki9wkpAhFH8efIIya dmkr2W1sDvr/07X0Ckb8cuJLAAIlm7uTj71axDQ8hb5+hSBg/ij4KOIfxuJy5G0qUcIL +VBwWmWw5zA/dXEpsOYnBiQvWsBkFym8W5OnpOkLpQEXJ3DWMRI//5LY12mGvJs+u987 D2Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DDgiG5bOO38Igs9T2YZ4BNcO3cZ9HESy5sPUGL9cd8k=; b=DekwKeXT7x91ELtVDz2KGVDyU8zLEArx/96WxThBd4kIIa2n3BWB+qRfQgC4jguWEr woTU7c/A8i1+mVuIXkMKMOwJt1d4v4RTkIa/NLE7cM/5xBoZ1QVQrcUad2Z671tRqGHu LnsfgqbzbjW2DE1F8eB+JAX8KyJ2i4US/nCF05Awfk8NH9W6L80974V0dDN054bBQVKj Hc6psZX2IdcZy460Cyz1qOOodpxp0OKLV34K0Kdyo62RI38KUPiUxLhNynfR/vtaH0A+ 6yUtbqmrFD0yQEYNlOVWbCGLGn+ls4ejglZsaDUJwLS03rKCpVf5s/a3fqpVn0zWl88I sp5A== X-Gm-Message-State: AKS2vOztDqRyMg+LVerin13gvCtHOEmcPffyhVQ/Ev3t1x50e/irrAxv kxss6jzuD0zox1NPD2o470Jpca6pGw== X-Received: by 10.237.37.169 with SMTP id x38mr45269559qtc.133.1497300839360; Mon, 12 Jun 2017 13:53:59 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Mon, 12 Jun 2017 13:53:58 -0700 (PDT) In-Reply-To: <63D8F7F8-7333-4EBE-9373-A1DFA20DEEB6@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> <63D8F7F8-7333-4EBE-9373-A1DFA20DEEB6@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 12 Jun 2017 13:53:58 -0700 X-Google-Sender-Auth: BOFVa-moTsrH_VFPEneBKCT6X3k Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fred Baker Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:54:02 -0000 At Mon, 12 Jun 2017 13:17:42 -0700, Fred Baker wrote: > > The IID length would still be defined by the > > link-type specification, and since that should be consistent with the > > addressing architecture, it *must* be 64 bits in practice. > > There I disagree, and if I were making a proposal, and if the link > layer address were to be relevant to it, my proposal would be that > the IID be the link layer address. In an 802.3 or 802.11 network, > that is a 48 bit value, in an 802.15.4 network it is 64 bits, and I > imagine there are other networks with still other link layer address > formats. The only reason to specify a universal IID length is for a > universal algorithm that has a specific requirement. The only one I > know of is SLAAC. I'm not sure on which point you disagree with me, but what I tried to say is that it's a logical consequence of the current specification (not my opinion on how we should design it). - For SLAAC, RFC4862 assumes that the IID length is defined in a link-type doc and it's consistent with the addressing architecture - The current addressing architecture spec (indirectly) says that IID length is 64-bit for all unicast addresses except those starting with binary 000 (i.e., for all global unicast addresses used in production in practice). There is no possibility than a 64-bit IID that meet these conditions. I understand some people think that it has never made sense or at least it doesn't make sense today anymore. I have no problem with having a discussion on updating the current specifications from that view. But it's still an update to the current specification. We can disagree on what current specs say and update it if we reach consensus as such, but we cannot change the fact that the current specs have said it. Or perhaps you meant when we consider addresses configured manually or using DHCPv6, the first point is not applicable and the IID length doesn't have to be defined by the link-type spec? If so, I see the point, but in that case we should more emphasize that IID or its length doesn't matter, IMO. Only on-link prefixes and the full 128-bit IPv6 addresses matter for actual host behavior, and they are irrelevant to the concept of IID. We could still say the IID in this case is the right-most bits of the address following the on-link prefix (whose length can be different from 64 bits), but I don't see a point in that artificial definition. -- JINMEI, Tatuya From nobody Mon Jun 12 14:08:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7712025C for ; Mon, 12 Jun 2017 14:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUs_jbPwdlFE for ; Mon, 12 Jun 2017 14:08:41 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92591296CF for ; Mon, 12 Jun 2017 14:08:40 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id l89so56596138pfi.2 for ; Mon, 12 Jun 2017 14:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kQVc75dbWWgRGRtX1wJmBBRv1yhFNSLRdZi9dOKphIw=; b=q/Jok03VAar1kdPt8JzOsyzfeerTiO8iQBTTKz97Lq58DtnyqHBkq7xjdH95OhWVKh XK2Z9s3D3rjDPyPLMWAd9wYgRAeMJbf/f6amTIoORp2l29WKpVrFfzglP0as44ZU3pLr gzhIP/+gq/TfwGWSTrZgv3Fthf22NmsCcnO7jVJElv5wpW3EQzndfkfv7/I4CMh6fKyr qg6RhvR5enuKOhnCpS/NicU7tMwztCLjYAz0SJ+UYJMTWDJQfI182t9Q5A7iuAcHsSPJ oum3N6uHYxpgCgU1uqechqSbV/4t6f20OrJ4bwlhhJWHO7G45ec7hrevyiZ7q7GJrS9N 71uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=kQVc75dbWWgRGRtX1wJmBBRv1yhFNSLRdZi9dOKphIw=; b=oKiVuJy9Jw9yhDEOcVAFLNUWG5L6P9WF51nnrMYAJp2CsnPdFfu1SMAWnWD/lqzbA9 cSYasjCtgdiTTVM8u0OkasHS+SuUv+MoynqD8brtwrPZQtsuRD7FGde2CxSp/UixGXMv CdM0n5XZIcbfohc+SwxKRiBh90gqf+QrmZFKyOu6wR5Umhn9WBbHWpEA4AqGZyHC3AEV NfR2BUTovuB+OKweUb+wseT2UGJ9Hm7G4McGO+FQooPQ8uYqV7BHizwCdRuk9CRffmkf s4m4D33eEpew4jYfzd1rORcUx4JtapdABeAvaXXkdj5ydrwh/J4o5B0+lNhHWuH9sNhK U9Xw== X-Gm-Message-State: AODbwcA10BS83UsHrO5PXqmsI9qI8PgtsXbyPhTSOfcMSEK0bsmq2hjW fv/XwI1btCU22ZNR X-Received: by 10.99.104.136 with SMTP id d130mr36089104pgc.236.1497301720267; Mon, 12 Jun 2017 14:08:40 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g23sm20813484pfj.131.2017.06.12.14.08.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 14:08:39 -0700 (PDT) Subject: Re: Tussles in IPv6 Land To: james woodyatt , IETF IPv6 Mailing List References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <450A257A-CBF2-419C-AD27-B72B0F2CEA6F@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <16bcd06e-ced9-1e3e-5cae-5ec0e48904bd@gmail.com> Date: Tue, 13 Jun 2017 09:08:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <450A257A-CBF2-419C-AD27-B72B0F2CEA6F@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:08:43 -0000 On 13/06/2017 05:47, james woodyatt wrote: > On Jun 12, 2017, at 10:22, Lee Howard wrote: >>> >>> Brian, please don't forget that networks are built to serve customers= , not operators. >> >> >> What networks? >> >> Enterprise operators build networks to do business.=20 >> Mobile network operators build networks to serve people using mobile d= evices. >> Residential access providers build networks to serve people at home. >> Community network operators build networks to serve the community. >> Universities build networks to enable students and faculty to do resea= rch, and also to attract students to the university. >> Content delivery network operators build networks to serve companies. >> Transit network operators build networks to transit and connect other = networks. >=20 > Home networks are designed using ad-hoc methodologies by people without= any understanding or skill in network operations. >=20 >> As Brian points out, these operators may have different needs. >=20 > For one very crucial category of network, calling the people who build = them =E2=80=9Coperators=E2=80=9D is an abuse of the technical language. True. In SOHO networks we need everything to happen under the covers, and= the users will not have the slightest interest in subnet sizes or interface identif= ier lengths. As far as I can tell, HNCP only treats /64 as a default, so it's already = set up for future flexibility. So while I agree with your (James's) comment, I t= hink it actually strengthens the argument that Lee was making. And so we've morphed this thred into another thread about /64... Brian From nobody Mon Jun 12 17:17:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409AB126CB6 for ; Mon, 12 Jun 2017 17:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztUPLJiubObA for ; Mon, 12 Jun 2017 17:17:18 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A9F129407 for ; Mon, 12 Jun 2017 17:17:18 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 83so58507416pfr.0 for ; Mon, 12 Jun 2017 17:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qxNpoe3pTK2YS1qPOkPweREjrIi/3Uf+8b6XkmG2NrY=; b=s06XQQLw5gSr2QIMyeaZgS/+TZTcg/Vrx9ekeqSOUb6nMByRppe2T4bPpd1PIbrEGv XEi0WVuq9fRiYvAyzv7YVUYbxDPZRT3rH7n8dRszo6O1qqF62WpoFJyz+UNW9+0CIZkT Olab0GFFLJS+f7ngvelFDqWe5iVWTpecVb4eOOiYUSVGPXKN7g6UGROrza8LuH/cF3Sv bWCfUwElkC4ioKZE/OHCVch8kdW16oGDMijJZn4LDuiFZ8sOUJbAVblSF9RK3DaA4pUH AZHvscQYEFtICv1rC0MHu55PMYmlXa/V7C5StCyAb+DT6TGhOOh1mxQCYASaVornSwi1 D6ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qxNpoe3pTK2YS1qPOkPweREjrIi/3Uf+8b6XkmG2NrY=; b=hbzma20Va/4CvgPqVdlydif+VYt8GuoOWZiMR9OPljhMzjSTH18uJvVV0YlHNCoTPL eAiZxQvccGKQBvYrPRIVcp2OqwKPQfgaxtbdgtWcuTecVMyETLDxdbhUqsCjX2AE3ZiA jnxkMqEtl2q1/UGBGjgsQ/m1ON1EmT4Lcf+02aKjULGo2KLP1PmB+Cd4T0IC1lZ655Dv TyqPM1oqqbpMcr8N4GS3FDwiqDCISx1rbYOasRGFZ/18i4xIKg4lr5I3YQcng4R8SZ14 StCTf80d2iAUBu1XqPfyp2COdS2NZfddIL107OuKGU+vVzmC1HIUY0W9G1Co8obGjVNL nDYg== X-Gm-Message-State: AODbwcC3c/wQ9Gt1aCOOL824GSe+KhOzGIc/ZYtcq0v3MlubCyAmnE9P 0xs8mav1w28kfRzW2g6QUA== X-Received: by 10.99.123.4 with SMTP id w4mr18260327pgc.188.1497313038063; Mon, 12 Jun 2017 17:17:18 -0700 (PDT) Received: from ?IPv6:2001:5a8:4:2290:7ccb:780d:5725:4460? ([2001:5a8:4:2290:7ccb:780d:5725:4460]) by smtp.gmail.com with ESMTPSA id f22sm22716782pfk.104.2017.06.12.17.17.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 17:17:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land From: james woodyatt In-Reply-To: <16bcd06e-ced9-1e3e-5cae-5ec0e48904bd@gmail.com> Date: Mon, 12 Jun 2017 17:17:16 -0700 Cc: IETF IPv6 Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <021D6FEA-A08E-4CC3-8B25-C935087750F2@google.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <450A257A-CBF2-419C-AD27-B72B0F2CEA6F@google.com> <16bcd06e-ced9-1e3e-5cae-5ec0e48904bd@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 00:17:20 -0000 On Jun 12, 2017, at 14:08, Brian E Carpenter = wrote: >=20 > And so we've morphed this thred into another thread about /64... I=E2=80=99d rather not. My point is complementary to Lorenzo=E2=80=99s = point in <16bcd06e-ced9-1e3e-5cae-5ec0e48904bd@gmail.com>, where he = implored the group to remember that the other side of the tussle = involving operators and their needs to manage their networks, i.e. the = network engineers, is the side comprising the users of the network and = the designers of human interfaces for machines and applications that = communicate via the network, i.e. the host engineers. All three of the major tussles you mentioned in the message that kicked = off this thread involve tensions between these two groups with often = conflicting interests. It=E2=80=99s not just the /64 issue. The DNS server address configuration issue is contentious because = different human interface designers are concerned with different = problems than network engineers, and we therefore have two methods of = configuring host operating systems because operating systems are = designed by different developers with different objectives in mind. The = tussle between network engineers and host engineers here is about which = side must carry more of the burden of ensuring interoperability between = hosts and the network. Likewise, from my perspective (which is quite far away from the heat of = the action), the tussle between network engineers and host engineers = with regard to header insertion seems to revolve around the effect of = header insertion on path MTU discovery, which has implications for = network application design. I, for one, am skeptical about plans to = admit header insertion not because I have some commitment to theoretical = purity, but precisely because I=E2=80=99m concerned about ever, some = day, in our glorious future, having any kind of decent expectation that = path MTU can be resolved over the Internet with any reliability, because = that has serious implications for application design. The point I wanted to add over and beyond the one that Lorenzo was = making is that we are not all just network engineers here. Enumerating a = list of all the possible types of network operator and putting forward = the view that all the important tussles in IPv6 Land are between = operators of different kinds of networks, neatly and conveniently erases = a whole other class of people with networks for which there are no = operators at all, a class of people who number orders of magnitude more = than the operators, and who have a stake in the tussle represented by a = whole other category of engineer, the host engineers, whose interests = diverge more significantly from the interests shared among all the = disparate subclasses of network engineer. Maybe erasing them from the discussion was an accident, and my point was = to try to correct what I hoped was merely an oversight and not an active = deliberate effort to shut them out. --james woodyatt From nobody Mon Jun 12 18:27:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D19129AE7 for ; Mon, 12 Jun 2017 18:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4oR-t3a7RG1 for ; Mon, 12 Jun 2017 18:27:03 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD0D129ADA for ; Mon, 12 Jun 2017 18:27:03 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 83so59202682pfr.0 for ; Mon, 12 Jun 2017 18:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jM1VWa/hEMyJARaNxoQNTPaZ4rJHJS+4T+SuDMdlsyc=; b=CSw2fNY96o3Rtyh4y6zmzB4kThhcoiECab1hjEIZUjKzX1r5WeWS8PPPWnV4p4Xafh BbxalqOWw76H1QTk/UQ6iEwii1l4luW6GZ47hNljycyNVx3LH8Ks/5hYU7ykVHWDUj2H KDG/vTB6Wl1ABJveS97pMWX0N7ij0tZCZ0TMjexhgcdupMJAhbwGnY/GfTwUP4QiziRg YHNE9SW3BUPUsLtGOb1Q2iMivsBdVB+UyyRTu1Io5RLfbbuPbyJMc/VXEiK7N9+AAqze sFABlcYFuKhMDYvo+aZMFiq2JE4/z+dLqYgQ8NXuoMvw04Pxo8dCRk2goRWza+KSE1Y+ GK4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jM1VWa/hEMyJARaNxoQNTPaZ4rJHJS+4T+SuDMdlsyc=; b=ojCaPHJQHzFJE6whBstG5lOXb3KXzCCXRmoEQqNGh2JqtGEUbtQOfIzaJFSTHOAEtI M6CyjTKM4vR/FzAhpOM8ybz+ux75vY6YL6NuTMnVNBbZAn/NZ6QmBmmWGoaAjg+Hso/E 0/7KNUVAwV/3ZtrAII5cpNP/ghK/ViNgcNXfYuS942rPvAVJvmKPYojxuC3l3OTpaAIk XjilxJtPdO9k68GjJTrJCq0ZT6SA+re3pJwUSMdK84UDSkf0097eBls3+JiFcfqGl3jf MlvcKWQihFvfY9TdTT5DnIolA4LZUX8Ffzo4dozVA2ZcNaiJXy9lGGypMZtau9Fyef0d /spw== X-Gm-Message-State: AODbwcBdd1expucupC7TMBMxYTpYMEZOvC+dzoHqe/pAeMjDJTbMw6Xt t0DWe8oTNdoDvvBW X-Received: by 10.84.238.201 with SMTP id l9mr58450521pln.153.1497317222541; Mon, 12 Jun 2017 18:27:02 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 67sm20662645pfn.84.2017.06.12.18.26.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 18:27:01 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont , otroan@employees.org Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> Date: Tue, 13 Jun 2017 13:26:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 01:27:05 -0000 Fernando, On 12/06/2017 12:47, Fernando Gont wrote: > On 06/11/2017 02:51 AM, Brian E Carpenter wrote: > [...] >>>> d) There is no physical reason for n to have the same value on different link media. >>> >>> There is no technical reason why IID length is tied to the datalink type. >> >> I believe there is: so that SLAAC can work with devices out of the box, without >> having to set the IID length. > > Not sure I follow. > > Router advertised Prefix/N (where N is nowadays hardcoded to be "64", > but need not). Host eploys RFC7217, and grabs 128-N random bits from F() > to generate the IID/address. > > Why does N need to be set on a per-link-type basis? It doesn't *need* to be. But SLAAC by design assumes that it is set per link-type; that is architectural flexibility which is removed by RFC4291, which IMHO is a bad message to send to the future. I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis back to us, and the main reason I signed on to draft-bourbaki-6man-classless-ipv6 > > > >>> There was at some point when we thought it was a good idea to embed L2 addresses in the network layer address. >>> Even so, it would be trivial to make implementations deal with arbitrary IID lengths. >>> >>>> e) Future link media might more appropriately use a different value. >>> >>> See above. has very little to do with data-linkt type. >> >> That's correct. By dropping modified EUI-64 we have removed a >> noticeable dependency. But who's to say there won't be a future >> link type whose deployment scenario is better suited by, say, >> 80 bit prefixes and 48 bit IIDs? I have no idea about that. > > Well, on such links the local router would advertise a /80 rather than a > /64. Why should the clients need to worry about this? Because SLAAC wouldn't work, because the addressing architecture forbids SLAAC from working in this case. > > > >>>> f) Therefore the addressing architecture should only define n=64 as a default >>>> recommendation for IPv6-over-foo documents. >>> >>> I don't think that follows from the arguments laid out above. >>> We can (if we want to), make SLAAC work with any IID length. Including 0. >>> >>> I still don't understand what the goal is here. What problem are you solving? What is the proposal? >> >> Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do. > > +1 Well actually, my statement was wrong. rfc4291bis needs a s/required/recommended/ to remove the inflexibility. Brian From nobody Mon Jun 12 18:28:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB0129AF3 for ; Mon, 12 Jun 2017 18:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4IwDR7I_Xi0 for ; Mon, 12 Jun 2017 18:28:06 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6D7129AE9 for ; Mon, 12 Jun 2017 18:28:06 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id f185so52604950pgc.0 for ; Mon, 12 Jun 2017 18:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=B67imV4HSh4Xf6s9BMImxRhMZuDhEFqnvZyTV9KKfn0=; b=o296FCwrExcsS9R7adJkr1J6SRyJFj61sXYstukmDszn4n51uNx8eXGemTPmwTsWgP T59TEOLhwhDIG27x0ab0IASKjNQejiLhdwexhT+fci/kWmbw4J8Av+JjNLCmZyxUPGhQ sh8Oe8e9Af7caCLRHnwRw4b+dfzmhskjBGwzZfdNs65jWxuLdZVj9mfX8o5OWp4eyiHy 7PmcIg8GPC2pXl3eytNOvD2xQSqrUxail8AwGM8Dh+AlDvjSbSmrL8/fXewoE9GHX5EF 9dSPbbul2UiHbhPMmRpMfWWWve5HvMG50HYJXXdheof/PPw/XCLIOP0q1k1+yvMLLKUH yU/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=B67imV4HSh4Xf6s9BMImxRhMZuDhEFqnvZyTV9KKfn0=; b=OMycd+eI9Y2iNWJX94Bciw09YmduoOlU/2079MNMnFMP7F+pi+dpS9LJB9hQcmLKb3 9aBHhK3TX1qQkaEr4nIkF4PKCucxDjke2FL70KfZIaZe22bZ5MBb9a8CtNShZ0NdRnyk K1i89EtumeXbE+2CTg+3ESppOF2VqrL1bWgOTIUXkpJWAWbjLZw99ldzthfpGJ4DeGnq fLbBYhwFcScv3BmURsU1KUDagnBgrNEyIWZ/d+mHrs1Ujog8fFdMb6jah8ubcuJsmf+V DT3SkJuZpVNFvX0GWofKPb4x1Z26F69xL1yuPh3NZ3jG0HqemJcp+tq9MH/fjIlVntqF doNg== X-Gm-Message-State: AODbwcA/sWpoIvEYN/kINbvzEk/flQvjasOdYV42ZsU47MF1ZUHFPJf6 ph8K0SCRY8UTVhy9 X-Received: by 10.99.99.65 with SMTP id x62mr31668983pgb.211.1497317286026; Mon, 12 Jun 2017 18:28:06 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j22sm6475975pfj.56.2017.06.12.18.28.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 18:28:05 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont , "Manfredi, Albert E" Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <69a56022-98fa-6ff9-add9-0345410ec171@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 13 Jun 2017 13:28:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <69a56022-98fa-6ff9-add9-0345410ec171@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 01:28:08 -0000 On 12/06/2017 12:55, Fernando Gont wrote: > On 06/11/2017 04:46 AM, Brian E Carpenter wrote: >> On 11/06/2017 12:00, Manfredi, Albert E wrote: >>> -----Original Message----- From: ipv6 >>> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >>> >>>>> If we remove the 64 bit boundary from 4291, then an update of >>>>> 2464 will likely result in the removal of any bit boundary >>>>> there as well. >>>> >>>> No, for the out-of-the-box reason. I can't see any practical >>>> alternative to a fixed length per link type. >>> >>> I think there are practical alternatives, so I too would suggest >>> not to state flatly that SLAAC requires fixed length IIDs. Anything >>> that requires RAs to work can make adjustments to its IID, in real >>> time. >> >> It cannot adjust its IID length when assigning itself a link-local >> address *before* receiving any RA/PIO messages. > > link-local could be considered a special case... Maybe, but that isn't how RFC4862 is written today. Brian From nobody Mon Jun 12 18:35:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC49612947C for ; Mon, 12 Jun 2017 18:35:23 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AKwJmJf_P7r for ; Mon, 12 Jun 2017 18:35:21 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 D74AA129479 for ; Mon, 12 Jun 2017 18:35:21 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id k71so52642094pgd.2 for ; Mon, 12 Jun 2017 18:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KxYHUwZjLdBqyy9PaVQaXQv9V8j+lHsExfUb0ClYlXE=; b=gPHRImmzt7JatfnnZFPKHy0NdnrgQLFALlTQONqB4bVmLyDdsTSP1tikiyfxzwawD1 lFfJr29UvwJj0JHHgtBBcBOh8a/d2wSRFU/Q2I6Jxeai09sgQXMzH9thrtVyRj0kUjGY 7XjkxuKpbxcTuCI0SfwT1Lkh1kNJk53MmL6qfBtzhpRKaWhf224xdx2y1lPGtIIbmWld byZb9dXZ1gzkAgBTQa9lozedVTh7TZNRd8ZqXrx2IFmxnz+zffOtxCurUs3CHpUqfT4G hzaiyzaFVkX6V+gsg7fRyJQS7o9WpHA3PLX6LRARIeaaeDQpcNWhuRs2dHa3257Rgn5J QhQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KxYHUwZjLdBqyy9PaVQaXQv9V8j+lHsExfUb0ClYlXE=; b=OejfKRgPkln1kKw4GYOOSh5prZ6AUxlCz3b7J88J5BFecLqJQZ350gHonS5Rda8jdy rNgQ0cgv/XO7g4g5cAW3g03ox9dkCopUwp98+QZjtTR0bN/H1Q5xmiFxlauH86Tc8+DR YEl/reX7Gt8jAFlsuQnIsKNliw4VSDNPyTa+YSByHXmUjGZft2oQRDvkSByMl5BdQo8U uNSEgISYCv+fD8l5JEHQTdWCssHFDTrImmyI4yGq/w57XYsrrLQM2/mJZbfBChF5sgIt gRXv/i87BiMw8oiYDr93AAD1ZYV+/B7sUj7C6RXT9iRWJxFGv1L2OzjUQsTSfVFhwQUU gM3g== X-Gm-Message-State: AODbwcCOCltyqaPDSI5M1psq9fZVhu4l2NVpPS269ZnXlRDqGNghvzyM hrEe66Qkn48iyv9m X-Received: by 10.84.217.152 with SMTP id p24mr59386492pli.206.1497317721245; Mon, 12 Jun 2017 18:35:21 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h71sm11865617pfk.126.2017.06.12.18.35.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 18:35:20 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont , otroan@employees.org Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> Date: Tue, 13 Jun 2017 13:35:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 01:35:23 -0000 On 12/06/2017 13:00, Fernando Gont wrote: > On 06/11/2017 09:29 PM, otroan@employees.org wrote: >> Brian, >> >>>>>> If we remove the 64 bit boundary from 4291, then an update of 2464 >>>>>> will likely result in the removal of any bit boundary there as well. >>>>> >>>>> No, for the out-of-the-box reason. I can't see any practical >>>>> alternative to a fixed length per link type. >>>> >>>> I think there are practical alternatives, so I too would suggest not to state flatly that SLAAC requires fixed length IIDs. Anything that requires RAs to work can make adjustments to its IID, in real time. >>> >>> It cannot adjust its IID length when assigning itself a link-local address *before* >>> receiving any RA/PIO messages. But whatever length N of IID it uses to generate its >>> LL address must match the the prefix length 128-N in a later RA/PIO with A=1. >>> Otherwise, SLAAC fails. >>> >>> (see Section 5.5.3 bullet d of RFC4862, as Jinmei-san kindly explained to me.) >>> >>> So in fact the only thing that works is if the equipment assumes the same IID length >>> as the router announces (as 128-N). Therefore, N must be predefined. >> >> As I said the argument is tenuous. >> This is a trivial change, if we were to go down this route. The fixed constant is a fundamental part of the IPv6 architecture. If we remove it from there, then it is a natural consequence to remove it from the IPv6 over foo documents and tweak SLAAC. >> >> The changes to SLAAC could be in two paragraphs: >> - LL generation. Fix IID length to 118 _or_ make IID length implementation specific. >> The on-link prefix for LL is regardless fe80::/10. > > In practice, it's /64. BSDs assume fe80::/64, and use some of the > assummed-to-be-zero words in that prefix to store e.g. interface index. > > >> - IID length = 128 - length of advertised prefix. Host is required to generate IID of suitable length per advertised prefix. >> (or just generate a 128 bit IID, and chop of the bits needed. >> >> >> To summarize: >> - There is no technical reason why SLAAC cannot be made ot work with arbitrary prefix lengths. >> (including very long prefixes, although it might take a while to find a non-duplicate if the addressing model >> moves from sparse to dense). > > +1 > > >> - There is no technical reason to have a fixed IID length defined by data-link type. > > +1 > > >> - Removing the constant from the addressing architecture will likely set these changes into motion. >> (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary >> to stay in IPv6 over foo is tenable.) > > Me, I don't think there's a reason to keep the 64 bit constant in > ipv6-over-foo documents. Actually, with RFC8064 in place, there's no > reason why the IID should be link-type dependent. I believe that is simply false unless you want to go back to the era of DIP switches with instructions to users to a) choose an IID length for their new subnet b) set the DIP switches on every device to select that length c) then plug and play. Otherwise LL addresses cannot be formed consistently on the whole link. OK, that is caricature, but without a substantial reworking of RFC4862 I believe that is essentially what we would need, in an automated version, before SLAAC can start. Anway, all this is empty talk as long as the addressing architecture *requires* 64 bits rather than *recommending* 64 bits. Brian From nobody Mon Jun 12 19:22:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AA2129480 for ; Mon, 12 Jun 2017 19:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPeoqTxofCo4 for ; Mon, 12 Jun 2017 19:22:13 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021E5128D3E for ; Mon, 12 Jun 2017 19:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5D2MBYe059652; Mon, 12 Jun 2017 19:22:12 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5D2M6eN059548 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 12 Jun 2017 19:22:06 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 19:22:05 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 19:22:05 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAARhCgIAAbSKAgAGcDQD//5E4sA== Date: Tue, 13 Jun 2017 02:22:04 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> In-Reply-To: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 02:22:15 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> there's no reason why the IID should be link-type dependent. > > I believe that is simply false unless you want to go back to the > era of DIP switches with instructions to users to > a) choose an IID length for their new subnet > b) set the DIP switches on every device to select that length > c) then plug and play. > > Otherwise LL addresses cannot be formed consistently on the > whole link. Why so, Brian? I've already described one easy technique: the host can crea= te IIDs of any length, based on an algorithm that we might just be debating= for a long time, but fundamentally can be quite straightforward. And then = the host chooses the correct IID to use for SLAAC, based on the RA it just = received. > OK, that is caricature, but without a substantial reworking of > RFC4862 I believe that is essentially what we would need, in > an automated version, before SLAAC can start. 1. Host can create, in real time, IIDs of length 128 to 0 bits. To do this,= for SLAAC, it SHOULD not be difficult IMO. One possibility: create random = 128-bit value, then use a simple truncation algorithm to reduce the number = of bits to the required value, at the appropriate time. 2. Host waits for RA. 3. Host determines prefix length after receiving RA, using the equation: IID length =3D 128 - prefix length 4. Host generates 128-bit SLAAC address. If we started with the 128-bit ran= dom number, just truncate as needed. 5. Perform DAD, as already prescribed. > Anway, all this is empty talk as long as the addressing > architecture *requires* 64 bits rather than *recommending* 64 > bits. True, but anything that *requires* something, based on a premise that has a= ll but been discarded, doesn't hold much credibility anymore. The fallout f= rom having deprecated that premise needs to be considered. A better future = can result, as in this case (IMO). I think there's something in philosophy = that addresses just this sort of situation. Where the general consensus of = an argument can change 180 degrees, if more information on the underlying p= remises is presented. Bert From nobody Mon Jun 12 19:30:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89BE12949B for ; Mon, 12 Jun 2017 19:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiv8e63kcy2u for ; Mon, 12 Jun 2017 19:30:48 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A228E128D3E for ; Mon, 12 Jun 2017 19:30:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5D2UmmT004662; Mon, 12 Jun 2017 19:30:48 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5D2Uc2L004539 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 12 Jun 2017 19:30:38 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (137.136.239.220) by XCH15-06-09.nw.nos.boeing.com (137.136.239.172) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 19:30:37 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 19:30:37 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAARhCgIAAbSKAgAGcDQD//5E4sIAAB9HQ Date: Tue, 13 Jun 2017 02:30:37 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 02:30:50 -0000 I should add, The IID length used by all SLAAC hosts on a link would be the same, because= presumably, they all receive the same RAs. With the same RAs, their IIDs w= ould have to come out to be the same length. And, most of this change doesn't even apply to RFC 4862. For the most part,= it applies to RFC 2464-bis. The main points of RFC 4862 remain the same. Bert From nobody Mon Jun 12 20:38:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D834D129B1D for ; Mon, 12 Jun 2017 20:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTleR_uebS2V for ; Mon, 12 Jun 2017 20:38:41 -0700 (PDT) Received: from smtp-6-48.vip.sina.com.cn (r3-67.sinamail.sina.com.cn [202.108.3.67]) by ietfa.amsl.com (Postfix) with SMTP id 9D0D1129B18 for ; Mon, 12 Jun 2017 20:38:39 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.255.40.2]) by vip.sina.com with ESMTP 13 Jun 2017 11:38:34 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 28117065620 Message-ID: From: "weigengyu" To: "Manfredi, Albert E" , "Brian E Carpenter" Cc: "6man WG" References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> In-Reply-To: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Tue, 13 Jun 2017 11:38:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 03:38:44 -0000 Hi, The flexibility of IID length will bring some benefits. But, is there any compatible issues to concern? For example, if two networks are assigned with two length IID in office and at home, the host, such as mobile phone, pad or note PC must adapt to the different IID lengths. Is it practical or available nowadays to have such adaptabilities. Is it a required to have a default IID length, eg. /64 for the local link? Should the default length be supported? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Manfredi, Albert E Sent: Tuesday, June 13, 2017 10:30 AM To: Brian E Carpenter Cc: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 I should add, The IID length used by all SLAAC hosts on a link would be the same, because presumably, they all receive the same RAs. With the same RAs, their IIDs would have to come out to be the same length. And, most of this change doesn't even apply to RFC 4862. For the most part, it applies to RFC 2464-bis. The main points of RFC 4862 remain the same. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Mon Jun 12 22:09:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C457129557 for ; Mon, 12 Jun 2017 22:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whfMdAr9-pjy for ; Mon, 12 Jun 2017 22:09:08 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517601294C4 for ; Mon, 12 Jun 2017 22:09:08 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 83so61652255pfr.0 for ; Mon, 12 Jun 2017 22:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=J1syTwgCuqXEwr6DoQhBfUBEsdVuf9NDGJSY1C94+Lc=; b=j67zlfnwc503Sy3W2oCFs7eJ/Lxc7M4sDInTkbfk5QFNiLawhp0q9wzUOJSecfiun6 YqB9pUZKtFJ5gaaDjXnrfigse6nxuF1ivWSOjgpVRvxWx79ia+NhmvbOyXLhmx1NMtXg 1T26L3xzq65EplPK8oRfb+8jB5QI9lEO8kRYOpeARuuAXHqRGWLwewB67IRbjGBcimhs Tzlr3mhxcQORn9b5e5a5t6yXyvOKXZt52FdYwdmKzsP0j1OHnWcZgfmT4FSNE+CXUjVY jwD11jaNw++bqLlHeON2jPzRCZntTp1oL/zuAs9/HAcpbqQmTcQgA/72GQP+lroXf3Ok IqjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=J1syTwgCuqXEwr6DoQhBfUBEsdVuf9NDGJSY1C94+Lc=; b=sbvBlMiOxIcrpkKxnUe1LmcXcY78/lT7z7nnuaksSXWaaZBWgzTV3mV3NScjMtsrz8 vNvPK5OaMf+Mx7VeV68QkNiaFYK1avjuKAxBQbykJONnBqQDhYHB9XM1JzCoGvE0CG9z 5Hg5Jb6xaSGo8jvcMqI2OBfA2DalfcwQ+KyPQIY3hxBMv0f+44dEG7JvkP4wJSOU6Ew9 sCvlFxuAh8mD/poc5QmLpDnDcJTx+nxfyBH75qcJjdCM8uglua38bzj5eFS/MxskjXjM oY5dfHrbsi+cBxM8ZPE3xVx8qw5ccF4eIkXTsXaIEKDwAARYG3w+9dNdYKqXxQ6OIYfZ XJ8Q== X-Gm-Message-State: AODbwcDO6N1Xropm6dsdZYJKzT3BYN8ZG+MUQEMutckJyq9QKLIGeEn+ 8tpr/cMtL0X9kYzC X-Received: by 10.99.172.17 with SMTP id v17mr62049809pge.234.1497330547580; Mon, 12 Jun 2017 22:09:07 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t5sm20922607pgt.19.2017.06.12.22.09.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 22:09:06 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 13 Jun 2017 17:09:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 05:09:10 -0000 On 13/06/2017 14:30, Manfredi, Albert E wrote: > I should add, > > The IID length used by all SLAAC hosts on a link would be the same, because presumably, they all receive the same RAs. With the same RAs, their IIDs would have to come out to be the same length. > > And, most of this change doesn't even apply to RFC 4862. It applies to the fact that the IID length must be known before forming a LL address, and that it must be the same length as implied by a *later* RA/PIO with A=1. So actually I think there is quite some work to be done on RFC4862, and it isn't clear to me that it could be backwards-compatible. Also see Gengyu Wei's message: when devices roam, what happens if the LL IID length for a given interface is supposed to change? DIP switches again? I don't think we're going to see a different IID length for any link type that's already using 64 today; too many things would have to change. > For the most part, it applies to RFC 2464-bis. The main points of RFC 4862 remain the same. It doesn't matter. If it isn't backwards compatible with deployed code, IMHO it isn't going to happen on Ethernet or Wi-Fi. Brian From nobody Mon Jun 12 23:56:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A812957A for ; Mon, 12 Jun 2017 23:56:24 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZURhYJ-GrRd for ; Mon, 12 Jun 2017 23:56:22 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id EAB8F128896 for ; Mon, 12 Jun 2017 23:56:21 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2017 06:56:21 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 08CC9D788B; Mon, 12 Jun 2017 23:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=z16YAyMTLpL3HuYKhgm6THJPTeE=; b= c6wPfeIEkKRAYYMc5KlHwp5DGzRgdMJaEa3OSQOb0piyN5a2g6PPmLrnaGHl4cTu JmgkgQ0mLrD+UhRiquDZ4pKmpwwi4u1FOODlhEbWE1TYIp0WVCdJoBgUlcVrkB9Q ewCnUrjBE37XjuZY8ztjXcm8UnXEBw+ulzDXX61J25w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=aPxiJ6TMntJsxC2m2i046VN Pk+khKSVSdNfTa1JJ90hpXEObBAeb0dgy47s97KFwj01oA9NovYPLkCk55T365Fm w1nsqbn2csbId3rfXS39C7kBVNYVf22oKGCAsDXTpy7+GbB7Ckaan8r+t8oUaun9 l48Y2ofsvp2S8nxSYtZg= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 849CFD788A; Mon, 12 Jun 2017 23:56:20 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8B6CFD2BF40E; Tue, 13 Jun 2017 08:56:22 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_54A9D080-F533-44B2-B569-1747A02C3509"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Tue, 13 Jun 2017 08:56:21 +0200 In-Reply-To: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> Cc: Fernando Gont , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 06:56:24 -0000 --Apple-Mail=_54A9D080-F533-44B2-B569-1747A02C3509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >> Me, I don't think there's a reason to keep the 64 bit constant in >> ipv6-over-foo documents. Actually, with RFC8064 in place, there's no >> reason why the IID should be link-type dependent. >=20 > I believe that is simply false unless you want to go back to the era > of DIP switches with instructions to users to > a) choose an IID length for their new subnet > b) set the DIP switches on every device to select that length > c) then plug and play. That's a gross misrepresentation of what would happen. For the LL we would agree on a fixed IID length of 64 (could be 118). For addresses generated from PIO, the host will dynamically generate an = IID of length 128 - prefix length. > Otherwise LL addresses cannot be formed consistently on the > whole link. Trivial to solve. > OK, that is caricature, but without a substantial reworking of > RFC4862 I believe that is essentially what we would need, in > an automated version, before SLAAC can start. >=20 > Anway, all this is empty talk as long as the addressing architecture > *requires* 64 bits rather than *recommending* 64 bits. This is what _will_ happen as soon as we start chipping away at the = boundary by changing the addressing architecture from requires to = recommended. The last stand for the 64 bit boundary will then be interoperability. Ole --Apple-Mail=_54A9D080-F533-44B2-B569-1747A02C3509 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZP4yWAAoJEL7aWKiYQt922usP/ij56HRYnVtoSgBg7PBrhYjY rqDvYycGAvraGvuTPsD71wf5aPp4bCbcSfvgqyT0h+N+QbGS5wZXHxkWNKnhDtKG EJ2OzrMk0ZEr8yjvNWGGbY+P7JbPzamu2i35VkLhWGmrl0VNB7qNFlejKhkXqcgz bcFvr/trOlemyAk8n2pbI57jRkhDLIk3MWcUGWmiRwMaL1QZkbhFb+mBA4omQsMM ia3bY3kNFgeMBpDCYGbb0Si5Ql4rj9JaWtLI/ihFWZGMJFStBqTRcTsXUdSrosfp 2Vbn88oez66PMBylIJzfsgzycATiaU13/tUf/sDhIOyUJYyCUkCtGlzhQrUbBf3g ILu1Uz0whrFjEAHveHin6Nk+nBklwSMJdLhKYkN+xbAnMO+khF+1kQnglxcfCgKs N9nHapRiSWV3BBJ3zyKWmrnqtbsPdcL5oBCImTFMf6rMo1xWIULOG0GvXNLGSYX/ 0aeD4u06S6sZFfBIEDHL8/gxN9rxqWP7EvW6yvkMpJXU8Xb14AqJvcFIPtE061mU jg6UeP29R4/snaFOasNMSy/C8WeNLNGjr9ldBfiz24KVbPPm+NEFAVztlpIilBN2 bZsnZH/uWG6VsZxqny1yetLzgxM1TJF8FjYew0FThxpXrTN6BzCEHZz/Gs8zfyhs kqb1UwuEbFSNcYW/k0Kj =5LNC -----END PGP SIGNATURE----- --Apple-Mail=_54A9D080-F533-44B2-B569-1747A02C3509-- From nobody Tue Jun 13 00:51:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08F128CD5 for ; Tue, 13 Jun 2017 00:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhjxZfolxs-d for ; Tue, 13 Jun 2017 00:51:08 -0700 (PDT) Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD431289C3 for ; Tue, 13 Jun 2017 00:51:07 -0700 (PDT) Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 13 Jun 2017 09:51:01 +0200 Received: from olen.dhcp.nlogic.no (213.52.81.38) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 13 Jun 2017 09:50:59 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> From: Ola Thoresen Message-ID: <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> Date: Tue, 13 Jun 2017 09:51:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [213.52.81.38] X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 07:51:10 -0000 On 13. juni 2017 04:22, Manfredi, Albert E wrote: > Why so, Brian? I've already described one easy technique: the host can > create IIDs of any length, based on an algorithm that we might just be > debating for a long time, but fundamentally can be quite > straightforward. And then the host chooses the correct IID to use for > SLAAC, based on the RA it just received. Some people argue in the DNS "tussle" that it might be a problem if the host receives different DNS-info from eg. RAs and DHCP. And now we are discussing if the host should create its LL prefix length based on a variable in the RAs? What if multiple routers in a network announces different prefix lengths? This would cause MUCH greater problems than just getting an invalid DNS-server and would require much more work for the operators to keep consistent throughout a complex network. I can foresee scenarios here, where one router is deployed and announcing prefix-lengths of /80 for its public prefix. Then another router is added do the mix, that does not have the flexibility to change the prefix-length, so it will always use /64. Then the operator would either have to renumber the first prefix to /64 as well, or you would be stuck with two different prefixes announced in the RAs, and the host constantly regenerating its LL. Or you would be forever forced to always use the longest prefix for all subnets, so as soon as I have deployed 2001:db8:1234:5678:9abc::/80 from one ISP, I can never use anything but a /80 on that link no matter what prefix size another ISP might give me. Rgds. Ola (T) From nobody Tue Jun 13 01:06:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B65B128BB7 for ; Tue, 13 Jun 2017 01:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02XXjeElb8nM for ; Tue, 13 Jun 2017 01:06:11 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 BF91B1243FE for ; Tue, 13 Jun 2017 01:06:11 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id h39so70703908uaa.3 for ; Tue, 13 Jun 2017 01:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PaPpYf+CSw6w6ahMDT/VkM6tbhEcEb2BSu4gTfTQD2k=; b=dVpWc/i7QkMEpOy6nlQi/Fjwii3T5S8/0i2kF09wLIIZgbFwSKTm/KGcesRGLVfRSe sANHmm/DMhBf3lOIFtLGDKTh7kHjE5qGyeFRm7G1570dn6izR7ils8MG0p57eYdYuYEa jwepvNpkUoUezGCzy0+MC28Kuzt+9mDVXQCbnWuiMr96ZtE9xfswOodFwBLIv+b3GFcY MIHU5/188D7KnRgKF/JjpQpUorbJ6Tk0xrcgmukHWPg0+IRvgfBtPDvdXe3IHGx4qxFN 757iSmc1P60mdX//VQ6q966LHTW+/11rSd8zu//tHmozmHY1r8xdrc4EFtvP3mR614Yv spQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PaPpYf+CSw6w6ahMDT/VkM6tbhEcEb2BSu4gTfTQD2k=; b=VZTEQBYAr77bdaKkckd2DFWy8tGzp7g3mYC5W07hr3olVR21pwS/yHSnyniH00T8nz qU0E1ZMO3xuIVLttSfdg5yLjYQOi9NCQs87r3MOJO2KU07T3xXSdCG7+EN/lQpvKCK9F iqxClZvrHQLTQmYKnPR4RANXIdQMSepU5VqZoivH45wBeNvOjYuFMKjW/lsnCEYnIQkT 1Bks2JxPIG21yPlxKhb3+xBuVQBNTgo2AVZu1GXCNnl7TH0x1aNZPMb0fgdAkTzLlm9d 0WwqhYDyJSzRQ9K7xVd2RUTd4FsmNCcXeHr6o7gCq4ggqeDj+hZvIsz1VurxtB4xpCUn 5u0w== X-Gm-Message-State: AKS2vOzLo/hXdXxzmvPZELsm7YiY6UNBTCkLpcmpkZ4X0XCh7WLzIvK/ BL80w5Vbh2Rc8zZCFzZNcPFTDaDxU6Km X-Received: by 10.176.27.90 with SMTP id n26mr1847452uai.94.1497341170589; Tue, 13 Jun 2017 01:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 01:05:49 -0700 (PDT) In-Reply-To: <3c9f6fca-f356-67c0-5e43-077e039dce86@si6networks.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> <3c9f6fca-f356-67c0-5e43-077e039dce86@si6networks.com> From: Lorenzo Colitti Date: Tue, 13 Jun 2017 17:05:49 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont Cc: David Farmer , Job Snijders , Erik Kline , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="f403045ea09294f8510551d2e84e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:06:13 -0000 --f403045ea09294f8510551d2e84e Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 8:06 PM, Fernando Gont wrote: > > That's not true at all. As an example: see if you can build a network > > that uses a /99 and satisfies the recommendations in section 8 or BCP > 204. > > Could you explain why a 799 wouldn't satisfy bcp204? You can't meet this recommendation with a /99: it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests. This can be achieved either by allowing the host to form new addresses autonomously (e.g., via SLAAC) or by providing the host with a dedicated /64 prefix. --f403045ea09294f8510551d2e84e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 9, 2017 at 8:06 PM, Fernando Gont <fgont@si6networks.com&g= t; wrote:
> That's not true at all. As an example: see if yo= u can build a network
> that uses a /99 and satisfies the recommendations in section 8 or BCP = 204.

Could you explain why a 799 wouldn't satisfy bcp204?

You can't meet this recommendation with a /99:

=C2=A0 =C2=A0it is RECOMMENDED that the network<= /div>
=C2=A0 =C2=A0give the host the ability to use new addresses witho= ut requiring
=C2=A0 =C2=A0explicit requests.=C2=A0 This can be ac= hieved either by allowing the host
=C2=A0 =C2=A0to form new addre= sses autonomously (e.g., via SLAAC) or by providing
=C2=A0 =C2=A0= the host with a dedicated /64 prefix.
--f403045ea09294f8510551d2e84e-- From nobody Tue Jun 13 01:18:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4364129BC6 for ; Tue, 13 Jun 2017 01:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8biP4d3j5k2I for ; Tue, 13 Jun 2017 01:18:43 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB991129BBF for ; Tue, 13 Jun 2017 01:18:42 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id 191so59867567vko.2 for ; Tue, 13 Jun 2017 01:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QNIuJQIEA9JT7oMRCK9J8dVhSp4TDZRBmbGeOzr+xCI=; b=YLLduGHyV0CZrN9tdhiDa5uLIAci9UqqHq14gt1r6wcutlKykMzNmUyGV0y2ptKp0K wfbJbBnapppC+bVShw+eWIlfLFdGl0mm/yBcX3+Q0NqV+vXCSRpqy+XzdYQo5gBL1X15 P6bdjRz+u4dLTbDiV1Vri0tXgGk3xe1IlMUzrc4z6ptVYtRYG+Z9RajnmGsX1viV8tLQ nqCZz/mV0RC3JVVIiQm7Xj0gXCOo8zFaBLjYjD0OAGUloc2M0i9q1c27sc+29sHKqchx s+rOqv9CGEYEgNe/Id7F2nBu2aDefJtasYn3klnu6JQrwXWCeSeZUuQBIy8sb8jQxfHP 8UWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QNIuJQIEA9JT7oMRCK9J8dVhSp4TDZRBmbGeOzr+xCI=; b=uMPkY+NFUUK665uEkBiE4fdCl26nF8LEXUnBrwmbIXFDWu6w8uw64ePJk973CfmMus RntcKfSAsXirDDO80eZsRascMMWbjiSr1M2J+L0jD+lG4cwHl1HiRo+YbDtF76vDUDoG tMY6vAsLgOfs6caYzs97QnFx52xESOStB46k+krDbM4uSUUwumVqCBlFOsl11aH3YXWf tsRs6Xl7SiPxuoPVqNItBpl3HHXXCDPMjpHREUZKXGqyW3MGi9zFiHPimWh8H2z2Hatw iKVchxRe/W0khR/W6b15j2/nheuYPG62bhwB6m1JfD+2/MmZ7HHT7024EdcUn9t6Y9rA TGLg== X-Gm-Message-State: AODbwcCUxE1BZCcnBqT5+d2CxgkAgZEcAbCKNphjSBeQ4IxKSkuTy7/G Pb+wodLcA4Jq82Azm8ffsSUiHmYW3LGf X-Received: by 10.31.64.130 with SMTP id n124mr18154297vka.44.1497341921788; Tue, 13 Jun 2017 01:18:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 01:18:20 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> From: Lorenzo Colitti Date: Tue, 13 Jun 2017 17:18:20 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Ole Troan , Fernando Gont , 6man WG Content-Type: multipart/alternative; boundary="001a114479a65b8e3a0551d31524" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:18:45 -0000 --001a114479a65b8e3a0551d31524 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 11, 2017 at 8:37 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > This has two aspects for me: > 1) It's simply out of place to define an arbitrary constant > in something called "architecture". > Er, what? It's perfectly fine to say that the address is 128 bits long, and that half of it is assigned to the network and half to the link. > 2) By defining it globally we forbid using some other value > on a future link-layer where a different value might be better. > A 'should' could cover that, of course, which is why I accept > the current 4291bis text. > I don't see why we need new text for that. Any document that wants to use a different value can simply update 4291. > > I am still confused what this draft proposes to change. > > Nothing in any current implementation. We have a popular implementation that only accepts 64-bit IID lengths in certain cases. Are you proposing that our implementation change or not? --001a114479a65b8e3a0551d31524 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 11, 2017 at 8:37 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
This ha= s two aspects for me:
1) It's simply out of place to define an arbitrary constant
in something called "architecture".

Er, what? It's perfectly fine to say that the address is 128 bit= s long, and that half of it is assigned to the network and half to the link= .
=C2=A0
2) By defining it gl= obally we forbid using some other value
on a future link-layer where a different value might be better.
A 'should' could cover that, of course, which is why I accept
the current 4291bis text.

I don't s= ee why we need new text for that. Any document that wants to use a differen= t value can simply update 4291.
=C2=A0
> I am still confused what this draft propose= s to change.

Nothing in any current implementation.

We have a popular implementation that only accepts 64-bit IID lengths in= certain cases. Are you proposing that our implementation change or not?
--001a114479a65b8e3a0551d31524-- From nobody Tue Jun 13 01:30:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF86129BC8 for ; Tue, 13 Jun 2017 01:30:10 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a_tGsSgmBNd for ; Tue, 13 Jun 2017 01:30:08 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 013C5128BB6 for ; Tue, 13 Jun 2017 01:30:07 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id h39so71019692uaa.3 for ; Tue, 13 Jun 2017 01:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xjXS2VLetK+bUbtLXd55FJ/RPGXR2JCOo98rlrXFEhk=; b=gOL/GybfT3HDERjpj8Um1HJ7i7gLwNt/c1ManvHWijeb2klUoSTl4rhEwKFYmcIk3k uRSVCTX+xfxZ56toc2LfkojwisY4h2Jqu9rNFn2NXNozYQ/mZ80j7MXMwDZ0TD6vY4wi peiaFXvvJ1SXq0G2omU8MZk4QJH+2s8+zDnuiluQY3YYqhU/Yl6Y6m0cb5Q2QaBtKvIG cz7iXld7AUwZJI5xbyJWhiotnXEPFEjKSpQ9d5tNwCbIofvxQLOnIyyQYl+ks0e11Dpf w87iNXuLumnz2P2nuub3FGf4qTzqY+yHhfPjGFi8y5FATblCMCBNwI2jxK2jV3L6oG4F XJrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xjXS2VLetK+bUbtLXd55FJ/RPGXR2JCOo98rlrXFEhk=; b=abhZM3MOTeZoCKpTdEw7tX7V/UcqLVM0bzHa6oHo+gNsmY7bKZOd8Vepvi8VspicaP 6s7rPDROX9SR1X3lcW9SfVO83dLlXvSMvkb9f+XmlL9AM8RGg3Bj9RJZmEX/Dtl33DKH 35lrpajTC9cjw/vc1G9By60V3+CHgx48a2f3aD5MgW43jpL6/ZDATxiiY3UXaq92/xFq MA+Tc+LhQfvAnhJxZ70oqbufPrBi68ruQ3J1sdGgp+tN0P61haUf4PNNCT6PBQ0FLFHo naNDvnJ+G8jV975k/bEZbKfaZvd/WmKjjDhy6cWmSVymnR5JESQc0T8jsD7F9UlKxXao tu/w== X-Gm-Message-State: AKS2vOzdAfDL+HXv2LRXfBIlHKsIOpSa9pmGJvLVd3c2n+vBrL0tAouW UL+D7uqjwv/3LToHK2aBqNIrxm7I+dx7 X-Received: by 10.176.83.16 with SMTP id x16mr1975240uax.11.1497342606977; Tue, 13 Jun 2017 01:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 01:29:45 -0700 (PDT) In-Reply-To: <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> From: Lorenzo Colitti Date: Tue, 13 Jun 2017 17:29:45 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Fernando Gont , Ole Troan , 6man WG Content-Type: multipart/alternative; boundary="94eb2c18f1ac329e9a0551d33e20" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:30:11 -0000 --94eb2c18f1ac329e9a0551d33e20 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 10:26 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Why does N need to be set on a per-link-type basis? > > It doesn't *need* to be. But SLAAC by design assumes that it is > set per link-type; that is architectural flexibility which is > removed by RFC4291, which IMHO is a bad message to send to the future. > > I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis > back to us You're not serious, are you? The IESG sent back draft-ietf-6man-rfc4291bis because there was clear lack of consensus, not for any architectural reason. --94eb2c18f1ac329e9a0551d33e20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 10:26 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
> Why does N ne= ed to be set on a per-link-type basis?

It doesn't *need* to be. But SLAAC by design assumes that it is<= br> set per link-type; that is architectural flexibility which is
removed by RFC4291, which IMHO is a bad message to send to the future.

I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis back to us

You're not serious, are you?=

The IESG sent back draft-ietf-6man-rfc4291bis bec= ause there was clear lack of consensus, not for any architectural reason.
--94eb2c18f1ac329e9a0551d33e20-- From nobody Tue Jun 13 02:04:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347F312EC20 for ; Tue, 13 Jun 2017 02:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyyH_o4rkOiR for ; Tue, 13 Jun 2017 02:04:12 -0700 (PDT) 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 371F712EBE1 for ; Tue, 13 Jun 2017 02:03:20 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v7so29307384ywc.2 for ; Tue, 13 Jun 2017 02:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YS/J7OWIZj4gRkpByZ1fmbjAkVbJPZEyezQXaipqv4w=; b=JOTdQdEehq2wD4q9e/dTGjkVd+WvLw5wAi/Wu4x80hkVvBmePk0vcPTUWw0gWS8KWl J2ksk1JD/tx7r68WDamt1rHbMb4FiNItbdYW4Ceth6ovQ4MDjhso3gXCRpqfyxC7zAhj pWa1fQHfonqumZb1HHEtr5eym5pcJ81NLzLBNnRuDPL77P8ILkk7gf4IlT5QFcnxU4uc egx8KhOdPWJj2U3JuwztZDv2yBs6L0jko/H+hAwMnKhjCM9Gy30FQQEEVJNDq+vOBMSV QTPcLiGuozGEABfsdD5Wtd/TtidRUs+oYo6Ofo35IkyqVGDni7RIIbKusfjDOZ+tLmQz JKYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YS/J7OWIZj4gRkpByZ1fmbjAkVbJPZEyezQXaipqv4w=; b=UT63ETBjmusiYUL7dGBfjh1lJZEi9aGq4ZD46jT6BgkNL6HEjfE3dwfokgkoGug8iJ K6dfklMyTBJ1Zy3q+lYZYG1Fw8PkVHQRjjxB5Q/M9rEX4h5gfKtM2k2Jrcz/m+a5nd3K ZGP06MH4nhPx6F+JvOFhB0TCwwNjWy/L7B6a6D1wZHY8WqQqOPn/2Z3Ssxl/JHZOWY3u bjy+PEwC7AB5jiQHaWI65viigvZhFYxaml/ZaEfekYdZWmqUGyfrMT1OIbe03yhPqJ/q 05AJSC4BO3yJtX8d5BTswOE+HdtTVKXW44fD5SmCyGpURTPrxyWcTbIfA2ynJ97K3caf TQnw== X-Gm-Message-State: AKS2vOzSgMbWa9f6dEIymBb3+XfpCi0TbkEpDrfQxqNfaPsRpvug+hBT u9dMLVrgGnTA2udyyxZ1L042w8Bslh8j X-Received: by 10.129.91.136 with SMTP id p130mr2226387ywb.176.1497344599348; Tue, 13 Jun 2017 02:03:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Tue, 13 Jun 2017 02:03:18 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Tue, 13 Jun 2017 11:03:18 +0200 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Ole Troan , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:04:19 -0000 On Sun, Jun 11, 2017 at 8:29 PM, wrote: > To summarize: > - There is no technical reason why SLAAC cannot be made ot work with arbitrary prefix lengths. > (including very long prefixes, although it might take a while to find a non-duplicate if the addressing model > moves from sparse to dense). > - There is no technical reason to have a fixed IID length defined by data-link type. > - Removing the constant from the addressing architecture will likely set these changes into motion. > (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary > to stay in IPv6 over foo is tenable.) > > If that's what we want. I believe we have to think quite hard about it and we need to consider the consequences quite hard. what none so far (I might have missed it), have said anything about is the policy side of IPv6 down the line if we start messing with the 64bit constant. Can anyone summarize what else is based on the argument that 64bit is the LAN side of things? whatever we do here will have wide scale effects. You can disagree or disagree but why should let's say RIPE continue using /32 or /29's? That argument is based on the amount of /48's and /56... which again lead down to /64. next thing we know is the routing table. Sure call me crazy, but why should there be a /48 constant there when we've removed the constants everywhere else? -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Tue Jun 13 02:16:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E97C12EC43 for ; Tue, 13 Jun 2017 02:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmvQ7hsjq2Sv for ; Tue, 13 Jun 2017 02:16:34 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A0412F268 for ; Tue, 13 Jun 2017 02:10:31 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id 63so46162727ywr.0 for ; Tue, 13 Jun 2017 02:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+Lfrc1JywTZ9NFZhZ+I6gXAiwKVFQQCxezviZjyKA3Q=; b=M3aE28+YjfUcmXvq4Ic0SgnFKDXEW7paoXfXkzYik3NKP9rYCbgpDdxh4WGBSqjXMO 48lEyfGwhtpYc8bFPBIV+zHd3hRog5C9mNtpiGXW+WDjTCm6DD0IpAH8EbgDo4aeva2w Dzl8Fm8WiUoEXrM58cM+Spo+uPe69jsW98oqZRAOp2jZQlwN4cWxteUb3rKGE9ymAmZs fusnzRM7kcDEGp3/hWKAfbTfXruOs5pgjKlPa+6dbX/nGqIsIU/cEEypiPeDFt1EKVei mTPRku7TXvTgh4KOvz1LF1KknI03b+6JnwXSgTYlQ/rgyj4qAvgxu3n8UQsTm6T/YolH 6ivQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+Lfrc1JywTZ9NFZhZ+I6gXAiwKVFQQCxezviZjyKA3Q=; b=BusdpQhZqpEn/dLbiLyn65h7lFKM4yRJhqw8HLHXNEJmnFkIcySdmB4LXI5TQM6EN2 U/OTwGCh16/u0S1GhjTmNdCeoj7eG6hcLoOiKgdfQ8DJBE1TOtac0717HdYFjlXc1h+M VIvrUiKBj1sQRmlS7gvJlkz5O4orXirkd6kA/i17Gnd0EZs58AczfO0CMarDIYpZgEKj XC2ZnH0Ek6ZmHypdZBin4P4zsCZ3SpcYvhZ9aWq5O4pwLAW4ahtdpqisaxukqo2bmNxQ t5H2y/GUgXSTWiXKgNjl+hCsAqpEHwIqVW5SoSlE+eTdYdbdhoAF1R2ucGHVT/PnqQyJ Efcw== X-Gm-Message-State: AKS2vOxXCZ+iL0OScULAeOo08u7TEhpAZNEsVWnD4h9qgkZqHwq+mEvd 8wN3eMJv4XyfSi1SAIAI+CT6Nl8aBRAV X-Received: by 10.129.91.136 with SMTP id p130mr2244790ywb.176.1497345029938; Tue, 13 Jun 2017 02:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.246.7 with HTTP; Tue, 13 Jun 2017 02:10:29 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Tue, 13 Jun 2017 11:10:29 +0200 Message-ID: Subject: Re: Tussles in IPv6 Land To: IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:16:36 -0000 On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert wrote: > But that begs the question, why is /64 the one size fits all answer? > What if in the future that number proves to be the wrong choices? > Flexibility seems like a better way to future proof this. What I seem to remember, read or heard somewhere is that it went something like this: IPv6 need more address space than IPv4 which is 32. 64 was just double, let's double that again and we should be safe? They end up with 128bit, and slice it in two half, /64. One for LAN and one for network. Why not? end of story. -- Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no From nobody Tue Jun 13 02:22:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112A512ECB6 for ; Tue, 13 Jun 2017 02:22:03 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7XhKRPXzn8q for ; Tue, 13 Jun 2017 02:21:58 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8457C12EC2B for ; Tue, 13 Jun 2017 02:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497345227; x=1497950027; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=olG8EhChN4ULqyzmjGrhzpMBn 2qA5Bi6yFFhIy0nsRQ=; b=ptpWkX9qvhq4TNvm5OlBjrZyGTHVd6NKC7DYsiLD5 +51Ogc+tCAWHsP7xWQ2oEElFcG12MGMnLNqpOECqfzRoO11X+6Gf3IsXiep1dpJS WKW+QYaQHmChkljE7eFadawFoWuYH+HXhn758BuNFcDMDo81RMC8IaTdMgUQ6Ewc EA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=g5cTVgtGjVKBrDScDSbl2JjkGGPq419IQ4x6zlVgCOO7TcuD1G/MUhwiu/7i IGs0a421eqZ65RTOGGOojxYvbUxN+v1kxY5+Mm/KAZOVD+ozYmDSD4p02 8F1s0GpQHlfY23Kjl7kE3DW6NxBghc158uUuUn03X4YqWWhKfzJ/5Q=; X-MDAV-Processed: mail.consulintel.es, Tue, 13 Jun 2017 11:13:47 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 13 Jun 2017 11:13:47 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449949.msg for ; Tue, 13 Jun 2017 11:13:46 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170613:md50005449949::HI2pwPQeqXDjy6b6:0000BG2X X-Return-Path: prvs=133763a1c1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Tue, 13 Jun 2017 11:13:45 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: JORDI PALET MARTINEZ To: 6man WG Message-ID: <9E7C466F-EFC6-438B-867D-B492AB6503A6@consulintel.es> Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:22:03 -0000 Fully agree, I know is not, up to a certain point, an IETF matter, but chan= ges on this will impact in making wrong the text in many RIR documents, pol= icies, etc. Do we really want to create that mess? Regards, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de Roger J=C3=B8rgensen Responder a: Fecha: martes, 13 de junio de 2017, 11:03 Para: Ole Troan , 6man WG Asunto: Re: draft-bourbaki-6man-classless-ipv6-00 On Sun, Jun 11, 2017 at 8:29 PM, wrote: > To summarize: > - There is no technical reason why SLAAC cannot be made ot work with= arbitrary prefix lengths. > (including very long prefixes, although it might take a while to f= ind a non-duplicate if the addressing model > moves from sparse to dense). > - There is no technical reason to have a fixed IID length defined by= data-link type. > - Removing the constant from the addressing architecture will likely= set these changes into motion. > (i.e. I don't think a position where one wants to remove the 64 bi= t constant from 4291 and expect the 64 bit boundary > to stay in IPv6 over foo is tenable.) > > If that's what we want. I believe we have to think quite hard about i= t and we need to consider the consequences quite hard. =20 what none so far (I might have missed it), have said anything about is the policy side of IPv6 down the line if we start messing with the 64bit constant. Can anyone summarize what else is based on the argument that 64bit is the LAN side of things? =20 whatever we do here will have wide scale effects. You can disagree or disagree but why should let's say RIPE continue using /32 or /29's? That argument is based on the amount of /48's and /56... which again lead down to /64. =20 next thing we know is the routing table. Sure call me crazy, but why should there be a /48 constant there when we've removed the constants everywhere else? =20 =20 =20 --=20 =20 Roger Jorgensen rogerj@gmail.com / roger@jorgensen.no =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Jun 13 02:43:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E33131500 for ; Tue, 13 Jun 2017 02:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1yqqvf8N4ti for ; Tue, 13 Jun 2017 02:43:01 -0700 (PDT) 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 94CFE131452 for ; Tue, 13 Jun 2017 02:30:14 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id 191so60703719vko.2 for ; Tue, 13 Jun 2017 02:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i13j0QDX0P3j1KVLeeW/jTk4MZuM5yfEw7ieqY4pfyU=; b=lFK2wLrUyRz3OYgrF73MC4uivx8n2BJHiOYXAsrwFxdTXSMQZ86lm9u+Au8vYWo1zt 1gb8N97inCaYm4Cq12dh04gE/nwbBISXs64KGqU+roDu9DD02NoTkQiTaocBQwRPRJ4p LsnfRDv9g5ezbC1Ouz6pclLkQNNCElg2g4VQ9/qT3lE6lMxF9J4IJzKdIhXJ4hfbtzHV guoe4gPdk14Td8vUF7KOU87hdKsy9rmMTbn5AGlTEuNBHFi6lynL5SDjByjrf3m7N8Na J/qDxEuDoN8fwhSLHuZ0yvL9BE6lXhk5Pq+3yMip8tAkxqq7TU36KvizOqKPCLpuTQPP vkCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i13j0QDX0P3j1KVLeeW/jTk4MZuM5yfEw7ieqY4pfyU=; b=AIQ6NsRezEsGUXepPycV/nPcKmlqr5g0g3udoTU+4RMY3id5QLIBSFNiAG6OYtLiyB Z0mg1ilHAp9ef3IqjcI1y+qBE8zQ7E7XVBWIGA9wD1njXceIp0kvGhcomVpJrXSABJEw d0lB7OWmSC+91Ix6C4gHKwAdomhPQVkpnB3WnWfJcE6+jy2nPu7kHp4hr014l2q+V8FC fMEZUhM2z4ARct6VlKgNC39n3RUEq22RP/YzbW1Q5Gqjpu1vJmAEXVNwKFnCjrjgIPy5 1SAvLqIxelu888UnfNK6CYpCNVF4EjmW0/lub5q9Bnu/bCCG5Kwmb0oOyG5GH25NoZjx 1ksg== X-Gm-Message-State: AODbwcBiyxXIsrRj9WNSfhCIIDhY+7l6u6VbBCwbKNbwt1dQ6g5+MW1m 6dcPOGnY7aMSrEM3MWKhWmfGYii2G7LmO5U= X-Received: by 10.31.236.193 with SMTP id k184mr22468605vkh.96.1497346213550; Tue, 13 Jun 2017 02:30:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 02:29:52 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Tue, 13 Jun 2017 18:29:52 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c08b3d22a95cd0551d415ca" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:43:03 -0000 --94eb2c08b3d22a95cd0551d415ca Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert wrote: > ILA is an innovative way to use IPv6 addresses, but as I described it > can't use this in a mobile network if every UE gets a /64. In this > case too much space is given the end host which probably a low end > device like a smart phone that really doesn't need it. > Again, that's the perception from the network operator side of the tussle. The perception from the other side is, "these bits belong to hosts, go and do mobility in the top 64 bits". It's really not hard to do mobility in the network layer. Just build a low-overhead tunneling mechanism that maps /64 prefixes belonging to nodes to base station IP addresses. We have lots of those, GTP being one. The overhead doesn't need to be 40 bytes, either - you could But that begs the question, why is /64 the one size fits all answer? > Because if you don't have a one-size-fits-all answer, you end up with not enough space. Your assertion above is "a mobile device doesn't need /64". Even if your assertion were true today (which I think it isn't - a full /64 is necessary to ensure that all devices behind the mobile node can run SLAAC, for example), whatever address space you think a mobile device will "need" is going to be based on how much you think a mobile device needs today, and that's going to constrain future usage. --94eb2c08b3d22a95cd0551d415ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 12:20 AM, Tom Herbert <tom@herbertland.com> wrote:
ILA is an innovative way to = use IPv6 addresses, but as I described it
can't use this in a mobile network if every UE gets a /64. In this
case too much space is given the end host which probably a low end
device like a smart phone that really doesn't need it.
=

Again, that's the perception from the network opera= tor side of the tussle. The perception from the other side is, "these = bits belong to hosts, go and do mobility in the top 64 bits". It's= really not hard to do mobility in the network layer. Just build a low-over= head tunneling mechanism that maps /64 prefixes belonging to nodes to base = station IP addresses. We have lots of those, GTP being one. The overhead do= esn't need to be 40 bytes, either - you could=C2=A0

But that begs the question, why is /64 the = one size fits all answer?

Because if yo= u don't have a one-size-fits-all answer, you end up with not enough spa= ce. Your assertion above is "a mobile device doesn't need /64"= ;. Even if your assertion were true today (which I think it isn't - a f= ull /64 is necessary to ensure that all devices behind the mobile node can = run SLAAC, for example), whatever address space you think a mobile device w= ill "need" is going to be based on how much you think a mobile de= vice needs today, and that's going to constrain future usage.
--94eb2c08b3d22a95cd0551d415ca-- From nobody Tue Jun 13 03:55:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A83131607 for ; Tue, 13 Jun 2017 03:55:56 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjHrLLt-4PKh for ; Tue, 13 Jun 2017 03:55:55 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 C9FCA131603 for ; Tue, 13 Jun 2017 03:51:00 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id m31so72834245uam.1 for ; Tue, 13 Jun 2017 03:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hdjqhxu+L7WjRjODwTrAfgpCZl+Cwjw4mp7dByIexys=; b=YMZMxviZNBJm/3CzL3syksVzItgrsBySPSP17mmAOifZBMuS1pOO+J/15l43GRraqX 5RUbdSJ4QE5VlGa906PQdccEulJS6UY1jPFqR30MzKB/dmYT2VADy+pwHBuY4/+jzxzq Z8LPeCuEwPKzzIHEteCeaODeUZ+VOlvc1gi9CTd2az4GycfpaLMvxZ/1wearrMBXtbyy /XDpIp9KpG76M7hHm87yt2/HNp2asQcgnfwUqYRTd4NjWfsqgsPVww22wraELH7V6Kv1 +CPWxA7xMudcweABujyLvba4OWSlihYF+4QyZSA0heM7CfcvFClkWcvQdT7hemq8pdH5 8B5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hdjqhxu+L7WjRjODwTrAfgpCZl+Cwjw4mp7dByIexys=; b=Xf1QDljS1fSy7HXsfxfEdq7QuDLkK/ggfZXttpkk/SsNAooyc+dNGALUgyKjXQw4Uc Y4oe6GGFnx918w2G/5LFWDo6e7qWn9lEQ+WcT/O1Fu1mjfV/KMEbG9WNhBVVASv6nSK5 Ozaz2BKgshd6YslQ8lwJyfhyAaKpD+9CccKZhSc5TndbK+0FZjpx9w/yBnvcJU5A/kxF 9TcxDO6PgvUWIDjz6CXJeWLcndJJGoQiJuP9PwNpJC0IWUMPQLe7Y2x7I/01MylKAVEm 1XSfAJn449igpJAXekFVe/PJk3btUfmQ1Ip8l8p5CkQbIF5k+REB/rEp1MnaKa5BNk7s 0Cew== X-Gm-Message-State: AKS2vOzk1da3gzY6Q8u/9rh5lP0lyYlHcCAiDlNNz8wzDmZyTHx24z7K gEk8nqusD04cEnQb3OoOUGsSnKvN9A== X-Received: by 10.159.60.82 with SMTP id w18mr2202359uah.19.1497351059727; Tue, 13 Jun 2017 03:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.86 with HTTP; Tue, 13 Jun 2017 03:50:29 -0700 (PDT) In-Reply-To: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> From: Mark Smith Date: Tue, 13 Jun 2017 20:50:29 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Brian E Carpenter Cc: 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 10:55:57 -0000 On 10 June 2017 at 11:33, Brian E Carpenter wrote: > Hi, > > I wrote the text below a couple of months ago, but then got distracted. > However, I do think it's important that as we argue about (for example) > /64, to remember what's going on behind the apparent argument. > > Regards > Brian > > Tussles in IPv6 Land > > Today (April 2017) we seem to have three very active tussles in the IPv6 technical > community. > > 1. Is header insertion on the fly OK, or is it the work of the devil? > > 2. Is the fixed interface identifier length of 64 bits OK, or is it the work of the devil? > > 3. Which is the work of the devil: getting the DNS server address via Router Advertisments, > or getting the DNS server address via DHCPv6? > >That's because inserting stuff (any stuff, not just this header) > in a packet changes its length and thereby breaks all known methods of determining > the maximum packet size allowed on a given path across the Internet. > I think it is more significant than that. It's (A) ignoring statements in a very widely implemented and deployed protocol specification that has existed for more than 20 years. RFC1883 contains the text about not processing EHs in the network. (B) ignoring the interoperability goal of protocol specifications, meaning that new implementations' features interoperate with existing implementations without significantly impacting their operation. Inserting EHs contradicts Postel's "Be conservative with what you send" because existing implementations aren't expecting in-flight inserted EHs, and that is because that action is not specified as a possibility in RFC2460. (C) ignoring the fundamental and foundation principles of layers and encapsulation/de-encapsulation to add or remove information to existing protocol data units (D) ignoring the operational consequences of making protocols and devices harder to troubleshoot and rectify because it breaks source address field semantics while the inserted EH is present. Despite theoretical claims, in practice the inserted EH may not be removed at the edge of the insertion domain because of device misconfiguration, implementation bugs or partial device failures, so troubleshooting may be occurring outside of the domain that inserted the EH. The operator who decided to insert the EH may not be the operator dealing with its consequences and having to troubleshoot and rectify it. Excepting (A) all of the above can operational impacts to end-user devices. They also will have financial impacts, both in terms of the cost of downtime, and I think creating technology that doesn't have as a priority trying to leverage existing proven methods and deployed implementations is creating unnecessary costs for end users. I think maximising robustness and availability for minimum cost for the Internet and its technologies' end-users should be the primary goal. That's a purely operational view, based on trying to provide the best and cheapest network service to end-users. All of a network operators actions and decisions should be traceable back to end-user needs, and be the action and decision that best meets those end-user needs. There are several reasons for that - though the main one seems to be that having > a 64 bit boundary everywhere makes portability (of code, and of computers) easier. Not in my case. To me it is to avoid network operational costs that would have to be borne by end-users that were unavoidable in IPv4 due to it's constrained number of addressing bits. At two separate large hospitals in the late 1990s I saw a router with 4 x /24s on its interface and another router with 25 x /26s on its interface (PCs were being used as routers before the subnets were collapsed down to a "proper" router). In each case, the cost of renumbering the >1000 hosts into a single large subnet were going to be so high that the hospitals avoided it and put up with sub-optimal routing. They had the money, however it was better spent on resources to help and heal patients. A large default subnet size makes this an impossible problem to have. Nobody ever ran out of addresses in IPX subnets. Network capital and operational costs are also opportunity costs to the network's owners and end-users. We should try minimise the technology's capex and opex so that we maximise the money network end-users can spend on their real goals and purposes for existence - healing patients, providing food, reducing opportunity costs for customers by making cheaper yet more effective products etc., I also care about the end-user privacy and security properties that have emerged from IPv6's much larger address space. I don't think this is a conceptual purist view. It is one of trying to look after the end-users of the Internet and its technologies, by reducing operational costs and enhancing privacy and security. > I think this is where RFC1958 should have been followed: "3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." I'd describe the IETF's approach to multiple effectively equivalent or near equivalent technologies to be Darwinian - survival of the fittest. Let them be invented, possibly implemented and then possibly deployed, and see which one or ones survive. However, the drawback of the theory of natural evolution is that it places no or very little cost on failure or factors what was learned from failure into future evolution. The costs of the IETF's Darwinian approach are now being incurred. There is no clear winner between RA/RDNSS and Stateless DHCPv6, at least in the eyes of the people who have to deploy it. Some developers or vendors of them do have a preference, however they also have an obligation to consider and possibly accommodate what the majority of their customers want. I have no specific preference for DHCPv6 for DNS, except that it existed before RA/RDNSS, would work and would achieve the outcome. While I wouldn't think it would totally avoid controversy, I think it would be useful if the IETF came up with a set of actions and criteria to try to judge and evaluate new proposals that are equivalents or near equivalents to existing methods. Certainly a problem statement is a requirement and one that is probably always being satisfied. However, I think there should be others such as - an independent evaluation of the problem statement to see whether what it says about the problems with the existing method stands up to scrutiny - how widely has the existing method been implemented - how widely has the existing method been deployed into production environments and on what scale - are the advantages of the new method compelling enough that those with existing deployments would be willing to utilise both in parallel, or replace the former method with the new method - from those who have deployed the existing method, what are the unexpected drawbacks they've discovered if any, and what have been the unexpected benefits they've discovered, if any We are wasting human resources if we allow new technologies to come into existence and be developed when the existing solution could be adequate or could have comparatively minor changes to be made adequate. If we believe network operator's needs are the most important, we'll have forgotten who network operators exist to serve and more broadly, who IPv6, the IETF and the Internet exists to serve. Regards, Mark. From nobody Tue Jun 13 04:34:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFD2131719 for ; Tue, 13 Jun 2017 04:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6INsbpJxQETs for ; Tue, 13 Jun 2017 04:34:01 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 00240131723 for ; Tue, 13 Jun 2017 04:33:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DBXkN1128925 for ; Tue, 13 Jun 2017 13:33:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B30E7205586 for ; Tue, 13 Jun 2017 13:33:49 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 82B39204A3C for ; Tue, 13 Jun 2017 13:33:49 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DBXmej009449 for ; Tue, 13 Jun 2017 13:33:48 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 - method feasible To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Jun 2017 13:33:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:34:03 -0000 Le 13/06/2017 à 04:22, Manfredi, Albert E a écrit : > -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] > On Behalf Of Brian E Carpenter > >>> there's no reason why the IID should be link-type dependent. >> >> I believe that is simply false unless you want to go back to the >> era of DIP switches with instructions to users to a) choose an IID >> length for their new subnet b) set the DIP switches on every device >> to select that length c) then plug and play. >> >> Otherwise LL addresses cannot be formed consistently on the whole >> link. > > Why so, Brian? I've already described one easy technique: the host > can create IIDs of any length, based on an algorithm that we might > just be debating for a long time, but fundamentally can be quite > straightforward. And then the host chooses the correct IID to use for > SLAAC, based on the RA it just received. > >> OK, that is caricature, but without a substantial reworking of >> RFC4862 I believe that is essentially what we would need, in an >> automated version, before SLAAC can start. > > 1. Host can create, in real time, IIDs of length 128 to 0 bits. To do > this, for SLAAC, it SHOULD not be difficult IMO. One possibility: > create random 128-bit value, then use a simple truncation algorithm > to reduce the number of bits to the required value, at the > appropriate time. > > 2. Host waits for RA. > > 3. Host determines prefix length after receiving RA, using the > equation: > > IID length = 128 - prefix length > > 4. Host generates 128-bit SLAAC address. If we started with the > 128-bit random number, just truncate as needed. > > 5. Perform DAD, as already prescribed. This method seems feasible to me. It would allow WiFi terminals to connect to a smartphone that was advertised a /64 on its LTE link and made a /65 for the WiFi interface. The RA would contain that /65 and the WiFi terminal would make an IID of length 63. This same WiFi terminal is backwards compatible: it could also connect to other WiFi networks where the RA has a prefix /64. Alex > >> Anway, all this is empty talk as long as the addressing >> architecture *requires* 64 bits rather than *recommending* 64 >> bits. > > True, but anything that *requires* something, based on a premise that > has all but been discarded, doesn't hold much credibility anymore. > The fallout from having deprecated that premise needs to be > considered. A better future can result, as in this case (IMO). I > think there's something in philosophy that addresses just this sort > of situation. Where the general consensus of an argument can change > 180 degrees, if more information on the underlying premises is > presented. > > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 13 04:34:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09A3131723 for ; Tue, 13 Jun 2017 04:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6JmKPCDU0sl for ; Tue, 13 Jun 2017 04:34:43 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 CF8E41316A1 for ; Tue, 13 Jun 2017 04:34:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DBYdLG129831 for ; Tue, 13 Jun 2017 13:34:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1DA3C203FB7 for ; Tue, 13 Jun 2017 13:34:39 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1420920149F for ; Tue, 13 Jun 2017 13:34:39 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DBYcS6009930 for ; Tue, 13 Jun 2017 13:34:38 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> From: Alexandre Petrescu Message-ID: <732df8e5-8f74-3bd9-b1d5-31c4a1670c6b@gmail.com> Date: Tue, 13 Jun 2017 13:34:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:34:45 -0000 Le 13/06/2017 à 05:38, weigengyu a écrit : > > Hi, > > The flexibility of IID length will bring some benefits. But, is there > any compatible issues to concern? > > For example, if two networks are assigned with two length IID in > office and at home, the host, such as mobile phone, pad or note PC > must adapt to the different IID lengths. It should work. Alex > > Is it practical or available nowadays to have such adaptabilities. Is > it a required to have a default IID length, eg. /64 for the local > link? Should the default length be supported? > > > Regards, > > Gengyu WEI Network Technology Center School of Computer Beijing > University of Posts and Telecommunications -----原始邮件----- From: > Manfredi, Albert E Sent: Tuesday, June 13, 2017 10:30 AM To: Brian E > Carpenter Cc: 6man WG Subject: RE: > draft-bourbaki-6man-classless-ipv6-00 > > > I should add, > > The IID length used by all SLAAC hosts on a link would be the same, > because presumably, they all receive the same RAs. With the same RAs, > their IIDs would have to come out to be the same length. > > And, most of this change doesn't even apply to RFC 4862. For the most > part, it applies to RFC 2464-bis. The main points of RFC 4862 remain > the same. > > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jun 13 04:36:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A01131728 for ; Tue, 13 Jun 2017 04:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7DmeBifnzbR for ; Tue, 13 Jun 2017 04:35:58 -0700 (PDT) Received: from atl4mhob08.registeredsite.com (atl4mhob08.registeredsite.com [209.17.115.46]) (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 0B52E13161E for ; Tue, 13 Jun 2017 04:35:57 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob08.registeredsite.com (8.14.4/8.14.4) with ESMTP id v5DBZuHq009371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Jun 2017 07:35:56 -0400 Received: (qmail 3715 invoked by uid 0); 13 Jun 2017 11:35:56 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 13 Jun 2017 11:35:55 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 13 Jun 2017 07:35:52 -0400 Subject: Re: Tussles in IPv6 Land From: Lee Howard To: Mark Smith , Brian E Carpenter CC: 6man Message-ID: Thread-Topic: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:36:00 -0000 On 6/13/17, 6:50 AM, "ipv6 on behalf of Mark Smith" wrote: >On 10 June 2017 at 11:33, Brian E Carpenter >wrote: >> Hi, >> >>That's because inserting stuff (any stuff, not just this header) >> in a packet changes its length and thereby breaks all known methods of >>determining >> the maximum packet size allowed on a given path across the Internet. >> > >I think it is more significant than that. > >It's > >(A) ignoring statements in a very widely implemented and deployed >protocol specification that has existed for more than 20 years. >RFC1883 contains the text about not processing EHs in the network. > >(B) ignoring the interoperability goal of protocol specifications, >meaning that new implementations' features interoperate with existing >implementations without significantly impacting their operation. >Inserting EHs contradicts Postel's "Be conservative with what you >send" because existing implementations aren't expecting in-flight >inserted EHs, and that is because that action is not specified as a >possibility in RFC2460. If you only insert and process EHs inside your network, then you can reasonably assume that they are expected. Strip EHs at your borders and everyone=E2=80=99s happy. > >(C) ignoring the fundamental and foundation principles of layers and >encapsulation/de-encapsulation to add or remove information to >existing protocol data units You think? Is routing information the same layer as the network layer, or higher or lower? Adding headers outside the IP headers seems to me to preserve the spirit of layering. An alternative would be to formalize a path layer, using MPLS as one model. > >(D) ignoring the operational consequences of making protocols and >devices harder to troubleshoot and rectify because it breaks source >address field semantics while the inserted EH is present. Yet operators are doing this now. Sounds like a tussle. > Despite >theoretical claims, in practice the inserted EH may not be removed at >the edge of the insertion domain because of device misconfiguration, >implementation bugs or partial device failures, so troubleshooting may >be occurring outside of the domain that inserted the EH. The operator >who decided to insert the EH may not be the operator dealing with its >consequences and having to troubleshoot and rectify it. Yes, that could be a problem. Do we have a documented BCP to drop packets with unexpected EH outbound and inbound? *IS* that the BCP? > > >If we believe network operator's needs are the most important, we'll >have forgotten who network operators exist to serve and more broadly, >who IPv6, the IETF and the Internet exists to serve. To summarize a point I made yesterday: The network serves whoever pays for the network. Not all networks are for individual consumers. Lee From nobody Tue Jun 13 04:40:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6128126C0F for ; Tue, 13 Jun 2017 04:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS5iCIOpZS6n for ; Tue, 13 Jun 2017 04:40:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 DE9201294E1 for ; Tue, 13 Jun 2017 04:40:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DBebPT134174 for ; Tue, 13 Jun 2017 13:40:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 43850202EBF for ; Tue, 13 Jun 2017 13:40:36 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 05C392054F5 for ; Tue, 13 Jun 2017 13:40:35 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DBeZiJ013541 for ; Tue, 13 Jun 2017 13:40:35 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Jun 2017 13:40:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:40:41 -0000 Le 13/06/2017 à 09:51, Ola Thoresen a écrit : > On 13. juni 2017 04:22, Manfredi, Albert E wrote: > >> Why so, Brian? I've already described one easy technique: the host >> can create IIDs of any length, based on an algorithm that we might >> just be debating for a long time, but fundamentally can be quite >> straightforward. And then the host chooses the correct IID to use >> for SLAAC, based on the RA it just received. > > > Some people argue in the DNS "tussle" that it might be a problem if > the host receives different DNS-info from eg. RAs and DHCP. And now > we are discussing if the host should create its LL prefix length > based on a variable in the RAs? > > What if multiple routers in a network announces different prefix > lengths? This would cause MUCH greater problems Please identify such a problem. In my setting, I could put a /64 and a /65 PIOs in a same RA. The kernel of the existing Host would self-configure an address out of that /64 and ignore the /65. The software-to-be-written in userspace would consider only the /65 and form a second address. What do you think breaks in this casE? > than just getting an invalid DNS-server and would require much more > work for the operators to keep consistent throughout a complex > network. > > I can foresee scenarios here, where one router is deployed and > announcing prefix-lengths of /80 for its public prefix. Then > another router is added do the mix, that does not have the > flexibility to change the prefix-length, so it will always use /64. What breaks in this case? Who complains? I think the existing Host simply ignores the /65. > Then the operator would either have to renumber the first prefix to > /64 as well, or you would be stuck with two different prefixes > announced in the RAs, and the host constantly regenerating its LL. But the LLs have a prefix and plen that is distinct from the PIOs. It is fe80::/10. > Or you would be forever forced to always use the longest prefix for > all subnets, No. Let's make that into a requirement: the longet-prefix applies for forwarding but MUST NOT apply for address auto-configuration. > so as soon as I have deployed 2001:db8:1234:5678:9abc::/80 from one > ISP, I can never use anything but a /80 on that link no matter what > prefix size another ISP might give me. Right above. Alex > > > Rgds. > > Ola (T) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 13 05:03:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3397D1317D2 for ; Tue, 13 Jun 2017 05:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPEGUnfR3oIq for ; Tue, 13 Jun 2017 05:03:10 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 F11C51317D1 for ; Tue, 13 Jun 2017 05:03:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A9ED949; Tue, 13 Jun 2017 14:03:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1497355382; bh=31upkC2oQPCBQ6TEbn4 58q0akoTx3I6be+V8l46Lwy4=; b=Yt2y//AOPHElB42z8mz7IfPg0DW3xIagGmH f8tR+0TVXBIDQcUfDumqj+O1AAmJ8HFp83TiPTy3JhGCbvlHYYn9OlEKusN/QZbu ABi0hPdiTl6fxj7xTHpfYZBz5XLids8Am/boQSt7CDIvD2ps6I+sBc3e9y9MyX2z KSvRPDWM= 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 vRUuMrtLtyR7; Tue, 13 Jun 2017 14:03:02 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:9300:61fd:a5cc:817:90b0] (unknown [IPv6:2a02:a213:a300:9300:61fd:a5cc:817:90b0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 05DAC3C; Tue, 13 Jun 2017 14:03:02 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <80BEC076-FD27-43ED-B2D5-BF4FC7D442E6@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_33EDD6DE-811C-446B-8D86-3A7B4EFA8A3E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land Date: Tue, 13 Jun 2017 14:03:01 +0200 In-Reply-To: Cc: 6man To: Mark Smith References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 12:03:12 -0000 --Apple-Mail=_33EDD6DE-811C-446B-8D86-3A7B4EFA8A3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > (D) ignoring the operational consequences of making protocols and > devices harder to troubleshoot and rectify because it breaks source > address field semantics while the inserted EH is present. Should we define that "insertable" EHs have an "inserted by" field to = ease traceability, filtering and debugging? Cheers, Sander --Apple-Mail=_33EDD6DE-811C-446B-8D86-3A7B4EFA8A3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZP9R1AAoJEKAtA7D+JBO5YKkH/jRPJSfyk5Tocg54HAC6nVWU ft2bqB4bQRsBOAzvXBaK7xv0wKFjjfmaiK/g41a2q1l6eL0lILVYbDVpfTafHM8p hm0E+ULnj1WygL4TXmZdVZMg6gnaLAclX0S/7y+NRSbDhj5M8RJ7Mh9EK5owrxYd 8fYr/IEIBgVcQhY1nYLEUN0wuauRob8k0ngAw13G9c+y4YZXwh0nDSKK0dKlZ9EW xjq0uvearRDeX0xNmWeP0zoVI0KS1jGazJmr4qvwF7zwE/PWAdaeq/mBJRQ01j+x FSMPkPQHkVs0KeMs3u/6enxi4zvMy7j/RT26f9xnqnYOkHHtQ3YRgbC8THhEJmM= =2zTk -----END PGP SIGNATURE----- --Apple-Mail=_33EDD6DE-811C-446B-8D86-3A7B4EFA8A3E-- From nobody Tue Jun 13 06:58:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C781612EAE2 for ; Tue, 13 Jun 2017 06:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m25PY9WRd5a9 for ; Tue, 13 Jun 2017 06:57:58 -0700 (PDT) Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7284C1242F7 for ; Tue, 13 Jun 2017 06:57:56 -0700 (PDT) Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 13 Jun 2017 15:57:47 +0200 Received: from olen.dhcp.nlogic.no (213.52.81.38) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 13 Jun 2017 15:57:45 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> From: Ola Thoresen Message-ID: <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no> Date: Tue, 13 Jun 2017 15:57:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [213.52.81.38] X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:58:01 -0000 On 13. juni 2017 13:40, Alexandre Petrescu wrote: > > > Le 13/06/2017 à 09:51, Ola Thoresen a écrit : >> On 13. juni 2017 04:22, Manfredi, Albert E wrote: >> >>> Why so, Brian? I've already described one easy technique: the host >>> can create IIDs of any length, based on an algorithm that we might >>> just be debating for a long time, but fundamentally can be quite >>> straightforward. And then the host chooses the correct IID to use >>> for SLAAC, based on the RA it just received. >> >> >> Some people argue in the DNS "tussle" that it might be a problem if >> the host receives different DNS-info from eg. RAs and DHCP. And now >> we are discussing if the host should create its LL prefix length >> based on a variable in the RAs? >> >> What if multiple routers in a network announces different prefix >> lengths? This would cause MUCH greater problems > > Please identify such a problem. > > In my setting, I could put a /64 and a /65 PIOs in a same RA. > > The kernel of the existing Host would self-configure an address out of > that /64 and ignore the /65. The software-to-be-written in userspace > would consider only the /65 and form a second address. > > What do you think breaks in this casE? > I am not talking about that. I am talking about the idea of deducing the prefix length for _Link_Local_ addresses from the RAs. If the link local address is randomly generated, which is the case in major OSes today, there is no way to ensure that the LL you created for one > /64 prefix matches the LL of a second router which also announces a prefix > /64 on the same link. Link local needs to be /64 to ensure that you can reach all possible routers on the link - unless you are going to add multiple LL addresses to an interface as well. But then we are suddenly facing other potential issues, so I a not sure that is a path we want to go... >> than just getting an invalid DNS-server and would require much more >> work for the operators to keep consistent throughout a complex network. >> >> I can foresee scenarios here, where one router is deployed and >> announcing prefix-lengths of /80 for its public prefix. Then >> another router is added do the mix, that does not have the >> flexibility to change the prefix-length, so it will always use /64. > > What breaks in this case? Who complains? I think the existing Host > simply ignores the /65. > What /65? The user complains, because the LL-address generated after receiving a RA from router B might make router A unavailable. 1) Router A announces a /80 2) Host generates an LL: fe80::AAAA:1234:abcd:4321/80 3) Router B announces a /64 4) Host generates an LL: fe80::B000:1234:abcd:4321/64 to match the prefix length of the new RA Since that /64 does not match the /80 from router A, router A is no longer able to talk to the Link Local address of the Host. But just for arguments sake. Let the Host keep the address, but just change the prefix length... 4) Host changes its LL-prefix length to: fe80::AAAA:1234:abcd:4321/64 to match the prefix length of the new RA Then router C comes along and also wants to play, but using the prefix fe80::CCCC:0:0:0/80 for its link local network. Now, router A and C can not talk to each other, and the host can not talk to router C Or even worse Router D is added, with a /60 prefix length: fe80:0:0:D0::/60 - Now, the Host MUST change its prefix to talk to the new router, but that will make all the other routers unavailable. In a dynamic network, with more than one router, you simply must have the same prefix length for all link local addresses, and just keeping it a /64 is much easier than trying to create a new algorithm to solve all potential pitfalls of using different prefix lengths for Link Local. Rgds. Ola Thoresen From nobody Tue Jun 13 07:03:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8912EB69 for ; Tue, 13 Jun 2017 07:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNUWHEtaPok9 for ; Tue, 13 Jun 2017 07:03:14 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 CF23B131817 for ; Tue, 13 Jun 2017 07:03:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DE350B019023 for ; Tue, 13 Jun 2017 16:03:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A83EC205983 for ; Tue, 13 Jun 2017 16:03:05 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9DF86205820 for ; Tue, 13 Jun 2017 16:03:05 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DE359g027029 for ; Tue, 13 Jun 2017 16:03:05 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> From: Alexandre Petrescu Message-ID: <24cdaf3e-5c3e-0c52-3d95-536ced6e0ac7@gmail.com> Date: Tue, 13 Jun 2017 16:03:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:03:16 -0000 Le 13/06/2017 à 11:03, Roger Jørgensen a écrit : > On Sun, Jun 11, 2017 at 8:29 PM, wrote: > >> To summarize: >> - There is no technical reason why SLAAC cannot be made ot work with arbitrary prefix lengths. >> (including very long prefixes, although it might take a while to find a non-duplicate if the addressing model >> moves from sparse to dense). >> - There is no technical reason to have a fixed IID length defined by data-link type. >> - Removing the constant from the addressing architecture will likely set these changes into motion. >> (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary >> to stay in IPv6 over foo is tenable.) >> >> If that's what we want. I believe we have to think quite hard about it and we need to consider the consequences quite hard. > > what none so far (I might have missed it), have said anything about is > the policy side of IPv6 down the line if we start messing with the > 64bit constant. Can anyone summarize what else is based on the > argument that 64bit is the LAN side of things? > > whatever we do here will have wide scale effects. You can disagree or > disagree but why should let's say RIPE continue using /32 or /29's? > That argument is based on the amount of /48's and /56... which again > lead down to /64. Is RIPE agreeing that a cellular operator allocates a _single_ /64 per end-user? Does RIPE understand the wide scale negative effects of such an agreement? Alex > > next thing we know is the routing table. Sure call me crazy, but why > should there be a /48 constant there when we've removed the constants > everywhere else? > > > From nobody Tue Jun 13 07:06:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B94127B52 for ; Tue, 13 Jun 2017 07:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNPFNAugWuA2 for ; Tue, 13 Jun 2017 07:06:49 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 D48D712714F for ; Tue, 13 Jun 2017 07:06:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DE6kEW057704 for ; Tue, 13 Jun 2017 16:06:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0F40205983 for ; Tue, 13 Jun 2017 16:06:46 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8AF5F205820 for ; Tue, 13 Jun 2017 16:06:46 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DE6kn0030709 for ; Tue, 13 Jun 2017 16:06:46 +0200 Subject: Re: Tussles in IPv6 Land To: ipv6@ietf.org References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Alexandre Petrescu Message-ID: <2d51f919-bb6a-1f55-8338-0e568f5336b5@gmail.com> Date: Tue, 13 Jun 2017 16:06:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:06:50 -0000 Le 13/06/2017 à 11:10, Roger Jørgensen a écrit : > On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert wrote: > >> But that begs the question, why is /64 the one size fits all answer? >> What if in the future that number proves to be the wrong choices? >> Flexibility seems like a better way to future proof this. > > What I seem to remember, read or heard somewhere is that it went > something like this: > > IPv6 need more address space than IPv4 which is 32. > 64 was just double, let's double that again and we should be safe? > They end up with 128bit, and slice it in two half, /64. One for LAN > and one for network. > Why not? Because IPv4 Classes were removed. (a 64 boundary makes it a 'Class E' address, like 8 made it a Class A). Alex > > end of story. > > > From nobody Tue Jun 13 07:10:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BA0127A90 for ; Tue, 13 Jun 2017 07:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps2WDUXqiCph for ; Tue, 13 Jun 2017 07:10:19 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F62126B6E for ; Tue, 13 Jun 2017 07:10:19 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id g66so64567983vki.1 for ; Tue, 13 Jun 2017 07:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mBKX8gXcFa1zAdf4wpt1eQIl2L0oafS04MrMku7EF+c=; b=NxA4r49fFR3HU2O+mba1IUZc6GDLnbJODkBwIc8/1FU6gaNWJoUjPdHy0sio4hVNDe P2sssrjUPapDp2/DXkdz/IcaO010fJYZnou8kHs+yuiMt3AeJ3WutTViuvTw1Yovt1DY KajvUyCsBG7mHRD9KJINhEH3hHHp5L/caxzYChwjuZjYiDfOzsH6qrnw5FYfn+n+DzzT C48AVk2xRS/6O5FJC35zUZWLZlB/8Nr0ZnPyngbob0kJHX62nvgLWnNBhff4oBgJKKTI zI447UOSnEimLolSR5xC9221ZCuyNRLCnzgEBSDp6tI7Tr7hgOpvLv3BWGsOIx0ujtlk x4dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mBKX8gXcFa1zAdf4wpt1eQIl2L0oafS04MrMku7EF+c=; b=HjYs4Ww6B0E6j1jAT7XocxP7fjRF/Kqfjf54oJiEiqA2qxG+T7d7oSGKMwZAPI+qya wWiRRjsXEqrple/3gREaiDhbh9cxV/ozgbWulcKbYrFUm0mysjqZ6FOc/AwR07jQt0ez bS8SF1qMgtcyaxFjeY2slywqT8ru8mc17fY3WTVSTZb0ss1LvoSpgPh3fRcO9wKx8fsq yrKC2xw5M8tTSvP1SdjPmyR0cXCJnLrRqSQD+7MLerZE7kpW+8klDAiwyRlhreFwrC0t p96TXtVHZQ3wqpX4/id0FeV0xPg8Mo1Y5GY0fY50dx/WHz1335oL7BqqRvrFjhCnAJAt joPQ== X-Gm-Message-State: AKS2vOxFbc/LsWihNGzGIbIIIoICYCWcBoB4yJl6JWBYEfjLwB6GBFHO th7mzi8m7GSnIfEsiiz45BD2Y735Xg== X-Received: by 10.31.162.199 with SMTP id l190mr13384vke.110.1497363018118; Tue, 13 Jun 2017 07:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.67 with HTTP; Tue, 13 Jun 2017 07:10:17 -0700 (PDT) Received: by 10.176.92.67 with HTTP; Tue, 13 Jun 2017 07:10:17 -0700 (PDT) In-Reply-To: <2d51f919-bb6a-1f55-8338-0e568f5336b5@gmail.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <2d51f919-bb6a-1f55-8338-0e568f5336b5@gmail.com> From: Mark Smith Date: Wed, 14 Jun 2017 00:10:17 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Alexandre Petrescu Cc: 6man WG Content-Type: multipart/alternative; boundary="001a1143a4f2cb78100551d7fe6b" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:10:21 -0000 --001a1143a4f2cb78100551d7fe6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 14 Jun. 2017 00:07, "Alexandre Petrescu" wrote: Le 13/06/2017 =C3=A0 11:10, Roger J=C3=B8rgensen a =C3=A9crit : > On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert wrote: > > >> But that begs the question, why is /64 the one size fits all answer? >> What if in the future that number proves to be the wrong choices? >> Flexibility seems like a better way to future proof this. >> > > What I seem to remember, read or heard somewhere is that it went > something like this: > > IPv6 need more address space than IPv4 which is 32. > 64 was just double, let's double that again and we should be safe? > They end up with 128bit, and slice it in two half, /64. One for LAN > and one for network. > Why not? > Because IPv4 Classes were removed. Why were they removed? Why were they added? (a 64 boundary makes it a 'Class E' address, like 8 made it a Class A). Alex > end of story. > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a1143a4f2cb78100551d7fe6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 Jun. 2017 00:07, "Alexandre Petrescu" <alexandre.petrescu@gmail.com&g= t; wrote:


Le 13/06/2017 =C3=A0 11:10, Roger J=C3=B8rgensen a =C3=A9crit :
On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert <tom@herbertland.com> wrote:
<snip>
But that begs the question, why is /64 the one size fits all answer?
What if in the future that number proves to be the wrong choices?
Flexibility seems like a better way to future proof this.

What I seem to remember, read or heard somewhere is that it went
something like this:

IPv6 need more address space than IPv4 which is 32.
64 was just double, let's double that again and we should be safe?
They end up with 128bit, and slice it in two half, /64. One for LAN
and one for network.
Why not?

Because IPv4 Classes were removed.

Why were they removed?

Why were they added?



(a 64 boundary makes it a 'Class E' address, like 8 made it a Class= A).

Alex


end of story.




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

--001a1143a4f2cb78100551d7fe6b-- From nobody Tue Jun 13 07:11:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C753D12EB69 for ; Tue, 13 Jun 2017 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50PdOGKvdGMs for ; Tue, 13 Jun 2017 07:11:16 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 E49BA128D19 for ; Tue, 13 Jun 2017 07:11:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DEBETG023595 for ; Tue, 13 Jun 2017 16:11:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 50900205A43 for ; Tue, 13 Jun 2017 16:11:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 330822058DD for ; Tue, 13 Jun 2017 16:11:14 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DEBDDX001460 for ; Tue, 13 Jun 2017 16:11:13 +0200 Subject: Re: Tussles in IPv6 Land To: ipv6@ietf.org References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Jun 2017 16:11:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:11:18 -0000 Le 13/06/2017 à 11:29, Lorenzo Colitti a écrit : > On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert > wrote: > > ILA is an innovative way to use IPv6 addresses, but as I described it > can't use this in a mobile network if every UE gets a /64. In this > case too much space is given the end host which probably a low end > device like a smart phone that really doesn't need it. > > > Again, that's the perception from the network operator side of the > tussle. The perception from the other side is, "these bits belong to > hosts, go and do mobility in the top 64 bits". It's really not hard to > do mobility in the network layer. Just build a low-overhead tunneling > mechanism that maps /64 prefixes belonging to nodes to base station IP > addresses. We have lots of those, GTP being one. The overhead doesn't > need to be 40 bytes, either - you could Deployed GTP-based mobility of a /64 still does not solve the need of multiple such /64s in a single moving network. Unless cellular operators provide mobility of a /56 - it's not the case. Alex > > But that begs the question, why is /64 the one size fits all answer? > > > Because if you don't have a one-size-fits-all answer, you end up with > not enough space. Your assertion above is "a mobile device doesn't need > /64". Even if your assertion were true today (which I think it isn't - a > full /64 is necessary to ensure that all devices behind the mobile node > can run SLAAC, for example), whatever address space you think a mobile > device will "need" is going to be based on how much you think a mobile > device needs today, and that's going to constrain future usage. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jun 13 07:30:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7512EACA for ; Tue, 13 Jun 2017 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ckA2tcFUDN6 for ; Tue, 13 Jun 2017 07:30:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 6C3A612EAC0 for ; Tue, 13 Jun 2017 07:29:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5DETZUT074274 for ; Tue, 13 Jun 2017 16:29:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 664F6205820 for ; Tue, 13 Jun 2017 16:29:35 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C8F7202E63 for ; Tue, 13 Jun 2017 16:29:34 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5DETYht015344 for ; Tue, 13 Jun 2017 16:29:34 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no> From: Alexandre Petrescu Message-ID: <20568267-7ca4-8d31-238c-ecf3271bd84e@gmail.com> Date: Tue, 13 Jun 2017 16:29:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:30:46 -0000 Le 13/06/2017 à 15:57, Ola Thoresen a écrit : > On 13. juni 2017 13:40, Alexandre Petrescu wrote: > >> >> >> Le 13/06/2017 à 09:51, Ola Thoresen a écrit : >>> On 13. juni 2017 04:22, Manfredi, Albert E wrote: >>> >>>> Why so, Brian? I've already described one easy technique: the host >>>> can create IIDs of any length, based on an algorithm that we might >>>> just be debating for a long time, but fundamentally can be quite >>>> straightforward. And then the host chooses the correct IID to use >>>> for SLAAC, based on the RA it just received. >>> >>> >>> Some people argue in the DNS "tussle" that it might be a problem if >>> the host receives different DNS-info from eg. RAs and DHCP. And now >>> we are discussing if the host should create its LL prefix length >>> based on a variable in the RAs? >>> >>> What if multiple routers in a network announces different prefix >>> lengths? This would cause MUCH greater problems >> >> Please identify such a problem. >> >> In my setting, I could put a /64 and a /65 PIOs in a same RA. >> >> The kernel of the existing Host would self-configure an address out of >> that /64 and ignore the /65. The software-to-be-written in userspace >> would consider only the /65 and form a second address. >> >> What do you think breaks in this casE? >> > > > I am not talking about that. I am talking about the idea of deducing the > prefix length for _Link_Local_ addresses from the RAs. I see, that's why. I was talking about PIOs for GUAs or ULAs, not for LLs. > If the link local address is randomly generated, which is the case in > major OSes today, there is no way to ensure that the LL you created for > one > /64 prefix matches the LL of a second router which also announces > a prefix > /64 on the same link. > Link local needs to be /64 to ensure that you can reach all possible > routers on the link - unless you are going to add multiple LL addresses > to an interface as well. > But then we are suddenly facing other potential issues, so I a not sure > that is a path we want to go... > > > >>> than just getting an invalid DNS-server and would require much more >>> work for the operators to keep consistent throughout a complex network. >>> >>> I can foresee scenarios here, where one router is deployed and >>> announcing prefix-lengths of /80 for its public prefix. Then >>> another router is added do the mix, that does not have the >>> flexibility to change the prefix-length, so it will always use /64. >> >> What breaks in this case? Who complains? I think the existing Host >> simply ignores the /65. >> > > What /65? > > The user complains, because the LL-address generated after receiving a > RA from router B might make router A unavailable. > > 1) Router A announces a /80 > 2) Host generates an LL: fe80::AAAA:1234:abcd:4321/80 > 3) Router B announces a /64 > 4) Host generates an LL: fe80::B000:1234:abcd:4321/64 to match the > prefix length of the new RA > > Since that /64 does not match the /80 from router A, router A is no > longer able to talk to the Link Local address of the Host. I am not sure what you meant by "router A not able to talk to Host"? I think you meant rather that Host is not able to send packets to Router A? (because Router A does not see the /64 of Router B). If so (Host not able to send packets to Router A) then I think this might be a typical problem of source address selection. This is independent of the address being of LL kind. > But just for arguments sake. Let the Host keep the address, but just > change the prefix length... > > 4) Host changes its LL-prefix length to: fe80::AAAA:1234:abcd:4321/64 to > match the prefix length of the new RA > > Then router C comes along and also wants to play, but using the prefix > fe80::CCCC:0:0:0/80 for its link local network. > Now, router A and C can not talk to each other, and the host can not > talk to router C > > Or even worse > > Router D is added, with a /60 prefix length: fe80:0:0:D0::/60 - Now, the > Host MUST change its prefix to talk to the new router, but that will > make all the other routers unavailable. Well, if the plen is made variable in an RFC it does not mean that people will add buttons to their computers and play them daily like tuning an FM radio. But if they do, it's at their risk :-) > In a dynamic network, with more than one router, you simply must have > the same prefix length for all link local addresses, and just keeping it > a /64 is much easier than trying to create a new algorithm to solve all > potential pitfalls of using different prefix lengths for Link Local. Err... I tend to agree. But I think too that in a dynamic network computers may agree somehow dynamically on a plen to use. An example of it is a seed in the SLAAC RFC which says that a router may interpret a prefix of another router, but left unsepcified. Another seed is the agreement Home Agents establish when exchanging router advertisements, or BGP routers, or VRRP, or others. I also tend to think that it may be easier to leave fe80::/10 (not fe80::/64) as a constant and not put it in RA. But maybe we can look at it closer. Alex > > > Rgds. > > Ola Thoresen > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jun 13 09:40:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D643112EB18 for ; Tue, 13 Jun 2017 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6qMS5H09G6U for ; Tue, 13 Jun 2017 09:40:02 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 9CB0C12EB3A for ; Tue, 13 Jun 2017 09:39:59 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u19so179615044qta.3 for ; Tue, 13 Jun 2017 09:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=83wqrT4lC1froF79soXJrlavwSQ5Y8rGZYLrytAEqB0=; b=W6QIVjE7eF4CFZutt75+eMsTQ2/tdffMiSjNUSnrrYUXAX5QB8XT2bjqZ2+MXe507n s8KT3cAuW7uuDZAiDEbAkpiTol11gYba4ixRTJ2/KF5KF+IKCLQg0NlCi+9IFw1A4rQ6 46tc02MXjdnN979UJVglwVTVAM5RDTlh3rDMc1RommG0GuRsB3jU+vjxjRRcHNevCwHk jRQq/nSVZW8XWd8GWqibSF7FDh+0DlgJ1tuFp80xCE3LUJ3LvyBdBHhNad61e4Wr6Juo Ddm2FF+xSYHhhxzVzsaQVTj4qhacUJGiDjEZQlxqBqTu6VjJ0FSQ0wBHmTwK/9h9Kojd 5xMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=83wqrT4lC1froF79soXJrlavwSQ5Y8rGZYLrytAEqB0=; b=UIke/ODJ3/uCCUEEp63yZNvRap92PcZsXApFTyZgEq00pjjzHlkhtVS8ok18b1OYXK QYK4Tw20zClEX6fb47Z4Rjrd7IcLrM5+AWLQOsbhnHVRREXlbg4eKiW87awj9LFLzYm6 ffmK6IP/LocXVUNR6AvXKUyoQ763gTueODX6T3HnrCVFk85FNb+LD3bR/BUatwRKxd8T yfXHCuCAMCD93rdPYDgelkgDrtrSJaOGj1ZADfsso4jWtt3OETpaaRq1VB91sN/laT8K uKY0f0tiSlfWM+Di/dlSLLIqNQLLTZvxrvTvFLG6dzv+f7j5oy72GthvIBBhNJuJpFdu Nttg== X-Gm-Message-State: AKS2vOzSdWJz1ovXTpcAp3hMxWLofDvga+gRS5glii5GTq7zrdOQ6z4P p43NiyZwiXHX2Idi7NZbvw3u0qMVdg== X-Received: by 10.55.158.208 with SMTP id h199mr1015924qke.254.1497371998629; Tue, 13 Jun 2017 09:39:58 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.53 with HTTP; Tue, 13 Jun 2017 09:39:57 -0700 (PDT) In-Reply-To: <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 13 Jun 2017 09:39:57 -0700 X-Google-Sender-Auth: jZgH4RqSj9ozDNsWpVjprTSTCdU Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Fernando Gont , Ole Troan , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:40:09 -0000 At Tue, 13 Jun 2017 13:26:59 +1200, Brian E Carpenter wrote: > > Router advertised Prefix/N (where N is nowadays hardcoded to be "64", > > but need not). Host eploys RFC7217, and grabs 128-N random bits from F() > > to generate the IID/address. > > > > Why does N need to be set on a per-link-type basis? > > It doesn't *need* to be. But SLAAC by design assumes that it is > set per link-type; that is architectural flexibility which is > removed by RFC4291, which IMHO is a bad message to send to the future. I don't get the "which is removed by RFC4291" part. Are you saying that the "architectural flexibility" existed with RFC3513 but was removed with RFC4291? RFC3513 already had this text: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Even RFC2373 had this: (2) The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. See section 2.5.1 for definitions. If I understand the "architectural flexibility" correctly, that flexibility was already removed by RFC2373. We were aware that the constraint in the addressing architecture can cause nasty issues in terms of the assumption of SLAAC (IID length is defined by link-type doc) at the time of rfc2462bis discussions but intentionally left it that way. Of course, we can still revisit the decision at that time, but I don't think it wise to do so in the context of rfc4291bis (see also below). In any case, > I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis > back to us, and the main reason I signed on to draft-bourbaki-6man-classless-ipv6 I don't think it's the reason why rfc4291bis was sent back. As far as I can see it was largely due to disagreement based on misunderstanding: - some people conflated on-link prefixes and subnet prefixes (where the latter is the prefix that is followed by IID in the addressing architecture) and objected to keeping the length of the latter to be 64 bits for most unicast addresses, while what they really wanted is variable-length on-link prefixes and they already have them. - some other people wanted to keep the length of subnet prefixes to be 64 bits. but perhaps those people interpreted the objection from the first group as an objection to keeping the subnet prefix length, and fired back at it. If the main goal for draft-bourbaki-6man-classless-ipv6 is to resolve this gridlock so we can move forward with rfc4291bis, the resolution is IMO quite simple: just to clarify the main misunderstanding. No architectural or protocol change is necessary: https://www.ietf.org/mail-archive/web/ipv6/current/msg27679.html Now, we are seeing a third group: - yet some other people do not think keeping the subnet prefix length to be 64 bits (for most unicast addresses) does not make sense at all and argue for loosening it. There are some variations of this group. Reintroducing the "architectural flexibility" (by making the subnet prefix/IID length only dependent on link-type specs) could be considered one of them. Some other people even suggest making it independent from the link-type and leaving it to host/operator's choice. We can discuss this proposal, but IMO this should be deferred as post-rfc4291bis fodder. I expect this will be a very controversial discussion that will take quite long time (at least the second group of people will fiercely fight against it), and there are currently very few (if not no) implementations of the most flexible behavior (i.e., making IID length fully variable) so it won't be compatible with the scope of rfc4291bis. -- JINMEI, Tatuya From nobody Tue Jun 13 10:13:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9013192C for ; Tue, 13 Jun 2017 10:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-9gdyI7IKxh for ; Tue, 13 Jun 2017 10:13:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id DE203131929 for ; Tue, 13 Jun 2017 10:13:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dKpO2-0000HlC; Tue, 13 Jun 2017 19:13:50 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Tussles in IPv6 Land From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-reply-to: Your message of "Mon, 12 Jun 2017 08:20:56 -0700 ." Date: Tue, 13 Jun 2017 19:13:49 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:13:56 -0000 >ILA is an innovative way to use IPv6 addresses, but as I described it >can't use this in a mobile network if every UE gets a /64. In this >case too much space is given the end host which probably a low end >device like a smart phone that really doesn't need it. Long prefixes are supported by DHCPv6 IA_NA today. Don't wait for SLAAC to change. Just use DHCPv6. SLAAC inherently wastes a lot of bits. In the past because of modified EUI-64, today because of pseudo randomness. If you want to free up bits for other purposes, increase allocation efficiency and use DHCPv6. From nobody Tue Jun 13 10:22:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8996512940F for ; Tue, 13 Jun 2017 10:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Hu8T9d3PCP for ; Tue, 13 Jun 2017 10:22:34 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCC712941C for ; Tue, 13 Jun 2017 10:22:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dKpWQ-0000E4C; Tue, 13 Jun 2017 19:22:30 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Tussles in IPv6 Land From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <033901d2e390$ed5b38e0$c811aaa0$@oneunified.net> In-reply-to: Your message of "Mon, 12 Jun 2017 12:31:13 -0300 ." <033901d2e390$ed5b38e0$c811aaa0$@oneunified.net> Date: Tue, 13 Jun 2017 19:22:29 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:22:36 -0000 >Out of curiosity, when a smartphone is used in tethered mode, ie, devices >are hanging off it via the built in hot-spot, do the devices get an address >out of the smartphone /64, or should the phone have a /60 or maybe /56 to >handoff to those devices? Say, as LTE gets more predominant, powerful, and >bandwidth capable, maybe with rural/farming areas getting into more IoT >stuff, maybe have a router hanging off that tethered hotspot? There are enough /48 prefixes that we will never run out if we give every paying customer a /48. There are enough /64 prefixes that we can give every link its own /64 and we will never run out. So whenever you find yourself subdividing a /64, look at where in the hierarchy bits are left unused. And then fix it at that level. From nobody Tue Jun 13 10:26:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0B131447 for ; Tue, 13 Jun 2017 10:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApFUPwySldrX for ; Tue, 13 Jun 2017 10:25:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E0FC1129457 for ; Tue, 13 Jun 2017 10:25:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dKpZm-0000EpC; Tue, 13 Jun 2017 19:25:58 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Tussles in IPv6 Land From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-reply-to: Your message of "Tue, 13 Jun 2017 10:15:54 -0700 ." Date: Tue, 13 Jun 2017 19:25:57 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:26:00 -0000 >Not everyone supports DHCPv6 as you probably know ;-) I know, but we should just treat those devices as IPv4-only and move on. It is not a good position to let one OS vendor lock up a large part of the IPv6 protocol. From nobody Tue Jun 13 11:30:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87095124BE8 for ; Tue, 13 Jun 2017 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8JHVE4wQ0QW for ; Tue, 13 Jun 2017 11:30:23 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 AD6E71243F6 for ; Tue, 13 Jun 2017 11:30:22 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id 36so33996611wry.3 for ; Tue, 13 Jun 2017 11:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2E0LfcAWfCdw2W1YL2GYKZaaq4CQEzpT3mCLoYRQf7Y=; b=lLb+vH08yVzGj847lf2SVIGR2AOh1BZH2ygvlsfhgn0gLvMiZ9gt2CEjdKLK0jaqn1 ZSz9gA1BWCuLA9VZVAX5MxBHKa7j4WNA6Ff/mjGKwAoTs5Kyc5fYwnpIymYNliDU9le5 bQtQeP4RMAQg6mW7FtlxWNXWUJhNEUgZf6NbChCeocDiRRzAC7yKf1jXTGF220DbBOSx f3IgwHzrASCaGrpBDG1m3XPauaWOFDO5c8ARy8hvu7PnGtRBZ2MyMj0YyhDkleoDPAcm 4GjQi8VqyIdVe4y5Oj0vz9mRysry+4wrNUgsNnWS/TFyRa7//8QVW7dw65wuWv3R6wJ7 kiWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=2E0LfcAWfCdw2W1YL2GYKZaaq4CQEzpT3mCLoYRQf7Y=; b=KOrufgdGGcqZP6Gc8CbJ7KWJ41TXgJRzZcYhMHvkbvHjPN6IsFlMlsn/wJ+EKgwWun qJDnocRv/+GWnbasGv0sZ3XHNCWZN+bQHkX5L1NK7oIfFj7mbL4XTgILhhF0eRKcztcM s5VOaV4sW7HtKyfbSYHrvmxVLnZW1zXfbyVQbo8XcsQJFdwHscs6C3eFQiqTI6e4ixu8 fPlqYTqWGdf8L5pau+Exr5Ftw3ohPhx359vNub+Ed5B+kBOAHrsNjCFAhODtHx7pmNMl PHz54AA09QksLp+OBnKfZXNYWrirPK4/HGpfzesTwE/ZJvRj+vlOeqmtZ6LVNyifz6A4 lEhg== X-Gm-Message-State: AKS2vOwVdGvnX0qaA8B1fjvMLVbjgFl1Hm7hvpQ8cEUupToGKkHe9VSd ItXFZP6bPNVrz1WjySZSOumDnjB9/Q== X-Received: by 10.223.174.194 with SMTP id y60mr4280432wrc.155.1497378621220; Tue, 13 Jun 2017 11:30:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.207 with HTTP; Tue, 13 Jun 2017 11:30:20 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Behcet Sarikaya Date: Tue, 13 Jun 2017 13:30:20 -0500 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Tom Herbert , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a1140860acfeba80551dba06e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:30:25 -0000 --001a1140860acfeba80551dba06e Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 4:29 AM, Lorenzo Colitti wrote: > On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert wrote: > >> ILA is an innovative way to use IPv6 addresses, but as I described it >> can't use this in a mobile network if every UE gets a /64. In this >> case too much space is given the end host which probably a low end >> device like a smart phone that really doesn't need it. >> > > Again, that's the perception from the network operator side of the tussle. > The perception from the other side is, "these bits belong to hosts, go and > do mobility in the top 64 bits". It's really not hard to do mobility in the > network layer. Just build a low-overhead tunneling mechanism that maps /64 > prefixes belonging to nodes to base station IP addresses. We have lots of > those, GTP being one. The overhead doesn't need to be 40 bytes, either - > you could > > But that begs the question, why is /64 the one size fits all answer? >> > > Because if you don't have a one-size-fits-all answer, you end up with not > enough space. Your assertion above is "a mobile device doesn't need /64". > Even if your assertion were true today (which I think it isn't - a full /64 > is necessary to ensure that all devices behind the mobile node can run > SLAAC, for example), whatever address space you think a mobile device will > "need" is going to be based on how much you think a mobile device needs > today, and that's going to constrain future usage. > > I also have some comments on this. But more importantly this discussion belongs to 5gangip list because it is where it started. Behcet > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a1140860acfeba80551dba06e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 13, 2017 at 4:29 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
On Tue, Jun 13, 2017 at 12:20 A= M, Tom Herbert <tom@herbertland.com> wrote:
ILA is an innovative way to use IPv6 addresses, but as I described it=
can't use this in a mobile network if every UE gets a /64. In this
case too much space is given the end host which probably a low end
device like a smart phone that really doesn't need it.
=

Again, that's the perception from the networ= k operator side of the tussle. The perception from the other side is, "= ;these bits belong to hosts, go and do mobility in the top 64 bits". I= t's really not hard to do mobility in the network layer. Just build a l= ow-overhead tunneling mechanism that maps /64 prefixes belonging to nodes t= o base station IP addresses. We have lots of those, GTP being one. The over= head doesn't need to be 40 bytes, either - you could=C2=A0
<= div>
But that begs the question, why is /64 the o= ne size fits all answer?

Because= if you don't have a one-size-fits-all answer, you end up with not enou= gh space. Your assertion above is "a mobile device doesn't need /6= 4". Even if your assertion were true today (which I think it isn't= - a full /64 is necessary to ensure that all devices behind the mobile nod= e can run SLAAC, for example), whatever address space you think a mobile de= vice will "need" is going to be based on how much you think a mob= ile device needs today, and that's going to constrain future usage.



I also have some commen= ts on this.
But more importantly this discussion belongs to 5gang= ip list because it is where it started.

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


--001a1140860acfeba80551dba06e-- From nobody Tue Jun 13 11:32:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6A4127843 for ; Tue, 13 Jun 2017 11:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3_kWwwHcRnp for ; Tue, 13 Jun 2017 11:32:04 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803C51243F6 for ; Tue, 13 Jun 2017 11:32:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5DIW3SK060461; Tue, 13 Jun 2017 11:32:03 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5DIVuNx060391 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 13 Jun 2017 11:31:56 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 11:31:55 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 11:31:55 -0700 From: "Manfredi, Albert E" To: Ola Thoresen , "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAARhCgIAAbSKAgAGcDQD//5E4sIAA18QAgABAIYCAACZZAP//0u7Q Date: Tue, 13 Jun 2017 18:31:55 +0000 Message-ID: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no> In-Reply-To: <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.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: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:32:06 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPbGEgVGhvcmVzZW4NCg0KPiBJIGFtIHRhbGtpbmcg YWJvdXQgdGhlIGlkZWEgb2YgZGVkdWNpbmcgdGhlIHByZWZpeCBsZW5ndGggZm9yDQo+IF9MaW5r X0xvY2FsXyBhZGRyZXNzZXMgZnJvbSB0aGUgUkFzLiBJZiB0aGUgbGluayBsb2NhbCBhZGRyZXNz IGlzDQo+IHJhbmRvbWx5IGdlbmVyYXRlZCwgd2hpY2ggaXMgdGhlIGNhc2UgaW4gbWFqb3IgT1Nl cyB0b2RheSwgdGhlcmUgaXMNCj4gbm8gd2F5IHRvIGVuc3VyZSB0aGF0IHRoZSBMTCB5b3UgY3Jl YXRlZCBmb3Igb25lID4gLzY0IHByZWZpeA0KPiBtYXRjaGVzIHRoZSBMTCBvZiBhIHNlY29uZCBy b3V0ZXIgd2hpY2ggYWxzbyBhbm5vdW5jZXMgYSBwcmVmaXggPg0KPiAvNjQgb24gdGhlIHNhbWUg bGluay4NCg0KSWYgdHdvIHJvdXRlcnMgb24gYSBsaW5rIG9mZmVyIHByZWZpeGVzIG9mIHRoZSBz YW1lIGxlbmd0aCB0byBhIGdpdmVuIGhvc3QsIHRoZW4gdGhlIHNpbXBsZSB0cnVuY2F0aW9uIGFs Z29yaXRobSBJIGFsbHVkZWQgdG8gd291bGQgZ2VuZXJhdGUgdGhlIHNhbWUgSUlEIHRvIGJlIHVz ZWQgaW4gYm90aCBjYXNlcy4gRm9yIGluc3RhbmNlLCAidHJ1bmNhdGUgdGhlIHVwcGVyIE4gYml0 cyBvZiB0aGF0IHJhbmRvbSAxMjgtYml0IHZhbHVlLCIgd2hlcmUgTiBpcyB0aGUgcHJlZml4IGxl bmd0aC4NCg0KSWYgdGhvc2UgdHdvIHJvdXRlcnMgb2ZmZXJlZCBkaWZmZXJlbnQgcHJlZml4IGxl bmd0aHMsIHRoZW4gY2xlYXJseSB0aGUgSUlEcyB1c2VkIHdvdWxkIGhhdmUgdG8gYmUgb2YgZGlm ZmVyZW50IGxlbmd0aHMuIElzIHRoZXJlIGEgcHJvYmxlbT8gSSBkb27igJl0IHNlZSBhIHByb2Js ZW0uIFlvdSBzaG91bGQgYmUgYWJsZSB0byBoYXZlIG11bHRpcGxlIGFkZHJlc3NlcyBhc3NpZ25l ZCB0byBhbiBpbnRlcmZhY2Ugd2l0aCBkaWZmZXJlbnQgbGVuZ3RocyBvZiBwcmVmaXggYW5kIElJ RCwgd2l0aCBubyBwcm9ibGVtLg0KDQo+IExpbmsgbG9jYWwgbmVlZHMgdG8gYmUgLzY0IHRvIGVu c3VyZSB0aGF0IHlvdSBjYW4gcmVhY2ggYWxsIHBvc3NpYmxlDQo+IHJvdXRlcnMgb24gdGhlIGxp bmsgLSB1bmxlc3MgeW91IGFyZSBnb2luZyB0byBhZGQgbXVsdGlwbGUgTEwNCj4gYWRkcmVzc2Vz IHRvIGFuIGludGVyZmFjZSBhcyB3ZWxsLg0KDQpJIGRvbuKAmXQgZ2V0IHRoYXQuIElmIHlvdSBz dGFydCB3aXRoIHRoZSBwcmVtaXNlIHRoYXQgYWxsIElJRHMgYXJlIHRvIGJlIDY0IGJpdHMgd2lk ZSwgVEhFTiB5b3UgY2FuIGNyZWF0ZSBhIHNpbXBsZSBydWxlIHRoYXQgdGhlIExMQSBJSUQgYW5k IGFueSBTTEFBQyBJSUQgd2lsbCBlbmQgdXAgYmVpbmcgaWRlbnRpY2FsLiBCdXQgdGhlcmUncyBu byBvdGhlciByZWFzb24gdG8gYXNzdW1lIHRoYXQgdGhpcyBpcyBhIHJlcXVpcmVtZW50LiBJdCBq dXN0IGZvbGxvd3MgYXMgYSBjb25zZXF1ZW5jZSBvZiB0aGF0IGluaXRpYWwgcHJlbWlzZSwgd2hp Y2ggd2FzIGJhc2VkIG9uIHRoZSBpZGVhIG9mIEVVSS02NC4NCg0KTGVhdmluZyBhc2lkZSBTTEFB QyBpdHNlbGYsIElQdjQgaXMgcGVyZmVjdGx5IGNhcGFibGUgb2YgZGVhbGluZyB3aXRoIG11bHRp cGxlIElQIGFkZHJlc3NlcyBhc3NpZ25lZCB0byBhbiBpbnRlcmZhY2UsIHdpdGggYSBkaWZmZXJl bnQgYWRkcmVzcyBtYXNrIHBlciBhZGRyZXNzLiBUaGlzIGNyZWF0ZXMgbm8gcHJvYmxlbXMsIGlu IG15IGV4cGVyaWVuY2UuDQoNCkJlcnQNCg0K From nobody Tue Jun 13 11:47:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D62129454 for ; Tue, 13 Jun 2017 11:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP7S0wkf2sPP for ; Tue, 13 Jun 2017 11:47:07 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0B129409 for ; Tue, 13 Jun 2017 11:47:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5DIl6Lx021492; Tue, 13 Jun 2017 11:47:06 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5DIkx5E021407 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 13 Jun 2017 11:46:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 11:46:58 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 11:46:58 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAARhCgIAAbSKAgAGcDQD//5E4sIAAB9HQgACir4CAAGy4QA== Date: Tue, 13 Jun 2017 18:46:58 +0000 Message-ID: <2c565dbf85f44d23abf831fa296c47e1@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:47:09 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPiBBbHNvIHNlZSBHZW5neXUgV2Vp J3MgbWVzc2FnZTogd2hlbiBkZXZpY2VzIHJvYW0sIHdoYXQgaGFwcGVucw0KPiBpZiB0aGUgTEwg SUlEIGxlbmd0aCBmb3IgYSBnaXZlbiBpbnRlcmZhY2UgaXMgc3VwcG9zZWQgdG8gY2hhbmdlPw0K PiBESVAgc3dpdGNoZXMgYWdhaW4/DQoNClllcywgdGhlIElJRCBsZW5ndGggd291bGQgY2hhbmdl LCBidXQgdGhpcyBjYW4gZWFzaWx5IGJlIHdpdGhvdXQgdXNlIG9mIERJUCBzd2l0Y2hlcy4gSXQg Y2hhbmdlcyBkeW5hbWljYWxseSwgd2l0aCBhIG5ldyBwcmVmaXggbGVuZ3RoIG9mZmVyZWQgaW4g dGhlIFJBLg0KDQo+IEl0IGRvZXNuJ3QgbWF0dGVyLiBJZiBpdCBpc24ndCBiYWNrd2FyZHMgY29t cGF0aWJsZSB3aXRoDQo+IGRlcGxveWVkIGNvZGUsIElNSE8gaXQgaXNuJ3QgZ29pbmcgdG8gaGFw cGVuIG9uIEV0aGVybmV0IG9yDQo+IFdpLUZpLg0KDQpJIHJlbWVtYmVyIGZpcnN0IHNldHRpbmcg dXAgbXkgd29ya3N0YXRpb24sIGF0IHdvcmssIGZvciBESENQLCBhcyBhIGd1aW5lYSBwaWcgZm9y IHRoZSByZXN0IG9mIHRoZSBvZmZpY2UuIE5vIHByb2JsZW0uIEFsbCB0aGUgb3RoZXIgaG9zdHMg Y29udGludWVkIHRvIHdvcmsganVzdCBmaW5lLiBUaGlzIHdvdWxkIGJlIGJhY2t3YXJkIGNvbXBh dGlibGUsIGluIHRoZSBzZW5zZSB0aGF0IGV4aXN0aW5nIGhvc3RzIHdvdWxkIG9ubHkgYmUgYWJs ZSB0byB1c2UgNjQtYml0IHByZWZpeCBsZW5ndGhzIGluIFJBcywgdG8gY29uZmlndXJlIFNMQUFD LiBObyBwcm9ibGVtLiBZb3UgY2FuIGVpdGhlciBjb250aW51ZSB0byBvZmZlciBhIDY0LWJpdCBw cmVmaXggbGVuZ3RoLCBmb3IgbGVnYWN5IGhvc3RzIHRvIHVzZSBTTEFBQywgb3IgeW91IGNhbiBz dG9wIG9mZmVyaW5nIDY0LWJpdCBJSURzLCBhbmQgbGVnYWN5IGhvc3RzIHdvdWxkIGJlIHVuYWJs ZSB0byBjb25maWd1cmUgU0xBQUMgYWRkcmVzc2VzLg0KDQpCZXJ0DQoNCg== From nobody Tue Jun 13 12:35:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D115F12956B for ; Tue, 13 Jun 2017 12:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svHUn-yhXrkE for ; Tue, 13 Jun 2017 12:35:54 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7835912954B for ; Tue, 13 Jun 2017 12:35:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5DJZrVE038999; Tue, 13 Jun 2017 12:35:53 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5DJZg5d038437 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 13 Jun 2017 12:35:42 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 12:35:41 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 12:35:41 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAARhCgIAAbSKAgAGcDQD//5E4sIAAB9HQgACir4CAAGy4QIAADpwQ Date: Tue, 13 Jun 2017 19:35:41 +0000 Message-ID: <4b1bc31dcb644b2ab593271b39a49cea@XCH15-06-11.nw.nos.boeing.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 19:35:56 -0000 SW4gY2FzZSBJIHdhc24ndCBjbGVhciBpbiB0aGlzIHJlcGx5Og0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb21dIA0KDQo+IEFsc28gc2VlIEdlbmd5dSBXZWkncyBtZXNzYWdlOiB3aGVu IGRldmljZXMgcm9hbSwgd2hhdCBoYXBwZW5zDQo+IGlmIHRoZSBMTCBJSUQgbGVuZ3RoIGZvciBh IGdpdmVuIGludGVyZmFjZSBpcyBzdXBwb3NlZCB0byBjaGFuZ2U/DQo+IERJUCBzd2l0Y2hlcyBh Z2Fpbj8NCg0KWWVzLCB0aGUgSUlEIGxlbmd0aCB3b3VsZCBjaGFuZ2UgKmZvciBnZW5lcmF0aW5n IGEgU0xBQUMgYWRkcmVzcyosIGJ1dCB0aGlzIGNhbiBlYXNpbHkgYmUgd2l0aG91dCB1c2Ugb2Yg RElQIHN3aXRjaGVzLiBJdCBjaGFuZ2VzIGR5bmFtaWNhbGx5LCB3aXRoIGEgbmV3IHByZWZpeCBs ZW5ndGggb2ZmZXJlZCBpbiB0aGUgUkEuDQoNClRoZSBsaW5rIGxvY2FsIGFkZHJlc3Mgb2YgdGhh dCBpbnRlcmZhY2UgZG9lcyBub3QgbmVlZCB0byBjaGFuZ2UsIG9mIGNvdXJzZS4gVGhlIGxpbmsg bG9jYWwgYWRkcmVzcyBjYW4gY29udGludWUgdG8gaGF2ZSBpdHMgNjQtYml0IElJRC4gSXQgd291 bGQganVzdCBubyBsb25nZXIgYmUgdGhlIGNhc2UgdGhhdCB0aGUgSUlEIG9mIHRoZSBMTEEsIGFu ZCB0aGUgSUlEIG9mIHRoZSBTTEFBQyBhZGRyZXNzLCB3b3VsZCBuZWNlc3NhcmlseSBiZSBpZGVu dGljYWwuIEFsdGhvdWdoIGRlcGVuZGluZyBob3cgSUlEcyBhcmUgZ2VuZXJhdGVkLCB5b3UgbWln aHQgZW5kIHVwIHdpdGggdGhlIGxvd2VyIGJpdHMgb2YgdGhlIElJRCBiZWluZyBpZGVudGljYWwu DQoNCkJlcnQNCg0K From nobody Tue Jun 13 13:28:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D912EAB2 for ; Tue, 13 Jun 2017 13:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR58h3j3aLnV for ; Tue, 13 Jun 2017 13:28:52 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 ED6D112DFE0 for ; Tue, 13 Jun 2017 13:28:51 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v18so65541461pgb.1 for ; Tue, 13 Jun 2017 13:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=55uIvTJyn5Em/M28+BR/FdT/jt2Pg0cL/vrUT07D/UE=; b=Xf6E1SDHdYdTx3Q120CZBWvQFL/9E9DrzumMfNBFtW6ZZgfRMoBUqDNBF0RvsGO69N vRxr3bonF6AfLZXcV9/n4tOB3t8pg5JdExbUDBl2cFRSeWklhO0JxCRRApqbpVwsW+yi 0glCczpk1kgeilYHQwZHc7EjJZuH4nvMajNlFribnqk+WbugAKe7gLIp4PWLAIkqhimI krQ2eqrOcU4zu7trYFzIzVgHqXlskGJkTXJ0bYnMxIS6aMDJTbqekjW/0H2Q2RR11Fah AOr7kMl+JETqwXob3kGwYEiBN/Hoi3P3G6BBnPRvK9UX8tf2w5krjZj0TIeMCXCsx+ZK D5AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=55uIvTJyn5Em/M28+BR/FdT/jt2Pg0cL/vrUT07D/UE=; b=DZ+pEURypFRbOq2bD1pCwzErEX3oxh1OWP73i4Da00e4dETLmVYZwo3ij+YfbbaFc5 b3kSLwqIU1hqnLh+qi7r2+F69mv4g+ctksjcyYAOAJpJGXjXEvyQAeEXWuk4EacfZBRk qz/ysyL6jLotr3Pdpc085h8/8Rnxf8VmgoT3X3UMnC2ZSaJ9kPYKDGuscspthuOpiZSR C3Mnxgx9/OPnRcERb9zsN1ieSrqPVIq7xNV4zyi8UPHwQxclYGA0kKtkuERxRdYkaV9/ vSWa8FLNCTR6IkfKYOGTpu/8Xlo64w/9WyI+GASsJ7ObDU/JMKhuUKjH9VeI/Rafdikb Pdug== X-Gm-Message-State: AKS2vOyjd7pPw5F6Ix6WVB6dkp6UHN4HrgHNmPVeHGX6jVMOZi+yIPiz BjUgvgY72FUqi8Kd X-Received: by 10.101.69.207 with SMTP id m15mr1264570pgr.242.1497385731312; Tue, 13 Jun 2017 13:28:51 -0700 (PDT) Received: from [192.168.178.21] ([118.149.108.214]) by smtp.gmail.com with ESMTPSA id s131sm25632455pgs.6.2017.06.13.13.28.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:28:50 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Ole Troan , Fernando Gont , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <01b8e1d6-125c-2ecb-6888-e7283f3d488b@gmail.com> Date: Wed, 14 Jun 2017 08:28:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:28:54 -0000 I'm replying selectively in this thread to avoid repetition. So: On 13/06/2017 20:18, Lorenzo Colitti wrote: > On Sun, Jun 11, 2017 at 8:37 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> This has two aspects for me: >> 1) It's simply out of place to define an arbitrary constant >> in something called "architecture". >> > > Er, what? It's perfectly fine to say that the address is 128 bits long, and > that half of it is assigned to the network and half to the link. But it doesn't. It first states that the boundary between prefix and IID is floating, and then states that it isn't. >> 2) By defining it globally we forbid using some other value >> on a future link-layer where a different value might be better. >> A 'should' could cover that, of course, which is why I accept >> the current 4291bis text. >> > > I don't see why we need new text for that. Any document that wants to use a > different value can simply update 4291. Agreed, theoretically. But simply s/required/recommended/ in 4291bis would be a much more elegant way of handling this. >>> I am still confused what this draft proposes to change. >> >> Nothing in any current implementation. > > > We have a popular implementation that only accepts 64-bit IID lengths in > certain cases. Are you proposing that our implementation change or not? No. But if some new link technology comes along for which there is a good technical argument for, say, 60 bit interface identifiers, wouldn't you want to accommodate it? (I have no idea what that argument might be.) Brian From nobody Tue Jun 13 13:30:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17F129C4A for ; Tue, 13 Jun 2017 13:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgehgANmzpQZ for ; Tue, 13 Jun 2017 13:30:12 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 4E5FC129AC7 for ; Tue, 13 Jun 2017 13:30:12 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id f185so65568748pgc.0 for ; Tue, 13 Jun 2017 13:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oiXaf8W2E0B1WOBVo3az8aRJvLN7v+mjk6IUwcVYmPM=; b=XlapWW2+tVJFC4NJ277OncXpMtqlq2IiExFGvF3e50bnjxRvn/JiQ7TaIC9P1QB5F+ HZAGn0geP4z5tI1kRSKkkqPWhMuJROOjRWLg97jCYcZ29AR707U+8P56ZS1piSNVotFG pQTWIdzALu4DR1igqe1noJTn7zYa0yUm3vDa5hNLbf+7M6GhtB0eoAwnRye6UYuxhd8Q Gg2Ug0EdfQu8aH8aPlL9+qS7asa9pkT3ZTFgytTzBfUIbveEBkJbypUx5z5pq2rSWnxr ZB5IkCgubMrNcEtsU+QO73Ay5kFAWddRjR6Wvb/BMOGLRBZm9Nn8ZeFUFrb93NeJF5vA QumA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oiXaf8W2E0B1WOBVo3az8aRJvLN7v+mjk6IUwcVYmPM=; b=hGqV8CnfW3M35XSpszQ9MzIZQx2/ayrpy9NajeuYYpzJR8LP91PHez0X1XiBFspCqj jdRMUGnpDtnBNV9qNCcTo8u2tWZgc/D6I+Wva5vELy5Fmxmah73Gjx+6uc3FPjOntmu3 uKPJiV7ka9UrXPIhZRgGxmflI/eNh6MyEFYXq1ZrvVJljHKJTHXcWn9teeWQ9VF4OJaq OG5G0ETa/4KhlDC7BMvQQmymj7nYUzUdJ4I8sOxwEkY23O/3zoN1SsvBXD2grKPntH3v pGrFNrTLVWOJF3fRFTOeYCG7ARHvz/zt4iY+2Q0OqroQqzBJTkzAZHXBm1QqepUvAz2Y nPLA== X-Gm-Message-State: AKS2vOzlyMW1CQ5eoVVRlCZjsUK2nM8WuYRHPUMVnJe3o5kZ/w8USdFy AhHzCZvwNVy8nckl X-Received: by 10.101.70.129 with SMTP id h1mr1346228pgr.50.1497385811626; Tue, 13 Jun 2017 13:30:11 -0700 (PDT) Received: from [192.168.178.21] ([118.149.108.214]) by smtp.gmail.com with ESMTPSA id w67sm25343837pfi.2.2017.06.13.13.30.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:30:10 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Fernando Gont , Ole Troan , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 14 Jun 2017 08:30:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:30:14 -0000 On 13/06/2017 20:29, Lorenzo Colitti wrote: > On Tue, Jun 13, 2017 at 10:26 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> Why does N need to be set on a per-link-type basis? >> >> It doesn't *need* to be. But SLAAC by design assumes that it is >> set per link-type; that is architectural flexibility which is >> removed by RFC4291, which IMHO is a bad message to send to the future. >> >> I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis >> back to us > > > You're not serious, are you? > > The IESG sent back draft-ietf-6man-rfc4291bis because there was clear lack > of consensus, not for any architectural reason. Yes, because there was clear lack of consensus *about this point*. Brian From nobody Tue Jun 13 13:35:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4841243F3 for ; Tue, 13 Jun 2017 13:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHu8iqB7P6_W for ; Tue, 13 Jun 2017 13:34:58 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 F1720129A8D for ; Tue, 13 Jun 2017 13:34:57 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id k71so65565961pgd.2 for ; Tue, 13 Jun 2017 13:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+Vq0yZpIPzjyIOw2hbv9l1JoePax8UdXXu/eWXHQ6hE=; b=fNKWHKbjmzaanujMtS2tJeYLDF0jgsk+ZXKvZozIvVmjaX/CHnEp3XNFpcLNWy4fVw woHHI6e7g5brrU6RqTfW/1Gnf8EaVAiamrEOrumsA8W6J8NUICSCKjbOY3nyE4w55im/ OGfJOanmQnLAhRPkoXj+9/YB6k1pK3fbLh5fVE6xyp3Uhuwl7kMm0I9XrPwOncUaaH7S 68CJm2kN0vkcXc0jE7VPabrGLwR1KaDuIqLZnEFGpjr58nMsrc4pu0S3O3nK+JK7Gyl9 UrGPj57FOYrMx/geJ5iajqeBJcZdzrP84reT4XIXzeN+hsP99fV0CHNI7E4cwWjiCM9f nqwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+Vq0yZpIPzjyIOw2hbv9l1JoePax8UdXXu/eWXHQ6hE=; b=KxlFsAzUCNL8SEyrhdsmk2KqGxo+CACr9Zz1wLjheH5H4Mf+euOgMQyg3es946sYbl roLEtdJ6gEC7YjQPjqBH4i/wyT/UbYhFAs+MGG6iwErgcOhwJU7LEKx9pXg6P/UCMkAi gZtFsR5L/yTTYAL/OnJm/ePPtoS60/91bVL5isJQV2NpRa1jsujScl4wWlhadkMqebr5 cr3mjBTwnzNEx9V9ZiSYG9AAmCFrwbRdCGh/s6aJK20tIGBbRsGdi7K8eHxRCNrjr8KV 709+Lco4FbJp7k/dhme0VgmABASbR3XT+VVw4o5p/lt0B6uy7DGBtgdoL1lAOrt0s6Hn 60Qg== X-Gm-Message-State: AKS2vOxN7V+DStGPo9R3iB6WpEkUNo46EmUVvOjrbV4Kt2GK0kU6ercl ap1MJlZj+5LlZwu2 X-Received: by 10.99.139.194 with SMTP id j185mr1369273pge.126.1497386097373; Tue, 13 Jun 2017 13:34:57 -0700 (PDT) Received: from [192.168.178.21] ([118.149.108.214]) by smtp.gmail.com with ESMTPSA id u194sm27646833pgc.2.2017.06.13.13.34.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:34:56 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Ola Thoresen , ipv6@ietf.org References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <9b259cb2-3d31-78bf-608c-aacf5fdb8101@nlogic.no> <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 14 Jun 2017 08:34:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4b16e46a-a5b8-699f-9df7-a76476d06a34@nlogic.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:35:02 -0000 Ola, On 14/06/2017 01:57, Ola Thoresen wrote: ... > I am not talking about that. I am talking about the idea of deducing the > prefix length for _Link_Local_ addresses from the RAs. You cannot do that, because you must be capable of forming the LL address before you receive any RA. Brian From nobody Tue Jun 13 13:44:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857541294DB for ; Tue, 13 Jun 2017 13:44:10 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I9d82zc-RaX for ; Tue, 13 Jun 2017 13:44:08 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 16356128768 for ; Tue, 13 Jun 2017 13:44:08 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2017 20:44:07 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 7996AD788D; Tue, 13 Jun 2017 13:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=qheKOTaF1fy6Gjq0mkRDQNkCGmc=; b= eSKHJOSr8G2VEOSstPUpdJ5BsJQfi27XnpLh6LWvu8X4JnVcqBZ/mJqdb6wEHK0k ubz0pAq5MY8ntlxz9lHfz00nwaFXQy8RKemzHQOT1nFwgHFmwpyzwKy8X9UQIGBb K6Sv5dZI7FWX4yVTYIqo5N/l1Hke0GbePIeOP2shhvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=RWHoitCztPkJoQvfqdoXGB9 K/bqBAw4mi28hFz+JhfT0+EFzM9IC/vL2gpCzyqLsa3b9Qst3np6Of34kwfUt7xl zN+RLfw/I4k+k3ruRog2bUwgLOho1sl6TcqzGDHbDjaa/xSscborgaDBxYP7/5Os Ug5MbfnnsRVgrq+SRPmQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 458F7D788A; Tue, 13 Jun 2017 13:44:07 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8F489D39643E; Tue, 13 Jun 2017 22:44:04 +0200 (CEST) From: otroan@employees.org Message-Id: <26A08B05-C0A8-438B-90CB-57BC102050B5@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_74A96AC8-F846-4280-8BD1-9F1F257A2577"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Tue, 13 Jun 2017 22:44:04 +0200 In-Reply-To: <01b8e1d6-125c-2ecb-6888-e7283f3d488b@gmail.com> Cc: Lorenzo Colitti , Fernando Gont , 6man WG To: Brian E Carpenter References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <01b8e1d6-125c-2ecb-6888-e7283f3d488b@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:44:10 -0000 --Apple-Mail=_74A96AC8-F846-4280-8BD1-9F1F257A2577 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >> We have a popular implementation that only accepts 64-bit IID lengths = in >> certain cases. Are you proposing that our implementation change or = not? >=20 > No. But if some new link technology comes along for which there is a = good > technical argument for, say, 60 bit interface identifiers, wouldn't = you > want to accommodate it? (I have no idea what that argument might be.) After we stopped recommending using link-layer addresses in the IID, I = have a hard time seeing why a new data-link layer would have = requirements for a particular length of the IID. Now if a link-layer is = designed that requires to embed link-layer addresses, then sure, but = that link-layer is then limited enough to be treated as a special case = anyhow. Ole --Apple-Mail=_74A96AC8-F846-4280-8BD1-9F1F257A2577 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZQE6UAAoJEL7aWKiYQt92+dIQAMghhvd0U2ccEPjmSkc8Bsnn vyisOMO75eFsaeXFTXssjvDtdNN9tLAHFdfLUarjnwQIU4tpwgPcbpHzAq68CfHc qtYeOOPGoR9/N5749l7hcXuq0i4M1xNuWGMVHCarPXdBzRUFwPV8sN5NtoHye87Y fgyQ0eHtjuKtDj66XOzWgrlC+idYyURpaCtOi38DqvtdfJVPVjJDENELhTR1qt0C emoiPRl11XTv+r7+xGq2YApuOkDDqGg1aw5sBExYQ81IR60Vw/miDstxdPttCYeP cmBLIwLoTRZwH71P8JmVIi+pkevClfCAPpC1Or+0oQKhDWF2o8QjlPtygO+e/QhG CwmJmoJlRzrXEXw0oYy/xeUtu+KvG1sWPnDa6+meIvQ0f12u6C2E07ORSDl1P/J5 /H5u8c70YrejwhCASAPf8+ieZEM/OUXSGmI3MAMy7mpJz7fsZACXinReErn+UG4t l5jqZFeIfgJn4iEdAqt1PG96Dh21eHSvRzYm5WQtEc2Bahrk13U0yTpFvUEJKw2r umLJu9U/tXY8IGAsBQKJmdmYtJ6VpsL3uc2yoAr44DsMHPRcnKOQpDomOXNrFcyY iy3S/tLae0xIG4/TCgQW0h8nYxyOaU9NLy7mCUKQLyS73yFbnJ3z9sDoDcMQMKfE h2lJOPMQ1XkCb6gq/eQZ =t5g5 -----END PGP SIGNATURE----- --Apple-Mail=_74A96AC8-F846-4280-8BD1-9F1F257A2577-- From nobody Tue Jun 13 13:45:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A5F126E3A for ; Tue, 13 Jun 2017 13:45:35 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH7Ie2soxHdA for ; Tue, 13 Jun 2017 13:45:33 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 1ACD1128616 for ; Tue, 13 Jun 2017 13:45:33 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id v18so65669752pgb.1 for ; Tue, 13 Jun 2017 13:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=y53FjwtNruTdorV14ufWCfo9B8nWibH2C7oKvrCE8T8=; b=B90FqXUP2oOwT8Un6Aq9qVxWnYmz8XtJcUcColSxFuu/93rb6nUPtxWbm0Xt2RhMFN LnHPEwJc/2KZFBLaJAVq27/vOOhE6XwKBec5Ol4Yzqd4uSI2SRZ5yGcwKSye2ORHnI0E oHtQXc64rJQ7IAOATHz1UgM0ZQrI+NOc9UY1YwV28W0jdwGz8s1o1MUAO6oR7V4t7O6E B3y7HpbqdY7uA36UfsElIjPMpZDKHy4i2xWtDPPdDt0AtwosDkOnIfRAl5X+y0ZQVPnz aey6sZscVc6fMZyOBnHPM5V1zzzHslPpcZCFtUWnUOkNW6A34yppVf4n9rff5INPE4n5 Ue6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=y53FjwtNruTdorV14ufWCfo9B8nWibH2C7oKvrCE8T8=; b=nm6K0ADJzsSABHq01tzzBkuEeU5CnTYRMG39Liagb7mnpFeD/MlPwVtlRQAbYew/BO jKNQurV96hGK7Q/owBMLe5qn5Qv7p3eZKsuGBy4vq+1ucM0VM1J0cEUUl9ooEOijbG5t 7C8XW9meBTRY74ABlVxFCWicrlmM7XWaj9coifYwfBWFPsr3d42t6RAQQXTs1m3L+CSn ppjqNtVg5s5JIg3mQYxb3euLLHUfl0QxLA8IJlwWHrNyOhYXx4DMJ03dNdM8TaVjxNNq BLMDM9RStIbnIfEP79MMTQJQE/XSy+X2j4XL5IHT7sb1g+v+vD2xBoccAnvMDMwfhKeH MUmw== X-Gm-Message-State: AKS2vOzkJHgv9k49kvZ3X8LM8CUYw7DiWg/TIbLEAiaYSM4ZKEB64x2X 2bwxQUdSY90lfEM0 X-Received: by 10.99.125.2 with SMTP id y2mr1379744pgc.10.1497386732519; Tue, 13 Jun 2017 13:45:32 -0700 (PDT) Received: from [192.168.178.21] ([118.149.108.214]) by smtp.gmail.com with ESMTPSA id i68sm29819583pfi.72.2017.06.13.13.45.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:45:32 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Fernando Gont , Ole Troan , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9f1cba73-b3d9-edc2-4354-fc03eccc5b94@gmail.com> Date: Wed, 14 Jun 2017 08:45:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:45:35 -0000 On 14/06/2017 04:39, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 13 Jun 2017 13:26:59 +1200, > Brian E Carpenter wrote: >=20 >>> Router advertised Prefix/N (where N is nowadays hardcoded to be "64",= >>> but need not). Host eploys RFC7217, and grabs 128-N random bits from = F() >>> to generate the IID/address. >>> >>> Why does N need to be set on a per-link-type basis? >> >> It doesn't *need* to be. But SLAAC by design assumes that it is >> set per link-type; that is architectural flexibility which is >> removed by RFC4291, which IMHO is a bad message to send to the future.= >=20 > I don't get the "which is removed by RFC4291" part. Are you saying > that the "architectural flexibility" existed with RFC3513 but was > removed with RFC4291? =20 No, that was not my intention. I'm sorry if it seemed otherwise. We have always had this rather strange feature that the address architecture describes a flexible boundary and then fixes it. > RFC3513 already had this text: >=20 > For all unicast addresses, except those that start with binary value= > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. >=20 > Even RFC2373 had this: >=20 > (2) The format prefixes 001 through 111, except for Multicast > Addresses (1111 1111), are all required to have to have 64-bi= t > interface identifiers in EUI-64 format. See section 2.5.1 fo= r > definitions. >=20 > If I understand the "architectural flexibility" correctly, that > flexibility was already removed by RFC2373. We were aware that the > constraint in the addressing architecture can cause nasty issues in > terms of the assumption of SLAAC (IID length is defined by link-type > doc) at the time of rfc2462bis discussions but intentionally left it > that way. Of course, we can still revisit the decision at that time, > but I don't think it wise to do so in the context of rfc4291bis (see > also below). >=20 > In any case, >=20 >> I think this is the main reason the IESG sent draft-ietf-6man-rfc4291b= is >> back to us, and the main reason I signed on to draft-bourbaki-6man-cla= ssless-ipv6 >=20 > I don't think it's the reason why rfc4291bis was sent back. As far as > I can see it was largely due to disagreement based on > misunderstanding: >=20 > - some people conflated on-link prefixes and subnet prefixes (where > the latter is the prefix that is followed by IID in the addressing > architecture) and objected to keeping the length of the latter to be > 64 bits for most unicast addresses, while what they really wanted is > variable-length on-link prefixes and they already have them. > - some other people wanted to keep the length of subnet prefixes to be > 64 bits. but perhaps those people interpreted the objection from > the first group as an objection to keeping the subnet prefix length, > and fired back at it. >=20 > If the main goal for draft-bourbaki-6man-classless-ipv6 is to resolve > this gridlock so we can move forward with rfc4291bis, the resolution > is IMO quite simple: just to clarify the main misunderstanding. No > architectural or protocol change is necessary: > https://www.ietf.org/mail-archive/web/ipv6/current/msg27679.html >=20 > Now, we are seeing a third group: >=20 > - yet some other people do not think keeping the subnet prefix length > to be 64 bits (for most unicast addresses) does not make sense at > all and argue for loosening it. >=20 > There are some variations of this group. Reintroducing the > "architectural flexibility" (by making the subnet prefix/IID length > only dependent on link-type specs) could be considered one of them. > Some other people even suggest making it independent from the > link-type and leaving it to host/operator's choice. >=20 > We can discuss this proposal, but IMO this should be deferred as > post-rfc4291bis fodder. I expect this will be a very controversial > discussion that will take quite long time (at least the second group > of people will fiercely fight against it), and there are currently > very few (if not no) implementations of the most flexible behavior > (i.e., making IID length fully variable) so it won't be compatible > with the scope of rfc4291bis. I largely agree with you. Making the boundary truly flexible is much=20 more complex than some people think. All I personally want to see is a version of 4291 that leaves some flexibility for further discussion, and doesn't appear to forbid a number of existing operational practices. I agree with you about the phrase "subnet prefix" in 4291. But I also believe that making the unicast IID length "recommended" instead of "required", although it seems like a small point, removes a lot of the objections we heard during IETF Last Call. Brian From nobody Tue Jun 13 14:21:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE5012940B for ; Tue, 13 Jun 2017 14:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SaZoSVnP-pY for ; Tue, 13 Jun 2017 14:21:43 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F7D1293E8 for ; Tue, 13 Jun 2017 14:21:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 220CF96C for ; Tue, 13 Jun 2017 21:21:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjgDOW843TF8 for ; Tue, 13 Jun 2017 16:21:43 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id E32D114E for ; Tue, 13 Jun 2017 16:21:42 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id 103so31147656uaf.11 for ; Tue, 13 Jun 2017 14:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wq5Yj/fVYaS7CaC/7kPmRxaix7BVVYdktp9/s/v7PWQ=; b=jZiIwVuAwd/3bl/qrs7HxECghpsmmTPqFodx60gx7dHWfzahmEbPwAwFUMHTFy7CZV 5T1pD33ICNF4cEARlhkzPgEGEtWbgDC85oTV14TISKzpQL1HYJi13/NzyJR++qO2cN/M oLIibFfPXRpYpgs5e44ljuBZu+CG1IR+oQeYAb1XP8qr6rHLXPUkfKKTZfvDpsfIuxTE 52M7rO9xMP+OeUGzIdnl1xmeMooi6ErFEGShwIFd7ikCFczzn1W3ABIxCL5kiqoJtTYT D8N64GvnsP7Uu0BvnOT8YYJPwvGeDsaNLjSCTBHGS/3Fj3HOzTtnDEZVskJCLUbixGyE jX9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wq5Yj/fVYaS7CaC/7kPmRxaix7BVVYdktp9/s/v7PWQ=; b=npkFtUXjuE0XNkd2xDo0jZh7u62k2U+fCBFiuKy+mKM256p+4NR6zgk1IL8vulcbQq qsoy6v/HPcG1DIGmvZilTJ34pdQlA1R0crbQRD0uxEgpnOdvRCvW9uDAbXkAvWpsFh5x nFxBDvnfoU5ZY8YMrIUct2GKq+wYsy0Be2dqLoSdxAM5bI8gsHjWqqpWIYJ4UoZ11QQt Ud3CD5QYZ8qVmEJfczrhh5jTOBqqH5nm02oHhaHwS57Bd8/VyLmNf+vRXutleVLs2DD1 g9N46+aHHqL7JAE0onNHNwWo+hiNmuw3PNBMFQHeep4BIy7Z4seW35RCmxuSYPCx+ccT jFGQ== X-Gm-Message-State: AKS2vOzH5ktl1BPQdN5PUHmJuQhKQpnFIHd6LU5G7oZIZA+nlfdry6Kz kACNFQAGJI5PcYKiZKuXJHaOOAmPdNA8DfQwxMsLO8Uzlc1lB23dcGZDD7d5MHXAMqRAVjE3eYH xWVPzqa+ijHDOdD4= X-Received: by 10.31.168.136 with SMTP id r130mr1048980vke.129.1497388901896; Tue, 13 Jun 2017 14:21:41 -0700 (PDT) X-Received: by 10.31.168.136 with SMTP id r130mr1048974vke.129.1497388901659; Tue, 13 Jun 2017 14:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Tue, 13 Jun 2017 14:21:41 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <033901d2e390$ed5b38e0$c811aaa0$@oneunified.net> From: David Farmer Date: Tue, 13 Jun 2017 16:21:41 -0500 Message-ID: Subject: Re: Tussles in IPv6 Land To: Philip Homburg Cc: 6man WG Content-Type: multipart/alternative; boundary="001a11415fa6930e690551de0510" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 21:21:46 -0000 --001a11415fa6930e690551de0510 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 12:22 PM, Philip Homburg < pch-ipv6-ietf-4@u-1.phicoh.com> wrote: > >Out of curiosity, when a smartphone is used in tethered mode, ie, devices > >are hanging off it via the built in hot-spot, do the devices get an > address > >out of the smartphone /64, or should the phone have a /60 or maybe /56 to > >handoff to those devices? Say, as LTE gets more predominant, powerful, > and > >bandwidth capable, maybe with rural/farming areas getting into more IoT > >stuff, maybe have a router hanging off that tethered hotspot? > > There are enough /48 prefixes that we will never run out if we give every > paying customer a /48. > > There are enough /64 prefixes that we can give every link its own /64 > and we will never run out. > > So whenever you find yourself subdividing a /64, look at where in the > hierarchy bits are left unused. And then fix it at that level. > Yes, I agree with everything you are saying, but if I don't control the allocation of the bits but I need bit where am I suppose to get them? Sub-dividing a /64 is ugly, but if your stuck between a rock and a hard place, you scratch at which ever is the softer substance. In my view the /64 is that softer substance. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a11415fa6930e690551de0510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 13, 2017 at 12:22 PM, Philip Homburg <= pch-ipv= 6-ietf-4@u-1.phicoh.com> wrote:
>Out of curiosity, when a smartphone is used in tethered mode, ie, = devices
>are hanging off it via the built in hot-spot, do the devices get an add= ress
>out of the smartphone /64, or should the phone have a /60 or maybe /56 = to
>handoff to those devices?=C2=A0 Say, as LTE gets more predominant, powe= rful, and
>bandwidth capable, maybe with rural/farming areas getting into more IoT=
>stuff, maybe have a router hanging off that tethered hotspot?

There are enough /48 prefixes that we will never run out if we give every paying customer a /48.

There are enough /64 prefixes that we can give every link its own /64
and we will never run out.

So whenever you find yourself subdividing a /64, look at where in the
hierarchy bits are left unused. And then fix it at that level.

Yes, I agree with everything you are saying, but if= I don't control the allocation of the bits but I need bit where am I s= uppose to get them?=C2=A0
Sub-dividing a /64 is ugly, but if your= stuck between a rock and a hard place, you scratch at which ever is the so= fter substance.=C2=A0 In my view the /64 is that softer substance.=C2=A0


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommuni= cation Services
Office of Information Technology
University of Minnes= ota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone= : 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11415fa6930e690551de0510-- From nobody Tue Jun 13 16:43:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BEC12EB76 for ; Tue, 13 Jun 2017 16:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voJ2c8Uqyu4V for ; Tue, 13 Jun 2017 16:43:55 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 EFB80129489 for ; Tue, 13 Jun 2017 16:43:54 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id q15so85163817uaa.2 for ; Tue, 13 Jun 2017 16:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2JGAL54f3XNX/VnqcyEKDuL3AvMiBKvSUurAgIH5PhU=; b=nmIl8bMDHccfdVp2jEHXkGUPZP3aln/ZNUovvt91uiePr3HfW8Ps+1D78ZvvGNEXzC qNkGHUnI2NHMwP9P1YWeLWKo/wOKMbYmyXeasQjxiE5PeAOocJddcaziomZ4GSCYSBYf eyucxMJ7GxmcDOwUdqXNU2WztQRn8CVdvUHVHy9Q+6nzE3NQJNqnz9PSSvuTPLm4sus1 W9Lcau71Em8Se7d+L8AZGTAd3aUrVYcnC9qfS28GfPGDNGfM5z0lup/t/O1r/aArAICi Ms2lE27/oYPdg1G5fa2IKcXHA0ii9IqU5CkXPmDAUl+6seA955MMilaK/5VD4UX2jp3u Ba3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2JGAL54f3XNX/VnqcyEKDuL3AvMiBKvSUurAgIH5PhU=; b=IVSyz1xUSrB8ytlKQ7/fRvgXioeLBrM0t4s5+Ikk7gDsFNDs43RJFoPDioIdQmYI9y 03xP3bV36+509UzBZVXJbkAGLdRRt4GBk/U9LAnrCE1Yk9paNfkBFmMsPL/SFlfZln/a TNprRqnRF2bZXwYufXdUISUJxECNzk8POlhKXf2WtiUJJhtvrrs021tghcz+rlhh21W5 +oK0j2o1PJXHO3T3r8RWOXyK3ipG6gQwv4qYJXHXe4Io/7rtZ5G3/lYxhOVErLV6R8NC 2oXrfmi6WvPzm5a0fxUzUXk5TLEHdElKw/IjB+lhJPNLA7X1AQIgCxpxZv68p7DkZVIp mAaA== X-Gm-Message-State: AKS2vOzjWwNdCOvGfkFOeT4SQBasr2bG6hWatDkz5BO3ZNnz4EWdZhKX 4A38NW66xWRR9hl2UbikhoijOIebT4m2WVU= X-Received: by 10.176.9.234 with SMTP id e42mr4354287uah.52.1497397433738; Tue, 13 Jun 2017 16:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 16:43:32 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 08:43:32 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Philip Homburg Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403043ee21420dd840551e00237" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 23:43:57 -0000 --f403043ee21420dd840551e00237 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg wrote: > >Not everyone supports DHCPv6 as you probably know ;-) > > I know, but we should just treat those devices as IPv4-only and move on. > Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best practices, for precisely the reason that they don't provide enough address space. --f403043ee21420dd840551e00237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 2:25 AM, Philip Homburg <pch-ipv6-ietf-= 4@u-1.phicoh.com> wrote:
>Not everyone supports DHCPv6 as you probably know ;-)

I know, but we should just treat those devices as IPv4-only and move on.

Why would you care? DHCPv6-only networks = are NOT RECOMMENDED by IETF best practices, for precisely the reason that t= hey don't provide enough address space.
--f403043ee21420dd840551e00237-- From nobody Tue Jun 13 17:23:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2127127599 for ; Tue, 13 Jun 2017 17:23:52 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkrK8_VZIi3c for ; Tue, 13 Jun 2017 17:23:50 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 83F8D126DEE for ; Tue, 13 Jun 2017 17:23:50 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id w1so192158993qtg.2 for ; Tue, 13 Jun 2017 17:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lwwwi6FU/QTZ0wHn1AjyaM7aFBeqAxu6/fqIM0ExYY0=; b=U1jKrdeiU7ScwLLIAkCpeqpZRlJHc0yzbIgS9LdWez6w2n6ro4KAlz27fdgu8A7qgS 5pABUMQRy8yMMWxs8RcXlyUPOwiPN4G3zh6XHs6qejmh7RuOiChbM7dD23g6mlmMm15B BVULEmemLLpBLfMecoDnA7n0P7VPR6XSSuMJb4EP6utkIejOrC79ev2x6zq0pD+448zL 4R4TZdHyoh384nvmLRkc0t4h1csnIK0U2QGuqEP0sc/7xekgS7vJpwKAMMbCqZGxg2j8 YSiwSS549r3uadssfg6B3GOyz6FyeHS1hb1zE8TfZVF5JHbK3ZxDxUlYXiVl8io+51tL 0/qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lwwwi6FU/QTZ0wHn1AjyaM7aFBeqAxu6/fqIM0ExYY0=; b=SGA4FhjrDt2SQwV9gzdVE05ny7O1PAGKVCU8EaFETXchJaQ0b0jVLa2yrc912XvKZA 9/wNLYMwfb9BayUXomPPaRqBeYUApjYsxdzdgYLoXirQwg+iwK4HuURn/0E4utoCaTk2 MbjFNvoi18sXW2ivMXta28/QjQ5w6Qi1ucO/s+uZRTGoy4VAWnVVtM4/KuQ9OiJT39F9 qSHq54kNpuT2y48cro0BwVoD8FrCD5HxYKJLYHRO40V/kSxh08t0dgK+b+h34VEC/Its lforF95SqrbaBI0Snp79Z+9HY7X59GFe5ofL6pUobtvugcHAQLB1z3s2TyCw4RotXvvK dz+A== X-Gm-Message-State: AKS2vOzXvxylWsJC6d2CuiiEgSn6auyDoJOKwl7ZzUjPGOlhw2MyEQmK SuaJHzZUeoiR0y383Pc= X-Received: by 10.237.44.197 with SMTP id g63mr3300820qtd.241.1497399829632; Tue, 13 Jun 2017 17:23:49 -0700 (PDT) Received: from [10.10.10.1] (c-24-62-111-143.hsd1.ma.comcast.net. [24.62.111.143]) by smtp.gmail.com with ESMTPSA id t35sm3675188qte.38.2017.06.13.17.23.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 17:23:48 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B2401B30-9DF1-47EF-AEA8-40EA77FFC691 Mime-Version: 1.0 (1.0) Subject: Re: Tussles in IPv6 Land From: Ralph Droms X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 13 Jun 2017 20:23:47 -0400 Cc: Philip Homburg , IETF IPv6 Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> To: Lorenzo Colitti Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:23:53 -0000 --Apple-Mail-B2401B30-9DF1-47EF-AEA8-40EA77FFC691 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jun 13, 2017, at 7:43 PM, Lorenzo Colitti wrote: >=20 >> On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg wrote: >> >Not everyone supports DHCPv6 as you probably know ;-) >>=20 >> I know, but we should just treat those devices as IPv4-only and move on. >=20 > Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best p= ractices, for precisely the reason that they don't provide enough address sp= ace. Can you explain this statement, please? I don't understand the connection b= etween DHCPv6 and the size of the available address space. - Ralph > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-B2401B30-9DF1-47EF-AEA8-40EA77FFC691 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On Jun 13, 2017, at 7:43 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>Not everyone supports DHCPv6 as you probably know ;-)

I know, but we should just treat those devices as IPv4-only and move on.

Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best practices, for precisely the reason that they don't provide enough address space.

Can you explain this statement, please?  I don't understand the connection between DHCPv6 and the size of the available address space.

- Ralph

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--Apple-Mail-B2401B30-9DF1-47EF-AEA8-40EA77FFC691-- From nobody Tue Jun 13 17:25:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6781293D9 for ; Tue, 13 Jun 2017 17:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjyB_P1phIAu for ; Tue, 13 Jun 2017 17:25:05 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 58716126DEE for ; Tue, 13 Jun 2017 17:25:05 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id 77so18623951wrb.1 for ; Tue, 13 Jun 2017 17:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4lJ8AED/4EW+aKVcVFayXHkLOKOPLFAuwwIbSLpAhJk=; b=JLBgXY8I7redKZTLCZcE70KhkmWgNbYJ7U5/bJbOFbvDPwW74nGQIfTAsxGQvpwdD1 L1Kt1qmc6OGyqJC/5KdU+/LX5FP3ranuAP+ZrKqH3FXFZO+aD+IHLr+3fmziGpFo1wM5 oLcQhF86WIdp1ZxGPc854i3F05phdOYvTc+dSavWP3M3yz+vWnTxz06F430VK/nPoVEy WDwr1dh3YjMuqlSdnl5d1AShFr6R80O/QtPR4Pngq7/U5dKS9T5gzhPVx0qwARccg6sp 1u4+32YSJm3gYyd/Rpj5lGQzJYcUtkS5FYD1r+D3f0H1lKYDJyJmqClmBYMe8tUoMTQm O29Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4lJ8AED/4EW+aKVcVFayXHkLOKOPLFAuwwIbSLpAhJk=; b=bm3SmtCWUlMXVeJuQ5adkeGHBm7ZeCSuiEcrgnSznncpSypOddBKWsEBZrhlqEvEQy ETfv4OvhnsLxqWlJPhXtlb+RjlJ1wdxCCqI+pxJdU9/Z4Cpjw3DlZk3y46Nb3l10QCJ+ wTWGsrGUkyBXTEM5Sgsru77TgbyU4vNA04UvhtBkzB47xAxvPxOGdrHGuaZ/Ced2iEXV oBmoP5f/XwFxCT1kMEe/toun0rrdAk2D8Tp9ZH8qWsMfE1hb9Cfasz0TQnfDLF6hUSVD uibkk7FYM98I7S/1LBm2DEzzLxZrpIXN/1MMM0e6YZoivk8OK+THqJdv5+tylCFT1sm3 Gb9Q== X-Gm-Message-State: AKS2vOz2XmE1wO9v3cVaMcWgl7GQnuVQ3CZghGaHooYEiad6m+SxyDQ3 u6Uv9dioCnS8IPzviu+yAjfPMGVdG6DZ X-Received: by 10.223.183.11 with SMTP id l11mr1270797wre.115.1497399903841; Tue, 13 Jun 2017 17:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Tue, 13 Jun 2017 17:25:02 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Tom Herbert Date: Tue, 13 Jun 2017 17:25:02 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:25:07 -0000 On Tue, Jun 13, 2017 at 2:29 AM, Lorenzo Colitti wrote: > On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert wrote: >> >> ILA is an innovative way to use IPv6 addresses, but as I described it >> can't use this in a mobile network if every UE gets a /64. In this >> case too much space is given the end host which probably a low end >> device like a smart phone that really doesn't need it. > > > Again, that's the perception from the network operator side of the tussle. > The perception from the other side is, "these bits belong to hosts, go and > do mobility in the top 64 bits". It's really not hard to do mobility in the > network layer. Just build a low-overhead tunneling mechanism that maps /64 > prefixes belonging to nodes to base station IP addresses. We have lots of > those, GTP being one. The overhead doesn't need to be 40 bytes, either - you > could > Lorenzo, The _whole_ point of ILA is to eliminate encapsulation. This is an example "to use IPv6 addresses in new and innovative ways" as you phrased it. If we continue using encapsulation then that's just business as usual and no different than IPv4. There's no innovation there. Actually, the situation is worse since IPv6 incurs more overhead than IPv4, so maybe carriers should just continue using IPv4 in their underlay network to avoid the 20 bytes overhead... Tom From nobody Tue Jun 13 17:29:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE37129421 for ; Tue, 13 Jun 2017 17:29:09 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0fYKfE6qFJ8 for ; Tue, 13 Jun 2017 17:29:08 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 5AE68127698 for ; Tue, 13 Jun 2017 17:29:08 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D65BC349315; Wed, 14 Jun 2017 00:29:05 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C51B316004A; Wed, 14 Jun 2017 00:29:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ADB7B160093; Wed, 14 Jun 2017 00:29:05 +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 Kf7o_3-9W-wZ; Wed, 14 Jun 2017 00:29:05 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5D13F16004A; Wed, 14 Jun 2017 00:29:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EE23D7BA332C; Wed, 14 Jun 2017 10:29:02 +1000 (AEST) To: David Farmer Cc: Philip Homburg , 6man WG From: Mark Andrews References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <033901d2e390$ed5b38e0$c811aaa0$@oneunified.net> Subject: Re: Tussles in IPv6 Land In-reply-to: Your message of "Tue, 13 Jun 2017 16:21:41 -0500." Date: Wed, 14 Jun 2017 10:29:02 +1000 Message-Id: <20170614002902.EE23D7BA332C@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:29:10 -0000 In message , David Farmer writes: > On Tue, Jun 13, 2017 at 12:22 PM, Philip Homburg < > pch-ipv6-ietf-4@u-1.phicoh.com> wrote: > > > >Out of curiosity, when a smartphone is used in tethered mode, ie, devices > > >are hanging off it via the built in hot-spot, do the devices get an > > address > > >out of the smartphone /64, or should the phone have a /60 or maybe /56 to > > >handoff to those devices? Say, as LTE gets more predominant, powerful, > > and > > >bandwidth capable, maybe with rural/farming areas getting into more IoT > > >stuff, maybe have a router hanging off that tethered hotspot? > > > > There are enough /48 prefixes that we will never run out if we give every > > paying customer a /48. > > > > There are enough /64 prefixes that we can give every link its own /64 > > and we will never run out. > > > > So whenever you find yourself subdividing a /64, look at where in the > > hierarchy bits are left unused. And then fix it at that level. > > > > Yes, I agree with everything you are saying, but if I don't control the > allocation of the bits but I need bit where am I suppose to get them? >From the ISP. Every ISP that is only handing out a /64 knows or should know that they are expected to handout more that one /64 when requested. If the ISP is a cell provider ask them why they don't support DHCP-PD. The initial single /64 was only ever ment to be a stop gap solution and 3GPP rev X does specify how to do DHCP-PD. Every access technology supports more than a single /64. Your ISP is capable of delivering more. Mark > Sub-dividing a /64 is ugly, but if your stuck between a rock and a hard > place, you scratch at which ever is the softer substance. In my view the > /64 is that softer substance. > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jun 13 17:38:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E012D574 for ; Tue, 13 Jun 2017 17:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb12jqDImbcd for ; Tue, 13 Jun 2017 17:38:54 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6889D1293D9 for ; Tue, 13 Jun 2017 17:38:54 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id F3F2DB6D for ; Wed, 14 Jun 2017 00:38:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nlPf3ZIY5FE for ; Tue, 13 Jun 2017 19:38:53 -0500 (CDT) Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id CE68EBBE for ; Tue, 13 Jun 2017 19:38:53 -0500 (CDT) Received: by mail-io0-f198.google.com with SMTP id e63so37240009iod.11 for ; Tue, 13 Jun 2017 17:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C5C+bx9jnKnUJxbOyXf9zKx7XbJgTK0ctxmh2o1ohZY=; b=oSzCLwY96cr5yfWApF0RQUbhRm/QV65qfIfY3+Fj/EXzlwv/CIPpJv5DNyjRf8FH2D HABoQzOWwCg7Bln9OtOkhf4gJDwDeId+RroeOt2FEs9g0jp0nwyrvFuaWvbd15qpOPtm jLoYc+q7br1Bh0ZpthYnRRp1SGhRU6mWfRUI544CDZfJfbgl62MaSjVghdIEdP2bHsD1 s1PpGEeTuy/w0NmIMj8h8G/FTzmjIrR4Oh2i5gIeGQ58ay0V327Kz093S2KHfLu3nnRb BJvSx6pxYIvVjWCmYKBnRMzSDMi/3xpQgGHERMJDoOTCY0nA1HGu2gEJ1ozGQH52leeH /++Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C5C+bx9jnKnUJxbOyXf9zKx7XbJgTK0ctxmh2o1ohZY=; b=ezfHAbrOnPf0yqWjQpLZMAQhWukS8DqKNHVZkZsNvFBihANDYTnqt2VCXkJTVJXcvA EEzmFVGXqsIcumKFt+uljvh6wVZyoyy81mMLp1SpVgEClHoAAhC27y6EoA0fAljL6CQP RV1ORJ5mw70+1stTE8aX+jkFITl0zpszuaGbcqH/6bmNkp/vubUBZxmfEOfz7ZFg7KpC uUdON3KeDSjN1WqOUZYHNfbQZu9/kleXYIbubZCz//dbZ4SmR8Eu+FT5UovzdCnA/cQo yDuUXW3QtkOtCGKCmbCVLxs6eTcJn4v2dmXyjb4C7HubKHX611M5I3yo2BO3lI/4u3oj D5GA== X-Gm-Message-State: AKS2vOzT91hEE3Wyq1K52TK78qL0ftYQdfha+U1RaR0cXLVOm62AxLiz ztGDKtsZ8stgLrkFa77eyd8JhO69umzL8wBY8nvtKx+z6quWY0r+IWex8pgcr1gNqovruj9s7No = X-Received: by 10.36.224.14 with SMTP id c14mr3516968ith.100.1497400733213; Tue, 13 Jun 2017 17:38:53 -0700 (PDT) X-Received: by 10.36.224.14 with SMTP id c14mr3516957ith.100.1497400733060; Tue, 13 Jun 2017 17:38:53 -0700 (PDT) Received: from [172.20.20.20] ([73.94.201.6]) by smtp.gmail.com with ESMTPSA id a11sm7205157ioj.4.2017.06.13.17.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 17:38:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-835353A5-A5C2-4406-825B-B0C2C0F3EC40 Mime-Version: 1.0 (1.0) Subject: Re: Tussles in IPv6 Land From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 13 Jun 2017 19:38:51 -0500 Cc: Philip Homburg , IETF IPv6 Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> To: Lorenzo Colitti Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:38:56 -0000 --Apple-Mail-835353A5-A5C2-4406-825B-B0C2C0F3EC40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone >> On Jun 13, 2017, at 18:43, Lorenzo Colitti wrote: >>=20 >> On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg wrote: >> >Not everyone supports DHCPv6 as you probably know ;-) >>=20 >> I know, but we should just treat those devices as IPv4-only and move on. >=20 > Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best p= ractices, for precisely the reason that they don't provide enough address sp= ace. I assume you're talking about RFC7934, but where does it say that? Nothing n= ormatively says that, it does suggest that you use SLAAC to meet the normati= ve recommendations, there is a warning about potential limits with DHCPv6, b= ut it doesn't specifically recommend against DHCPv6, especially normatively.= Furthermore, a recommendation for SLAAC isn't a recommendation against DHCP= v6 in any way.= --Apple-Mail-835353A5-A5C2-4406-825B-B0C2C0F3EC40 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



Sent from my iPhone
On Jun 13, 2017, at 18:43, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>Not everyone supports DHCPv6 as you probably know ;-)

I know, but we should just treat those devices as IPv4-only and move on.

Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best practices, for precisely the reason that they don't provide enough address space.

I assume you're talking about RFC7934, but where does it say that?  Nothing normatively says that, it does suggest that you use SLAAC to meet the normative recommendations, there is a warning about potential limits with DHCPv6, but it doesn't specifically recommend against DHCPv6, especially normatively. Furthermore, a recommendation for SLAAC isn't a recommendation against DHCPv6 in any way.
--Apple-Mail-835353A5-A5C2-4406-825B-B0C2C0F3EC40-- From nobody Tue Jun 13 17:58:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992F1129407 for ; Tue, 13 Jun 2017 17:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6EuVdVr_dIP for ; Tue, 13 Jun 2017 17:58:18 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 911B0127BA3 for ; Tue, 13 Jun 2017 17:58:18 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id D3705BA2 for ; Wed, 14 Jun 2017 00:58:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyIiRjTyZWCh for ; Tue, 13 Jun 2017 19:58:17 -0500 (CDT) Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id A58FEA79 for ; Tue, 13 Jun 2017 19:58:17 -0500 (CDT) Received: by mail-it0-f71.google.com with SMTP id x129so49767704ite.3 for ; Tue, 13 Jun 2017 17:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qIOx1A3SKNOcTe6Po9Ycnequ7QQWccOys7mwm2rCZ3g=; b=M8gz43mGAn9FgJwDrLSIxuv07vz9RVQTQOkZ8oE3pDkWRNmYdq7Nlj1tQKfo/rCZLy KMuu9HELXQDfmDNB0gS2xXUqaEScGKOHElY2b6vpZQO7kwGMx1HaugkpkIGMnnpOnlPZ Qe7+d9uzC0U+3iiQYj8YpBX/6Lw35GXqLfxCEvD+iYBrjBvzqPnlSWrrFuE5vSnrgY0G QMke/zsUY+z7+3fda92fw52W6w4TWP2m3GIwrkq81vL6/5KfrqgoPeUclDBjgRuBoaxv M13pmDqZ/BLKwF+eBkNHHDYwQ/XcYUus25TUGPvQPF8y/fcvHKYgPg7kG2yrgHyoodIk y9yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qIOx1A3SKNOcTe6Po9Ycnequ7QQWccOys7mwm2rCZ3g=; b=SuEM5o36RAPKBseFEpbIQ4MCuWrJYtacjMtk6mk8kVtEBnDNEJ0qkr8JTEeKd91IoY uTTEsDIU6mHNZshMn0lzQJ9JqDVrRsX3xU1KqAZECdovRixrIBw1fx1VbNil5Ws2nfn8 6HXRPoi5EpVaz6S8Wr9vKajDHXwjVXvsZfwhzvAX7z7Rz2kLwrE2e697fqGNItY9YpCU J+nZ7fKV9A6xA1s15mKqC1c+7MqKT0F372c0WfvjakFrfsxZWj1QFW4Q6QKVsxe4IFXl 1AeDtWXTOKXW7IniSkOvhNa/lU28eOY5CHdWk720xmBBqxKpwagj5CRoAQ15rZVcnwpR XEHA== X-Gm-Message-State: AODbwcAe7QJIcp17vHQ/qLOF6M4cJ1b5uJSxhcUqRayPuCh8xftK0CDu rzcZ0QABeHdYbyDJIOQbtWBMCAYGVYLmeUtCno22sksJEfvYy/s6/4umAjq1CHcW7AtT5cTxjZI = X-Received: by 10.36.222.69 with SMTP id d66mr21333320itg.14.1497401896923; Tue, 13 Jun 2017 17:58:16 -0700 (PDT) X-Received: by 10.36.222.69 with SMTP id d66mr21333309itg.14.1497401896766; Tue, 13 Jun 2017 17:58:16 -0700 (PDT) Received: from [172.20.20.20] ([73.94.200.156]) by smtp.gmail.com with ESMTPSA id y79sm7233547iod.13.2017.06.13.17.58.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 17:58:16 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E9BF02E1-3FE8-45E7-BE3F-2710806CC943 Mime-Version: 1.0 (1.0) Subject: Re: Tussles in IPv6 Land From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 13 Jun 2017 19:58:15 -0500 Cc: Philip Homburg , IETF IPv6 Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> To: Lorenzo Colitti Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:58:21 -0000 --Apple-Mail-E9BF02E1-3FE8-45E7-BE3F-2710806CC943 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Jun 13, 2017, at 19:38, David Farmer wrote: >=20 > On Jun 13, 2017, at 18:43, Lorenzo Colitti wrote: >=20 >>> On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg wrote: >>> >Not everyone supports DHCPv6 as you probably know ;-) >>>=20 >>> I know, but we should just treat those devices as IPv4-only and move on.= >>=20 >> Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best= practices, for precisely the reason that they don't provide enough address s= pace. >=20 > I assume you're talking about RFC7934, but where does it say that? Nothin= g normatively says that, it does suggest that you use SLAAC to meet the norm= ative recommendations, there is a warning about potential limits with DHCPv6= , but it doesn't specifically recommend against DHCPv6, especially normative= ly. Furthermore, a recommendation for SLAAC isn't a recommendation against D= HCPv6 in any way. In fact nothing in RFC7934 overrides section 5.9.5 of RFC6434 which explicit= ly recommends all nodes implement DHCPv6 for address configuration. So treating devices that don't support DHCPv6 as IPv4 only devices seems as r= easonable to me as the decision for a device to not implement DHCPv6. Basically, those in glass houses shouldn't cast stones. David Farmer= --Apple-Mail-E9BF02E1-3FE8-45E7-BE3F-2710806CC943 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit






Sent from my iPhone
On Jun 13, 2017, at 19:38, David Farmer <farmer@umn.edu> wrote:

On Jun 13, 2017, at 18:43, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>Not everyone supports DHCPv6 as you probably know ;-)

I know, but we should just treat those devices as IPv4-only and move on.

Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best practices, for precisely the reason that they don't provide enough address space.

I assume you're talking about RFC7934, but where does it say that?  Nothing normatively says that, it does suggest that you use SLAAC to meet the normative recommendations, there is a warning about potential limits with DHCPv6, but it doesn't specifically recommend against DHCPv6, especially normatively. Furthermore, a recommendation for SLAAC isn't a recommendation against DHCPv6 in any way.

In fact nothing in RFC7934 overrides section 5.9.5 of RFC6434 which explicitly recommends all nodes implement DHCPv6 for address configuration.

So treating devices that don't support DHCPv6 as IPv4 only devices seems as reasonable to me as the decision for a device to not implement DHCPv6.

Basically, those in glass houses shouldn't cast stones.

David Farmer
--Apple-Mail-E9BF02E1-3FE8-45E7-BE3F-2710806CC943-- From nobody Tue Jun 13 18:24:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D06B131AC0 for ; Tue, 13 Jun 2017 18:24:07 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cen554gRO7kc for ; Tue, 13 Jun 2017 18:24:05 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 B796A131AAF for ; Tue, 13 Jun 2017 18:24:05 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id t7so12331933yba.3 for ; Tue, 13 Jun 2017 18:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M2i1b/ybxaykdQQ/MH5K/XErXfxoqNB5fZmo1YmBz9w=; b=Ch+ixI4zFh+hA3Up+yrv/4oHVb2zBUjJASuYYe9FX1tyh411dvnSc6uN5bBRsfm2YC Qubzvkm4L/QT+T6hb+wvQQITDDboqSc9eDVTiWhbWTrJancqyt/nutSfEnD02Fv+Yx3q FIdZ4GPnpDyH1ASV4A/dZwOGxxof6IX83WVsohgSPmHLLOhLrNBwE9zm1fuzXs69ZwGj ojoYdy5pIPwehhBvhTWZJHO6Dm5yznvACKPGB0ZAzgx4Ktt8PJ4pWOjbuMfWxg1Z8em5 ry81phcz5E0J6t1K3WJ5YLvHVTDC80A0mOBvdDBA5dVmya/pcYGlbxwp9DGt+LQNmKFq l7EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M2i1b/ybxaykdQQ/MH5K/XErXfxoqNB5fZmo1YmBz9w=; b=EijkUZNdXcCXMS9+u6sNHuRMy19hXG89Ba9rGo+dPP5Mn+Dr5ZyrwAVgQY7fKCi/6T C2MjP41viUQmbYEEirdpVjcY9uWLJzeZF/uoJAyX+N/ulYtX0M03uMm+TeUSEqfCwQub SDKwvevVkqXJQi94PpDMAmEgwAz6g0+hE4V8XRqliDmEjDD6mznsBrjOLOEENEwvE/ZO 7WOfvhtqs2UZCPaAKe3JLKJSzl8YNzywS5IojhnN7B7iAy45JHW2Og+0zEhVKJcaFzAS t/uXeoV0UCmsxWPgxmD9H+t3dr5/BSIMhvLG5IkFBMLA0JOFk7Pc8PvxGPl6sdV3Z0+P KZRw== X-Gm-Message-State: AKS2vOyM+lvlf5qdfpKQ3bTwXiQ/z1LUBv27KbLb/prSkTq5kqMqAqGa h1WGZ/UsNvGnGPit5sDzdvbNZHyFkw== X-Received: by 10.37.180.18 with SMTP id n18mr5412483ybj.258.1497403445024; Tue, 13 Jun 2017 18:24:05 -0700 (PDT) MIME-Version: 1.0 References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: From: Ca By Date: Wed, 14 Jun 2017 01:23:54 +0000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti , Tom Herbert Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403045e6aa26d1ce60551e16849" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:24:08 -0000 --f403045e6aa26d1ce60551e16849 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 5:25 PM Tom Herbert wrote: > On Tue, Jun 13, 2017 at 2:29 AM, Lorenzo Colitti > wrote: > > On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert > wrote: > >> > >> ILA is an innovative way to use IPv6 addresses, but as I described it > >> can't use this in a mobile network if every UE gets a /64. In this > >> case too much space is given the end host which probably a low end > >> device like a smart phone that really doesn't need it. > > > > > > Again, that's the perception from the network operator side of the > tussle. > > The perception from the other side is, "these bits belong to hosts, go > and > > do mobility in the top 64 bits". It's really not hard to do mobility in > the > > network layer. Just build a low-overhead tunneling mechanism that maps > /64 > > prefixes belonging to nodes to base station IP addresses. We have lots of > > those, GTP being one. The overhead doesn't need to be 40 bytes, either - > you > > could > > > Lorenzo, > > The _whole_ point of ILA is to eliminate encapsulation. This is an > example "to use IPv6 addresses in new and innovative ways" as you > phrased it. If we continue using encapsulation then that's just > business as usual and no different than IPv4. There's no innovation > there. Actually, the situation is worse since IPv6 incurs more > overhead than IPv4, so maybe carriers should just continue using IPv4 > in their underlay network to avoid the 20 bytes overhead... > > Tom > I agree with this approach of "no change" since ILA does meet the requirements to replace the existing 3gpp mobility system, let alone offer a compelling benefit. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f403045e6aa26d1ce60551e16849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jun 13, 2017 = at 5:25 PM Tom Herbert <tom@herbe= rtland.com> wrote:
On Tue, = Jun 13, 2017 at 2:29 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Tue, Jun 13, 2017 at 12:20 AM, Tom Herbert <tom@herbertland.com> wrote:
>>
>> ILA is an innovative way to use IPv6 addresses, but as I described= it
>> can't use this in a mobile network if every UE gets a /64. In = this
>> case too much space is given the end host which probably a low end=
>> device like a smart phone that really doesn't need it.
>
>
> Again, that's the perception from the network operator side of the= tussle.
> The perception from the other side is, "these bits belong to host= s, go and
> do mobility in the top 64 bits". It's really not hard to do m= obility in the
> network layer. Just build a low-overhead tunneling mechanism that maps= /64
> prefixes belonging to nodes to base station IP addresses. We have lots= of
> those, GTP being one. The overhead doesn't need to be 40 bytes, ei= ther - you
> could
>
Lorenzo,

The _whole_ point of ILA is to eliminate encapsulation. This is an
example "to use IPv6 addresses in new and innovative ways" as you=
phrased it. If we continue using encapsulation then that's just
business as usual and no different than IPv4. There's no innovation
there. Actually, the situation is worse since IPv6 incurs more
overhead than IPv4, so maybe carriers should just continue using IPv4
in their underlay network to avoid the 20 bytes overhead...

Tom

I agree with thi= s approach of "no change" since ILA does meet the requirements to= replace the existing 3gpp mobility system, let alone offer a compelling be= nefit.=C2=A0

ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--f403045e6aa26d1ce60551e16849-- From nobody Tue Jun 13 18:56:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921EF128C81 for ; Tue, 13 Jun 2017 18:56:04 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc-QqE9jeyZe for ; Tue, 13 Jun 2017 18:56:02 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 5AD2E129AD8 for ; Tue, 13 Jun 2017 18:56:02 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q15so86339436uaa.2 for ; Tue, 13 Jun 2017 18:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PEBZead/9WgZhkXOh7akjl/Yfj8w3x5QXts5WxORuFc=; b=LQoY24ouN3hPZ6Z3ShFarhBkCqjukMxw11pP+MbDCYCDR1VhZCEd6PHvNm/oPPXqks zc0WnQL4FTz8n/Us6NFwh0YBl+s2El8liucVqzsw4BgLJh4+N6/lnNBbYdCRZqwG/5LR Ls/bFJb/Tdk655OnwZVDG23dzF4J0C4xiqJY5f9/kjzEV9CRQLlfbAda6k7mk6Uyzsps Q+fBfnUFVOY5bGSK3nRVqzs1NF5G4P8NiBkNAhqPDs56A/QrVooKkAM4gW+1niwNxLMq GcFQWjRZPeMfBBQR8LaGUmEuQI4Pz/IVC/pFb48WePOr/psPng2KzXzminoqh4FUA04L 2fcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PEBZead/9WgZhkXOh7akjl/Yfj8w3x5QXts5WxORuFc=; b=Lo7COvBkV/xgWfOMLJyV+laHtngDngN8KAXI2/X8wR+eSrpI8OBT7Fy+rqZcpAoE2H +Wjo5pElz1p5OR0by+T04iTQgfcI1cNpJMOexsx8X28QUq14xPRwAQH20ES/4HEjge4y FVnkGsqWC6E87MnOHx3vd3gw9CuXL0WcXV1iraCildT+wozo03MYR3jrHaawtCKUBHsh Q1knmybRzk/OeGpsPYoSY5WMT1vqydjyxtHzDv+/hv8HLqQAog8T7Sgx5dRCf9rV8axd WY53YjUx1XCl5lNvzdYgFWS4zwUaO9ARXLK6Hb6MVl0fQDE9kU0tsvt8oYBesJvRxnvp 10cg== X-Gm-Message-State: AKS2vOz6aaelFjN+jEGeEe15XRRMx2zW5s4Ykn22c3qu/7j4j8gJQess vo67wkbCQDFbKC9O7ksE9si8gLBXoQ== X-Received: by 10.176.18.232 with SMTP id o40mr2955031uac.32.1497405361328; Tue, 13 Jun 2017 18:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.67 with HTTP; Tue, 13 Jun 2017 18:55:30 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> From: Mark Smith Date: Wed, 14 Jun 2017 11:55:30 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lee Howard Cc: Brian E Carpenter , 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:56:04 -0000 On 13 June 2017 at 21:35, Lee Howard wrote: > > > On 6/13/17, 6:50 AM, "ipv6 on behalf of Mark Smith" on behalf of markzzzsmith@gmail.com> wrote: > >>On 10 June 2017 at 11:33, Brian E Carpenter >>wrote: >>> Hi, >>> >>>That's because inserting stuff (any stuff, not just this header) >>> in a packet changes its length and thereby breaks all known methods of >>>determining >>> the maximum packet size allowed on a given path across the Internet. >>> >> >>I think it is more significant than that. >> >>It's >> >>(A) ignoring statements in a very widely implemented and deployed >>protocol specification that has existed for more than 20 years. >>RFC1883 contains the text about not processing EHs in the network. >> >>(B) ignoring the interoperability goal of protocol specifications, >>meaning that new implementations' features interoperate with existing >>implementations without significantly impacting their operation. >>Inserting EHs contradicts Postel's "Be conservative with what you >>send" because existing implementations aren't expecting in-flight >>inserted EHs, and that is because that action is not specified as a >>possibility in RFC2460. > > If you only insert and process EHs inside your network, then you can > reasonably assume that they are expected. Strip EHs at your borders and > everyone=E2=80=99s happy. > So in theory, practice and theory are the same. In practice they're not. Here's a scenario. This is packet's path over the Internet. You're at AS8, providing OTT video services to 50 000 end-users at AS0. [AS0 pkt src]--[AS1]--[AS2]--[AS3]--[AS4]--[AS5]--[AS6]--[AS7]--[AS8 pkt ds= t] Imagine both AS2 and AS5 are inserting EHs and theoretically always removing them, for their own local purposes. Now AS5 is not actually removing them because of any of an implementation bug, misconfiguration or a partial device failure. Will this fault be constrained to AS5? No, not at all. Will this fault be visible to AS5? No, not at all. They'll see no signs of failure such as drops on egress of their AS, as they're not performing any processing of the packets after they've left the AS. How will you at AS8 go about identifying from the broken packets you're receiving which of the ASes along the path is inserting the EH and then not removing the EH that is breaking your service? How long will it take? I'd estimate a minimum of a week to contact all of the ASes in the path, ask them if they're inserting EHs, work to overcome their scepticism that their equipment is misbehaving (because it is always initially assumed somebody else's equipment that is misbehaving when there are no local effects), organise a packet capture on their egress link etc., etc. How are you going to recover your the lost revenue from AS5 once you've identified them as the cause. How are you going to get back the customers who've cancelled their subscription to your OTT video service because it took a week or more to resolve this? What if AS2 is inserting but not removing EHs too? The complexity of troubleshooting this scenario increases even more. Or AS2 is in inserting EHs but not removing them, but AS5 is inserting and removing them. AS5 might accept AS2's inserted EHs, and then have AS2s inserted EHs interfere with AS5's use of them. Unless the cause of AS2 not removing EHs is obvious (e.g., misconfiguration), you'll now have to have both AS2 and AS5 tap their traffic to determine if their EH removal is being performed correctly. Again, this is after you've spent a lot of time contacting all ASes to determine who is inserting EHs in flight. >> >>(C) ignoring the fundamental and foundation principles of layers and >>encapsulation/de-encapsulation to add or remove information to >>existing protocol data units > > You think? > Is routing information the same layer as the network layer, or higher or > lower? Adding headers outside the IP headers seems to me to preserve the > spirit of layering. It is. Encapsulation treats the to-be-encapsulated PDU as an atom. Inserting EHs is not adding headers and is not treating the PDU as an atom. It is splitting the original PDU apart to insert the EH. i.e., before: IPv6 Pkt - [Orig. IPv6 Hdr][Orig. IPv6 Payload]> after: IPv6 Pkt - [Orig. IPv6 Hdr][New EH][Orig. IPv6 Payload] > An alternative would be to formalize a path layer, using MPLS as one mode= l. > We already have a way to do that. IP-in-IP tunnelling. In the IPv6 EH insertion draft, that is being proposed for the SR domain transit case but not when the packet is originated in the SR domain. So there are two different mechanisms being proposed that achieve the exact same outcome (segment routing) based on where the packet originates, either internally or externally. As the only distinction between internal and external packet origins is the value in the source address field, I don't think there is anything to prevent a single method being used for all packets, regardless of their origin. That would be simpler to implement and troubleshoot. The IP-in-IP tunnel method is conventional, proven and far easier to troubleshoot than the EH insertion method. I think IPsec provides a proven model of adding information to packets. transport mode - packet origin host to packet final destination host - insert AH and/or ESP EH in the host's stack during the construction of the IP(v6) header, remove it when the IP(v6) header is deconstructed and the payload handed up to the transport layer implementation tunnel mode - host to gateway (router) or gateway to gateway - add AH and/or ESP EH by encapsulating the original packet in a new IP(v6) packet. >> >>(D) ignoring the operational consequences of making protocols and >>devices harder to troubleshoot and rectify because it breaks source >>address field semantics while the inserted EH is present. > > Yet operators are doing this now. Sounds like a tussle. I don't think it is widespread enough to have uncovered how hard troubleshooting will be. People assume things they've put in place are working if they themselves don't see any consequences. The domain of the EH insertion mechanism is local, the potential fault domain for it extends to any packet destination that is beyond the AS that inserted but didn't remove the EH. The closer to the source of the packet the EH insertion occurs, the greater the the potential fault domain, which could include all destinations on the Internet. In the above example, imagine AS1 is the EH insertion domain failing to remove them, and [AS2] through [AS8] is just one of the paths across which the AS0 subscribers are sending packets across. > >> Despite >>theoretical claims, in practice the inserted EH may not be removed at >>the edge of the insertion domain because of device misconfiguration, >>implementation bugs or partial device failures, so troubleshooting may >>be occurring outside of the domain that inserted the EH. The operator >>who decided to insert the EH may not be the operator dealing with its >>consequences and having to troubleshoot and rectify it. > > Yes, that could be a problem. Do we have a documented BCP to drop packets > with unexpected EH outbound and inbound? *IS* that the BCP? > I don't think high speed IPv6 routers are likely to be able to perform any form of exhaustive EH validation. It would be a new requirement, and one that router vendors have never had before. Doing so is of course also a direction contradiction to "extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." so RFC2460 can't be pointed to as a reason why routers should be expected to perform EH validation. Expecting all AS operators on the Internet to upgrade their devices to perform EH validation just to protect against the case of EHs not being removed is putting the cost of prevention of failure onto the potential victims, not onto the party who chose to insert the EH that then didn't end up removing it. A better mechanism will localise mechanism failures to the domain where the decision to use and implement the mechanism was made. It is better avoid or minimise the possibility of the local mechanism failure consequences being externalised. >> >> >>If we believe network operator's needs are the most important, we'll >>have forgotten who network operators exist to serve and more broadly, >>who IPv6, the IETF and the Internet exists to serve. > > To summarize a point I made yesterday: > The network serves whoever pays for the network. Not all networks are for > individual consumers. > I think you've misunderstood what an "end-user" is. It is the end or final user or consumer of the service. It could be an individual, a group of individuals, an organisation or a device. Whether or not the entity identified as the service end-user is making a direct financial payment or not doesn't distinguish whether they're a service end-user. A network's service end-user is the hosts attached it, with the service being carrying of packets to and from the hosts. If an IPv6 network doesn't provide better service to hosts than an IPv4 network does, because of either the network operator's decisions or IETF decisions, then there is no need for an IPv6 service over an IPv4 one. Regards, Mark. From nobody Tue Jun 13 19:22:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC1F1200C1 for ; Tue, 13 Jun 2017 19:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjneE20uG0DE for ; Tue, 13 Jun 2017 19:22:25 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD641274D0 for ; Tue, 13 Jun 2017 19:22:25 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id g66so73761354vki.1 for ; Tue, 13 Jun 2017 19:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LIdBreEX/TdYJjiOu7xttGYkxAINuCy0V9r3V5WaHxA=; b=uRPh7M1ILtuSUsWYv3yzQLOri54roguc7R10NIBLbp630KrR4Xz3YPqPfbWD3xgm5f Pb2wKKxC2sZ1xYOX88psSUHwwcxWLg01yJ/ni7xGpoE1DD7FQLQPZx2Hk0y6NUToN35I 4pLyGmyPH+jUyDt6cK9WJqHTjcAWZrStMHUgbR422+lwCSXNi+dMkRH30Vf784PHCrRw WuuYzRey0bFpEgJzAJXJ5YR549gMH79VdXYAeJOcmgXDiEbuS7YNQetpirUGE4uYs0x8 i46hH3wZC31I++SC9wVxMFl+MnWr9OtxMcgnF4AQWKPGLuwFOTsMxt4M2JQxmqA1cFpT oUhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LIdBreEX/TdYJjiOu7xttGYkxAINuCy0V9r3V5WaHxA=; b=EHlc6wRKdBfWCkb1TbfTWQkEdjEsti/YQ7prp02Nh+4tAhNHYbYlmRVnyaDPrlOnwT N+TMWvyunOD1m2RZ9+vQ9NwpFRV4ydEommFR8PAUIAtpfqZVyeZ1Mnb7Gh+d2rT5rgu2 1KTqTfW6GXr8rGC59NFyE6mM8Fj3p0TBl0kY8mONlZxsXOgXOmL342hURN0KfXDDK61z hhCnDVgx12jOfZIX/A0+yeLUSC8Lr2Kau9WoKozVVsRVuH1+HUUNgXCAfXEOgaGbrpVY 4t8qlHDJSY6+hqKp9eGSHkIVCDiHYrITMxRMOvWbOHucIs5bQY5YbkYnph1RXsUE4R15 8jDw== X-Gm-Message-State: AKS2vOxjPzyl9R0hWuprGhGDzxzZj08VjQa6Wrrt016+9cQ+gdwvUnAW k/YGxC5WsBM27pZzl1a2MIffc9rqdOUD X-Received: by 10.31.33.81 with SMTP id h78mr1736229vkh.29.1497406944484; Tue, 13 Jun 2017 19:22:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 19:22:03 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 11:22:03 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a11c024ca0316fd0551e23918" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 02:22:27 -0000 --001a11c024ca0316fd0551e23918 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 9:25 AM, Tom Herbert wrote: > The _whole_ point of ILA is to eliminate encapsulation. I know what you're trying to do with of ILA is to eliminate encapsulation. I just disagree it's the right tradeoff, because it deprives hosts of the ability to innovate, and that's not worth saving a few bytes of encapsulation overhead. Actually, the situation is worse since IPv6 incurs more overhead than IPv4, > so maybe carriers should just continue using IPv4 in their underlay network > to avoid the 20 bytes overhead... Technically you don't even have to use IPv4 or IPv6. You could use something else like MPLS. --001a11c024ca0316fd0551e23918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 9:25 AM, Tom Herbert <tom@herbertland.com> wrote:
The _whole_ point of ILA is t= o eliminate encapsulation.

I know what you&= #39;re trying to do with of ILA is to eliminate encapsulation. I just disag= ree it's the right tradeoff, because it deprives hosts of the ability t= o innovate, and that's not worth saving a few bytes of encapsulation ov= erhead.

Actually, the si= tuation is worse since IPv6 incurs more overhead than IPv4, so maybe carrie= rs should just continue using IPv4=C2=A0in their underlay network to avoid = the 20 bytes overhead...

Technically you do= n't even have to use IPv4 or IPv6. You could use something else like MP= LS.
--001a11c024ca0316fd0551e23918-- From nobody Tue Jun 13 19:26:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682C012957B for ; Tue, 13 Jun 2017 19:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZsYp5hmmHqb for ; Tue, 13 Jun 2017 19:26:22 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF7E12947C for ; Tue, 13 Jun 2017 19:26:22 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id y70so35451318vky.3 for ; Tue, 13 Jun 2017 19:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ohHDrzktTM/seOwzHNj6BJyj7JjK1cFWIMmYYBF1rnI=; b=n6iJF7VZLXrcPJUIjVziXLpvVTIicF71McFHEzYZv+UXAsmdiqvfsdy5mzd9jcfcKp BtAmIk6pePoMgthkfMnmbc7F9EihQOKAaYqneDvIUTECRhdWMSlUbyJlkdfHnmj5GKlX w/RUlXkoHoS1yEBho9ChT8nWfR5q0Y5aLSr/tzpu47NY1t4zowGwqbpiU2gKZ9PES0tt gSFlwe3mYS5ugAAVVV01XpsPABV5EGvvxzgUWDdTiiOkNUwwiF+qaRfxiw1lAgXuTs5z HlWUMX/ZLM5cJoaD3SOWRFZBKaJaNkRdiz0mndUFrTQ3GLNCsYwVAVBh6ASCyIggezn4 xmVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ohHDrzktTM/seOwzHNj6BJyj7JjK1cFWIMmYYBF1rnI=; b=EP0fjKWeE+SoP/W2OiVHyLMDWq5ZVdaMrpvu1T5FjMHNovllPL0wfmQHOhh2G6XMyl 5z5gaMQ1ZI5MWLN24OmDhB/NqS8OBXpT3KJ4DCMFgtnkVsQk8E2edMLHSk249k4Xuma/ bgjaG0l/sbQ78IGNZrtOrPMtZEHzqekhi+F1+FiSt3fy6RQc98BVjSK/gsPcHpl6oRSC f0EOLENxwMO4pg1fRX9RfDiTYNIfq6/rP33BQN0s7KFngstsjjSr+Qr4tKpri1JgSmdN EVkkoV9EDemLA3K6n9DUTWDgT62jiRfe7Mkb5GLZRvwdokZ4i/93FuJraNtCJGmxtTV1 sO9Q== X-Gm-Message-State: AKS2vOyuUCRtkN62xT6BVv9AT7qN2rq9LETLpwL3Vm2tXxp+Y3NJYqmM 5LIPfQpTSONTpRWhNxEE4pRHZXSrJ45U X-Received: by 10.31.64.130 with SMTP id n124mr1732596vka.44.1497407180832; Tue, 13 Jun 2017 19:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 19:25:59 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 11:25:59 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: David Farmer Cc: Philip Homburg , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a114479a61ad57b0551e24756" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 02:26:24 -0000 --001a114479a61ad57b0551e24756 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 9:38 AM, David Farmer wrote: > On Wed, Jun 14, 2017 at 2:25 AM, Philip Homburg < > pch-ipv6-ietf-4@u-1.phicoh.com> wrote: > >> >Not everyone supports DHCPv6 as you probably know ;-) >> >> I know, but we should just treat those devices as IPv4-only and move on. >> > > Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best > practices, for precisely the reason that they don't provide enough address > space. > > > I assume you're talking about RFC7934, but where does it say that? > It says so here: Due to the drawbacks imposed by requiring explicit requests for address space (see Section 4), it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests. You can't meet that recommendation on a network that only supports address assignment via DHCPv6 IA_NA/IA_TA. As the document says, you can certainly do it if you provide the host with a prefix using DHCPv6 PD, or some future DHCPv6 option that does not have those limitations. --001a114479a61ad57b0551e24756 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 9:38 AM, David Farmer <farmer@umn.edu> wrot= e:
<= div>
On Wed, Jun 14, 2017 at 2:25 AM, Phil= ip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>Not every= one supports DHCPv6 as you probably know ;-)

I know, but we should just treat those devices as IPv4-only and move on.

Why would you care? DHCPv6-only networks = are NOT RECOMMENDED by IETF best practices, for precisely the reason that t= hey don't provide enough address space.

I assume you're talking abou= t RFC7934, but where does it say that?
=

It says so here:

=C2=A0 = =C2=A0Due to the drawbacks imposed by requiring explicit requests for
=
=C2=A0 =C2=A0address space (see Section 4), it is RECOMMENDED that the= network
=C2=A0 =C2=A0give the host the ability to use new addres= ses without requiring
=C2=A0 =C2=A0explicit requests.
=
=C2=A0
You can't meet that recommendation on a network t= hat only supports address assignment via=C2=A0DHCPv6 IA_NA/IA_TA. As the do= cument says, you can certainly do it if you provide the host with a prefix = using DHCPv6 PD, or some future DHCPv6 option that does not have those limi= tations.
--001a114479a61ad57b0551e24756-- From nobody Tue Jun 13 20:03:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5BB129B05 for ; Tue, 13 Jun 2017 20:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FEUkADg_FzV for ; Tue, 13 Jun 2017 20:03:42 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E69129B04 for ; Tue, 13 Jun 2017 20:03:41 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id e142so51722502ywa.1 for ; Tue, 13 Jun 2017 20:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3iWBwbRV1AFA5xG9QknUvpSH2TwZWYGbj3xs4nLvRic=; b=Rx1Cmbuzu6kOnU9OihXH7CZRdA52lzT0BIewBotUstuzEDOT56X2FXxqXfu5PueKq3 +9u374lPQuHQ3lOkH/zi17JhTrHNlSECrnXISJo0/NjuiO6EWBG/JtfoJpQwUFIjU6y9 +qk4CUNH4fQYoYC+0l6RjO+z+tC4O/dfpuhgf7xZX9cCOcrPAsy8STp5BntqEhmLqMcE 9ahEWWfSFFws7TEdDFFa9qBZQoJ84jphX/IVVFs6rrLtl6SEVSKDzSAyHTlzw9iq/U0v XUarv+J5CS8+VFI4wclP9enoE6TNJgw8wOVvsJCl6/IKT1FIv9uEK0uwrH5VG7L2LSQN sgJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3iWBwbRV1AFA5xG9QknUvpSH2TwZWYGbj3xs4nLvRic=; b=E+xDnlVtTqkaOnwASEMsw+FvWLAMrIVi7PbFUxdY527ccRWx9rywG9lMWhrADaK1D6 AIFRA2zo+bCI/iAOGwz2/wPowYRUilARaTuURD3jRk+I7/jcAE/KNJbodUBVTK2/4TMD v+DMcZFSAI9BfXVd7gLm7NqQcNB4KDhh5P5QRsD2M1iiiTHG8MP5DelW+FcEGX4qPP3Y SpYHdgiMD9fRQch+giVP1L3mtHVzlW+q4tohQHbMlosnlvdog/1Eep5w2wTnIuEVKbQP yXrrAbFeRAYFSAgHOQFyQGbvoC1ClU87+n7o9TCtE4Wmz3uwpOS8Bo/9cpD/2vxGWO1d sbHQ== X-Gm-Message-State: AKS2vOwhHkNP4jpFA+ZPmcal8leTzJ1HSx42y/+92st9VzJd6H60s9cP VU5hDNXve+A32q6OxT7RPM9iVXBTJbBG X-Received: by 10.129.121.203 with SMTP id u194mr5343127ywc.288.1497409420922; Tue, 13 Jun 2017 20:03:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Tue, 13 Jun 2017 20:03:19 -0700 (PDT) In-Reply-To: <2d51f919-bb6a-1f55-8338-0e568f5336b5@gmail.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <2d51f919-bb6a-1f55-8338-0e568f5336b5@gmail.com> From: Erik Kline Date: Wed, 14 Jun 2017 12:03:19 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Alexandre Petrescu Cc: IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0b1c94a367750551e2cc9a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:03:50 -0000 --94eb2c0b1c94a367750551e2cc9a Content-Type: multipart/alternative; boundary="94eb2c0b1c949e89a50551e2cc10" --94eb2c0b1c949e89a50551e2cc10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 13 June 2017 at 23:06, Alexandre Petrescu wrote: > > > Le 13/06/2017 =C3=A0 11:10, Roger J=C3=B8rgensen a =C3=A9crit : > >> On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert wrote= : >> >> >>> But that begs the question, why is /64 the one size fits all answer? >>> What if in the future that number proves to be the wrong choices? >>> Flexibility seems like a better way to future proof this. >>> >> >> What I seem to remember, read or heard somewhere is that it went >> something like this: >> >> IPv6 need more address space than IPv4 which is 32. >> 64 was just double, let's double that again and we should be safe? >> They end up with 128bit, and slice it in two half, /64. One for LAN >> and one for network. >> Why not? >> > > Because IPv4 Classes were removed. > > (a 64 boundary makes it a 'Class E' address, like 8 made it a Class A). > Arguments about address space issues that proceed from an analogy to IPv4 make no logical sense to me. A 2-seater sports car and 18-wheel truck are both technically "automobiles", but it absolutely /does not/ follow that they should be operated in exactly the same way. --94eb2c0b1c949e89a50551e2cc10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 13 June 2017 at 23:06, Alexandre Petrescu <alexandre.pet= rescu@gmail.com> wrote:


Le 13/06/2017 =C3=A0 11:10, Roger J=C3=B8rgensen a =C3=A9crit :
On Mon, Jun 12, 2017 at 5:20 PM, Tom Herbert <tom@herbertland.com> wrote:
<snip>
But that begs the question, why is /64 the one size fits all answer?
What if in the future that number proves to be the wrong choices?
Flexibility seems like a better way to future proof this.

What I seem to remember, read or heard somewhere is that it went
something like this:

IPv6 need more address space than IPv4 which is 32.
64 was just double, let's double that again and we should be safe?
They end up with 128bit, and slice it in two half, /64. One for LAN
and one for network.
Why not?

Because IPv4 Classes were removed.

(a 64 boundary makes it a 'Class E' address, like 8 made it a Class= A).

Arguments about address space issu= es that proceed from an analogy to IPv4 make no logical sense to me.
<= div>
A 2-seater sports car and 18-wheel truck are both techni= cally "automobiles", but it absolutely /does not/ follow that the= y should be operated in exactly the same way.
--94eb2c0b1c949e89a50551e2cc10-- --94eb2c0b1c94a367750551e2cc9a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgGO7OburDNzy5r/HJra6HuHqOSticAo8/ 864B2/mhW7gwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjE0 MDMwMzQxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAHNIb8tE/0cl4tIEP3B2gj3H+nfgwyN6uHDbYW16Uzf7cvU3DTg1 +ItEHR1kpQ+Xzv8vQF+8djatKR74NHjAy+MhpTgNqGvsUS9x+6Zr2XbliN2wtZBY4UCvktEZTlRC 7fE5LITmxShN0L5YNayW7tvg2D2Oj6RG1iIK42eZHBcZOWj/LR/caZMkYiDl2/aVZ9lG1zsSzJgT fpddVxxegaE73ocPChqUe9msxa9m31GMqbV5QxcL98pDsV8FHrx2SJbZtz+lrSBHw27fdRKXIva5 lPPiNbSCduk8CO/E9f/eVEUZHH0OcuSAcupqJeeJTwZnXXI93OlHUhkBrJGY2yY= --94eb2c0b1c94a367750551e2cc9a-- From nobody Tue Jun 13 20:12:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301D2129473 for ; Tue, 13 Jun 2017 20:12:53 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O01wblHwBekO for ; Tue, 13 Jun 2017 20:12:51 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 C2BF4127286 for ; Tue, 13 Jun 2017 20:12:51 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 68so69543329uas.0 for ; Tue, 13 Jun 2017 20:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xCPqKWgy34RMFPpY/SliwFQ5bhorntvlXjfYwSmTMR8=; b=W5XCdSiJbmyUtJGee815HGEqBNFEUKpEN0/Y//p5/dqdgu+qIeg6sH3mIJ66C64ii9 a27PcKJJsM2lEk6YTondCAKLbwQBFOT9jZWqgURHDq8k4lUf6PXek0Ue5RQ+QqTEEOpj 1xZDEONcfSzE+9bTV3abo5iNvFogSbMPc+oGLMUiiGpxfZZh9qRTzFhaK1KXudpZWElx e26vutd19bBNN27QTFwmEAR+z75oau3cLxb/b6sx8fcZbO3bgwE/u4KidaWMmsM7f1ww Qsp2LdOI3XAYdaNpxZt+PvRjxO1G9lwlJT+WO9efq1lmpjWiDTEYsLa4zVfrT9E7dd/H vL2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xCPqKWgy34RMFPpY/SliwFQ5bhorntvlXjfYwSmTMR8=; b=Po64n2z8vnUPtoESWtureajOL+Uq022m1A9ml91baqKholdFkC0TEZvS5tfLPcEvb3 UMgXd7Af+EA6jDb1YnGKyEC2plFrF+D6jhlo9kjz6N2HSeMr3higO5Ho5Xj+++/qt3ap VlAmb2hi4bGOWdp8FQaRS2k39Q1zYKhA6kwqKThAnhgIQqOaG5I6UER/FzKDCUhGmbVT rb/qfm1s2NS8DY/14PtZrB3mbEMQQdNHk2ZuXjIANJmvB2yLkaU/LRjLgjUvYGwRLr1Z PvGlEkAZ9IgT/6wKKVu9v6djA36qItUIa46vB09sHjMqdUcqfN5NM6Z4wroWtG5KNf2P SOBA== X-Gm-Message-State: AKS2vOwBYQ6YCBUF4N9jfoTTmyquiVZDMOujbA6ZJrR6w+0FiFwzemRn m6MKPHveexQysUR37Ach7fc3CFbetM4k X-Received: by 10.176.83.16 with SMTP id x16mr4958836uax.11.1497409970665; Tue, 13 Jun 2017 20:12:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Tue, 13 Jun 2017 20:12:29 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 12:12:29 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Ralph Droms Cc: Philip Homburg , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c18f1ac62c6380551e2edc8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:12:53 -0000 --94eb2c18f1ac62c6380551e2edc8 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 9:23 AM, Ralph Droms wrote: > Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF best > practices, for precisely the reason that they don't provide enough address > space. > > > Can you explain this statement, please? I don't understand the connection > between DHCPv6 and the size of the available address space. > The answers are in RFC 7934. --94eb2c18f1ac62c6380551e2edc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 9:23 AM, Ralph Droms <rdroms.ietf@gmail.com>= ; wrote:
<= div>
=
Why would you care? DHCPv6-only networks are NOT RECOMMENDED by IETF b= est practices, for precisely the reason that they don't provide enough = address space.

Can you explain this statemen= t, please?=C2=A0 I don't understand the connection between DHCPv6 and t= he size of the available address space.

The answers are in RFC 7934.
--94eb2c18f1ac62c6380551e2edc8-- From nobody Tue Jun 13 20:36:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B207612946C for ; Tue, 13 Jun 2017 20:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfy0oDrjgYyY for ; Tue, 13 Jun 2017 20:36:44 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 AABDD129480 for ; Tue, 13 Jun 2017 20:36:43 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id q97so169785934wrb.2 for ; Tue, 13 Jun 2017 20:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MpDHCzcrcJKiZxWXdi3pu+rjZPX74MD3cN8reQtJkYI=; b=OwzYVbhIgfzJncXu0+im2S3ACwdnOwFSNCK67F0vqKuFfHJuLCQvQaLDqOx0r73Vi4 zV4X3iYkv0iP9LUR+wZFij2Ygh1TL05Q7hLMYcRJDO75Brp+QGB7xUo2f1q5Xg38sGKH 4yjKvfyKBgrmfYhMgjf3s18PMOHcBoLzkQd8Gaqb58zjEfBt94w9v9nZ3/ti9cvd0jMZ s3oqK9NbZi8lmDOEkHG98Ekjp9DPduBpFvY0f4gL/2Pp0TNysCOTddxsdjZt09Hr8qZ2 We2kBhWuxGIvi+RY/T3JrluEXkpHD/7oNx2fSJbs3jd8yJR0j2NtFdFV1qdlU9EOBz+p ajLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MpDHCzcrcJKiZxWXdi3pu+rjZPX74MD3cN8reQtJkYI=; b=go+IT+k+pEkAN9PycczCop4w0jTbo0hWVbldjinybPhMiUDRzjKOFgJBnkwvTJ7xsO puRVeR64Bvprpayidutkptscpd4wyvEZh9XcOT9qQxCxVd5xtcreA2sFiEYjpDbxa4ZK c3PcLJVM26jo44Gv4oPQg7ky93CpMpWfPT5de3SukS8BQ7QRUcDI6FPwfTJ2cYXF0XoP 8MF9u/Q990Ri+fTu7/+IhyqB0vSwmMdUvRd6Qmz51mH9V0f1SK634BljQ6mH2J1s580A eUVCs9GwPZBWOTaqvJDxjw/TLFZ8MXSb4xt8A2rQnwFAFYADASjArlM2FUzOPh1w5IiB TjIg== X-Gm-Message-State: AKS2vOxBg1aqhlWjmAo1mRCZ0Oh17zju43Sv68sLun8FiKwlkIzwINd0 wK2n7nKfVn7negKO+GB10P5AKuL6mftv X-Received: by 10.223.166.196 with SMTP id t62mr4547638wrc.52.1497411402188; Tue, 13 Jun 2017 20:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Tue, 13 Jun 2017 20:36:41 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Tom Herbert Date: Tue, 13 Jun 2017 20:36:41 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:36:46 -0000 On Tue, Jun 13, 2017 at 7:22 PM, Lorenzo Colitti wrote: > On Wed, Jun 14, 2017 at 9:25 AM, Tom Herbert wrote: >> >> The _whole_ point of ILA is to eliminate encapsulation. > > > I know what you're trying to do with of ILA is to eliminate encapsulation. I > just disagree it's the right tradeoff, because it deprives hosts of the > ability to innovate, and that's not worth saving a few bytes of > encapsulation overhead. > Can you tell me what the killer app is on a smartphone that require 2^64 addresses? Tom >> Actually, the situation is worse since IPv6 incurs more overhead than >> IPv4, so maybe carriers should just continue using IPv4 in their underlay >> network to avoid the 20 bytes overhead... > > > Technically you don't even have to use IPv4 or IPv6. You could use something > else like MPLS. From nobody Wed Jun 14 00:11:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87E127977 for ; Wed, 14 Jun 2017 00:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOSkhScwRs8P for ; Wed, 14 Jun 2017 00:11:45 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D131C1276AF for ; Wed, 14 Jun 2017 00:11:44 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id 191so75967893vko.2 for ; Wed, 14 Jun 2017 00:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oLuT3qwIP83TQtS2pUZ3Av8F1BJSrdnaWOiiDY9dk8c=; b=V1W+J8+P5LSekT1os683ib5cf6RQVeI6JBt8Rq+zmOm367q4HT2J0PGqx82LPn8ieu iBRxQ+SxpO+jqM0eM5VSaaywaJxhkzV6cyWruNgS2jMn70n2PIOlYwVNhVS2aUP7nlgu 3uFL0IIyT/UqA6tjwXUBKO5kjwSGv1Y/g7BVBixJyoJZ/yFKBw0rFIznyeiZTjgxN7Gk V3pCXR9yU/laYUoZysa2QkPV35hXUhmOLhsIOfyH0GvEUBW972tJVIW24bC8ThFbOqMy +63YuXM9SrBzALLudT/aYBwJMevUa69ifAEcCzlwoadj9Vtn2IdgEYxHwQr7Ny/vXRcg i4Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oLuT3qwIP83TQtS2pUZ3Av8F1BJSrdnaWOiiDY9dk8c=; b=I3jBCmhyAbf9BHcF7MUKME3rPey0MbvpzX0EcJwd/Dnfk5MrlihPb75wk2qgqpuAzQ oCEccaeadJN1jsvrDITURvc3/112HXV0zrMmIRSaQQ5cZEzjf6lv+c4rSG6etEAuqn+x oVcrzRK2MuWV37oMxuoU9W1MPo+Z1ZNeOJkeQ0zJNz0Uf4sgk17ewUc1BLhywY4kCAHg 8QPaq+7lwKyAHnW0LuPUFgqSAu8LahQBlP1NihgavC6dXhHa7ykn6reUV44TuEtjZYjy CtENmXSbviD1qocFAsHsGNRaw7jaj0j8NRa9KyNXmm98S+ZmJzsmFpGg9K0AAH4iiSsT Du4g== X-Gm-Message-State: AKS2vOxmgj4o5XWMP5FyBED3+EVkqL4Pv3JYrSFzkl/Fc2PvQrr4rlzY BSbQNts91fWGyt/D3zkrHo0QORZqXP8KITg= X-Received: by 10.31.170.2 with SMTP id t2mr2262204vke.100.1497424303574; Wed, 14 Jun 2017 00:11:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 00:11:22 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 16:11:22 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a11430a72b2f54c0551e6431a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 07:11:46 -0000 --001a11430a72b2f54c0551e6431a Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 12:36 PM, Tom Herbert wrote: > Can you tell me what the killer app is on a smartphone that require > 2^64 addresses? > I don't have one for you today, and I don't think I will have one for you tomorrow either. I want to preserve the ability for someone else to give you the answer during the expected multi-decade year lifetime of the protocol. If you take the bits for your own use, we will never get that answer. --001a11430a72b2f54c0551e6431a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 12:36 PM, Tom Herbert <tom@herbertland.com> wrote:
Can you tell me what the kil= ler app is on a smartphone that require
2^64 addresses?

I don't have one fo= r you today, and I don't think I will have one for you tomorrow either.= I want to preserve the ability for someone else to give you the answer dur= ing the expected multi-decade year lifetime of the protocol. If you take th= e bits for your own use, we will never get that answer.
--001a11430a72b2f54c0551e6431a-- From nobody Wed Jun 14 00:50:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D2F129B51 for ; Wed, 14 Jun 2017 00:49:58 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RettSPRh0YZ for ; Wed, 14 Jun 2017 00:49:57 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 DF4F1129B50 for ; Wed, 14 Jun 2017 00:49:56 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id q15so89727212uaa.2 for ; Wed, 14 Jun 2017 00:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U3vixbQrU7kwRVwTeb7XQBT+2h3ARQEkxXFeZN9owr8=; b=q0dh1EpHaNrL2BtswlhnSVUEBjUI5yVGcr53HNTGxsDim8WmhAZV7MMAyhYCVosfJ+ i/whkuM0nq1dexjLKAyFvyTZn3alF5JCc2MSCdbVZznvP0avo+raJQgczF0ypd+nBTB/ OgEm79rJzkKoGuAnVMtX3wBbR2fAXA6o1wD0pr75NANKRiOgB0TxaF5sFtbYUw/9lr/p umVoiC0D6qcVHPS2EMDy1fXnjsunBZgj47KK/Ku2N6J7X5ifSEQGDPIDe+FKqyq+fuV4 eqOon8Hgq2Pk3clT1s9Haz94y4fy0DB8fWmaRGHHygh8Kc6nh1naJ1ZQBQ8EHWHGNFV1 F8Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U3vixbQrU7kwRVwTeb7XQBT+2h3ARQEkxXFeZN9owr8=; b=C9OvrS+HK3JeRnTIZCBDrPFntXdEJ8cqPlILDH9E8Gvi/JKG4rt/4fBWQll/JRY9Y3 uqhBIGhc7kBC35XN3uRfmzMtzq+Bxkfi68wIIuEJW5+8++3tuubIxrUdR/bxb9iQ4Txc j5SOr7ipWduBQto1hw6O4gWMofcSMvV+jKlCmL9oXg1Vst7ZHctnNdxr9SX1/jZwGU6d RZJYDXzrhkYRW31/aWCmOhkWZDaBYidTLhE1YhgmMOBtUC4d10iACDqqJYDA3tsh6KLz jKe/ek82CJlv8z5oPTN8n92UzG8+sz5E+yYMEwz+KsdF5HMa1yq2uFcCAUM4syElKSz3 5pIQ== X-Gm-Message-State: AKS2vOzedkPdfQ6Kt3+Js37CXLzraIy3RJZE+Smt1mwdSOz/xovmD0IJ 3v1gPq/5AWuay2CVIi71AuLqzWCcZShn X-Received: by 10.176.83.16 with SMTP id x16mr5505848uax.11.1497426595789; Wed, 14 Jun 2017 00:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 00:49:34 -0700 (PDT) In-Reply-To: <01b8e1d6-125c-2ecb-6888-e7283f3d488b@gmail.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <01b8e1d6-125c-2ecb-6888-e7283f3d488b@gmail.com> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 16:49:34 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: Ole Troan , Fernando Gont , 6man WG Content-Type: multipart/alternative; boundary="94eb2c18f1ac521ce40551e6cc27" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 07:49:59 -0000 --94eb2c18f1ac521ce40551e6cc27 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 5:28 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Er, what? It's perfectly fine to say that the address is 128 bits long, > and > > that half of it is assigned to the network and half to the link. > > But it doesn't. It first states that the boundary between prefix > and IID is floating, and then states that it isn't. > There is no contradiction here. The value is floating, but *in the current standards*, it is set to 64 for all unicast addresses except those in ::/3. Should we change this? No, I don't think so. Can we change this? Yes, absolutely - all we need to do is update 4291. > I don't see why we need new text for that. Any document that wants to use > a > > different value can simply update 4291. > > Agreed, theoretically. But simply s/required/recommended/ in 4291bis > would be a much more elegant way of handling this. > In the ivory tower, maybe. In the real world, simply changing from "is" to "should" would be a result in immediate pressure to switch to longer interface IIDs on currently-defined link types of interest (specifically, Ethernet and wifi). Remember that implementations are not built based on what the standard recommends, but on a balance between what the standard requires and what the operator desires. (If you doubt this view, I suggest reading your co-authors' comments.) Also remember that most implementations already support longer-than-64 bit prefixes today. > > We have a popular implementation that only accepts 64-bit IID lengths in > > certain cases. Are you proposing that our implementation change or not? > > No. But if some new link technology comes along for which there is a good > technical argument for, say, 60 bit interface identifiers, wouldn't you > want to accommodate it? (I have no idea what that argument might be.) > It's pretty clear that if an IPv6-over-foo document comes along that says the IID length is 60 (and correspondingly updates 4291), then in order to to support IPv6 over foo, either our implementation would need to change, or the parts that rely on the 64-bit IID lengths would be disabled. As you say, we don't know whether something like this will come along, and I don't think we should preemptively update 4291 to accommodate this. It's hard for me to think of something you can do with 60 bits but can't do with 64 bits. --94eb2c18f1ac521ce40551e6cc27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 5:28 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> Er, what? It's perfectly fine t= o say that the address is 128 bits long, and
> that half of it is assigned to the network and half to the link.

But it doesn't. It first states that the boundary between prefix=
and IID is floating, and then states that it isn't.

There is no contradiction here. The value is floating, but= *in the current standards*, it is set to 64 for all unicast addresses exce= pt those in ::/3. Should we change this? No, I don't think so. Can we c= hange this? Yes, absolutely - all we need to do is update 4291.
<= br>
> I don't see why we need new text for that. Any document tha= t wants to use a
> different value can simply update 4291.

Agreed, theoretically. But simply s/required/recommended/ in 4291bis=
would be a much more elegant way of handling this.
In the ivory tower, maybe. In the real world, simply changing f= rom "is" to "should" would be a result in immediate pre= ssure to switch to longer interface IIDs on currently-defined link types of= interest (specifically, Ethernet and wifi).

Remem= ber that implementations are not built based on what the standard recommend= s, but on a balance between what the standard requires and what the operato= r desires. (If you doubt this view, I suggest reading your co-authors' = comments.) Also remember that most implementations already support longer-t= han-64 bit prefixes today.
=C2=A0
> We have a popular imple= mentation that only accepts 64-bit IID lengths in
> certain cases. Are you proposing that our implementation change or not= ?

No. But if some new link technology comes along for which there is a= good
technical argument for, say, 60 bit interface identifiers, wouldn't you=
want to accommodate it? (I have no idea what that argument might be.)

It's pretty clear that if an IPv6-over-f= oo document comes along that says the IID length is 60 (and correspondingly= updates 4291), then in order to to support IPv6 over foo, either=C2=A0our = implementation would need to change, or the parts that rely on the 64-bit I= ID lengths would be disabled.

As you say, we don&#= 39;t know whether something like this will come along, and I don't thin= k we should preemptively update 4291 to accommodate this. It's hard for= me to think of something you can do with 60 bits but can't do with 64 = bits.
--94eb2c18f1ac521ce40551e6cc27-- From nobody Wed Jun 14 02:17:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7DF128CD5 for ; Wed, 14 Jun 2017 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5cjYV3w6eqh for ; Wed, 14 Jun 2017 02:17:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5EE126CF9 for ; Wed, 14 Jun 2017 02:17:20 -0700 (PDT) Received: from [192.168.0.183] (unknown [105.60.72.189]) (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 3AB9383576; Wed, 14 Jun 2017 11:18:10 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , otroan@employees.org Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <40843011-5365-5df9-4339-eda0815b7a2d@gmail.com> <0051e1f1-6c5b-303d-67fb-d5a059a65336@si6networks.com> <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> From: Fernando Gont Message-ID: <0efe3787-72cf-2a21-078d-485fa784be4f@si6networks.com> Date: Wed, 14 Jun 2017 12:04:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <96eaf050-63b6-4804-81b7-77605820c2a3@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:17:24 -0000 Hello, Brian, On 06/13/2017 04:26 AM, Brian E Carpenter wrote: > Fernando, > > On 12/06/2017 12:47, Fernando Gont wrote: >> On 06/11/2017 02:51 AM, Brian E Carpenter wrote: >> [...] >>>>> d) There is no physical reason for n to have the same value on different link media. >>>> >>>> There is no technical reason why IID length is tied to the datalink type. >>> >>> I believe there is: so that SLAAC can work with devices out of the box, without >>> having to set the IID length. >> >> Not sure I follow. >> >> Router advertised Prefix/N (where N is nowadays hardcoded to be "64", >> but need not). Host eploys RFC7217, and grabs 128-N random bits from F() >> to generate the IID/address. >> >> Why does N need to be set on a per-link-type basis? > > It doesn't *need* to be. But SLAAC by design assumes that it is > set per link-type; that is architectural flexibility which is > removed by RFC4291, which IMHO is a bad message to send to the future. I think that RFC4291 should simply say that the RECOMENDED value is 64, leaving the door open to other values. With RFC8064 in place, there's not much reason for this value to be per-link. BUt that doesnt' mean that a specific value should be mandated (MUST). >>>> There was at some point when we thought it was a good idea to embed L2 addresses in the network layer address. >>>> Even so, it would be trivial to make implementations deal with arbitrary IID lengths. >>>> >>>>> e) Future link media might more appropriately use a different value. >>>> >>>> See above. has very little to do with data-linkt type. >>> >>> That's correct. By dropping modified EUI-64 we have removed a >>> noticeable dependency. But who's to say there won't be a future >>> link type whose deployment scenario is better suited by, say, >>> 80 bit prefixes and 48 bit IIDs? I have no idea about that. >> >> Well, on such links the local router would advertise a /80 rather than a >> /64. Why should the clients need to worry about this? > > Because SLAAC wouldn't work, because the addressing architecture > forbids SLAAC from working in this case. Exactly. SLAAC should be able to work with non-64 bits. Implementations should be made made flexible with that in mind, no matter we keep 64 as RECOMMENDED. >>>>> f) Therefore the addressing architecture should only define n=64 as a default >>>>> recommendation for IPv6-over-foo documents. >>>> >>>> I don't think that follows from the arguments laid out above. >>>> We can (if we want to), make SLAAC work with any IID length. Including 0. >>>> >>>> I still don't understand what the goal is here. What problem are you solving? What is the proposal? >>> >>> Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do. >> >> +1 > > Well actually, my statement was wrong. rfc4291bis needs a s/required/recommended/ > to remove the inflexibility. Agreed. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 14 02:17:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227FC128D44 for ; Wed, 14 Jun 2017 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMTU43y_nK62 for ; Wed, 14 Jun 2017 02:17:26 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE2B126CF9 for ; Wed, 14 Jun 2017 02:17:25 -0700 (PDT) Received: from [192.168.0.183] (unknown [105.60.72.189]) (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 580C3833BC; Wed, 14 Jun 2017 11:18:15 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , "Manfredi, Albert E" Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <69a56022-98fa-6ff9-add9-0345410ec171@si6networks.com> From: Fernando Gont Message-ID: <2dff8594-1d9a-c3f3-4037-113469c6195f@si6networks.com> Date: Wed, 14 Jun 2017 12:05:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:17:28 -0000 On 06/13/2017 04:28 AM, Brian E Carpenter wrote: > On 12/06/2017 12:55, Fernando Gont wrote: >> On 06/11/2017 04:46 AM, Brian E Carpenter wrote: >>> On 11/06/2017 12:00, Manfredi, Albert E wrote: >>>> -----Original Message----- From: ipv6 >>>> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >>>> >>>>>> If we remove the 64 bit boundary from 4291, then an update of >>>>>> 2464 will likely result in the removal of any bit boundary >>>>>> there as well. >>>>> >>>>> No, for the out-of-the-box reason. I can't see any practical >>>>> alternative to a fixed length per link type. >>>> >>>> I think there are practical alternatives, so I too would suggest >>>> not to state flatly that SLAAC requires fixed length IIDs. Anything >>>> that requires RAs to work can make adjustments to its IID, in real >>>> time. >>> >>> It cannot adjust its IID length when assigning itself a link-local >>> address *before* receiving any RA/PIO messages. >> >> link-local could be considered a special case... > > Maybe, but that isn't how RFC4862 is written today. Well, that's why we're here, I guess. :-) For instance, link-local only works with fe80::/64, no matter what the spec says (i.e., shorter prefixes do not work). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 14 02:17:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260C9126BF0 for ; Wed, 14 Jun 2017 02:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81uz7snmQH1b for ; Wed, 14 Jun 2017 02:17:32 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F28128D44 for ; Wed, 14 Jun 2017 02:17:32 -0700 (PDT) Received: from [192.168.0.183] (unknown [105.60.72.189]) (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 ED4BD83576; Wed, 14 Jun 2017 11:18:21 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter , otroan@employees.org Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> From: Fernando Gont Message-ID: <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> Date: Wed, 14 Jun 2017 12:09:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:17:41 -0000 Hi, Brian, On 06/13/2017 04:35 AM, Brian E Carpenter wrote: > On 12/06/2017 13:00, Fernando Gont wrote: >> On 06/11/2017 09:29 PM, otroan@employees.org wrote: [....] >>> - Removing the constant from the addressing architecture will likely set these changes into motion. >>> (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary >>> to stay in IPv6 over foo is tenable.) >> >> Me, I don't think there's a reason to keep the 64 bit constant in >> ipv6-over-foo documents. Actually, with RFC8064 in place, there's no >> reason why the IID should be link-type dependent. > > I believe that is simply false unless you want to go back to the era > of DIP switches with instructions to users to > a) choose an IID length for their new subnet > b) set the DIP switches on every device to select that length > c) then plug and play. > > Otherwise LL addresses cannot be formed consistently on the > whole link. > > OK, that is caricature, but without a substantial reworking of > RFC4862 I believe that is essentially what we would need, in > an automated version, before SLAAC can start. > > Anway, all this is empty talk as long as the addressing architecture > *requires* 64 bits rather than *recommending* 64 bits. * Mandate fe80::/64 for link-local * RECOMMENDED /64 for subnets * Make SLAAC implementations flexible so that they could do SLAAC if a non-64 PIO is advertised. (it's kind of weird that we even have flexibility wrt the prefix length in parts of 4291, and in the PIO options themselves, and then mandate one specific value) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 14 02:23:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C54126CF9 for ; Wed, 14 Jun 2017 02:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kusZsI3L6dQM for ; Wed, 14 Jun 2017 02:23:30 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C514126BF0 for ; Wed, 14 Jun 2017 02:23:30 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id B0ECD78931 for ; Wed, 14 Jun 2017 11:23:28 +0200 (CEST) Date: Wed, 14 Jun 2017 11:23:27 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170614092327.GB30896@gir.theapt.org> References: <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:23:32 -0000 On 2017 Jun 14 (Wed) at 12:09:11 +0300 (+0300), Fernando Gont wrote: :Hi, Brian, : :* Mandate fe80::/64 for link-local :* RECOMMENDED /64 for subnets :* Make SLAAC implementations flexible so that they could do SLAAC if a :non-64 PIO is advertised. As someone who is on the "/64 is the devil" side, I am perfectly happy with the above. -- I only touch base with reality on an as-needed basis! -- Royal Floyd Mengot (Klaus) From nobody Wed Jun 14 02:28:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B662A128CDC for ; Wed, 14 Jun 2017 02:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C3TiICZdUxU for ; Wed, 14 Jun 2017 02:28:45 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 808C1126CF9 for ; Wed, 14 Jun 2017 02:28:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5E9ShHO045999 for ; Wed, 14 Jun 2017 11:28:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D1EB1203438 for ; Wed, 14 Jun 2017 11:28:43 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BE8DA201C9B for ; Wed, 14 Jun 2017 11:28:43 +0200 (CEST) Received: from [132.166.85.96] ([132.166.85.96]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5E9SgU9011793 for ; Wed, 14 Jun 2017 11:28:43 +0200 Subject: Re: Tussles in IPv6 Land To: ipv6@ietf.org References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Alexandre Petrescu Message-ID: Date: Wed, 14 Jun 2017 11:28:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:28:48 -0000 Le 13/06/2017 à 19:25, Philip Homburg a écrit : >> Not everyone supports DHCPv6 as you probably know ;-) > > I know, but we should just treat those devices as IPv4-only and move on. > > It is not a good position to let one OS vendor lock up a large part of the > IPv6 protocol. I would like Android backers to make DHCPv6-PD work. At work, the compilation of ISC software on Android is a very difficult task (impossible?), whereas the same software on other IoT platforms like Sierra goes very smoothly. Alex > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jun 14 02:32:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCB1128B37 for ; Wed, 14 Jun 2017 02:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoTTIBQoEqLq for ; Wed, 14 Jun 2017 02:32:42 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B514B126BF0 for ; Wed, 14 Jun 2017 02:32:42 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l75so62309800ywc.3 for ; Wed, 14 Jun 2017 02:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PO7PRUJN4EZ6FYTUMFAl1JEieT8qxDd2NdIlmdS5T2I=; b=rPRD73re15D/aMlMygy60ydc6OXyyXslklZ4Qn1ghjsydtEkwc2h06e2OCdJQdItsh eOnWtdKBgp00avRE6BvwvHKtUmuqwLsNQ0sD7xtMA5cGCFF4jIY3nttrYPaemFgbyKwl caKbVrhtFRgclQIOde4lbnrSlp7JdmsfRC2QNcImIVQ96x7aRgF+pZP0ceQJd9plfAM4 jjSosN0nzrhdQucULIxJG7PJjgq7V8CPn+Tp7gdP6pwOtHhwaaiAn8NOstmj/Hwk055J S2gNpNVJefc5jH8pW1afHgsCy7s2MNdJjt8LnyiEEkhWaWucjVaS7FTd8+o1LaePTOxO /Vzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PO7PRUJN4EZ6FYTUMFAl1JEieT8qxDd2NdIlmdS5T2I=; b=VTIA6dFmwM9J1ngxJsgtKceGdnHJHk71HSbaG7HetuG2Wp9hYByoejyW50u1fy8HCE j7d9VnPHrKMKwgFb8Nb30ve9+1RTjda549UJwqEi+bLZyHhNokaO8nRIWnZvzfnMT1l/ N6Yuh13xkKBFk/BdoeNH/zxt0YDO8uk3cUIdeI6y1xZ6jeb3hd2+qqDff7JmOrm317bl ThBpA0PQFHGAiiQloOmlUcbZyggXGIPPLCOV9XiN+BVnGZnidip+OsclTqZ2MYHlB0LZ 41jka/YbIgnOUwDUIehnjcHVESbuKuqrTNvL7yOAF14lwBdHeJzOIGm50S1g2DfWN781 ysUQ== X-Gm-Message-State: AKS2vOwzphY3jzSKtwcsR7blcfew1LtykJkQ88R13Nz+MKugXDOqmxSl hJwFjWwPFpCePiMFu0YhyaU9zoezLuuO X-Received: by 10.129.89.135 with SMTP id n129mr6250407ywb.181.1497432761765; Wed, 14 Jun 2017 02:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Wed, 14 Jun 2017 02:32:21 -0700 (PDT) In-Reply-To: <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> From: Erik Kline Date: Wed, 14 Jun 2017 18:32:21 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Fernando Gont Cc: Brian E Carpenter , Ole Troan , 6man WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11470b74ddd38c0551e83b6d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:32:45 -0000 --001a11470b74ddd38c0551e83b6d Content-Type: multipart/alternative; boundary="001a11470b74d7983b0551e83b5f" --001a11470b74d7983b0551e83b5f Content-Type: text/plain; charset="UTF-8" On 14 June 2017 at 18:09, Fernando Gont wrote: > Hi, Brian, > > On 06/13/2017 04:35 AM, Brian E Carpenter wrote: > > On 12/06/2017 13:00, Fernando Gont wrote: > >> On 06/11/2017 09:29 PM, otroan@employees.org wrote: > [....] > >>> - Removing the constant from the addressing architecture will likely > set these changes into motion. > >>> (i.e. I don't think a position where one wants to remove the 64 bit > constant from 4291 and expect the 64 bit boundary > >>> to stay in IPv6 over foo is tenable.) > >> > >> Me, I don't think there's a reason to keep the 64 bit constant in > >> ipv6-over-foo documents. Actually, with RFC8064 in place, there's no > >> reason why the IID should be link-type dependent. > > > > I believe that is simply false unless you want to go back to the era > > of DIP switches with instructions to users to > > a) choose an IID length for their new subnet > > b) set the DIP switches on every device to select that length > > c) then plug and play. > > > > Otherwise LL addresses cannot be formed consistently on the > > whole link. > > > > OK, that is caricature, but without a substantial reworking of > > RFC4862 I believe that is essentially what we would need, in > > an automated version, before SLAAC can start. > > > > Anway, all this is empty talk as long as the addressing architecture > > *requires* 64 bits rather than *recommending* 64 bits. > > * Mandate fe80::/64 for link-local > * RECOMMENDED /64 for subnets > * Make SLAAC implementations flexible so that they could do SLAAC if a > non-64 PIO is advertised. > 128-bit IPv4, yippee. IPv6 NAT, I cannot wait. I propose we also change the name of the working group while we're at it, maybe v4-128-man. --001a11470b74d7983b0551e83b5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 June 2017 at 18:09, Fernando Gont <fgont@si6networks.com> wrote:
Hi, Brian,

On 06/13/2017 04:35 AM, Brian E Carpenter wrote:
> On 12/06/2017 13:00, Fernando Gont wrote:
>> On 06/11/2017 09:29 PM, ot= roan@employees.org wrote:
[....]
>>>=C2=A0 - Removing the constant from the addressing architecture= will likely set these changes into motion.
>>>=C2=A0 =C2=A0 (i.e. I don't think a position where one want= s to remove the 64 bit constant from 4291 and expect the 64 bit boundary >>>=C2=A0 =C2=A0 =C2=A0to stay in IPv6 over foo is tenable.)
>>
>> Me, I don't think there's a reason to keep the 64 bit cons= tant in
>> ipv6-over-foo documents. Actually, with RFC8064 in place, there= 9;s no
>> reason why the IID should be link-type dependent.
>
> I believe that is simply false unless you want to go back to the era > of DIP switches with instructions to users to
> a) choose an IID length for their new subnet
> b) set the DIP switches on every device to select that length
> c) then plug and play.
>
> Otherwise LL addresses cannot be formed consistently on the
> whole link.
>
> OK, that is caricature, but without a substantial reworking of
> RFC4862 I believe that is essentially what we would need, in
> an automated version, before SLAAC can start.
>
> Anway, all this is empty talk as long as the addressing architecture > *requires* 64 bits rather than *recommending* 64 bits.

* Mandate fe80::/64 for link-local
* RECOMMENDED /64 for subnets
* Make SLAAC implementations flexible so that they could do SLAAC if a
non-64 PIO is advertised.

128-bit IPv4,= yippee.

IPv6 NAT, I cannot wait.

I propose we also change the name of the working group while we= 9;re at it, maybe v4-128-man.
--001a11470b74d7983b0551e83b5f-- --001a11470b74ddd38c0551e83b6d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgpP7umwx0T7uF294s3efLdEhstoJJUPTd o7leGGq6Qt0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjE0 MDkzMjQyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAKQ56yIZyC6J8X6BdIhS82Cnqj1mkGAzGDCZ2P1APqKVA2VWE8Qh tZayejV6RUt/NiwsZfkHwCtBSmHxPxMJF5E42c2BohnZ4tuFgT626WcxouqV94H7fzZh3U8FcSeC PEMF5W8VEit8pZwIMb1rvjpsYsXReVxQyTUEE7YmO7dxuotx3XHyjpIAvhE6cLOtqtNsc0QgjMT6 FsqrRt9m+pp+p1BWf/yDgGfsXM1tVm8je/QBNGP4QDRnnODJADSnYgz9ua0noOVnjwbqIaVvAHnW yWTKhL7Apza3xiYq3NfGCzAAu5vfXi2thU+OkI1L4hERVX8exMv9ESKbqL5COiE= --001a11470b74ddd38c0551e83b6d-- From nobody Wed Jun 14 02:35:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA574126CF9 for ; Wed, 14 Jun 2017 02:35:31 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbioyrLNyaOV for ; Wed, 14 Jun 2017 02:35:29 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 08B7612717E for ; Wed, 14 Jun 2017 02:35:28 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 09:35:27 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0673CD788B; Wed, 14 Jun 2017 02:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=CYlrAwiMNfqIPWvLnSoF1P3bgbc=; b= fHzMKVTEkXLsa3v9XlQDu2hs0kzC7/HnBFnSo4K3cK1Xvom2KPK15+MXmVQ38y0E aIGkLnfZ9PkOoTkIKeBiMU99fcM9KNN7CUkaO9IzRQIK8E6Nwtu1zoBC3Kf6LoY4 P2VGJzhGEtaDG0sQAKamCcEQaZp6XzOp+SYuQcdvoSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=VU/zODeDTSUTCHLxpKkHQkt GlMiEpiX91SLx1wzWU4qH+D/faWxssuuML7XC139SLYM7r2qGCj4TVsLEMGmDgax O6zeYMXzs9alqlKo5nBQZ6DKBk0bqw3DGDqjujedSToCwL+rvhxsyGK2kb98ewGm J/k2afvsu/30e3EVDxAw= Received: from h.hanazo.no (unknown [173.38.220.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CFA3BD788F; Wed, 14 Jun 2017 02:35:26 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 95550D3E62E0; Wed, 14 Jun 2017 11:35:24 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0B52C4A3-2C74-4B07-9894-D1BF48B09FF7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Wed, 14 Jun 2017 11:35:23 +0200 In-Reply-To: <20170614092327.GB30896@gir.theapt.org> Cc: 6man WG To: Peter Hessler References: <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:35:32 -0000 --Apple-Mail=_0B52C4A3-2C74-4B07-9894-D1BF48B09FF7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Peter, > :* Mandate fe80::/64 for link-local > :* RECOMMENDED /64 for subnets > :* Make SLAAC implementations flexible so that they could do SLAAC if a > :non-64 PIO is advertised. > > As someone who is on the "/64 is the devil" side, I am perfectly happy > with the above. Reason being? Ole --Apple-Mail=_0B52C4A3-2C74-4B07-9894-D1BF48B09FF7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZQQNcAAoJEL7aWKiYQt92MbQP/iwDuy61wU6+ICDg5s9tDTy4 4b3H5S0cm58sG1JZUVGznY0wPQLdL2y1jEl7L2Yz1SdlOc5aS4gDXiT4lNEi9Ovk ZBUigVXSqXO0HGVuID0ZiRTvKoj1KiizlMuTR6mNBygli08O8LL0MgkDnzX6swRB T3lkkCeIpnz2qX8UQ9O9hXHDrRh0Aot1N/ukr783C+U9JwgsmRaSr7GjUPD3sZ0R WCqRx36nW652oUWclGJ/WlgjzYTcvwt2PZtPnAWzHmjxuer6c4dAPSI0vZd/WJMu ktzjlOWf72k++hEpH153qd3wj89dRtR2VqRzNDOI19JI2JoPPaQZYJwn1I/eYynE //wtw395llaiMlv2+wvDr1du7rcjIhQUTzaGxOHL7qQeSEG7X3mJn9fW/YW5iMSx HlRXO6YXho31u5sZbAVIU74DF7PDR4wkZ3u0yuFty+EZk/ssMsCJJRZk6ZwQHPio OSj/A3SXlePjuZsKxEDhCFpP0q3YxmMZ4CSiqftpT6e4WdbapALW4SjkuJ9S/W9S JrW5d5urafzjeBAK/KVHeSDLqd4JKhPFe/Kvfc6Kp+HFoyDsjgljJ/AFyrbQOcit 65RTQWtsZoaiHUwgJwev0tceMl0C8JoLTmdHLgpwlnbjaV5HFdzB+1czUG2oRaAB KasyRF+insz5ueGItfKh =4veb -----END PGP SIGNATURE----- --Apple-Mail=_0B52C4A3-2C74-4B07-9894-D1BF48B09FF7-- From nobody Wed Jun 14 02:39:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31231126BF0 for ; Wed, 14 Jun 2017 02:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNZjRSzWiolm for ; Wed, 14 Jun 2017 02:39:06 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C4C128D44 for ; Wed, 14 Jun 2017 02:39:05 -0700 (PDT) Received: from [192.168.0.183] (unknown [105.60.72.189]) (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 AA69183579; Wed, 14 Jun 2017 11:39:52 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: otroan@employees.org, Brian E Carpenter Cc: 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> From: Fernando Gont Message-ID: <380119fd-cb71-79c8-cdcc-ebdcd33d17ff@si6networks.com> Date: Wed, 14 Jun 2017 12:18:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:39:08 -0000 On 06/13/2017 09:56 AM, otroan@employees.org wrote: >> >> Anway, all this is empty talk as long as the addressing architecture >> *requires* 64 bits rather than *recommending* 64 bits. > > This is what _will_ happen as soon as we start chipping away at the boundary by changing the addressing architecture from requires to recommended. If changing such a value means a change in the architecture, then what you have is not an architecture. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 14 02:39:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA6D129568 for ; Wed, 14 Jun 2017 02:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GglGn3ATRH12 for ; Wed, 14 Jun 2017 02:39:14 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E15A12953B for ; Wed, 14 Jun 2017 02:39:14 -0700 (PDT) Received: from [192.168.0.183] (unknown [105.60.72.189]) (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 7065683579; Wed, 14 Jun 2017 11:40:05 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti , Brian E Carpenter Cc: Ole Troan , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <01b8e1d6-125c-2ecb-6888-e7283f3d488b@gmail.com> From: Fernando Gont Message-ID: Date: Wed, 14 Jun 2017 12:28:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:39:16 -0000 On 06/14/2017 10:49 AM, Lorenzo Colitti wrote: > On Wed, Jun 14, 2017 at 5:28 AM, Brian E Carpenter > > wrote: [....] > > I don't see why we need new text for that. Any document that wants to use a > > different value can simply update 4291. > > Agreed, theoretically. But simply s/required/recommended/ in 4291bis > would be a much more elegant way of handling this. > > > In the ivory tower, maybe. In the real world, simply changing from "is" > to "should" would be a result in immediate pressure to switch to longer > interface IIDs on currently-defined link types of interest > (specifically, Ethernet and wifi). > > Remember that implementations are not built based on what the standard > recommends, but on a balance between what the standard requires and what > the operator desires. (If you doubt this view, I suggest reading your > co-authors' comments.) Also remember that most implementations already > support longer-than-64 bit prefixes today. Even if one were to keep the "MUST be /64" for SLAAC, RFC4291 should be clear that for non-slaac you should be free to use whatever you please (whether manual or DHCPv6). > > We have a popular implementation that only accepts 64-bit IID lengths in > > certain cases. Are you proposing that our implementation change or not? > > No. But if some new link technology comes along for which there is a > good > technical argument for, say, 60 bit interface identifiers, wouldn't you > want to accommodate it? (I have no idea what that argument might be.) > > > It's pretty clear that if an IPv6-over-foo document comes along that > says the IID length is 60 (and correspondingly updates 4291), then in > order to to support IPv6 over foo, either our implementation would need > to change, or the parts that rely on the 64-bit IID lengths would be > disabled. Why should the IID depend on ipv6-over-foo dcuments? We don't recommend to embed MAC addresses in IIDs anymore. > As you say, we don't know whether something like this will come along, > and I don't think we should preemptively update 4291 to accommodate > this. It's hard for me to think of something you can do with 60 bits but > can't do with 64 bits. Then.. why do you want to force 64? :-) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 14 02:40:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE6812953B for ; Wed, 14 Jun 2017 02:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w40lOK8YBu7y for ; Wed, 14 Jun 2017 02:40:36 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80568128CDC for ; Wed, 14 Jun 2017 02:40:36 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 2C62178931 for ; Wed, 14 Jun 2017 11:40:35 +0200 (CEST) Date: Wed, 14 Jun 2017 11:40:34 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170614094034.GC30896@gir.theapt.org> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:40:39 -0000 On 2017 Jun 14 (Wed) at 11:35:23 +0200 (+0200), otroan@employees.org wrote: :Peter, : :> :* Mandate fe80::/64 for link-local :> :* RECOMMENDED /64 for subnets :> :* Make SLAAC implementations flexible so that they could do SLAAC if a :> :non-64 PIO is advertised. :> :> As someone who is on the "/64 is the devil" side, I am perfectly happy :> with the above. : :Reason being? : :Ole link-local simply doesn't matter. since it is on the link, we already know the mac address and privacy won't help. it's a silly place, with silly rules. leave it at /64, so we don't have to fight with it. leaving a RECOMMENDED for /64 subnets is fine. forcing it to be a MUST is not fine to me. While the arguments in favour of /64 subnets are valid, there are many differently valid reasons to have non-/64 subnets, as mentioned many times in this (and other recent) threads. As mentioned, there is a plen field in SLAAC advertisements, so we should be able to use them. -- I call them as I see them. If I can't see them, I make them up. -- Biff Barf From nobody Wed Jun 14 02:48:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F46129B52 for ; Wed, 14 Jun 2017 02:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQFbSrJy9zI4 for ; Wed, 14 Jun 2017 02:48:48 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC349129B4F for ; Wed, 14 Jun 2017 02:48:47 -0700 (PDT) Received: from [192.168.0.183] (unknown [105.60.72.189]) (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 CF47E83579; Wed, 14 Jun 2017 11:49:37 +0200 (CEST) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Erik Kline Cc: Brian E Carpenter , Ole Troan , 6man WG References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 14 Jun 2017 12:41:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:48:50 -0000 On 06/14/2017 12:32 PM, Erik Kline wrote: > > > On 14 June 2017 at 18:09, Fernando Gont > wrote: > > Hi, Brian, > > On 06/13/2017 04:35 AM, Brian E Carpenter wrote: > > On 12/06/2017 13:00, Fernando Gont wrote: > >> On 06/11/2017 09:29 PM, otroan@employees.org > wrote: > [....] > >>> - Removing the constant from the addressing architecture will > likely set these changes into motion. > >>> (i.e. I don't think a position where one wants to remove the > 64 bit constant from 4291 and expect the 64 bit boundary > >>> to stay in IPv6 over foo is tenable.) > >> > >> Me, I don't think there's a reason to keep the 64 bit constant in > >> ipv6-over-foo documents. Actually, with RFC8064 in place, there's no > >> reason why the IID should be link-type dependent. > > > > I believe that is simply false unless you want to go back to the era > > of DIP switches with instructions to users to > > a) choose an IID length for their new subnet > > b) set the DIP switches on every device to select that length > > c) then plug and play. > > > > Otherwise LL addresses cannot be formed consistently on the > > whole link. > > > > OK, that is caricature, but without a substantial reworking of > > RFC4862 I believe that is essentially what we would need, in > > an automated version, before SLAAC can start. > > > > Anway, all this is empty talk as long as the addressing architecture > > *requires* 64 bits rather than *recommending* 64 bits. > > * Mandate fe80::/64 for link-local > * RECOMMENDED /64 for subnets > * Make SLAAC implementations flexible so that they could do SLAAC if a > non-64 PIO is advertised. > > > 128-bit IPv4, yippee. > > IPv6 NAT, I cannot wait. > > I propose we also change the name of the working group while we're at > it, maybe v4-128-man. If your opinion is that the only thing that separates IPv6 from IPv4 (other than the address length) is the 64-bit boundary, that's quite a message. :-) Probably more controversial than changing the name of the wg. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 14 02:51:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B659129B50 for ; Wed, 14 Jun 2017 02:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-L4qAaAqeQj for ; Wed, 14 Jun 2017 02:51:36 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:67c:12f4::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A59C129B4F for ; Wed, 14 Jun 2017 02:51:36 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id AC44E78931 for ; Wed, 14 Jun 2017 11:51:34 +0200 (CEST) Date: Wed, 14 Jun 2017 11:51:33 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170614095133.GD30896@gir.theapt.org> References: <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:51:37 -0000 On 2017 Jun 14 (Wed) at 18:32:21 +0900 (+0900), Erik Kline wrote: :IPv6 NAT, I cannot wait. : If you cannot wait, all versions of OpenBSD since 2003 have this feature. :I propose we also change the name of the working group while we're at it, :maybe v4-128-man. support -- According to my best recollection, I don't remember. -- Vincent "Jimmy Blue Eyes" Alo From nobody Wed Jun 14 02:52:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3BF129B4F for ; Wed, 14 Jun 2017 02:52:39 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXbYeR1zTeZZ for ; Wed, 14 Jun 2017 02:52:37 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id F1EC7129B64 for ; Wed, 14 Jun 2017 02:52:30 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 09:52:30 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B1520D788D; Wed, 14 Jun 2017 02:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=j/5DkBfCcK//BizBb+3bLANgqIk=; b= Cg/yhIXE4qmU6hP5K7MWlZAuLkvQWMns4tvO+U7OmgwcMmyZe4yPdvR6aKCKZCHk 4XbQq+PjXu0nuSBj7dRjfkHWvfw18ykAvXWi7MkbWet+Iu0sUGR2upwC3yAbOV9R Rw0EvIfMNzX6Oe5cCupGXiSczU9+VXDrBIJkB+jlF8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=B5BG0+Dj0d1+GBNBqjRmVxC 87J24RCnA4STQwm1TMpdfPpUJDFuIubmMJkH9lA2E/l2Y0RcOmvu4zzCmcnUp4Ry D43xzeOspM6F3pO/umKNwTTBdZ7ZCvcllxbPwIF6iKM1j4VhztcVFxoL6rU/J9ZY WhHnTOEEQ8j+mFKg8764= Received: from h.hanazo.no (unknown [173.38.220.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7E88FD788B; Wed, 14 Jun 2017 02:52:30 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B9F57D3EB201; Wed, 14 Jun 2017 11:52:28 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D2E0975A-FB24-40D0-941D-0F9DC34316BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Wed, 14 Jun 2017 11:52:27 +0200 In-Reply-To: <20170614094034.GC30896@gir.theapt.org> Cc: 6man WG To: Peter Hessler References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:52:39 -0000 --Apple-Mail=_D2E0975A-FB24-40D0-941D-0F9DC34316BB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Peter, > leaving a RECOMMENDED for /64 subnets is fine. forcing it to be a MUST > is not fine to me. While the arguments in favour of /64 subnets are > valid, there are many differently valid reasons to have non-/64 subnets, > as mentioned many times in this (and other recent) threads. Which arguments matter to you? What _problem_ does changing the 64 bit boundary solve for _you_? Ole --Apple-Mail=_D2E0975A-FB24-40D0-941D-0F9DC34316BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZQQdcAAoJEL7aWKiYQt92OAwQAMzGTuH1r8H20dTA0EUqhukL K5GvuPYKCjvPXuzVEC5uYk2lcFLBrakS4E7Up3SeKuzf77C4veKyxsgxc6ckVFPW 1Vex3bV+BrwitAO408rDpQXQM76YvUDcjPmEUzoXxeulTVL2oU2jscIzmxB+gTNK UtHVRcR/O/G23IXF1Y13T0FEeG98wOc+2PbFiuA3zqK2peauGBh+6F+KJErUPLpp m/cHw+iE4rqVNBJ6MbXOQROUkpMZV5OhfHI5cAfpsWPAOvNqRRf4KuJuDEfwOi5V g2g2bcd7C771PrhzvCFoFLRoPhla23v7Coi2f/9hSD6WNkGGNQzr2+VHdT9RT35s Gf8Uj0edG4toO/9lpWCnlTPhS+dJ/6EMdhEjFiY4m4Rch1vk1QOV399y82Dj1bFn 1hLcVTexpYkhv6rYHGEhUqP4+KUqFl3UVSFHcnyrMbBU4Q3ci6iSG7uD7dLSnwEx 4S9VF4W9ZOAA5Va1e4kggQ/xTScF8Jx6GT54/LVYKjcRZpUxZf1XX5+Cujr3UhbW /1DVUjwVvt919u9jXhzfeppIGyEeTK3XSSiLmee+vv8U8lWUdOZqgs1H02RhDybs ja5QvA07rSJaT8rP81h17Kl54s/5XuGxD9WQX6Pv+5hUtaGRmQF3DJzgbrUsk+2q ks2PTVQeCJuISjBIoga2 =WG3s -----END PGP SIGNATURE----- --Apple-Mail=_D2E0975A-FB24-40D0-941D-0F9DC34316BB-- From nobody Wed Jun 14 02:59:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F2A129B6D for ; Wed, 14 Jun 2017 02:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV87nVlXWg9i for ; Wed, 14 Jun 2017 02:59:13 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517C8129B64 for ; Wed, 14 Jun 2017 02:59:13 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 03AD578931 for ; Wed, 14 Jun 2017 11:59:12 +0200 (CEST) Date: Wed, 14 Jun 2017 11:59:10 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170614095910.GE30896@gir.theapt.org> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:59:15 -0000 On 2017 Jun 14 (Wed) at 11:52:27 +0200 (+0200), otroan@employees.org wrote: :Peter, : :> leaving a RECOMMENDED for /64 subnets is fine. forcing it to be a MUST :> is not fine to me. While the arguments in favour of /64 subnets are :> valid, there are many differently valid reasons to have non-/64 subnets, :> as mentioned many times in this (and other recent) threads. : :Which arguments matter to you? :What _problem_ does changing the 64 bit boundary solve for _you_? : :Ole The problem is wasting space (I acknowledge your arguments, and reject them), uglyness of the addresses, and the fact that _my_ network is not _your_ network. I'm already running non-/64 subnets on my personal networks. I'm also running non-/64 subnets on my $work networks. mandating /64 subnets in the _architectural specification_ is a bug, period. IPv4 got rid of classful subnets in 1993, IPv6 can join the last century as well. -- "A raccoon tangled with a 23,000 volt line today. The results blacked out 1400 homes and, of course, one raccoon." -- Steel City News From nobody Wed Jun 14 03:13:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36741129B9C for ; Wed, 14 Jun 2017 03:13:08 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vER1yuUGLm6U for ; Wed, 14 Jun 2017 03:13:06 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 2ACB8129B9B for ; Wed, 14 Jun 2017 03:13:06 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id h39so91696652uaa.3 for ; Wed, 14 Jun 2017 03:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=beamlqL2j8DHm254tFFIp7vgxCJQNuzFNjP2jJIqKo8=; b=RiO2olGwYmnfm8gxImAyht0nZN3EetirXUaSKUppLl+rVz/Yl9ZR0NM6Ob2fbCDLgB HX0FuQxQitSSH78ZPhGJ7ll2JWu6S6v/wv/Fpi0U1XNzE7KizEF4ZClOpDt3+cZ2Snkt vaFYo9i3MCMN6OUbJgkhExuGZAHdcyDfygPSGU6Ixh44vCLyCOLqCZYaYMSEvyzsyRR6 PtgEUTpBq1B87N+Zw9J9NwRRMrtwCJu08wcUQ58Td14DNufKOZPWtzmCDNXwj/8Vtinj 5ruMdwpBtDo10O6LfUawWjtBjAQ+9ckmLNhXK76wxxP31Uk0bO/D0WNIy8Z/HKd1B/fs V2Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=beamlqL2j8DHm254tFFIp7vgxCJQNuzFNjP2jJIqKo8=; b=QMk83R14/dZodMMXAbizVy2CVpxuvjUxXg244N/txesIr1R230hruz0yQpP7/I+aMs AlIwQ9kOpV0Sqtx4ELX5tGgzCULHWoeE5oI1+XpWqmVsZ17umG+J+7sW5W/mU8yr9HU4 7nD2/31+Q2TF+9t8iP6pSSw8zj4902fu8qqZvERqg/Xw2z0/Ibkh3BlX7R3x3GzJJkLm gbO5+BUzIGKmU4pFQuDj3X02ws2/XU3+QN9BubEOfY1zFpNuqSyGIINAxUfZM3QWPubX yjlQtqk0ULR7qhyafQm9+UEIs7pF0A06f1BMTFfsb95kkdOkqpRYsEAnlAHbfXOqDyIb a94w== X-Gm-Message-State: AKS2vOy3pu+sPxHClJz79K0VB1gmfnradYxh0PpzTlweZvSeopwdMZ0p e/2jRSN8o957r8adxoqHCBS4SJLyWgB5 X-Received: by 10.176.6.132 with SMTP id g4mr2346858uag.20.1497435184790; Wed, 14 Jun 2017 03:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 03:12:44 -0700 (PDT) In-Reply-To: <20170614095910.GE30896@gir.theapt.org> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> From: Lorenzo Colitti Date: Wed, 14 Jun 2017 19:12:44 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Brian E. Carpenter" Cc: IETF IPv6 Mailing List , Peter Hessler Content-Type: multipart/alternative; boundary="94eb2c123900444e4f0551e8cca2" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:13:08 -0000 --94eb2c123900444e4f0551e8cca2 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 6:59 PM, Peter Hessler wrote: > I'm already running non-/64 subnets on my personal networks. I'm also > running non-/64 subnets on my $work networks. > > mandating /64 subnets in the _architectural specification_ is a bug, > period. > > IPv4 got rid of classful subnets in 1993, IPv6 can join the last century > as well. > Brian (and everyone on this thread, really): QED. Peter, thanks for writing this email so clearly. I think we now have a clear example of what some operators will feel encouraged to do if we change "is /64" to "should be /64". With the the current state of affairs, such networks happen to work but are not guaranteed to interoperate, and host implementations are not required to work on them. If we change the standards to admit that subnets may be non-64 bits, there will be pressure on implementations to conform. Even if this sort of opinion were a minority opinion among network operators, it is the nature of networking software development that host implementations adapt to the lowest common denominator. Let's not do that here. There is no technical reason to do so. This is exactly the sort of scarcity thinking that the 64-bit boundary is intended to avoid. Let's ensure that such limitations - which as Peter says, belong to the last century - stay in the last century and do not enter this one. --94eb2c123900444e4f0551e8cca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 6:59 PM, Peter Hessler <phessler@theapt.org><= /span> wrote:
I'm = already running non-/64 subnets on my personal networks.=C2=A0 I'm also=
running non-/64 subnets on my $work networks.

mandating /64 subnets in the _architectural specification_ is a bug,
period.

IPv4 got rid of classful subnets in 1993, IPv6 can join the last century as well.

Brian (and everyone on this th= read, really): QED.

Peter, thanks for writing this= email so clearly. I think we now have a clear example of what some operato= rs will feel encouraged to do if we change "is /64" to "shou= ld be /64". With the the current state of affairs, such networks happe= n to work but are not guaranteed to interoperate, and host implementations = are not required to work on them. If we change the standards to admit that = subnets may be non-64 bits, there will be pressure on implementations to co= nform.

Even if this sort of opinion were a minorit= y opinion among network operators, it is the nature of networking software = development that host implementations adapt to the lowest common denominato= r. Let's not do that here. There is no technical reason to do so.

This is exactly the sort of scarcity thinking = that the 64-bit boundary is intended to avoid. Let's ensure that such l= imitations - which as Peter says, belong to the last century - stay in the = last century and do not enter this one.
--94eb2c123900444e4f0551e8cca2-- From nobody Wed Jun 14 03:19:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A173129B9E for ; Wed, 14 Jun 2017 03:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKjOQ6moh3nR for ; Wed, 14 Jun 2017 03:19:05 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33030129B9C for ; Wed, 14 Jun 2017 03:19:05 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id DBDA378931 for ; Wed, 14 Jun 2017 12:19:03 +0200 (CEST) Date: Wed, 14 Jun 2017 12:19:02 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170614101902.GF30896@gir.theapt.org> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:19:07 -0000 On 2017 Jun 14 (Wed) at 19:12:44 +0900 (+0900), Lorenzo Colitti wrote: :On Wed, Jun 14, 2017 at 6:59 PM, Peter Hessler wrote: :> mandating /64 subnets in the _architectural specification_ is a bug, :> period. :> :> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century :> as well. :> :This is exactly the sort of scarcity thinking that the 64-bit boundary is :intended to avoid. Let's ensure that such limitations - which as Peter :says, belong to the last century - stay in the last century and do not :enter this one. Anyone who thinks my statements encourage the /64 boundary is clearly delusional. The "last century" comment was about having artificial limitations, such as /64. Not about scarcity. -- The bigger the theory the better. From nobody Wed Jun 14 06:08:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497521294F8 for ; Wed, 14 Jun 2017 06:08:15 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GghpEqa2GbsF for ; Wed, 14 Jun 2017 06:08:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 5DD3012EBB6 for ; Wed, 14 Jun 2017 06:08:12 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 4241024AE0B; Wed, 14 Jun 2017 13:06:49 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2FA23160072; Wed, 14 Jun 2017 13:06:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1FEFC160051; Wed, 14 Jun 2017 13:06:52 +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 tK4aFjax17a0; Wed, 14 Jun 2017 13:06:52 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C0C20160008; Wed, 14 Jun 2017 13:06:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E97607BB0491; Wed, 14 Jun 2017 23:06:49 +1000 (AEST) To: Peter Hessler Cc: ipv6@ietf.org From: Mark Andrews References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 In-reply-to: Your message of "Wed, 14 Jun 2017 11:59:10 +0200." <20170614095910.GE30896@gir.theapt.org> Date: Wed, 14 Jun 2017 23:06:49 +1000 Message-Id: <20170614130649.E97607BB0491@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:08:15 -0000 In message <20170614095910.GE30896@gir.theapt.org>, Peter Hessler writes: > On 2017 Jun 14 (Wed) at 11:52:27 +0200 (+0200), otroan@employees.org wrote: > :Peter, > : > :> leaving a RECOMMENDED for /64 subnets is fine. forcing it to be a MUST > :> is not fine to me. While the arguments in favour of /64 subnets are > :> valid, there are many differently valid reasons to have non-/64 subnets, > :> as mentioned many times in this (and other recent) threads. > : > :Which arguments matter to you? > :What _problem_ does changing the 64 bit boundary solve for _you_? > : > :Ole > > The problem is wasting space (I acknowledge your arguments, and reject > them), uglyness of the addresses, and the fact that _my_ network is not > _your_ network. > > I'm already running non-/64 subnets on my personal networks. I'm also > running non-/64 subnets on my $work networks. > > mandating /64 subnets in the _architectural specification_ is a bug, > period. > > IPv4 got rid of classful subnets in 1993, IPv6 can join the last century > as well. We got rid of classful subnets in 1993 *because* there were not enough subnets to go around with them. We didn't get rid of them because as a concept they were bad. Do you say that 18446744073709551616 subnets is too few to go around? 2^64 address would have been enough to support the world using variable length subnets. IPng evaluated this and decided that it was not a good idea as variable length subnets really are too complicated. Instead IPng went initially with 128 bit addresses and, initially, /80 subnets so that we didn't have to deal with variable sized subnets. This was later changed to /64 bit subnets to handle 64 bit mac addresses. Mark > -- > "A raccoon tangled with a 23,000 volt line today. The results blacked > out 1400 homes and, of course, one raccoon." > -- Steel City News > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 14 06:20:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3C12762F for ; Wed, 14 Jun 2017 06:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv6nfUdx-W5r for ; Wed, 14 Jun 2017 06:20:39 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD2126B71 for ; Wed, 14 Jun 2017 06:20:38 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A1976E6065; Wed, 14 Jun 2017 15:20:37 +0200 (CEST) Date: Wed, 14 Jun 2017 15:20:37 +0200 (CEST) Message-Id: <20170614.152037.74746841.sthaug@nethelp.no> To: marka@isc.org Cc: phessler@theapt.org, ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: sthaug@nethelp.no In-Reply-To: <20170614130649.E97607BB0491@rock.dv.isc.org> References: <20170614095910.GE30896@gir.theapt.org> <20170614130649.E97607BB0491@rock.dv.isc.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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:20:41 -0000 > 2^64 address would have been enough to support the world using > variable length subnets. IPng evaluated this and decided that it > was not a good idea as variable length subnets really are too > complicated. Instead IPng went initially with 128 bit addresses > and, initially, /80 subnets so that we didn't have to deal with > variable sized subnets. This was later changed to /64 bit subnets > to handle 64 bit mac addresses. But since IPv6 *forwarding* is still based on longest prefix match, plenty of people will need to learn the subtleties of how IPv6 is *both* variable length *and* fixed size, at the same time. I don't exactly have high hopes here... Steinar Haug, AS2116 From nobody Wed Jun 14 06:23:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704B312E91F for ; Wed, 14 Jun 2017 06:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPLMJNfyE3IC for ; Wed, 14 Jun 2017 06:23:08 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270581294FF for ; Wed, 14 Jun 2017 06:23:08 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 63so215538ywr.0 for ; Wed, 14 Jun 2017 06:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NUoCLdtkOagLW9MDW8odmV2wC/RBFh1JlW6jilBZmoQ=; b=o5ObYTFflWy8qVjrVRJYnpFqONnwT5i5hOoQ75ffDrufoGIajKDmvZiOUFhuyMXbIw 6jvRmwucaMcfSvnFqiKwtidj12iu4gkPgN4K+tZ0oQJCRWIEwBQPZfwAneDRodKy+npe ZuGGRzzrdlHJW5fWFaAf9rOg5tgXNyRm6+DTwc+y8jPpnxD+Mb0hu2BO4qL8e4o9ehgn ygp09aKgR+XGN+wE3KOCIRhwwR0DecXeI8d//KkHH7foeFtmI8gB+iXM5BZWNkoD1OiX 1WV8KHqovZug72kDmVVg4vwwX6kuJoWDZoio14Tld9IIy3fzTaeqqhaQuebcnA8uIIv9 qPtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NUoCLdtkOagLW9MDW8odmV2wC/RBFh1JlW6jilBZmoQ=; b=t+S2j4BQc9trO7emUb3iV0FXUgzca0HVoSOMbnVNPM63CX0r17SaCjBjhFR4LDhgDR mL/wyWJfyGS9hg96n5BF2H5Vnp1aa9BRRmaFnUoZIJa4RmEL9EC9s6RLDqMOUFfWgcUz VpEn0Pql3Lk3NUWhpExeOzUga9Z5YWWQzhZiL7rSROhhXKQOBATFX6jXGRITXpsaQ0Fe uKbqMY28txZgn9EAgbGFUBBSoB/w2q2oSx5AMwO6rMiXQBmZ0YSXRsJJF15UZnu6Wuue c0cIDjyW3nRjKFog3sgYmC8TwaoLAqlMVmqUNpAPRNzmNRbEfZKVsw0B98pnte3zhOgS mD1g== X-Gm-Message-State: AKS2vOye3dfcItRkCxFtY9XlvSFK+f0PHqib9aU0l7b9a80KJwEMSuHV Q7cR/8u5S+8u1WeWdYkJf7p6kjHiGPG6 X-Received: by 10.129.138.194 with SMTP id a185mr17915ywg.207.1497446587151; Wed, 14 Jun 2017 06:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Wed, 14 Jun 2017 06:22:46 -0700 (PDT) In-Reply-To: <20170614130649.E97607BB0491@rock.dv.isc.org> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170614130649.E97607BB0491@rock.dv.isc.org> From: Erik Kline Date: Wed, 14 Jun 2017 22:22:46 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Mark Andrews Cc: Peter Hessler , IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07f7d8ecb1de0551eb7329" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:23:10 -0000 --94eb2c07f7d8ecb1de0551eb7329 Content-Type: multipart/alternative; boundary="94eb2c07f7d8e61a3d0551eb7351" --94eb2c07f7d8e61a3d0551eb7351 Content-Type: text/plain; charset="UTF-8" On 14 June 2017 at 22:06, Mark Andrews wrote: > > In message <20170614095910.GE30896@gir.theapt.org>, Peter Hessler writes: > > On 2017 Jun 14 (Wed) at 11:52:27 +0200 (+0200), otroan@employees.org > wrote: > > :Peter, > > : > > :> leaving a RECOMMENDED for /64 subnets is fine. forcing it to be a > MUST > > :> is not fine to me. While the arguments in favour of /64 subnets are > > :> valid, there are many differently valid reasons to have non-/64 > subnets, > > :> as mentioned many times in this (and other recent) threads. > > : > > :Which arguments matter to you? > > :What _problem_ does changing the 64 bit boundary solve for _you_? > > : > > :Ole > > > > The problem is wasting space (I acknowledge your arguments, and reject > > them), uglyness of the addresses, and the fact that _my_ network is not > > _your_ network. > > > > I'm already running non-/64 subnets on my personal networks. I'm also > > running non-/64 subnets on my $work networks. > > > > mandating /64 subnets in the _architectural specification_ is a bug, > > period. > > > > IPv4 got rid of classful subnets in 1993, IPv6 can join the last century > > as well. > > We got rid of classful subnets in 1993 *because* there were not > enough subnets to go around with them. We didn't get rid of them > because as a concept they were bad. > > Do you say that 18446744073709551616 subnets is too few to go > around? > > 2^64 address would have been enough to support the world using > variable length subnets. IPng evaluated this and decided that it > was not a good idea as variable length subnets really are too > complicated. Instead IPng went initially with 128 bit addresses > and, initially, /80 subnets so that we didn't have to deal with > variable sized subnets. This was later changed to /64 bit subnets > to handle 64 bit mac addresses. > Thank you. --94eb2c07f7d8e61a3d0551eb7351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 June 2017 at 22:06, Mark Andrews <marka@isc.org> wrote= :

In message <201= 70614095910.GE30896@gir.theapt.org>, Peter Hessler writes:
> On 2017 Jun 14 (Wed) at 11:52:27 +0200 (+0200), otroan@employees.org wrote:
> :Peter,
> :
> :> leaving a RECOMMENDED for /64 subnets is fine.=C2=A0 forcing it = to be a MUST
> :> is not fine to me.=C2=A0 While the arguments in favour of /64 su= bnets are
> :> valid, there are many differently valid reasons to have non-/64 = subnets,
> :> as mentioned many times in this (and other recent) threads.
> :
> :Which arguments matter to you?
> :What _problem_ does changing the 64 bit boundary solve for _you_?
> :
> :Ole
>
> The problem is wasting space (I acknowledge your arguments, and reject=
> them), uglyness of the addresses, and the fact that _my_ network is no= t
> _your_ network.
>
> I'm already running non-/64 subnets on my personal networks.=C2=A0= I'm also
> running non-/64 subnets on my $work networks.
>
> mandating /64 subnets in the _architectural specification_ is a bug, > period.
>
> IPv4 got rid of classful subnets in 1993, IPv6 can join the last centu= ry
> as well.

We got rid of classful subnets in 1993 *because* there were not
enough subnets to go around with them.=C2=A0 We didn't get rid of them<= br> because as a concept they were bad.

Do you say that 18446744073709551616 subnets is too few to go
around?

2^64 address would have been enough to support the world using
variable length subnets.=C2=A0 IPng evaluated this and decided that it
was not a good idea as variable length subnets really are too
complicated.=C2=A0 Instead IPng went initially with 128 bit addresses
and, initially, /80 subnets so that we didn't have to deal with
variable sized subnets.=C2=A0 This was later changed to /64 bit subnets
to handle 64 bit mac addresses.

Thank y= ou.
--94eb2c07f7d8e61a3d0551eb7351-- --94eb2c07f7d8ecb1de0551eb7329 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgKV94C9hMuqU9rBxjCyjLDMzEVKi9nhus tT8/dvtncQYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjE0 MTMyMzA3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAIu09NyZBJRn1pX/WIoItrGvd3PviPvwCcIW6nHUrdaHtWWGrotK mk+cdSBRWp4YGCDGaao98Z4ewOoPNyi47q9d+e9IlqFlHazvSKq+HirFxV2VrpcQ2NehoOwpQ/ph zFuINOlq7WBSzF3BN6qtNYRko2oyY+pOxrxvL6uhoK/ksiQyNf5T2+ZByAXQPM0kfFxoVxnwxUZJ Z8iFKCMdW50to4dqsDu/McfUipSQkTZ434tUsgeX4m3kDCHloJGso9UrNQe2vyHKzrUFNakbI9Zb SuCvOyRR+3ss0uVRu7fJ5imE8Nv8CGNWsL7Xf/K+Q+QdrBjSVsBjV+0N0B6rKrs= --94eb2c07f7d8ecb1de0551eb7329-- From nobody Wed Jun 14 08:09:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F6B12EB69 for ; Wed, 14 Jun 2017 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgo1JTcHKJzG for ; Wed, 14 Jun 2017 08:09:28 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D324E12EACA for ; Wed, 14 Jun 2017 08:09:27 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id o83so3390086lff.3 for ; Wed, 14 Jun 2017 08:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dhF8YiqzmZt8FQtyvYqumO0kC/UPQF52ZYul1qLMH2U=; b=LnULBoCNMho6dZm8df766lhyda1ZqWryyeKiIZYG9ybQ+QxHtBXUbEP/HlAnn0P4Bt 0ULY/Nao2sE55bt7rXl+s+Mporf7gPCSEHQbeLkBZj3zHu8MTTMXUS8b83uwvx3gVWL4 cRj8AmGRVvlkctA/AlVqfQDU6hGPMTmIuC7ym3TuZxzW/pAkd2nSU5tXE0KFCMGUxN8V /1EEMINscxegxT+Fu+MHyE+YzpjdneivrvhA5pABr6TwAcIUEGLhLyMpJnULZm0AIxj0 9dOCUk9D4W/KS+bLaksgLxNSGxW99fSe14YxrLnQtDlD2imwBwtuRNYOKT+4vKK5/uFg Ny8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dhF8YiqzmZt8FQtyvYqumO0kC/UPQF52ZYul1qLMH2U=; b=DDpem5yAo1lN2ingqSKsMPfnrII6B6A4R2qvNc6pGU8BCxRFqnUqVHDnC8ZXFag4xU o+l8nIrZ7K5qPdAx5pNorPXzUm6f8oFzenh64vhQ5AUATOmSzta3EgXJ+0iXPk+8sCJ/ DLTnq3OhvC5M1EhJiZRW925zuYZrgaZg0660kZEzLjhDWpsTYTISmQ3abgrrRNzMLc0f MPrLluXOZ3tzB1sHYECOb8L09+bIzeos2qTSaLnncgZcD1MgJcrgv+TvZ/eon3y1mwiI HezTol234lQi9N52UTf20URXx27BJebhgoi6CO5Eq0CV/rVbErhRZFlU+eP6ZQpvFWFZ 4CTQ== X-Gm-Message-State: AKS2vOx4uOlOYpYJPIgC1pEpND6SaH1fuYydS+++JR/3Dfr6SdpO17Mu whOwnN8yOBHGYfcW8g7FRr9LdB3WRi/FNLc= X-Received: by 10.28.191.29 with SMTP id p29mr380107wmf.60.1497452965868; Wed, 14 Jun 2017 08:09:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Wed, 14 Jun 2017 08:09:25 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Tom Herbert Date: Wed, 14 Jun 2017 08:09:25 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:09:30 -0000 On Wed, Jun 14, 2017 at 12:11 AM, Lorenzo Colitti wrote: > On Wed, Jun 14, 2017 at 12:36 PM, Tom Herbert wrote: >> >> Can you tell me what the killer app is on a smartphone that require >> 2^64 addresses? > > > I don't have one for you today, and I don't think I will have one for you > tomorrow either. I want to preserve the ability for someone else to give you > the answer during the expected multi-decade year lifetime of the protocol. If such an application never materializes then all you've done is waste half of the bits in IPv6 addresses and inhibit potential and tangible innovation. IMO, arbitrarily allocating half the bits to hosts with the justification that some day it might be useful is a poor justification for a protocol requirement. Tom From nobody Wed Jun 14 08:29:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97412EC2E for ; Wed, 14 Jun 2017 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDN2efMTf0y3 for ; Wed, 14 Jun 2017 08:29:05 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94CC12EC2F for ; Wed, 14 Jun 2017 08:29:05 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id y70so2702092vky.3 for ; Wed, 14 Jun 2017 08:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+czkXiwwIzzF91NM/zJVdaDz6Sx7UyyO+DLWaPlUx5o=; b=lPncYZNm3hGfjoKDSOBs/Epx0WJDA8OYpZab9wHkK8HQYTK/v2SXURUIjPbQ6VFh+f gC693RdsQ2HQg/EauVrWCql8HkwcjTQVcxJiIpAS8pgCjsTHj2+Q89GSrXkcTbvATplr 4ok4Bqbe4RK30Nca+8N+tUBiZk7v22b7Sevi1qv1JyqDf0MP8LqqRfJieet2EuQwETG2 RqEwNqG3sSa7w2rYEy0+6vGGCXeWWPXaNCcZ/93gFqESQjWw8/w5YCI0/8wI3PIsMZkl WRAuPncY6fKfqNhMoL/OJ+ICGqlcSOGDepr/DfuiirlRwK4NFWDzoikBaMIsdbNiwNU2 sP8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+czkXiwwIzzF91NM/zJVdaDz6Sx7UyyO+DLWaPlUx5o=; b=ZVz9ywKoMBIG0ObxR3XySySwZiLutD6J4bO8Prq0Wt9OWTLiCqNRZ8lQ5DUKAXps0T tg4YQNOn7N4i4CU3RgEYJTwwKRRPG1XDErg2UE7/S0uUHBF0ZYptz6KKiFq5jpdvIntE mrgg8hpia095RzR6J5kGh4nIq2c9vCkU/xLTy2yWRhYX6Yg0U4lTNPIj57TxBqPrUkg5 T1PR5NRXppi4xsourtv9zT1KPfDrsZ96IhTwjQLP+67VPwHOKNLTOvlVcGVqGpuRwJQX yZ6wdQPxhehbl0XAKyPAL0BI0EfIkVPiBJgZLbADb2BjItdIn1AgD/y4LbjpNYNgShcT JoXg== X-Gm-Message-State: AKS2vOxPE3/IE5qBJDRkaEdIaHKQCTS1ean/1ULAnwE5/zns7se/ANG+ zT7cjbK7/ezgWZeTEqvEXCfqDwIPuxPr X-Received: by 10.31.170.2 with SMTP id t2mr461152vke.100.1497454144253; Wed, 14 Jun 2017 08:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 08:28:43 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Lorenzo Colitti Date: Thu, 15 Jun 2017 00:28:43 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Ole Troan , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="001a11430a72569f1d0551ed3625" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:29:08 -0000 --001a11430a72569f1d0551ed3625 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 12:09 AM, Tom Herbert wrote: > > I don't have one for you today, and I don't think I will have one for you > > tomorrow either. I want to preserve the ability for someone else to give > you > > the answer during the expected multi-decade year lifetime of the > protocol. > > If such an application never materializes then all you've done is > waste half of the bits in IPv6 addresses and inhibit potential and > tangible innovation. IMO, arbitrarily allocating half the bits to > hosts with the justification that some day it might be useful is a > poor justification for a protocol requirement. > Agreed. I'm pretty sure the next 30 years will produce something better than the ability to do mobility without encapsulation. And ILA isn't the only way to do mobility without encapsulation, anyway - all you need is a way to update correspondent nodes with your current address when it changes. --001a11430a72569f1d0551ed3625 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 15, 2017 at 12:09 AM, Tom Herbert <tom@herbertland.com> wrote:
> I don&= #39;t have one for you today, and I don't think I will have one for you=
> tomorrow either. I want to preserve the ability for someone else to gi= ve you
> the answer during the expected multi-decade year lifetime of the proto= col.

If such an application never materializes then all you've done i= s
waste half of the bits in IPv6 addresses and inhibit potential and
tangible innovation. IMO, arbitrarily allocating half the bits to
hosts with the justification that some day it might be useful is a
poor justification for a protocol requirement.

Agreed. I'm pretty sure the next 30 years will produce somethin= g better than the ability to do mobility without encapsulation. And ILA isn= 't the only way to do mobility without encapsulation, anyway - all you = need is a way to update correspondent nodes with your current address when = it changes.
--001a11430a72569f1d0551ed3625-- From nobody Wed Jun 14 08:43:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9264C12EC41 for ; Wed, 14 Jun 2017 08:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miJCxRxlW8Ah for ; Wed, 14 Jun 2017 08:43:51 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 7260D129B73 for ; Wed, 14 Jun 2017 08:43:51 -0700 (PDT) X-AuditID: 60721c4b-0e3ff7000000704e-03-594159b4d6ff Received: from VAADCEX42.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id CF.9E.28750.4B951495; Wed, 14 Jun 2017 11:43:49 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX42.cable.comcast.com (147.191.103.219) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 11:43:47 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Wed, 14 Jun 2017 11:43:47 -0400 From: "Leddy, John" To: Lorenzo Colitti , Tom Herbert CC: IETF IPv6 Mailing List Subject: Re: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS4YmQvKMLPigQ7E+ftM7iiCHfIaIkfeKvgABH6ID//8EnAA== Date: Wed, 14 Jun 2017 15:43:46 +0000 Message-ID: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: multipart/alternative; boundary="_000_F618B0F0DF5749F99287AB2996825575cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf2wTVRz33bX01u3p25W2b3VUd5Hg5tyPaGJxsA0zdQsJcYqBMzFwbY+2 9tdy126rEsUYjEww/oCBxcmMI5gBhYwMiJOpBYkbYZABmyOIbAzJNoKJijKj4r1eO67+dZ/3 +Xze+3y/33t5DM1uN9oYXygiSiEhwM0z6tbKDY5HD/PL+IpEqWPq9C+U48Cpm8BxbniCrqXr O3ui9Vs62vX1XV2z1HP0S8YlbjHgaxal8uq1Ru/It8cMTX/VtG7fPExtAB9UtwGGwehxPH7y iTZgZFh0hMLnO6/Q6iIJcN/+G8oiR1kMADy8KUzwPFSKd7SP6Amej5bjgd5+HcE0KsF7Z+6k eBMqwr+NXadVD4fPXp/SqfgpPHPloxTWoYX4/J0jKT9Edfi9k2MGNfhXPf7hch9FhBzUiP/Y fMlAMEAW/OfgPkoNs+KLk7tSGCOEu746Q6vYjKeu/ps61IzKcE/322lPKT49OglUXIF7d6tF Y2THHTOX0w14cP+egzq1oHw88PFk2mPFx08c1b8PCuKa6LhmS1yzJa4MlUbF+MCX5aqlCG99 d9yg4ofxxk86DKrlSXzsJ6vW0gmYbmBvFgS3K+gNRyMVlWUuwRkQy1zhoEuQI+TbA8gdkAqX HwWJ2WeTADGAy4O6lct4Vi80y7FgEvgZijPDbfkKda8z7I55Bdm7RooGRJmbD9e/oNBwjnZG A37OBstXK6xpjg2JLXJAjCiXjrNDZ0sNz1rnNDkqN/lcvnBUXhOVAsodYWjl2HdWkWPdQuxV UQqrYUlwP6PjrNDkreJZ5BEiol8Um0Qpo7YwDIfhMyQ5XxI9Yus6XyCSkZV9JUsVBWmVVLEL 4KcjtTxr0QqaeovgjqJqnrVp5f+XTDE5SeBh8pS6B+tI3XKTEJR9nnS0CR56WmHzMmwqtgC2 kkrZDKmJXAA7yYgsGSk7bhBsBMztif2/U6wuFA6JNitcR05CxO6NhuZatlng2I8VPHufRiDR tkI4THizhr+bbnsQjhO1QKNmF5B5NKaBS7krJmgj6XnKk3K3Yxa2ETI3TaYaxjCc+jVpTtNv IdxJ+jWnley0aWWwlDLY58/WksFGhIh2sPYLS8hg02x6sN3EymbIrME+QPyWjJSdZNsA/O7c vtj3E+dmt8BD4LZjK28vTrxcu2s9PZp7quHnNtgXeD3/828+u1kt1tU0/t1YPnTmsQ/fPHF1 ReO13d+Zb10bek1443jvJcdQ7KG9iYOLohdvgC9WxP2Lc1c6q+5Z+so0XDgytK23+MLEW/Fb e77+p3Jff9WmqkcW73xx1J5omA4K7ZxO9gqVJbQkC/8B2gKwLKoFAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:43:53 -0000 --_000_F618B0F0DF5749F99287AB2996825575cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNvdWxkIHVzZSBWNiBTZWdtZW50IFJvdXRpbmcgYW5kIGluc2VydCBhbiBTUiBoZWFkZXIg b24gZW50cmFuY2UgdG8gdGhlIGRvbWFpbiB3aXRoIHRoZSBWNiBMb2NhdGlvbiBvZiB0aGUgRW5k IFVzZXIgZGV2aWNlLiAgT3V0Ym91bmQgaXNu4oCZdCByZWFsbHkgYW4gaXNzdWUuDQoNClRoZW4g d2UgY2FuIHN0YXkgd2l0aCB0aGUgaGFyZCAvNjQuDQoNCkZyb206IGlwdjYgPGlwdjYtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUu Y29tPg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDExOjI4IEFNDQpUbzogVG9t IEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5jb20+DQpDYzogSUVURiBJUHY2IE1haWxpbmcgTGlz dCA8aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBUdXNzbGVzIGluIElQdjYgTGFuZA0KDQpP biBUaHUsIEp1biAxNSwgMjAxNyBhdCAxMjowOSBBTSwgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0 bGFuZC5jb208bWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb20+PiB3cm90ZToNCj4gSSBkb24ndCBo YXZlIG9uZSBmb3IgeW91IHRvZGF5LCBhbmQgSSBkb24ndCB0aGluayBJIHdpbGwgaGF2ZSBvbmUg Zm9yIHlvdQ0KPiB0b21vcnJvdyBlaXRoZXIuIEkgd2FudCB0byBwcmVzZXJ2ZSB0aGUgYWJpbGl0 eSBmb3Igc29tZW9uZSBlbHNlIHRvIGdpdmUgeW91DQo+IHRoZSBhbnN3ZXIgZHVyaW5nIHRoZSBl eHBlY3RlZCBtdWx0aS1kZWNhZGUgeWVhciBsaWZldGltZSBvZiB0aGUgcHJvdG9jb2wuDQoNCklm IHN1Y2ggYW4gYXBwbGljYXRpb24gbmV2ZXIgbWF0ZXJpYWxpemVzIHRoZW4gYWxsIHlvdSd2ZSBk b25lIGlzDQp3YXN0ZSBoYWxmIG9mIHRoZSBiaXRzIGluIElQdjYgYWRkcmVzc2VzIGFuZCBpbmhp Yml0IHBvdGVudGlhbCBhbmQNCnRhbmdpYmxlIGlubm92YXRpb24uIElNTywgYXJiaXRyYXJpbHkg YWxsb2NhdGluZyBoYWxmIHRoZSBiaXRzIHRvDQpob3N0cyB3aXRoIHRoZSBqdXN0aWZpY2F0aW9u IHRoYXQgc29tZSBkYXkgaXQgbWlnaHQgYmUgdXNlZnVsIGlzIGENCnBvb3IganVzdGlmaWNhdGlv biBmb3IgYSBwcm90b2NvbCByZXF1aXJlbWVudC4NCg0KQWdyZWVkLiBJJ20gcHJldHR5IHN1cmUg dGhlIG5leHQgMzAgeWVhcnMgd2lsbCBwcm9kdWNlIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiB0aGUg YWJpbGl0eSB0byBkbyBtb2JpbGl0eSB3aXRob3V0IGVuY2Fwc3VsYXRpb24uIEFuZCBJTEEgaXNu J3QgdGhlIG9ubHkgd2F5IHRvIGRvIG1vYmlsaXR5IHdpdGhvdXQgZW5jYXBzdWxhdGlvbiwgYW55 d2F5IC0gYWxsIHlvdSBuZWVkIGlzIGEgd2F5IHRvIHVwZGF0ZSBjb3JyZXNwb25kZW50IG5vZGVz IHdpdGggeW91ciBjdXJyZW50IGFkZHJlc3Mgd2hlbiBpdCBjaGFuZ2VzLg0K --_000_F618B0F0DF5749F99287AB2996825575cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <2385D2E9976E2A43A7D74170F97A160C@comcast.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBj b3VsZCB1c2UgVjYgU2VnbWVudCBSb3V0aW5nIGFuZCBpbnNlcnQgYW4gU1IgaGVhZGVyIG9uIGVu dHJhbmNlIHRvIHRoZSBkb21haW4gd2l0aCB0aGUgVjYgTG9jYXRpb24gb2YgdGhlIEVuZCBVc2Vy IGRldmljZS4mbmJzcDsgT3V0Ym91bmQgaXNu4oCZdCByZWFsbHkgYW4gaXNzdWUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoZW4gd2UgY2FuIHN0YXkgd2l0aCB0aGUgaGFyZCAvNjQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5p cHY2ICZsdDtpcHY2LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBMb3JlbnpvIENv bGl0dGkgJmx0O2xvcmVuem9AZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVz ZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDExOjI4IEFNPGJyPg0KPGI+VG86IDwvYj5Ub20gSGVyYmVy dCAmbHQ7dG9tQGhlcmJlcnRsYW5kLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPklFVEYgSVB2NiBN YWlsaW5nIExpc3QgJmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBUdXNzbGVzIGluIElQdjYgTGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biAxNSwg MjAxNyBhdCAxMjowOSBBTSwgVG9tIEhlcmJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21AaGVy YmVydGxhbmQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9tQGhlcmJlcnRsYW5kLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgSSBkb24ndCBoYXZlIG9uZSBmb3IgeW91IHRvZGF5LCBhbmQgSSBkb24ndCB0aGluayBJ IHdpbGwgaGF2ZSBvbmUgZm9yIHlvdTxicj4NCiZndDsgdG9tb3Jyb3cgZWl0aGVyLiBJIHdhbnQg dG8gcHJlc2VydmUgdGhlIGFiaWxpdHkgZm9yIHNvbWVvbmUgZWxzZSB0byBnaXZlIHlvdTxicj4N CiZndDsgdGhlIGFuc3dlciBkdXJpbmcgdGhlIGV4cGVjdGVkIG11bHRpLWRlY2FkZSB5ZWFyIGxp ZmV0aW1lIG9mIHRoZSBwcm90b2NvbC48YnI+DQo8YnI+DQpJZiBzdWNoIGFuIGFwcGxpY2F0aW9u IG5ldmVyIG1hdGVyaWFsaXplcyB0aGVuIGFsbCB5b3UndmUgZG9uZSBpczxicj4NCndhc3RlIGhh bGYgb2YgdGhlIGJpdHMgaW4gSVB2NiBhZGRyZXNzZXMgYW5kIGluaGliaXQgcG90ZW50aWFsIGFu ZDxicj4NCnRhbmdpYmxlIGlubm92YXRpb24uIElNTywgYXJiaXRyYXJpbHkgYWxsb2NhdGluZyBo YWxmIHRoZSBiaXRzIHRvPGJyPg0KaG9zdHMgd2l0aCB0aGUganVzdGlmaWNhdGlvbiB0aGF0IHNv bWUgZGF5IGl0IG1pZ2h0IGJlIHVzZWZ1bCBpcyBhPGJyPg0KcG9vciBqdXN0aWZpY2F0aW9uIGZv ciBhIHByb3RvY29sIHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLiBJJ20gcHJldHR5IHN1cmUgdGhl IG5leHQgMzAgeWVhcnMgd2lsbCBwcm9kdWNlIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiB0aGUgYWJp bGl0eSB0byBkbyBtb2JpbGl0eSB3aXRob3V0IGVuY2Fwc3VsYXRpb24uIEFuZCBJTEEgaXNuJ3Qg dGhlIG9ubHkgd2F5IHRvIGRvIG1vYmlsaXR5IHdpdGhvdXQgZW5jYXBzdWxhdGlvbiwgYW55d2F5 IC0gYWxsIHlvdSBuZWVkIGlzIGEgd2F5IHRvIHVwZGF0ZSBjb3JyZXNwb25kZW50DQogbm9kZXMg d2l0aCB5b3VyIGN1cnJlbnQgYWRkcmVzcyB3aGVuIGl0IGNoYW5nZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_F618B0F0DF5749F99287AB2996825575cablecomcastcom_-- From nobody Wed Jun 14 10:36:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A03E1292C5 for ; Wed, 14 Jun 2017 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGb9LlxKEuKv for ; Wed, 14 Jun 2017 10:36:42 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848FA128AB0 for ; Wed, 14 Jun 2017 10:36:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5EHaf7m037581; Wed, 14 Jun 2017 10:36:41 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5EHaclC037563 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 14 Jun 2017 10:36:39 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 10:36:38 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 14 Jun 2017 10:36:38 -0700 From: "Manfredi, Albert E" To: "otroan@employees.org" CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS5O3iBqlt++AmEkC1QOEah1pM8KIkiz6AgAADVoCAAAFzAIAAA1KAgAAEk2A= Date: Wed, 14 Jun 2017 17:36:38 +0000 Message-ID: <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:36:44 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of otroan@employees.org > What _problem_ does changing the 64 bit boundary solve for _you_? A category of problems, such as creating hotspots with smartphones that hav= e been allocated a single /64. A real-world situation, in which there's no = conceivable reason to have to go hat in hand to service provider, asking fo= r more /64s. And in fact, from an operator's point of view, would not a use= r asking for more /64s be a bigger pain than a user subnetting his own /64,= with no consequence at all to the operator? I do acknowledge the "race to the bottom" potential. Then again, being over= ly stingy with /64s amounts to the same thing. Operators can make things ba= d, no matter what solution you adopt. Allowing the boundary to move gives u= sers and app designers more flexibility and independence. For some players,= that's a good thing. Plus, I oppose the idea of artificially declaring that a fixed IID length i= s associated with each link type. This is a legacy notion, driven by ration= ales no longer valid. It's an unnecessary constraint. Or if stated, add a h= istorical note as to why you have stated it. If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise= to cripple non-/64 solutions by artificially mandating that SLAAC be only = possible with /64s. The smartphone hotspot example is one in which a non-/6= 4 SLAAC would work great. And there's simply no reason to state that SLAAC = can only work with /64s. It's not true! Using RECOMMENDED for /64s? IMO, that RECOMMENDED would only apply to opera= tors. It should be RECOMMENDED that ISPs not hand out /128s, or other overl= y long prefixes. I would almost rather use the word "typical." The "typical= " prefix at the "operator to user boundary" may be /64 (or /56 perhaps). Bu= t app designers and users? No, there should be no such recommendations. Bert From nobody Wed Jun 14 10:51:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22A312878D for ; Wed, 14 Jun 2017 10:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKZleBmaMCQU for ; Wed, 14 Jun 2017 10:51:45 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391291201F2 for ; Wed, 14 Jun 2017 10:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497462702; x=1498067502; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=UH47zNuOqzF/T9wKY68gUvpTo LCiSYXSQ8nHzkUDiIw=; b=SMF6nXvCMt9PQUOhu7zRQon3ZHV/73QlD8BJZ7tjq y56/vNTcxEscWYff7nSx7v3RlzFLkN8MfEcyaxoHZ7OYdCyONeiqDe1UyXMCuBAO R3YFVIDhQJa0NzdIjXq+BJmq7PS0cvO6sEijAAnoYWxiu4DSVjg5Sgw7B01SWy8p b4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=V1QB6QExwRilxbJZ9FtEgqjTfuAfQsb/7+q/q2Fr34tJ8bui6ihezoJzoWpw IXXLgUCDHgoZ8sMlJ8wiHFWEUw/823jClHuk2PjsDnRrvBIJ5shFA2P8Q TWg5zDi08N0U91t1kJFfERIUBZsHNCOeymnbpoJ43K01BCSUJdFlfY=; X-MDAV-Processed: mail.consulintel.es, Wed, 14 Jun 2017 19:51:42 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 14 Jun 2017 19:51:41 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005451177.msg for ; Wed, 14 Jun 2017 19:51:40 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170614:md50005451177::+GIT2WJUbBMy0Hds:000046U3 X-Return-Path: prvs=1338998007=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 14 Jun 2017 19:51:37 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: JORDI PALET MARTINEZ To: 6man WG Message-ID: <62D63775-949F-4E73-8A95-A94924920E70@consulintel.es> Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:51:48 -0000 I just don=E2=80=99t see the need for that. 3G/LTE operators providing broadband services to CPEs, have ways (dedicated= provisioning or DHCPv6-PD), to receive a /48. I=E2=80=99ve used that. So why not using the same for a cellular phone that may require instead of = /64 a /56? Regards, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de "Manfredi, Albert E" Responder a: Fecha: mi=C3=A9rcoles, 14 de junio de 2017, 19:36 Para: "otroan@employees.org" CC: 6man WG Asunto: RE: draft-bourbaki-6man-classless-ipv6-00 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of otroan@employees= .org =20 > What _problem_ does changing the 64 bit boundary solve for _you_? =20 A category of problems, such as creating hotspots with smartphones that= have been allocated a single /64. A real-world situation, in which there's= no conceivable reason to have to go hat in hand to service provider, askin= g for more /64s. And in fact, from an operator's point of view, would not a= user asking for more /64s be a bigger pain than a user subnetting his own = /64, with no consequence at all to the operator? =20 I do acknowledge the "race to the bottom" potential. Then again, being = overly stingy with /64s amounts to the same thing. Operators can make thing= s bad, no matter what solution you adopt. Allowing the boundary to move giv= es users and app designers more flexibility and independence. For some play= ers, that's a good thing. =20 Plus, I oppose the idea of artificially declaring that a fixed IID leng= th is associated with each link type. This is a legacy notion, driven by ra= tionales no longer valid. It's an unnecessary constraint. Or if stated, add= a historical note as to why you have stated it. =20 If part of what makes IPv6 wonderful is SLAAC, then I don't think it's = wise to cripple non-/64 solutions by artificially mandating that SLAAC be o= nly possible with /64s. The smartphone hotspot example is one in which a no= n-/64 SLAAC would work great. And there's simply no reason to state that SL= AAC can only work with /64s. It's not true! =20 Using RECOMMENDED for /64s? IMO, that RECOMMENDED would only apply to o= perators. It should be RECOMMENDED that ISPs not hand out /128s, or other o= verly long prefixes. I would almost rather use the word "typical." The "typ= ical" prefix at the "operator to user boundary" may be /64 (or /56 perhaps)= . But app designers and users? No, there should be no such recommendations. =20 Bert =20 =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Jun 14 11:09:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68906129408 for ; Wed, 14 Jun 2017 11:09:57 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwxGxMoHRT6O for ; Wed, 14 Jun 2017 11:09:55 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A323D1293EE for ; Wed, 14 Jun 2017 11:09:55 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id l89so3980355pfi.2 for ; Wed, 14 Jun 2017 11:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=55NT8dh28vI+cWcoRg5aREIqB+JLGC5e8DLM9T4ZoGc=; b=OA9tb59aC7snELcauO4+BFHxdu8Kp0dLxe1fy2D2WjAG/98mLTo4M1X5mtVYgafeoF T7kCFV0x4l3W0WcmF3MzYXJZNx7YftzbXl7KSJ92wxI5jaPqHB5i22Ue62rK+284eWXZ WxgLOGO5gPj9CoxzTX2v0F0hJTbVjwn5b6SN6JYeKf6bnEbOWNymFeWSmKx8o3IrOVgi 9pcbmcrf4oCsXRAad+Gqnpr4DK5PoiJJpbQO+USZiK7itt9vsOyygRDN8iw4RUC+6dbk f86/LbLiBABkNXvp8lMtVsTUlLs3Lr++mX99eeRS2im2xuhR0kCxxtkPUwcK/MbmN53C YBDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=55NT8dh28vI+cWcoRg5aREIqB+JLGC5e8DLM9T4ZoGc=; b=KkkkEFmdq0y1bd7vnmFNMORMSy/bIZaKV402m9UxbQI2B8vWu/vr1HPtbRoYT1zIHe WfEd6+e28oVvftamTqp8k10dX1JK9tpK/0s5lH7kbfzBMZ4zjkN0oa61U9+0P89drepK Famzi/wN8nvTGKjp0OgnT25XMgemriKSaeYeOVZR1JrhE/W9+bglHJTCNMF+GyLcoNnd KLECvCloij8CX0EZfTyc1WQZptXNOgJu8/PpvMpln7Qeqt+Ztr5jR907CrpF5r968iP3 ToV+NkGCQ//8NZjcUjQIHOeZ3IBUzzVGV3pn/gn7Dzo+vsiGSKBqrCjFncCQaDPNLdWI 2LDA== X-Gm-Message-State: AKS2vOxzUrwFtMwdRm8VFJsI6l2zOqmeou8QqoxqPdymDG2vyWuN6w/P 6du+lz5lrlXr8AgE+/t9tQ== X-Received: by 10.84.197.3 with SMTP id m3mr1476861pld.40.1497463794865; Wed, 14 Jun 2017 11:09:54 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:170:a37a:4a61:ea80? ([2620:0:10e7:10:170:a37a:4a61:ea80]) by smtp.gmail.com with ESMTPSA id e124sm1011482pgc.17.2017.06.14.11.09.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 11:09:53 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_478C920F-8353-4567-B55E-64CBDDD93037" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Date: Wed, 14 Jun 2017 11:09:58 -0700 References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> To: 6man WG In-Reply-To: <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 18:09:57 -0000 --Apple-Mail=_478C920F-8353-4567-B55E-64CBDDD93037 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 14, 2017, at 10:36, Manfredi, Albert E = wrote: > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of = otroan@employees.org >>=20 >> What _problem_ does changing the 64 bit boundary solve for _you_? >=20 > A category of problems, such as creating hotspots with smartphones = that have been allocated a single /64. A real-world situation, in which = there's no conceivable reason to have to go hat in hand to service = provider, asking for more /64s. [=E2=80=A6] This category of problem is about connecting *routers* (not hosts) to = the Internet via RFC 7278. If all you=E2=80=99re connecting at the hotspot are hosts, then why = would you need more than one subnet? And if you need more than one = subnet=E2=80=94 for some premium mobile hotspot thingie I guess=E2=80=94 = why not use more than one UE? "What is the killer app for connecting *routers* to the Internet using a = /64 subnet sharing scheme?=E2=80=9D I ask, bearing in mind that you = can=E2=80=99t be talking about 6LBR, because RFC 4944 fixes the subnet = prefix length at 64 bits for all 6LO-over-link specifications. And why = isn=E2=80=99t simply using IPv6/NAT the simpler and more straightforward = solution to your category of problems? Shorter james: I=E2=80=99m not ready to believe you have any problems in = this category. Please provide a clear example. --james woodyatt > --Apple-Mail=_478C920F-8353-4567-B55E-64CBDDD93037 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 14, 2017, at 10:36, Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote:
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of otroan@employees.org

What = _problem_ does changing the 64 bit boundary solve for _you_?

A category of problems, such as = creating hotspots with smartphones that have been allocated a single = /64. A real-world situation, in which there's no conceivable reason to = have to go hat in hand to service provider, asking for more /64s. = [=E2=80=A6]

This category of problem is about connecting = *routers* (not hosts) to the Internet via RFC 7278.

If all you=E2=80=99re connecting at the hotspot = are hosts, then why would you need more than one subnet? And if you need = more than one subnet=E2=80=94 for some premium mobile hotspot thingie I = guess=E2=80=94 why not use more than one UE?

"What is the killer app for connecting *routers* = to the Internet using a /64 subnet sharing scheme?=E2=80=9D I ask, = bearing in mind that you can=E2=80=99t be talking about 6LBR, because = RFC 4944 fixes the subnet prefix length at 64 bits for all 6LO-over-link = specifications. And why isn=E2=80=99t simply using IPv6/NAT the simpler = and more straightforward solution to your category of = problems?

Shorter james: I=E2=80=99m not ready to believe you have any = problems in this category. Please provide a clear example.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_478C920F-8353-4567-B55E-64CBDDD93037-- From nobody Wed Jun 14 11:53:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FAE129464 for ; Wed, 14 Jun 2017 11:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaLHePf5FuOQ for ; Wed, 14 Jun 2017 11:53:52 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9E612783A for ; Wed, 14 Jun 2017 11:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5EIrpAh038692; Wed, 14 Jun 2017 11:53:51 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5EIrjx0038670 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 14 Jun 2017 11:53:45 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 11:53:44 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 14 Jun 2017 11:53:44 -0700 From: "Manfredi, Albert E" To: james woodyatt , 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS5O3iBqlt++AmEkC1QOEah1pM8KIkiz6AgAADVoCAAAFzAIAAA1KAgAAEk2CAAIZuAP//kAoQ Date: Wed, 14 Jun 2017 18:53:44 +0000 Message-ID: <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 18:53:54 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGph bWVzIHdvb2R5YXR0DQoNCj4gVGhpcyBjYXRlZ29yeSBvZiBwcm9ibGVtIGlzIGFib3V0IGNvbm5l Y3RpbmcgKnJvdXRlcnMqIChub3QgaG9zdHMpDQo+IHRvIHRoZSBJbnRlcm5ldCB2aWEgUkZDIDcy NzguDQoNCk9yIGhvc3RzIHdoaWNoIG9wZXJhdGUgbGlrZSByb3V0ZXJzPw0KDQo+IElmIGFsbCB5 b3XigJlyZSBjb25uZWN0aW5nIGF0IHRoZSBob3RzcG90IGFyZSBob3N0cywgdGhlbiB3aHkgd291 bGQgeW91DQo+IG5lZWQgbW9yZSB0aGFuIG9uZSBzdWJuZXQ/DQoNCk15IHNtYXJ0cGhvbmUgaXMg YXNzaWduZWQgYSBzaW5nbGUgLzY0LiBJdCBiZWNvbWVzIGEgV2lGaSBob3RzcG90LiBTbywgZGUg bWluaW1pcywgaXQgY3JlYXRlcyBhIC82NSwgZm9yIGl0cyBXaUZpIGludGVyZmFjZSwgd2hpY2gg YW55IG51bWJlciBvZiBsb2NhbCBXaUZpIHVzZXJzIGNhbiB1c2UuIFdoeSBub3QgYWxsb3cgU0xB QUMgZm9yIHRoZXNlIFdpRmkgdXNlcnM/IEFuZCwgd2h5IHNob3VsZCB3ZSBub3QgYWxsb3csIHRy aXZpYWxseSwgbW9yZSBmbGV4aWJpbGl0eT8gV2Ugbm93IGhhdmUgdGhlc2UgIndob2xlIGhvbWUg V2lGaSIgc3lzdGVtcy4gV2h5IHNob3VsZCB0aGF0IHNtYXJ0cGhvbmUncyAvNjQgbm90IGJlIGNh cGFibGUgb2Ygc3VwcG9ydGluZyB0d28gb3IgdGhyZWUgbG9jYWwgV2lGaSBob3RzcG90cz8NCg0K UG9pbnQgYmVpbmcsIGFsbCBvZiB0aGlzIGNhbiBiZSBkb25lIHdpdGggYWJzb2x1dGVseSBubyBj b25zZXF1ZW5jZXMgdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIsIG90aGVyIHRoYW4gcG90ZW50aWFs bHkgc29tZSBleHRyYSB0cmFmZmljIHZvbHVtZSBvbiB0aGF0IG9uZSAvNjQgZmFjaW5nIHRoZSBv cGVyYXRvci4gQnV0IG9ubHkgaWYgdGhhdCA2NC1iaXQgYm91bmRhcnkgaXMgbm90IGZpeGVkLg0K DQo+IEFuZCBpZiB5b3UgbmVlZCBtb3JlIHRoYW4gb25lIHN1Ym5ldOKAlCBmb3Igc29tZSBwcmVt aXVtIG1vYmlsZSBob3RzcG90DQo+IHRoaW5naWUgSSBndWVzc+KAlCB3aHkgbm90IHVzZSBtb3Jl IHRoYW4gb25lIFVFPw0KDQpPZiBjb3Vyc2UgeW91IGNhbiB1c2UgbXVsdGlwbGUgcGhvbmVzIHdp dGggLzY0cywgaWYgdGhhdCdzIHdoYXQgeW91J3JlIGFza2luZz8gIEJ1dCBub3Qgd2l0aG91dCBn b2luZyBoYXQgaW4gaGFuZCB0byB0aGUgb3BlcmF0b3IuDQoNCldpdGggSW9ULCBleGFtcGxlIGlu IGNhcnMsIG9yIGluIGhvbWVzLCBubyBvbmUgY2FuIHRlbGwgaG93IG1hbnkgZGlmZmVyZW50IHN1 Ym5ldHMgd2lsbCBtYWtlIHNlbnNlLiBJZiBhIGhvbWUgcm91dGVyIGlzIGFzc2lnbmVkIGEgLzY0 LCBpdCBzaG91bGQgYmUgYWJsZSB0byB1c2UgdGhhdCBvbmUgLzY0IGVmZmVjdGl2ZWx5LCB3aXRo b3V0IGNvbnN0YW50bHkgaGF2aW5nIHRvIGFzayBmb3IgbW9yZT8gQW5kIFNMQUFDIHNob3VsZCBi ZSBhdmFpbGFibGUsIGZvciBpbnNpZGUgdGhlIGhvbWUuIFdoeSBub3Q/IEVpdGhlciB0aGF0LCBv ciBmb3Igc3VyZSwgeW91IHdpbGwgc2VlIE5BVCB1c2VkIHdpdGggSVB2Ni4NCg0KU3VtbWFyeTog SSBrZWVwIHNlZWluZyBwZW9wbGUgc2F5aW5nIHRoYXQgdGhleSBkb27igJl0IHdhbnQgdG8gc2Vl IE5BVCB1c2VkIHdpdGggSVB2Ni4gSW4gdGhlIG5leHQgc2VudGVuY2UsIHRoZXkgc2F5IHRoZXkg d2FudCBhIGZpeGVkIGJvdW5kYXJ5IGF0IC82NC4gVGhlIG9ubHkgd2F5IHRoZSB0d28gaWRlYXMg Y2FuIGJlIGNvbXBhdGlibGUgaXMgaWYgd2UgaGF2ZSBhIHByZWZpeCBwb2xpY2UgdGhhdCBtYW5k YXRlcyBzb21lIGFyYml0cmFyeSBtYXggcHJlZml4IGxlbmd0aCB0byBiZSBoYW5kZWQgb3V0LCBi eSBvcGVyYXRvcnMsIGxpa2UgLzQ4LiBCdXQgb3BlcmF0b3JzIGtlZXAgc2F5aW5nIG5vIHdheSwg YW5kIHRoZXkgaGFuZCBvdXQgLzY0cy4gUm9jaywgaGFyZCBwbGFjZS4gKEFuZCwgbm90IHRvIGJl IGlnbm9yZWQsIHRoZW4gdGhlcmUncyB0aGUgaHlwZSBvZiB0aGlzIGxpbWl0bGVzcyBhZGRyZXNz IHNwYWNlIG9mZmVyZWQgYnkgMTI4LWJpdCBhZGRyZXNzZXMsIGFzIGlmIGl0J3MgYWN0dWFsbHkg dXNhYmxlLikNCg0KQmVydA0KDQo= From nobody Wed Jun 14 17:11:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C75128616 for ; Wed, 14 Jun 2017 17:11:08 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaTzGweOTJ1h for ; Wed, 14 Jun 2017 17:11:06 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 24396128ACA for ; Wed, 14 Jun 2017 17:11:06 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 6870E24AE09; Thu, 15 Jun 2017 00:09:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 49EC0160097; Thu, 15 Jun 2017 00:09:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 23884160096; Thu, 15 Jun 2017 00:09:45 +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 K-qIhfW0-P7L; Thu, 15 Jun 2017 00:09:45 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9A0DC160008; Thu, 15 Jun 2017 00:09:44 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D0E667BB303B; Thu, 15 Jun 2017 10:09:42 +1000 (AEST) To: "Manfredi, Albert E" Cc: james woodyatt , 6man WG From: Mark Andrews References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 In-reply-to: Your message of "Wed, 14 Jun 2017 18:53:44 +0000." <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 15 Jun 2017 10:09:42 +1000 Message-Id: <20170615000942.D0E667BB303B@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 00:11:08 -0000 In message <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com>, "Manfredi, Albert E" writes: > From: ipv6 mailto:ipv6-bounces@ietf.org On Behalf Of james woodyatt > > > This category of problem is about connecting *routers* (not hosts) > > to the Internet via RFC 7278. > > Or hosts which operate like routers? > > > If all youre connecting at the hotspot are hosts, then why would you > > need more than one subnet? > > My smartphone is assigned a single /64. It becomes a WiFi hotspot. So, de > minimis, it creates a /65, for its WiFi interface, which any number of > local WiFi users can use. Why not allow SLAAC for these WiFi users? And, > why should we not allow, trivially, more flexibility? We now have these > "whole home WiFi" systems. Why should that smartphone's /64 not be > capable of supporting two or three local WiFi hotspots? > > Point being, all of this can be done with absolutely no consequences to > the service provider, other than potentially some extra traffic volume on > that one /64 facing the operator. But only if that 64-bit boundary is not > fixed. Operators that only give you a single /64 have already STOLEN 65535 subnets from you. The architecture document say to give each site a /48. Addresses are handed to ISP's in the basis of /48's being handed out to customers (you don't need to justify the space beyond saying you are giving out /48s). It doesn't cost more to route /48 than it does a /64. These is less than a cent difference per customer to get a /48 vs a /64 from the RIRs. A cell phone is a site border router the moment it turns on tethering. > > And if you need more than one subnet for some premium mobile hotspot > > thingie I guess why not use more than one UE? > > Of course you can use multiple phones with /64s, if that's what you're > asking? But not without going hat in hand to the operator. > > With IoT, example in cars, or in homes, no one can tell how many > different subnets will make sense. If a home router is assigned a /64, it > should be able to use that one /64 effectively, without constantly having > to ask for more? And SLAAC should be available, for inside the home. Why > not? Either that, or for sure, you will see NAT used with IPv6. > > Summary: I keep seeing people saying that they dont want to see NAT used > with IPv6. In the next sentence, they say they want a fixed boundary at > /64. The only way the two ideas can be compatible is if we have a prefix > police that mandates some arbitrary max prefix length to be handed out, > by operators, like /48. But operators keep saying no way, and they hand > out /64s. Rock, hard place. (And, not to be ignored, then there's the > hype of this limitless address space offered by 128-bit addresses, as if > it's actually usable.) More it is the MBA that thinks saving a couple of dollars on RIR fees by only requesting just enough space to support a /64 per customer is a good idea without looking at the entire picture. Yes, it adds up when there are millions of customers. Charging 5 cents extra per month would cover the additional costs many times over. > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 14 17:14:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C10512941D for ; Wed, 14 Jun 2017 17:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHJCBewvH9KT for ; Wed, 14 Jun 2017 17:14:46 -0700 (PDT) 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 62CB51286CA for ; Wed, 14 Jun 2017 17:14:46 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id x63so7851607pff.3 for ; Wed, 14 Jun 2017 17:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wLZlEajKShDq2YKQGqEC5LtcUsVTgQcCi3m4S7jR2J0=; b=sFxkJw3zfzzrNlYuIfg5PpHVWWIvNmSxPbHTusy5z/+LJok+Sr9bZHdxQpOPOQLOyX 4BDHJX0AO1J5AheyODdM1Mp4zmF2xd1bSDN3B58DbWngwZq35lD3QGrSp9sh05a2x56l U8epi4lraPLcfNkpfMySUl/gblJBUgleoRTiBcXnfzCJk1HXxnsAF6+2kbTRbUfD2Bk1 RL+KELD4Gmd61wEmhAyY/JvzOLjCThuFTZqkjMpmZNBI7NxxtZ3oqHIuPcDoQa3bFhNT ECqsyNMGieOMF0vhj0Ahovp4gy/Hw6kyB50QBijUm5pkPcxEMFaf1g++ZxVvmfCbYScr 14yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=wLZlEajKShDq2YKQGqEC5LtcUsVTgQcCi3m4S7jR2J0=; b=EgQ1LXzGtQub5ANrPFCnVsLTdWRnWCJjDMlIdT7yIkOMztQM3sR1LMl2fajSbrgc8s dpwY7Jl0rcqj9CjoJOum9qD+swLdg/hMWTTJSAicaHWrjRRdSFvouENLxc3hlQC/VWOV pYWMbP1uviqn0Wc4KldcVVD55cx/vHk/N1mIGm0P79lJVo8C8ycUKWpJSBuFrD8OP6ZC Z6ZN3ZxN03r908jc5oR0L2dRJNgX4ncWakCOJehq+ySF9amAfGqQLGIWtNr5zHu4zJCi y5MKIi7lExthEXgbjMv2g3MCOnQAd/UfJcPQM7T1fYypqCeExbAu6/ooExTNVR/1YVZF p1pw== X-Gm-Message-State: AKS2vOz3uT/WO0VZWfFamlkbhPV8wBPCml6VqJ1F1zb22wI/Ykewup0S HQ96OMi/w+flBy2v X-Received: by 10.84.164.193 with SMTP id l1mr2853193plg.243.1497485685460; Wed, 14 Jun 2017 17:14:45 -0700 (PDT) Received: from [192.168.178.21] ([118.148.126.2]) by smtp.gmail.com with ESMTPSA id z13sm1983102pfk.99.2017.06.14.17.14.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 17:14:44 -0700 (PDT) Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti , Tom Herbert Cc: IETF IPv6 Mailing List References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 15 Jun 2017 12:14:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 00:14:48 -0000 On 14/06/2017 19:11, Lorenzo Colitti wrote: > On Wed, Jun 14, 2017 at 12:36 PM, Tom Herbert wrote: > >> Can you tell me what the killer app is on a smartphone that require >> 2^64 addresses? The question is slightly premature. Try: "What is the killer use case on a smartphone that requires many addresses that are essentially unguessable because they include 64 pseudo-random bits?" Lorenzo's answer below covers this case too, and he's right, if we believe that miscreants in the far future may have enough computing power to search a very large space, even if the use case only needs a few thousand addresses. (64 is only a parameter, even in this sub-sub-sub-thread, but it's the right order of magnitude - privacy concerns require several tens of bits even with today's computing power.) BTW, I aoplogise to the WG for having provoked this thread. My intention was only to remind people that these tussles are a sign of success for IPv6. Brian > I don't have one for you today, and I don't think I will have one for you > tomorrow either. I want to preserve the ability for someone else to give > you the answer during the expected multi-decade year lifetime of the > protocol. If you take the bits for your own use, we will never get that > answer. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jun 14 17:16:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87BD126CC7 for ; Wed, 14 Jun 2017 17:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2MhV2SifZ0q for ; Wed, 14 Jun 2017 17:16:46 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D72D1205D3 for ; Wed, 14 Jun 2017 17:16:46 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id v7so9528529ywc.2 for ; Wed, 14 Jun 2017 17:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WrizfmiUo/hWgHnvIQxj+qK2tnivrcVMysCC/3stoEU=; b=ZTseQyu2xWnpUSqOOd0Fe9YgqO/ldhAX9bedQChRb/VJnr4tGUwy2F7BqVEqXAU54H L5EkfwQ096PKf5oaq3fkeWwnFsfeCeqpdinsQ6rCtsZo+M39HFiKX/9t+eNqpK16KTum xZTnJH5Dyl//7gTbTSWgGmw5QQPYpCuwEq6MRPVAP9X8P0T1qOdXMZ2uiX7sBcb6HbVM BOGzQXkpWyhut94VhmOJadS2k+ugWD9PaS+Mmp+ivPZkJWQy3RtbAX/tZyRrqHWl8mcV fJrZQncOaj4nDY6z+X5+GcUO8DjJK+VUo15G43zG5EQlgUFF+HbQ7vfdpXTpzJDCmGBY ihkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WrizfmiUo/hWgHnvIQxj+qK2tnivrcVMysCC/3stoEU=; b=Iy2vJu6dVvBcx7vqccmCT/TxZ15h3GnAh3LMx5KS2mgGE2T3QzH8SGWDJRUwEuoNlI Af8fRsbfPQNs2Rr09CkYzBf8foAysF7KyDkKCVht7/DGgTdrfcXZhABfjpefCS7mvDRd cQAJqWGNtEwdZjlXs8dO0LnxCEohXgX2p+DhwyZHfB1qr0IGrmYVs/tF5yMk9rXv+A/w oyKxa0YYjmnoTBllYfBV0VoOIzMLXNFvlAf63FLwsyysBN9bem3T+JIa2SbcicCGSjkD dLUoJFKrEoPqLlAMP/R1CoV/qbXWmUjbLikwXCvMHimRoTzSa1EjFHsJlxoTLKXzwrMl aDmA== X-Gm-Message-State: AKS2vOz90eD6MCp+XSwLIoSH/9rI1TWdgkaJpCm1ALbQoKTDRNtGX8/H JRwgtyOkx4yB0hzcgaSguX+LM82GNg== X-Received: by 10.129.182.87 with SMTP id h23mr2238933ywk.318.1497485805438; Wed, 14 Jun 2017 17:16:45 -0700 (PDT) MIME-Version: 1.0 References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com> <20170615000942.D0E667BB303B@rock.dv.isc.org> In-Reply-To: <20170615000942.D0E667BB303B@rock.dv.isc.org> From: Ca By Date: Thu, 15 Jun 2017 00:16:34 +0000 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" , Mark Andrews Cc: 6man WG , james woodyatt Content-Type: multipart/alternative; boundary="f403045e678c7d4e260551f49533" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 00:16:49 -0000 --f403045e678c7d4e260551f49533 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 5:11 PM Mark Andrews wrote: > > In message <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com>, > "Manfredi, Albert E" writes: > > From: ipv6 mailto:ipv6-bounces@ietf.org On Behalf Of james woodyatt > > > > > This category of problem is about connecting *routers* (not hosts) > > > to the Internet via RFC 7278. > > > > Or hosts which operate like routers? > > > > > If all youre connecting at the hotspot are hosts, then why would you > > > need more than one subnet? > > > > My smartphone is assigned a single /64. It becomes a WiFi hotspot. So, de > > minimis, it creates a /65, for its WiFi interface, which any number of > > local WiFi users can use. Why not allow SLAAC for these WiFi users? And, > > why should we not allow, trivially, more flexibility? We now have these > > "whole home WiFi" systems. Why should that smartphone's /64 not be > > capable of supporting two or three local WiFi hotspots? > > > > Point being, all of this can be done with absolutely no consequences to > > the service provider, other than potentially some extra traffic volume on > > that one /64 facing the operator. But only if that 64-bit boundary is not > > fixed. > > Operators that only give you a single /64 have already STOLEN 65535 > subnets from you. The architecture document say to give each site > a /48. Addresses are handed to ISP's in the basis of /48's being > handed out to customers (you don't need to justify the space beyond > saying you are giving out /48s). It doesn't cost more to route /48 > than it does a /64. These is less than a cent difference per > customer to get a /48 vs a /64 from the RIRs. A cell phone is a > site border router the moment it turns on tethering. > > > > And if you need more than one subnet for some premium mobile hotspot > > > thingie I guess why not use more than one UE? > > > > Of course you can use multiple phones with /64s, if that's what you're > > asking? But not without going hat in hand to the operator. > > > > With IoT, example in cars, or in homes, no one can tell how many > > different subnets will make sense. If a home router is assigned a /64, it > > should be able to use that one /64 effectively, without constantly having > > to ask for more? And SLAAC should be available, for inside the home. Why > > not? Either that, or for sure, you will see NAT used with IPv6. > > > > Summary: I keep seeing people saying that they dont want to see NAT used > > with IPv6. In the next sentence, they say they want a fixed boundary at > > /64. The only way the two ideas can be compatible is if we have a prefix > > police that mandates some arbitrary max prefix length to be handed out, > > by operators, like /48. But operators keep saying no way, and they hand > > out /64s. Rock, hard place. (And, not to be ignored, then there's the > > hype of this limitless address space offered by 128-bit addresses, as if > > it's actually usable.) > > More it is the MBA that thinks saving a couple of dollars on RIR > fees by only requesting just enough space to support a /64 per > customer is a good idea without looking at the entire picture. Yes, > it adds up when there are millions of customers. Charging 5 cents > extra per month would cover the additional costs many times over. That MBA does not exist. I have never seen RIR fees be a factor in subnet size for ipv6. > > > Bert > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > 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 > -------------------------------------------------------------------- > --f403045e678c7d4e260551f49533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jun 14, 2017 = at 5:11 PM Mark Andrews <marka@isc.org<= /a>> wrote:

In message <1c0deb36b1534ca58ad275b80706c1c1@XC= H15-06-11.nw.nos.boeing.com>, "Manfredi, Albert E" writes:=
> From: ipv6 mailto:ipv6-bounces@ietf.org On Behalf Of james woodyatt
>
> > This category of problem is about connecting *routers* (not hosts= )
> > to the Internet via RFC 7278.
>
> Or hosts which operate like routers?
>
> > If all youre connecting at the hotspot are hosts, then why would = you
> > need more than one subnet?
>
> My smartphone is assigned a single /64. It becomes a WiFi hotspot. So,= de
> minimis, it creates a /65, for its WiFi interface, which any number of=
> local WiFi users can use. Why not allow SLAAC for these WiFi users? An= d,
> why should we not allow, trivially, more flexibility? We now have thes= e
> "whole home WiFi" systems. Why should that smartphone's = /64 not be
> capable of supporting two or three local WiFi hotspots?
>
> Point being, all of this can be done with absolutely no consequences t= o
> the service provider, other than potentially some extra traffic volume= on
> that one /64 facing the operator. But only if that 64-bit boundary is = not
> fixed.

Operators that only give you a single /64 have already STOLEN 65535
subnets from you.=C2=A0 The architecture document say to give each site
a /48.=C2=A0 Addresses are handed to ISP's in the basis of /48's be= ing
handed out to customers (you don't need to justify the space beyond
saying you are giving out /48s).=C2=A0 It doesn't cost more to route /4= 8
than it does a /64.=C2=A0 These is less than a cent difference per
customer to get a /48 vs a /64 from the RIRs.=C2=A0 A cell phone is a
site border router the moment it turns on tethering.

> > And if you need more than one subnet for some premium mobile hots= pot
> > thingie I guess why not use more than one UE?
>
> Of course you can use multiple phones with /64s, if that's what yo= u're
> asking?=C2=A0 But not without going hat in hand to the operator.
>
> With IoT, example in cars, or in homes, no one can tell how many
> different subnets will make sense. If a home router is assigned a /64,= it
> should be able to use that one /64 effectively, without constantly hav= ing
> to ask for more? And SLAAC should be available, for inside the home. W= hy
> not? Either that, or for sure, you will see NAT used with IPv6.
>
> Summary: I keep seeing people saying that they dont want to see NAT us= ed
> with IPv6. In the next sentence, they say they want a fixed boundary a= t
> /64. The only way the two ideas can be compatible is if we have a pref= ix
> police that mandates some arbitrary max prefix length to be handed out= ,
> by operators, like /48. But operators keep saying no way, and they han= d
> out /64s. Rock, hard place. (And, not to be ignored, then there's = the
> hype of this limitless address space offered by 128-bit addresses, as = if
> it's actually usable.)

More it is the MBA that thinks saving a couple of dollars on RIR
fees by only requesting just enough space to support a /64 per
customer is a good idea without looking at the entire picture.=C2=A0 Yes, it adds up when there are millions of customers.=C2=A0 Charging 5 cents
extra per month would cover the additional costs many times over.

That MBA does not exist.= =C2=A0 I have never seen RIR fees be a factor in subnet size for ipv6.=C2= =A0




> Bert
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0INTERNET: mark= a@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--f403045e678c7d4e260551f49533-- From nobody Wed Jun 14 17:23:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31027127241 for ; Wed, 14 Jun 2017 17:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAtihZ51CLiT for ; Wed, 14 Jun 2017 17:23:53 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 26BBA129435 for ; Wed, 14 Jun 2017 17:23:53 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id y77so2150042ioe.3 for ; Wed, 14 Jun 2017 17:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lcCJosv2A/91Sq+wl03nw73IDRqN7Ci4TmQQn/XBTtI=; b=qlSJy9jIdrIdDCEfS1nfVRg9fotor06l/x8QcdgfbCS9xl5JwKi3OUwzasc3r72cMu BaZdyVFcVX1EIaGJMdpUbpVR8r7qQt/nDQ///8HxC48iGgH6Xykp6n90QQhbws8K58Tm br6nMqF/01aecSJtUe9JgIOOYMH9/3Ws81/Q8KGaQhtcXBG1Gtpqpan8CW65X+GV/MQY zoWhWYxftRK+aFudQ9+rIynvwIjt2YEsnB75rP1/nOYE9DVvhl4iVSUvGUSU7NE5XgTQ VGI+txMfFtDSDzKD8cL/U8QDhLv8mjXgmAUuMLFFcAF4CRkCKqvVSOUlWVoPwrxDQDeK K/5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lcCJosv2A/91Sq+wl03nw73IDRqN7Ci4TmQQn/XBTtI=; b=f/8rYBlxOj++r4a9D5NBWgolN7fNV/ciqIhbeec7ovVF96c84j91PallUr9HVER+Lf /IZc6CdqdRFpPfcJMZYAkkbNRW8JRPsuvLbmafijILj/LcmkJ/qYFoBag+DBXIObpk26 iYxRxTj8lEkHnYNLl5GAq8uHArTMLkov6uXyl5mJEOa9jnreu/OJxnKQ5V5ax2iJXyw6 Mn9BBR1MreAOYfA+boHmf1OU+iOrfiQJqCgE4EzW+RCRlt8zEPO0QdfFOiUDwYCc/fRI mj7psPVa1X8F+pP7bgdlXP3y4Pj+Hoz/VRa6ntyN4AV/y7kl3SftyYSRlLdQJSgIvctg Ccuw== X-Gm-Message-State: AKS2vOzYW8Eeyx8PFIFC0CtWU+pAI2iNEH26Xh0Xdu1P/0499U1p/zTm saion31QXCj8SQ== X-Received: by 10.107.34.206 with SMTP id i197mr2776122ioi.67.1497486232450; Wed, 14 Jun 2017 17:23:52 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g198sm774599itb.29.2017.06.14.17.23.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 17:23:51 -0700 (PDT) From: Bob Hinden Message-Id: <2F82AC9F-763D-428D-9D23-E73948D1EE8A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_64EEAC30-C68E-414B-A433-4D1840929D4A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land Date: Wed, 14 Jun 2017 17:23:48 -0700 In-Reply-To: Cc: Bob Hinden , IPv6 List To: Brian Carpenter References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 00:23:55 -0000 --Apple-Mail=_64EEAC30-C68E-414B-A433-4D1840929D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 14, 2017, at 5:14 PM, Brian E Carpenter = wrote: >=20 > On 14/06/2017 19:11, Lorenzo Colitti wrote: >> On Wed, Jun 14, 2017 at 12:36 PM, Tom Herbert = wrote: >>=20 >>> Can you tell me what the killer app is on a smartphone that require >>> 2^64 addresses? >=20 > The question is slightly premature. Try: >=20 > "What is the killer use case on a smartphone that requires > many addresses that are essentially unguessable because > they include 64 pseudo-random bits?" >=20 > Lorenzo's answer below covers this case too, and he's right, if > we believe that miscreants in the far future may have enough > computing power to search a very large space, even if the use > case only needs a few thousand addresses. >=20 > (64 is only a parameter, even in this sub-sub-sub-thread, but it's > the right order of magnitude - privacy concerns require several > tens of bits even with today's computing power.) >=20 > BTW, I aoplogise to the WG for having provoked this thread. My > intention was only to remind people that these tussles are > a sign of success for IPv6. Good point. It=E2=80=99s not like current specification don=E2=80=99t = work. For example, Google is showing a peak of ~19% of their traffic is = IPv6. Bob --Apple-Mail=_64EEAC30-C68E-414B-A433-4D1840929D4A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZQdOWAAoJEK7rdBF357uoxD4H+QGi3B8cYsjD5dejPMY1ZK7B Z6w4YO/NIYwbdfZrpf/Gxakx4km3zPDSXPDfoBgptqQTH312DDZ7igHNjRTjku32 vmY/WjG/qsfn04umHXY4CBkGoBXyTUjOatsjbOXU2/UbRdSXK2yOgk0VBtP21kaD oh+Ckac7Nv9jgKsXV/jpJhXbdZUcq43d4RQD8UZIKHBj8GZlNWBIW3sTwZ2cdW0/ qG43gzfI8H2KuK7IGh2A0qFBU+UKJDS0+MWfxLTb2ph2cV4wbHTS485l9J6ago/3 E7fbN5VDp0w6ODAil4T/1rzxHfYUqMPg2ppRjzN+/aGlAb11/yu0fFxvRQLLz3Q= =gjQ/ -----END PGP SIGNATURE----- --Apple-Mail=_64EEAC30-C68E-414B-A433-4D1840929D4A-- From nobody Wed Jun 14 18:00:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA728126DC2 for ; Wed, 14 Jun 2017 18:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5nyGmZD3GL1 for ; Wed, 14 Jun 2017 18:00:34 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 13F3D126CC7 for ; Wed, 14 Jun 2017 18:00:33 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 68so56766uas.0 for ; Wed, 14 Jun 2017 18:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KCJtiO4qUGtjoFUnT76MNcVpkMGMOZAoTBHFPhJ2Lts=; b=BpAbYr0IvmAu4PEZMkf53woUN0fMI9+RYlARnOBo2Hcu5o66Ks3tGlyedjA2+//orB HroCHy6wzVymH5ASrD7sZXGUECln5o0knoKq0foO23+0x6Ck8FskufDWjS+3CmlIyywf n9KKeH2VIiAKsbSQpGc/9sJbzI2vyugCqHtWEaxKpRHrucmvHdPbZp/oNPsG9U9DvcGk IyjzccH4OhKF8jj4hn1NTP9z1N1jgygCdsdzlpIr3Q4XxF/ZLSqtGXIm5tacXOSVKWm2 YgMtV3eNDnANE0BsoxgT68eJPGFbkwNbhSBqcOR8VONRF14bWXrQcjj0SbDTOt8REGBn UQGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KCJtiO4qUGtjoFUnT76MNcVpkMGMOZAoTBHFPhJ2Lts=; b=SPpEv2v8+B+QHEktYaRnhJAih74Ro6W0HSeEVgiN87o3wp0ZyPdhycNX3Vb1XnSNyQ nrEoCMZubrM685U16Xv+Fj+F7P10fhNzttbVmrPn5mJWUXPllXhHdKuBM0wAr1NmgY/6 vouU+U7GPOhp2uoDWQJW/gdbMHYzmgnEGiCV9Xqwsil7N3FHqsEfrLGwu30SVl4zNAk6 uC1Ulm+trvSV9PFj8n6sZBEgCGcvNKtZmdBbal/KpHd7kDmJpXwvhwKMjbnpKYk6aARf veR0Vgxs9x+q8gCG3hsvh+idLM6+sv1wyKnUvln0RhFXo+xB3hnyQ/h0/VEhlJbZZpJl Efzw== X-Gm-Message-State: AKS2vOwCZ2gA+DTSBVBAWAmCeiBw/xqRVXH517L1MJZGUjxkSCwF4sSm xpey4gltkFucxx1MkQVrowchi5MzCQaj X-Received: by 10.176.83.16 with SMTP id x16mr1948383uax.11.1497488432783; Wed, 14 Jun 2017 18:00:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 18:00:12 -0700 (PDT) In-Reply-To: <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 15 Jun 2017 10:00:12 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: "otroan@employees.org" , 6man WG Content-Type: multipart/alternative; boundary="94eb2c18f1ac182b330551f5325f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 01:00:36 -0000 --94eb2c18f1ac182b330551f5325f Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of > otroan@employees.org > > > What _problem_ does changing the 64 bit boundary solve for _you_? > > A category of problems, such as creating hotspots with smartphones that > have been allocated a single /64. That works today on all major smartphone OSes. And the situation is actually the opposite: the only reason it works today is that phones *already had* a /64 instead of a /128. If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise > to cripple non-/64 solutions by artificially mandating that SLAAC be only > possible with /64s. The smartphone hotspot example is one in which a > non-/64 SLAAC would work great. And there's simply no reason to state that > SLAAC can only work with /64s. It's not true! > SLAAC doesn't work unless the network provides enough address space to make collisions vanishingly unlikely. --94eb2c18f1ac182b330551f5325f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E <albert.e.manfr= edi@boeing.com> wrote:
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ie= tf.org] On Behalf Of otroan@emp= loyees.org

> What _problem_ does changing the 64 bit boundary solve for _you_?

A category of problems, such as creating hotspots with smartphones t= hat have been allocated a single /64.

That = works today on all major smartphone OSes. And the situation is actually the= opposite: the only reason it works today is that phones *already had* a /6= 4 instead of a /128.

If = part of what makes IPv6 wonderful is SLAAC, then I don't think it's= wise to cripple non-/64 solutions by artificially mandating that SLAAC be = only possible with /64s. The smartphone hotspot example is one in which a n= on-/64 SLAAC would work great. And there's simply no reason to state th= at SLAAC can only work with /64s. It's not true!
<= br>
SLAAC doesn't work unless the network provides enough add= ress space to make collisions vanishingly unlikely.
--94eb2c18f1ac182b330551f5325f-- From nobody Wed Jun 14 23:18:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6399D129AF9 for ; Wed, 14 Jun 2017 23:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKX8-Q3uYy9H for ; Wed, 14 Jun 2017 23:18:05 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 2F524129B08 for ; Wed, 14 Jun 2017 23:18:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5F6I1Sc035743 for ; Thu, 15 Jun 2017 08:18:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 69B81200DE0 for ; Thu, 15 Jun 2017 08:18:01 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5E1EE200C0F for ; Thu, 15 Jun 2017 08:18:01 +0200 (CEST) Received: from [132.166.84.66] ([132.166.84.66]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5F6I0Gf007657 for ; Thu, 15 Jun 2017 08:18:00 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: ipv6@ietf.org References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> Date: Thu, 15 Jun 2017 08:18:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 06:18:07 -0000 Le 15/06/2017 à 03:00, Lorenzo Colitti a écrit : > On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E > > > wrote: > > -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org > ] On Behalf Of otroan@employees.org > > >> What _problem_ does changing the 64 bit boundary solve for _you_? > > A category of problems, such as creating hotspots with smartphones > that have been allocated a single /64. > > > That works today on all major smartphone OSes. If this refers to '64share' - that's an INFORMATIONAL way of of working. It has drawbacks. If OS means OS distribution - that's that particular distribution's advantage, or inconvenient. An OS like linux can be distributed as Android (run the non-scalable 64share, avoid DHCP-PD) or can be distributed as Legato (dont run 64share and run the scalable DHCP-PD). Please be precise with respect to 'OS'. > And the situation is actually the opposite: the only reason it works > today is that phones *already had* a /64 instead of a /128. They may have it, in a way. So, if that category of problems is not sufficient, a similar category of problems is other major IoT or M2M devices that run other major OS distribution than smartphones. In the automotive market these small routers are called for example on-board routers and road-side units. Similar small routers are in the smart building and smart city markets. These need to connect to cellular networks and offer connectivity to more other devices than a smartphone does. Alex > If part of what makes IPv6 wonderful is SLAAC, then I don't think > it's wise to cripple non-/64 solutions by artificially mandating that > SLAAC be only possible with /64s. The smartphone hotspot example is > one in which a non-/64 SLAAC would work great. And there's simply no > reason to state that SLAAC can only work with /64s. It's not true! > > > SLAAC doesn't work unless the network provides enough address space > to make collisions vanishingly unlikely. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jun 14 23:25:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25D9129AF9 for ; Wed, 14 Jun 2017 23:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqj1cky9Jg9j for ; Wed, 14 Jun 2017 23:25:35 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C488D1294C7 for ; Wed, 14 Jun 2017 23:25:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id 63so1788998ywr.0 for ; Wed, 14 Jun 2017 23:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DWSb1ibicz1QqeL6ROTze0Z2M8kvx05n5scrtnTzVoY=; b=YJMs9c96gMSAPsWsDdi3LB167JcsPfVC7XL8YoDt8q76Z+wnpLd/LWNOzKjdzc1/8I U8Z5pD0YqE6Vnl+n58O557uGEEagnG0LLogjyfi87F1EdyTq7q3Nvetz2Um2lEOR4hT+ BIaoIvsKJLSEk4cl7o7VJBoQDucaA7ovniVAnl0UNHX/APc0BhvZ/fXHuR0Q8gBau2a7 zD+2parE+l9gdGwB5wwrzxeZ+jS37fXpGvIT1oNe6vgMaOtCXv66G0vcHqZdgfzLvGtj O+zQ5NEh+E62nZUTy6HYzb7BvsZoOGKLWZ+9WZ/J8NASZIvGb8x/omDJX0iq2pjKHkeO bL3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DWSb1ibicz1QqeL6ROTze0Z2M8kvx05n5scrtnTzVoY=; b=YyzJAfjWEwsMLw6S9+t86uqXjHv3SqOxU+GfhkWsAcZRy5HeBI710VjgBohbXFI1mB wASzn5XfKLzCaKsB6CkG78eCu91UeJBMl3V3PE3guOvX66bSEa0lyEs3iOABSYTdCWyA dEr+1VNAXStoDq28XTkkr4zIzRtu3Sk+M/KxpSjlqrhQyIizIphNPQPyRhf8BCBzLOz5 ZdG9aLTdLidqpzW26ajW3xMwtY09LTo60q7LX4Lbij4nUoWnfyIhegHT1KeILaCvR7sv xs+Gz4VguLOJEKHcn4+9mRf91XLILo7+t6IhpVItdzPuUku48C6LTSippKGYtGkDcV16 Zd+w== X-Gm-Message-State: AKS2vOz0hWO75e4eIY2VDdt7BquaNSnrFatf3gRgJqgscvxMw1FmL9HR fFOFp6OlH2hlhNzfsWBhBVXOLU+0X7bh X-Received: by 10.129.130.71 with SMTP id s68mr3285391ywf.42.1497507933883; Wed, 14 Jun 2017 23:25:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Wed, 14 Jun 2017 23:25:13 -0700 (PDT) In-Reply-To: <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> From: Erik Kline Date: Thu, 15 Jun 2017 15:25:13 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Alexandre Petrescu Cc: IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07c8a477c6960551f9bc03" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 06:25:37 -0000 --94eb2c07c8a477c6960551f9bc03 Content-Type: multipart/alternative; boundary="94eb2c07c8a472fcd50551f9bc49" --94eb2c07c8a472fcd50551f9bc49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 15 June 2017 at 15:18, Alexandre Petrescu wrote: > > > Le 15/06/2017 =C3=A0 03:00, Lorenzo Colitti a =C3=A9crit : > >> On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E < >> albert.e.manfredi@boeing.com > >> wrote: >> >> -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org >> ] On Behalf Of otroan@employees.org >> >> >> What _problem_ does changing the 64 bit boundary solve for _you_? >>> >> >> A category of problems, such as creating hotspots with smartphones that >> have been allocated a single /64. >> >> >> That works today on all major smartphone OSes. >> > > If this refers to '64share' - that's an INFORMATIONAL way of of working. > It has drawbacks. > I think we should consider promoting 64share from informational to proposed standard. We have a not inconsiderable amount of experience doing IPv6 tethering with it at this point. --94eb2c07c8a472fcd50551f9bc49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 15 June 2017 at 15:18, Alexandre Petrescu <alexandre.pet= rescu@gmail.com> wrote:

Le 15/06/2017 =C3=A0 03:00, Lorenzo Colitti a =C3=A9crit :
On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E <albert.e.manfredi@boeing.com= <mailto:albert.e.manfredi@boeing.com>>
wrote:

-----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>] On Behalf Of otroan@employees.org <mailto:otroan@employees.org>
What _problem_ does changing the 64 bit boundary solve for _you_?

A category of problems, such as creating hotspots with smartphones that hav= e been allocated a single /64.


That works today on all major smartphone OSes.

If this refers to '64share' - that's an INFORMATIONAL way of of= working.=C2=A0 It has drawbacks.

I thi= nk we should consider promoting 64share from informational to proposed stan= dard.=C2=A0 We have a not inconsiderable amount of experience doing IPv6 te= thering with it at this point.
--94eb2c07c8a472fcd50551f9bc49-- --94eb2c07c8a477c6960551f9bc03 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQghJXSMh9hHZPU/ZT5crWRKAeXSV7h2Wrw F8NeFAfAPUgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjE1 MDYyNTM0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBALfK7KNWJYDfIu9KM2z3FW8N6uBoEBX14IKQSy1tE8hS2b4VzU1f VknDNDP4DCIlEo90CzYDGkw1kQfrtb3qpMnLJk3kf4FXhlBBbf/zjZmT0NO+MoLULv64HkMw8UBD KRhFTjlN570eenG7ZV/ymj4+vrIa9TNlhIgReH06k7r+7kXnIEeq+oVCe7iFZunoKkKR6ugcGOuS RDQmMWeymRLq5kD+YWwi9aTJqcUuuxCNlMazwJwEY+RlS767FvDk0RtTpD2CnCKeLljBLR4oaMTe CVQ+yMXAAhjjDGnm4gK3iWwD9IDwEnMJtD+rpu6Yc2SKYRjo3VU+2UFNZhxcK0o= --94eb2c07c8a477c6960551f9bc03-- From nobody Wed Jun 14 23:27:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F113129B07 for ; Wed, 14 Jun 2017 23:27:00 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24iHoDuAjECo for ; Wed, 14 Jun 2017 23:26:58 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 865DC1294C7 for ; Wed, 14 Jun 2017 23:26:58 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g40so2846795uaa.3 for ; Wed, 14 Jun 2017 23:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J+5YMb+CdpJUMmUg2/mh+mi/LU2SxEs6wGseHTHrIew=; b=tG/zL83dFfZX4XaewGx7d5SurkgjQSuVKgxArLXId9qOsBMmL1PGXTdPh9FXWvLSSN 8357S9qLAY62x9MuL6BGTTR9juKJ2abGbTtDfcitRmPwxWV9z0BuL6/GTemVqPLUoFSX TJpQGyW2pOvRYRJqaHCk9WqsIBVQWTCo120rD7QI6L7TIewP/8MIO98nKOEIJGiKd3Mw 2l2Ghq/4XcyRXF+m+D5zPPmUppDH0nY+j3+Nxy5z0i1EKNQb9iCErFlHgtI/be78onTA UmbB26LzHU8oEoDz/+kc92wOiPRiPqep7HayYR9LGJ/QkZ1SMOXUUnAfNU3wF2sPxKUN Pmpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J+5YMb+CdpJUMmUg2/mh+mi/LU2SxEs6wGseHTHrIew=; b=lNwwJQyNmEO1yPlEi54YJynoXc8fkWr07adx/7exDKLADGyigW/Ba8ihxed0QPdQtC uLE2DUg07KGUcfJM8vHCYtGrc1cdDLFIfHcTFijf5dznpotBjPqtyCIQIWFpH8KSYB8c SHy6TtYhFjaK3wXkKhQOPafD+rmtBVQ5CKYlz5LflXJXwJKxMp4LjXTosRi8g8d9wxn7 GuEH4rWSsppRVfZmDgDL3bk4LrNBS0JxZ0rpwgAPm/nB4cJ1DA95s2EQ1H0pB3/EG4Z3 cu4xxdA7PsNLhqKRAoyggGmXY6ltJzCaI+jnkrTK3CPFS3+Rc8c8hmfMUnj1dPqmOeQf VXIg== X-Gm-Message-State: AKS2vOytkZ56LZbPAkWPik8v28zVgq+CNgBmSUvz4jfpUGeyWjHF6Qj0 fMYpefRYOnhXcc3vIM9MQUQi5tYLhInU X-Received: by 10.176.9.213 with SMTP id e21mr471633uah.52.1497508017487; Wed, 14 Jun 2017 23:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 23:26:36 -0700 (PDT) In-Reply-To: <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> From: Lorenzo Colitti Date: Thu, 15 Jun 2017 15:26:36 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Alexandre Petrescu Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403043eeca86e9d470551f9c156" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 06:27:00 -0000 --f403043eeca86e9d470551f9c156 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 3:18 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > A category of problems, such as creating hotspots with smartphones that >> have been allocated a single /64. >> >> That works today on all major smartphone OSes. >> > > If this refers to '64share' - that's an INFORMATIONAL way of of working. > It has drawbacks. > > If OS means OS distribution - that's that particular distribution's > advantage, or inconvenient. > > An OS like linux can be distributed as Android (run the non-scalable > 64share, avoid DHCP-PD) or can be distributed as Legato (dont run 64share > and run the scalable DHCP-PD). > > Please be precise with respect to 'OS'. That's why I said all "major" smartphone OSes. --f403043eeca86e9d470551f9c156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 15, 2017 at 3:18 PM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
A category of problems, such as creating h= otspots with smartphones that have been allocated a single /64.

That works today on all major smartphone OSes.

If this refers to '64share' - that's an INFORMATIONAL way of of= working.=C2=A0 It has drawbacks.

If OS means OS distribution - that's that particular distribution's= advantage, or inconvenient.

An OS like linux can be distributed as Android (run the non-scalable 64shar= e, avoid DHCP-PD) or can be distributed as Legato (dont run 64share and run= the scalable DHCP-PD).

Please be precise with respect to 'OS'.

=
That's why I said all "major" smartphone OSes.
--f403043eeca86e9d470551f9c156-- From nobody Thu Jun 15 02:20:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0FF12D574 for ; Thu, 15 Jun 2017 02:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lj_LAQRUU0a for ; Thu, 15 Jun 2017 02:20:25 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id AF313129BBD for ; Thu, 15 Jun 2017 02:20:23 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dLQwv-0000HYC; Thu, 15 Jun 2017 11:20:21 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Thu, 15 Jun 2017 10:00:12 +0900 ." Date: Thu, 15 Jun 2017 11:20:19 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 09:20:27 -0000 >SLAAC doesn't work unless the network provides enough address space to make >collisions vanishingly unlikely. Indeed. So any RFC that makes smaller pseudo random IIDs possible has to have at least a section that analyses collision probabilities. And set a lower limit that is generally safe. Just leaving it to an operator to figure out that a /112 prefix will sometimes lead to an IoT device failing due to an address collision is extremely poor protocol design. From nobody Thu Jun 15 03:46:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9C2126B7E for ; Thu, 15 Jun 2017 03:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkE3GogTP8qd for ; Thu, 15 Jun 2017 03:46:09 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 83B60129B28 for ; Thu, 15 Jun 2017 03:46:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5FAk613043525; Thu, 15 Jun 2017 12:46:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BED33203F7E; Thu, 15 Jun 2017 12:46:06 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B06B7203F75; Thu, 15 Jun 2017 12:46:06 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5FAk6tE002126; Thu, 15 Jun 2017 12:46:06 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Erik Kline Cc: IETF IPv6 Mailing List References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> From: Alexandre Petrescu Message-ID: <11ae3894-7a94-3509-7218-1e386163dda1@gmail.com> Date: Thu, 15 Jun 2017 12:46:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 10:46:11 -0000 Le 15/06/2017 à 08:25, Erik Kline a écrit : > > > On 15 June 2017 at 15:18, Alexandre Petrescu > > wrote: > > > > Le 15/06/2017 à 03:00, Lorenzo Colitti a écrit : > > On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E > > >> > wrote: > > -----Original Message----- From: ipv6 > [mailto:ipv6-bounces@ietf.org > >] > On Behalf Of otroan@employees.org > > > > What _problem_ does changing the 64 bit boundary solve for > _you_? > > > A category of problems, such as creating hotspots with > smartphones that have been allocated a single /64. > > > That works today on all major smartphone OSes. > > > If this refers to '64share' - that's an INFORMATIONAL way of of > working. It has drawbacks. > > > I think we should consider promoting 64share from informational to > proposed standard. We have a not inconsiderable amount of experience > doing IPv6 tethering with it at this point. I think that promotion will not work, because despite large experience it still does not scale to more. On the contrary, I think Android and Apple IOS backers should promote DHCP-PD. Alex From nobody Thu Jun 15 05:44:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65F8129C27 for ; Thu, 15 Jun 2017 05:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGwBCqMkQYN2 for ; Thu, 15 Jun 2017 05:43:58 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064A4129C21 for ; Thu, 15 Jun 2017 05:43:57 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y70so6202998vky.3 for ; Thu, 15 Jun 2017 05:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K0zIJ7LygIhY1RocdMFW1ePA+nMrKc8IoGi6P/NfR+0=; b=qc6pAaD1z+ziTI/RGgOZMK3bvXk53hJj8evV1VGyFfs//R6HZp8/XdIrXqcpFuYT8x e0bl09DzDZZ1WxVC2Tv3KfbIoA2IYQ0V4lp4BEz4guEkQ2PiTnYmvB2WXxl/5oykAKDM Q5JelAbBz9eKakhdq1Q8uCjr0lg36Cm1DdOPYXqSxbC7WnzqS30yUfhnImS9vnKd4Ota mB7C635FkIknh1mLfj0cuR1HrXgvrN0EBNb+i11aRzP0Im2Uh/5b5cdgIhkpuT0YXK+h fpIKMoNrz5E984/T2DIX7PgC3swo18YBXaJ7HLcrfTz3L8NZUntriOZqf/zPM7zVE0CA QkTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K0zIJ7LygIhY1RocdMFW1ePA+nMrKc8IoGi6P/NfR+0=; b=jkddprRgE+ds97lZgYM3AG9RnfaYSyiF/1QqRj9XJ3XsIYSK/ooPz8cTxECPHr0PIN J6XM6u0rqrUq9Yt28x73c5axiZaxOIukzBgUPIwYI5azjev4jXpSU1MvVMa4BY4QJbOz qzy0P+uPTAOCsyg5B4sy47/JNia93LPpHAOshlDk1MSixP3Sb6z6dgzkMqD1aAdlJoGU fhaijngysWV/cITa2wrF0XgIGdM7/50JYmun0r193T+v9d1k8aXqoFhOOwHqnvmqipDl AavH2OeGD8/hytYWIv7kr5E5rnSzeSPoBPayMuTVkqkGZPViYjqrp3Fus95lpNJmmm6j 6DJA== X-Gm-Message-State: AKS2vOx42kBfBRTYy8x1aAvh7KlxkH/wiqYi7PUWhjK2JzrZ1In5CbV3 Nw/64cfWPOQnAMLS6IKwVmgY8EhnVd7Z X-Received: by 10.31.236.193 with SMTP id k184mr2929284vkh.96.1497530636853; Thu, 15 Jun 2017 05:43:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 15 Jun 2017 05:43:35 -0700 (PDT) In-Reply-To: <11ae3894-7a94-3509-7218-1e386163dda1@gmail.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> <11ae3894-7a94-3509-7218-1e386163dda1@gmail.com> From: Lorenzo Colitti Date: Thu, 15 Jun 2017 21:43:35 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Alexandre Petrescu Cc: Erik Kline , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c08b3d2a70df50551ff058c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 12:44:01 -0000 --94eb2c08b3d2a70df50551ff058c Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 7:46 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > On the contrary, I think Android and Apple IOS backers should promote > DHCP-PD. > Are there any mobile carriers that support this today, or plan to support this in the future? --94eb2c08b3d2a70df50551ff058c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 15, 2017 at 7:46 PM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
On t= he contrary, I think Android and Apple IOS backers should promote DHCP-PD.<= br>

Are there any mobile carriers that supp= ort this today, or plan to support this in the future?=C2=A0
--94eb2c08b3d2a70df50551ff058c-- From nobody Thu Jun 15 06:34:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5A012EB9E for ; Thu, 15 Jun 2017 06:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO0CwsWzoeiW for ; Thu, 15 Jun 2017 06:34:44 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 4F46612EB9A for ; Thu, 15 Jun 2017 06:34:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5FDYfRo041544; Thu, 15 Jun 2017 15:34:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF9D1201620; Thu, 15 Jun 2017 15:34:41 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A6DD92041E9; Thu, 15 Jun 2017 15:34:41 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5FDYfg2026662; Thu, 15 Jun 2017 15:34:41 +0200 Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: Erik Kline , IETF IPv6 Mailing List References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> <11ae3894-7a94-3509-7218-1e386163dda1@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 15 Jun 2017 15:34:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 13:34:46 -0000 Le 15/06/2017 à 14:43, Lorenzo Colitti a écrit : > On Thu, Jun 15, 2017 at 7:46 PM, Alexandre Petrescu > > wrote: > > On the contrary, I think Android and Apple IOS backers should > promote DHCP-PD. > > > Are there any mobile carriers that support this today, or plan to > support this in the future? Let's think about that and be back soon. Alex From nobody Thu Jun 15 09:35:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE99129A97 for ; Thu, 15 Jun 2017 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDdXROZv-ddD for ; Thu, 15 Jun 2017 09:35:20 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7865712E872 for ; Thu, 15 Jun 2017 09:35:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:fa1e:dfff:fedd:15e] (unknown [IPv6:2001:470:1f09:baa:fa1e:dfff:fedd:15e]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 1A4E21A071 for ; Thu, 15 Jun 2017 16:35:08 +0000 (UTC) From: Simon Hobson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Hitting the tech news Message-Id: Date: Thu, 15 Jun 2017 17:35:07 +0100 To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 16:35:22 -0000 Decent writeup, and some "interesting" comments = https://www.theregister.co.uk/2017/06/15/carriers_risk_being_railroaded_on= _ipv6_consultant_warns/ > Small carriers aren't showing up to IPv6 standards chats, consultant = warns > And that means useful stuff could be left out of customer premises = equipment >=20 > Smaller ISPs are dealing themselves out of discussions about the = inevitable transition to IPv6, a Spanish consultant warns, and could = find their future defined by large telcos. >=20 > Frustrated at their indifference, Jordi Martinez of Consulintel has = appealed for just a bit more enthusiasm (and participation) from ISPs in = IPv6 decision-making. > ... From nobody Thu Jun 15 09:42:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E09912EA76 for ; Thu, 15 Jun 2017 09:42:25 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohn_3JF5BkSr for ; Thu, 15 Jun 2017 09:42:23 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C358812EAA4 for ; Thu, 15 Jun 2017 09:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497544941; x=1498149741; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=qqBxCtGWWMNCphaOFrfJpIG/7 hV7xDhkIxwqf7Itb1U=; b=SjVVhvGxJLWc/hWFemJuqNBPJe3BEcDdKgVpiNHbY +M+W1jnqh8GCzwYwG9CioyqSUAzLhyYMkOe7MFTqjg1xzfN7qaf1ts/isSDJB8IK 55zdB+/8a4RDA71UoZlJB2j4ZEi2xbzWpD9XFWXOZeFdhbIhvzxBsk/AUGdSjdx2 5U= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=C8t4Yrc9v6JTwQ+T+JF3wP80nxrKKxhbNfbfp6U0+gBb5GugD0Drkd2BW7j6 YIIpGWrgcHVd3aRnyIjfEE2cg4U1J8fiJf2GxvJ0oi6Ae9bXpLth0TM5p +530UQDzUg4Ihf9aCRyVKAAeeN6VORBy+NycXzUz0p4UJ3s9enrsXI=; X-MDAV-Processed: mail.consulintel.es, Thu, 15 Jun 2017 18:42:21 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 15 Jun 2017 18:42:19 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005451762.msg for ; Thu, 15 Jun 2017 18:42:19 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170615:md50005451762::YX0K2zaZIa/MuuMl:00008yvC X-Return-Path: prvs=133989d359=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 15 Jun 2017 18:42:14 +0200 Subject: Re: Hitting the tech news From: JORDI PALET MARTINEZ To: 6man WG Message-ID: <7B18897F-5B90-4BF8-AE87-1F116A825F27@consulintel.es> Thread-Topic: Hitting the tech news References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 16:42:25 -0000 I guess this is due to my recent call for more active participation thru NO= G mailing lists =E2=80=A6 https://mailman.nanog.org/pipermail/nanog/2017-June/091393.html The author of the article changed my family name =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de Simon Hobson Responder a: Fecha: jueves, 15 de junio de 2017, 18:35 Para: 6man WG Asunto: Hitting the tech news Decent writeup, and some "interesting" comments =20 https://www.theregister.co.uk/2017/06/15/carriers_risk_being_railroaded= _on_ipv6_consultant_warns/ =20 > Small carriers aren't showing up to IPv6 standards chats, consultant = warns > And that means useful stuff could be left out of customer premises eq= uipment >=20 > Smaller ISPs are dealing themselves out of discussions about the inev= itable transition to IPv6, a Spanish consultant warns, and could find their= future defined by large telcos. >=20 > Frustrated at their indifference, Jordi Martinez of Consulintel has a= ppealed for just a bit more enthusiasm (and participation) from ISPs in IPv= 6 decision-making. > ... =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Jun 15 10:05:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7235812EAA1 for ; Thu, 15 Jun 2017 10:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQGsY1OemImG for ; Thu, 15 Jun 2017 10:05:00 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 538EA12E04B for ; Thu, 15 Jun 2017 10:05:00 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id g40so11936687uaa.3 for ; Thu, 15 Jun 2017 10:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nefmu8ujn+CUeUSrLevL1fEgI2yY3LM2lVvbp+QoJTE=; b=z+x4kPwKhTyCJDuOxtF+mCnK9nb7zb8+fu/IpYcAA+sy7tdkMkO8ILwoQlOQ116f87 QY9q3Xyp9RyZ2NuBnBwrEXHaqy9dn3NnlZ/l4kjBoB8aWev0ZB6hOVYF9W4bxbxcSF1I C5NEGqWAeH85Xag/T9ndL3wMbqEFcS8u/QzOVNjTJbPZRr3OftyJRgvMpIL4qnSj4CZG mLKdWr8EDi1EZ5FehuwJb+Kl0WakEfbgWvB5XglGF+olzZDbJYcBxRoXaVcRVJTD5NHQ JyMJzYC3WIAspgd9LOYTiIlXyHoh3wMFDls0ZeTyDWj0SusAj6AbJLvB9r+PATTTUO7I rbdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nefmu8ujn+CUeUSrLevL1fEgI2yY3LM2lVvbp+QoJTE=; b=UONnMsfxDV7iOy1IbRwriG+auUI1f8eCcstxfxurhVxhWq9RGQ+NArrXd+FmImz6nu dbtkI+/vVo38YvI2Hrjy/ike4QAL8nfhKtaE1CCFkHMsrfpoXKjSMSDsK8vrMW7wbCNb AB103CZreZrEbnXOE+FlktQyw2zP+YA4qceq1/NsGaOYXVyz1Msc3u6gn6XRMawazvKv MQxkME7vWMfJV3kcwhLFp8qTIBlptKEKmn4HKK3h4uxqzwAFyF3ijkP+XNrxCGSk8pg7 DiEwFCwdrtxHMJXzsrNgl8a+JvkJHm0oZm39uZG2Q/wJ+cqB7Lg9DOtNd6KX5Zo7FN41 apgw== X-Gm-Message-State: AKS2vOwlzjKS6Xv9Fwu5hukw2o5H7Y2waf78JGAUslWjlFLjDyChY7Gn QcJvOeRPsoi4of+WJTQgnShErjQSluFFKs1mHg== X-Received: by 10.159.59.143 with SMTP id r15mr2343712uah.110.1497546299280; Thu, 15 Jun 2017 10:04:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.198 with HTTP; Thu, 15 Jun 2017 10:04:18 -0700 (PDT) In-Reply-To: References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> From: Warren Kumari Date: Thu, 15 Jun 2017 13:04:18 -0400 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Philip Homburg Cc: ipv6@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:05:02 -0000 On Thu, Jun 15, 2017 at 5:20 AM, Philip Homburg wrote: >>SLAAC doesn't work unless the network provides enough address space to make >>collisions vanishingly unlikely. > > Indeed. So any RFC that makes smaller pseudo random IIDs possible has to > have at least a section that analyses collision probabilities. So, a couple of years ago I was doing some work with Juan Carlos and Dan Harkins in the IEEE on MAC Randomization (basically randomizing your (WiFi) MAC address to improve privacy / thwart pervasive monitors). There was some discussion on how many bits you would need to randomize to make it unlikely that multiple machines will independently choose the same address. I argued that if you randomize 24 bits, and have a stadium of ~2000 people, you will basically never get a collision. Dan disagreed, and so, in a fit of pique, I wrote an App Engine app to prove him wrong -- and achieved exactly the opposite. This is a birthday paradox problem, and you will get a collision once every ~9 times. I've just updated my little app and put it here: https://ipv6-collision-probability.appspot.com/ It's interesting to play with the numbers and see how likely a collision is, given a certain subnet length and number of hosts. > And set > a lower limit that is generally safe. > > Just leaving it to an operator to figure out that a /112 prefix will > sometimes lead to an IoT device failing due to an address collision is > extremely poor protocol design. Example: With a /112, and 100 hosts, you will have a collision every ~14 times... W > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jun 15 10:14:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CA2129329 for ; Thu, 15 Jun 2017 10:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJD9gQNdpRFp for ; Thu, 15 Jun 2017 10:14:50 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256941274D2 for ; Thu, 15 Jun 2017 10:14:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5FHEnnC001918; Thu, 15 Jun 2017 10:14:49 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5FHEgHS001841 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 15 Jun 2017 10:14:42 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Jun 2017 10:14:41 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 15 Jun 2017 10:14:41 -0700 From: "Manfredi, Albert E" To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS5O3iBqlt++AmEkC1QOEah1pM8KIkiz6AgAADVoCAAAFzAIAAA1KAgAAEk2CAAPkMAIAAWMsAgAA72hA= Date: Thu, 15 Jun 2017 17:14:41 +0000 Message-ID: <78390ea8f1d34bd685040ce9d876355a@XCH15-06-11.nw.nos.boeing.com> References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> In-Reply-To: <242f3221-9040-6f14-6011-3f854bb00642@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:14:52 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3UNCg0KPiBTbywgaWYg dGhhdCBjYXRlZ29yeSBvZiBwcm9ibGVtcyBpcyBub3Qgc3VmZmljaWVudCwgYSBzaW1pbGFyDQo+ IGNhdGVnb3J5IG9mIHByb2JsZW1zIGlzIG90aGVyIG1ham9yIElvVCBvciBNMk0gZGV2aWNlcyB0 aGF0IHJ1bg0KPiBvdGhlciBtYWpvciBPUyBkaXN0cmlidXRpb24gdGhhbiBzbWFydHBob25lcy4N Cg0KWWVzLCBJIHRoaW5rIHRoaXMgaXMgdGhlIGJyb2FkZXIgaXNzdWUuIFRoZSBjZWxscGhvbmUg ZXhhbXBsZSBpcyBhbiBlYXN5IHdheSB0byBpbGx1c3RyYXRlIHRoZSBwcm9ibGVtLCBhbmQgYXMg ZmFyIGFzIEkgY2FuIHRlbGwsIHRoZSBhdmFpbGFibGUgc29sdXRpb25zIHRyZWF0IHRoZSBsb3dl ciA2NCBiaXRzIGFzIGEgZmxhdCBhZGRyZXNzIHNwYWNlIGV4Y2x1c2l2ZWx5LiBXaGljaCBtYXkg YmUgZmluZSBmb3IgdGhlIHNtYXJ0cGhvbmUgaG90c3BvdCwgYnV0IGhhcmRseSBmaW5lIGFzIGEg c2NhbGFibGUgc29sdXRpb24uDQoNCklmIG5vdGhpbmcgZWxzZSwgYWxsb3dpbmcgZm9yIDQ4LWJp dCBJSURzIHNob3VsZCBiZSBhIG5vIGJyYWluZXIuIFRoZSBjb2xsaXNpb24gcG90ZW50aWFsIHdp dGggU0xBQUMgaXMgZXZlcnkgYml0IGFzIGxvdyBhcyBpdCB3YXMgd2l0aCBTTEFBQy1jdW0tRVVJ LTY0LCBhbmQgKmluIGVmZmVjdCosIHN1Y2ggYSBzb2x1dGlvbiB3b3VsZCByZXN0b3JlIHRob3Nl IHdhc3RlZCB1cHBlciAxNiBiaXRzIG9mIEVVSS02NCB0byB1c2VmdWxuZXNzLiBJdCBwcm92aWRl cyB0aGUgc2FtZSBiZW5lZml0IGFzIGFzc2lnbmluZyAvNDhzIHRvIGV2ZXJ5IGN1c3RvbWVyLCBi dXQgd2l0aG91dCB0aGUgZWdyZWdpb3VzIHdhc3RlIG9mIGFkZHJlc3Mgc3BhY2UuIEFuZCBpZiBJ SURzIGdldCBzaG9ydGVyLCB0aGVuIERBRCB3aWxsIGRldGVjdCBjb2xsaXNpb25zIG1vcmUgb2Z0 ZW4sIGJ1dCB0aGF0IGRvZXNuJ3QgaGF2ZSB0byBlbmQgdXAgaW4gZmFpbHVyZSBuZWNlc3Nhcmls eT8gVHJ5LCB0cnkgYWdhaW4uIE9yIHVzZSBESENQLVBELg0KDQpJJ20gbm90IHNvIHRha2VuIGJ5 IHRoZSBwcml2YWN5IGJlbmVmaXRzIG9mIGFuIG92ZXJseSBzcGFyc2VseSB1c2VkIGJsb2NrIG9m IDY0IGJpdHMuIE90aGVyLCBtb3JlIGFkZHJlc3Mtc3BhY2UtZWZmaWNpZW50IHRlY2huaXF1ZXMg Y2FuIGJlIHVzZWQgdG8gYWNoaWV2ZSB0aGF0IGdvYWwsIGxpa2UgdmVyeSBzaG9ydCBhZGRyZXNz IGxpZmV0aW1lcy4NCg0KQW55d2F5LCBhcyBJIHNlZSBpdCwgc3VjaCB1cGRhdGVzIGNhbiBiZSBp bnRyb2R1Y2VkIGdyYWNlZnVsbHksIGZ1bGx5IGJhY2t3YXJkIGNvbXBhdGlibGUuIEEgaG9zdCB1 cGRhdGVkIHRvIGdlbmVyYXRlIElJRHMgb2YgdmFyaW91cyBsZW5ndGhzIGNhbiBvYnZpb3VzbHkg YWxzbyBnZW5lcmF0ZSA2NC1iaXQgSUlEcyENCg0KQmVydA0KDQo= From nobody Thu Jun 15 10:23:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2068D129512 for ; Thu, 15 Jun 2017 10:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S86a5ehbOjKM for ; Thu, 15 Jun 2017 10:23:42 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (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 B6658126D73 for ; Thu, 15 Jun 2017 10:23:41 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id d73so5096954wma.0 for ; Thu, 15 Jun 2017 10:23:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RIabmHdy4YNg47OQ4xcGCmpCtOX0bAgCl0Ujkrli7sU=; b=Ch7CW2f+KOiygpyaGLi1J1V1d2+en/8wV/IwRoRhf27x/tSi4TfrjMpmOcwoHmEJmk 9z/WZSvV1svXERgnV0dMpL5hv1TtwU19J3lXh1c9M+eKdQpuUw7X0UI5yqRCIgYJ7Q/O QVaZxEXEWKtZohkPxjmFAN0dhIXnx5MNib1qf0h/JaqY7t9+Ms4RawE74wny5xg5b6iV wgvJykY1i0+B714v+MZQWnYWWafnWrLsGgW4wucY2poIj1Mfwl5BIEtDAYzcDunPQRax WwZ8ufBbD9jd0SEu6E/1RD08aU1Mcu69dCmAHXNI6T43pmdcIMiriED6nHMF501RENEX Ow7A== X-Gm-Message-State: AKS2vOwgKOtM62xS4s58GYDg6DnDXkgN5xJre33f0DhObYoFB5BblD4Z JH25OGYTeuhXr23xRsnM+LRq X-Received: by 10.80.138.34 with SMTP id i31mr4520065edi.119.1497547419943; Thu, 15 Jun 2017 10:23:39 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:190e:76f2:51:ff6b]) by smtp.gmail.com with ESMTPSA id w12sm481507edd.21.2017.06.15.10.23.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 10:23:39 -0700 (PDT) Date: Thu, 15 Jun 2017 19:23:38 +0200 From: Job Snijders To: Warren Kumari Cc: Philip Homburg , ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170615172338.dykhzfeogmpznymt@Vurt.local> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:23:44 -0000 On Thu, Jun 15, 2017 at 01:04:18PM -0400, Warren Kumari wrote: > On Thu, Jun 15, 2017 at 5:20 AM, Philip Homburg wrote: > >> SLAAC doesn't work unless the network provides enough address space > >> to make collisions vanishingly unlikely. > > > > Indeed. So any RFC that makes smaller pseudo random IIDs possible > > has to have at least a section that analyses collision > > probabilities. > > So, a couple of years ago I was doing some work with Juan Carlos and > Dan Harkins in the IEEE on MAC Randomization (basically randomizing > your (WiFi) MAC address to improve privacy / thwart pervasive > monitors). > > There was some discussion on how many bits you would need to randomize > to make it unlikely that multiple machines will independently choose > the same address. I argued that if you randomize 24 bits, and have a > stadium of ~2000 people, you will basically never get a collision. > Dan disagreed, and so, in a fit of pique, I wrote an App Engine app to > prove him wrong -- and achieved exactly the opposite. This is a > birthday paradox problem, and you will get a collision once every ~9 > times. > > I've just updated my little app and put it here: > https://ipv6-collision-probability.appspot.com/ > > It's interesting to play with the numbers and see how likely a > collision is, given a certain subnet length and number of hosts. Hah, nice :) > > And set a lower limit that is generally safe. > > > > Just leaving it to an operator to figure out that a /112 prefix will > > sometimes lead to an IoT device failing due to an address collision > > is extremely poor protocol design. > > Example: With a /112, and 100 hosts, you will have a collision every > ~14 times... Luckily there are other methods of numbering things: manually, or programmatically, or through DHCPv6. I believe there are more use cases then IoT devices. SLAAC is not the only way of doing things. Kind regards, Job From nobody Thu Jun 15 10:32:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FFA1293EC for ; Thu, 15 Jun 2017 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiiaTTAOq44F for ; Thu, 15 Jun 2017 10:31:57 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 2EC3B1293D8 for ; Thu, 15 Jun 2017 10:31:57 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id q15so12418288uaa.2 for ; Thu, 15 Jun 2017 10:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MdxW/1kZPFBVLHorLulTb9dBUVInSp/R5Og2UtAgW+U=; b=eiZvM2iWg43qVfFwz/Ypz0nG5OqE2UPfudoTJ90c5Ic4fpAGzOje9E6fehnAXgPPjM T2/BvT+qMl1rDh72iD6ll9fzlacFwEYsifW07tvJV3FkR3N1ljZNmy+X4NnoUM+fg4Dh 4o5J4oAMcpGPUY0FkkNIAXs+REwuWoGvi6T3nsgICEatTq+74UKwOxRuYMA+hI75j+Q5 gfXH1zS9ozEcBN5SdxPrIyu1Jirly6OFXpVFDuW6pSwKi6Q/KdAtI6jjcolDmxS8Eil4 o7byP7LjvJttj7nxDT4VTOWQUca6HahG1PWfl2EhNi23taDoRn0tQfx0RIjSyM0xvu8F liOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MdxW/1kZPFBVLHorLulTb9dBUVInSp/R5Og2UtAgW+U=; b=L2eLCNuxCT87v+Jead7i4Vgt0EZLiQ0xKw/nSacSeL2jhRiIzLD8xge5ZqAu9KLtZa iR/NYOK8REORHaVmvaxCgD13KgAV1kWx7/Dwsx4rpTd2buSRcb9DEqe3t9X+pltx/kKk ZhrHZMMEwB4C8TiPBfbLrDBFOtlS58E3jYFRCihS/D3UAKGc9RtWslF2VamrPaiCw7ID 0iNTgkcLmrkNLr8UvirR9K1zMeaMxWWWxG1egP14CxZKQScUZYC8SomuQgpJD5LrzZXr LKzQPSioR33hMslEF7NTQlyxAhqYPspS+QEJuILv3y0Bk1wXdBZ0jVN5N9kFXTheywfs RtQg== X-Gm-Message-State: AKS2vOwFtebyGRRmo6YXKUNA16tTe+r1GcP/sz0IJDeXCvz7UkuC57rB ASIwwHrGGVQdln1z+Nw2AAJ3+clLMaDn X-Received: by 10.159.60.162 with SMTP id s34mr4056390uai.89.1497547915300; Thu, 15 Jun 2017 10:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.198 with HTTP; Thu, 15 Jun 2017 10:31:14 -0700 (PDT) In-Reply-To: <20170615172338.dykhzfeogmpznymt@Vurt.local> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <20170615172338.dykhzfeogmpznymt@Vurt.local> From: Warren Kumari Date: Thu, 15 Jun 2017 13:31:14 -0400 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: Philip Homburg , ipv6@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:31:59 -0000 On Thu, Jun 15, 2017 at 1:23 PM, Job Snijders wrote: > On Thu, Jun 15, 2017 at 01:04:18PM -0400, Warren Kumari wrote: >> On Thu, Jun 15, 2017 at 5:20 AM, Philip Homburg wrote: >> >> SLAAC doesn't work unless the network provides enough address space >> >> to make collisions vanishingly unlikely. >> > >> > Indeed. So any RFC that makes smaller pseudo random IIDs possible >> > has to have at least a section that analyses collision >> > probabilities. >> >> So, a couple of years ago I was doing some work with Juan Carlos and >> Dan Harkins in the IEEE on MAC Randomization (basically randomizing >> your (WiFi) MAC address to improve privacy / thwart pervasive >> monitors). >> >> There was some discussion on how many bits you would need to randomize >> to make it unlikely that multiple machines will independently choose >> the same address. I argued that if you randomize 24 bits, and have a >> stadium of ~2000 people, you will basically never get a collision. >> Dan disagreed, and so, in a fit of pique, I wrote an App Engine app to >> prove him wrong -- and achieved exactly the opposite. This is a >> birthday paradox problem, and you will get a collision once every ~9 >> times. >> >> I've just updated my little app and put it here: >> https://ipv6-collision-probability.appspot.com/ >> >> It's interesting to play with the numbers and see how likely a >> collision is, given a certain subnet length and number of hosts. > > Hah, nice :) > >> > And set a lower limit that is generally safe. >> > >> > Just leaving it to an operator to figure out that a /112 prefix will >> > sometimes lead to an IoT device failing due to an address collision >> > is extremely poor protocol design. >> >> Example: With a /112, and 100 hosts, you will have a collision every >> ~14 times... > > Luckily there are other methods of numbering things: manually, or > programmatically, or through DHCPv6. I believe there are more use cases > then IoT devices. SLAAC is not the only way of doing things. > Yup, fully agree -- this isn't intended to support (or detract from) SLAAC, DHCPv6, manual, unicorns, hippopotamuses or any other address assignment solution, it's just a tool, like a hammer. Just like with a hammer, you can wield it to justify your views :-P W > Kind regards, > > Job -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jun 15 13:04:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78612878D for ; Thu, 15 Jun 2017 13:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGM3OJBiWWrJ for ; Thu, 15 Jun 2017 13:04:25 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 9B52D1201F2 for ; Thu, 15 Jun 2017 13:04:25 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id q97so27820571wrb.2 for ; Thu, 15 Jun 2017 13:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2tje4F0Ts7OdjOqc7dZfp6uG6nfAUWf/kgSiNLOcpR4=; b=H2MuOH2PRYF/qbNsTXeLP8hs45vxdqJ21Z+VoGm+Jhx5EZSjbnM3m+oonwLyzb3jVx TVV24rY5PyAjB6MosFdJtCLIniI1ad1nqP06e2/nfBrHBpLa9Vs0a89Y+X0lk3FuIDsb 48mri0BDUJJ5MfrtNyVX5y/Ei+Eb9WndFms+aklfnGiLdZJzHShgi7jiRHJYaoruZ5oP AO6OBCzLeU1boyOE5hynRzmvovlVez1YgCd8X3OEGCZGSuUfPZwuRtic6ZJWUJ4pwet/ /869hrCjjy09MJv7UK4iJAbi738Z6RN9A4V82BCYSGs9Bux6kBUrkk+SZtLWna6qNdZY pAzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2tje4F0Ts7OdjOqc7dZfp6uG6nfAUWf/kgSiNLOcpR4=; b=ov702uDST6i+Wr+Hilpo7xWu2GP4/7fmoPBOF5ev0Wf48HLuKuYmM+TFLMoBCOtQzf Pyf6rJi/n3nLbnqioNr186sE9RdYL1cGB89tdWSOs0eC1T4R0/GqmtK2KFl9cC/7cdDL bP2JPlF6Lud6vuqSZQjgMsgxUuYc2PPEEfMcILQj3fM+UXEMZGcYEu8n3qweO3NOljQE F13dDw+iWqH5ju0MJ15C7V1g0jzpHhwTqqfFNhUXzJMGEkDQYxFnYYI2mjW0Qa9zCQLr 0sF9ShcYs3DSzeEeTtPArxTH5LvN2k1w+LWKUy6n9CAYVSj0o39T7oPpwtwoTWmlCm7n FCfQ== X-Gm-Message-State: AKS2vOyBWOwrhrWcGV2dtrOU50EWaI+QbEVl7vZw4xyibxsL02+4OZvd 0GO6PqOT4jp28L8QsSCyeoIdZZKI5Ohf X-Received: by 10.223.183.11 with SMTP id l11mr4678854wre.115.1497557063911; Thu, 15 Jun 2017 13:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Thu, 15 Jun 2017 13:04:22 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> From: Tom Herbert Date: Thu, 15 Jun 2017 13:04:22 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Brian E Carpenter Cc: Lorenzo Colitti , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 20:04:29 -0000 On Wed, Jun 14, 2017 at 5:14 PM, Brian E Carpenter wrote: > On 14/06/2017 19:11, Lorenzo Colitti wrote: >> On Wed, Jun 14, 2017 at 12:36 PM, Tom Herbert wrote: >> >>> Can you tell me what the killer app is on a smartphone that require >>> 2^64 addresses? > > The question is slightly premature. Try: > > "What is the killer use case on a smartphone that requires > many addresses that are essentially unguessable because > they include 64 pseudo-random bits?" > > Lorenzo's answer below covers this case too, and he's right, if > we believe that miscreants in the far future may have enough > computing power to search a very large space, even if the use > case only needs a few thousand addresses. > Brian, If there is a killer app then it may well be in security, however I would think that to justify /64 as the standard, one would have to demonstrate that such security can't be comprised and ubiquity is required. I'd also point out that giving the host more bits for entropy means the the network side gets less. So while it might be hard to guess a host address, if it's easy to guess the prefix assigned to the device which can then that could be an avenue to for DOS attack on the device. It seems like for security we would want both network and host contribution and the address to be unguessable, so it might make sense to give them an equal number of bits of entropy and hence something longer than /64 would be needed. Tom > (64 is only a parameter, even in this sub-sub-sub-thread, but it's > the right order of magnitude - privacy concerns require several > tens of bits even with today's computing power.) > > BTW, I aoplogise to the WG for having provoked this thread. My > intention was only to remind people that these tussles are > a sign of success for IPv6. > > Brian > >> I don't have one for you today, and I don't think I will have one for you >> tomorrow either. I want to preserve the ability for someone else to give >> you the answer during the expected multi-decade year lifetime of the >> protocol. If you take the bits for your own use, we will never get that >> answer. >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> From nobody Thu Jun 15 13:20:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8026128D40 for ; Thu, 15 Jun 2017 13:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuhTWzr2taSE for ; Thu, 15 Jun 2017 13:20:28 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E4C1201F2 for ; Thu, 15 Jun 2017 13:20:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5FKKQKH064903; Thu, 15 Jun 2017 13:20:27 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5FKKQR1064895 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 15 Jun 2017 13:20:26 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Jun 2017 13:20:25 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 15 Jun 2017 13:20:25 -0700 From: "Manfredi, Albert E" To: Tom Herbert CC: IETF IPv6 Mailing List Subject: RE: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS5hKhwQnicctxIEa/s3kHx814saImWwSA Date: Thu, 15 Jun 2017 20:20:25 +0000 Message-ID: <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 20:20:30 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert > I'd also point out that giving the host more bits for entropy > means the the network side gets less. So while it might be > hard to guess a host address, if it's easy to guess the prefix > assigned to the device which can then that could be an avenue to > for DOS attack on the device. I agree with this general line of thinking, and I'd also point out that as = computers become faster, this security benefit will decrease and then vanis= h. Really, to create a vast address space, and then after the fact, establi= sh "rules" that require that vast address space to be only **very** sparsel= y used, is counterproductive? Why isn't is better to use real security meas= ures, such as TLS? The 17-year cicada has practically no defenses. The only way the species su= rvives is through huge numbers, very short lifespans, and exceedingly long = dormant periods buried underground. I would prefer having some defenses, gi= ven a choice. Bert From nobody Thu Jun 15 14:57:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C243129562 for ; Thu, 15 Jun 2017 14:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRw5wzT_j4Yu for ; Thu, 15 Jun 2017 14:57:50 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CC412946A for ; Thu, 15 Jun 2017 14:57:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 5B29F1A071 for ; Thu, 15 Jun 2017 21:57:45 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Hitting the tech news From: Simon Hobson In-Reply-To: <7B18897F-5B90-4BF8-AE87-1F116A825F27@consulintel.es> Date: Thu, 15 Jun 2017 22:57:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0EDD104B-7D4C-4749-9548-6D5C24033298@thehobsons.co.uk> References: <7B18897F-5B90-4BF8-AE87-1F116A825F27@consulintel.es> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 21:57:52 -0000 JORDI PALET MARTINEZ wrote: > The author of the article changed my family name =85 I imagine that would be a common problem when dealing with us pesky = native english speakers. TBH it's only accidental (having read about it = somewhere some time ago) that I know enough to realise what's been done = there. FWIW I completely agree with your call for participation. No offence = intended to those that already participate, but it is clear that the = discussions are dominated by people working with "big networks" and with = a "big network/operation" mentality. Picking up on just one point in = your post on the NANOG list, speaking as a technically literate = individual - if an ISP insists that I have to use their router, then = they don't get my business. Several ISPs in the UK do just that = - and I can see some commercial justification for it - but of all the = ones that I have any experience with (with my other hat on as an = employee of a small IT services provider) have significant "issues" = (mostly a crap CPE that just doesn't support anything past "giving = internet access to devices"). One example of deficiencies in CPE routers (at least in the IPv4 space) = is not having any means to forward anything other than UDP or TCP = traffic - which means you can't run a GRE tunnel through them in order = to get IPv6 via (in this case) Hurricane Electric's tunnelbroker = service. Or with my work hat on, no proper support for site-site VPNs = which are really common in the small business world. At least if the ISP = supports using another router then you can work around this - but = unfortunately at work we've had cases where this limitation only comes = to light when you ask for (in our case, usually DSL) access details and = the ISP refuses to provide them and it's too late to tell them where to = shove they service (in many cases, the customer has ordered the internet = service, and we later get tasked with making it do things other than = "give internet access to devices"). From nobody Thu Jun 15 18:18:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13C2129C25 for ; Thu, 15 Jun 2017 18:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_BOKtkJn4SX for ; Thu, 15 Jun 2017 18:18:06 -0700 (PDT) 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 04AB2129408 for ; Thu, 15 Jun 2017 18:18:06 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 83so15170306pfr.0 for ; Thu, 15 Jun 2017 18:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kvypaiGfLsQ81V866sK3l5X0fo6yNFQZLATqUnqt0Qk=; b=u6LX9ZiODaHu14/0R7MkjdFLwfHFsF5IowYnBxw/ZsLLRLLZkPhgw1rRQYo75qEqyr aEOQQ/DmmLXmi8FMWl/HI3cWo82Jz3wmoSyvAqZsA0tBsf3qhL8xKd48B39D1tBUnvRp 9QflkELIER/sKrR/ktpxTudbLkHSjydV9Q6iAXj6CCAwtcTNUYBTlIEXbgk720C2dSUA YbxpLsK+qEfuf9ZwDAN3hyJnB6T/zicwoqWBETvIx80vFvs/rOnn2zXnOuqC2xmPZIbG mZD3IAuoji4RQFkOYWR0y3uRIQ0PO3FvJh1/s/pqPGBlW8GT5r1Ksk9dTlvji6u8mzm/ vu2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=kvypaiGfLsQ81V866sK3l5X0fo6yNFQZLATqUnqt0Qk=; b=CmHJlBzPQept7LxJuUfjYR7bXTXRg2A4CzJvamhqEOVrAJC/1gbSU+Ajh5fspiaz5o lurydct4cxi9iCE4KAbiRj4/82Zlnp0/bj+yM9e8QE/A5JvXDJnKMCtSiK4xb5OGhH7d mqeTmOaKFgsG3w0Y/q9P0mf4QcwtbWVeOC4iF8Z4CXtSU1G+7tSuWecZRTNG6cnsQ0+c nMJ3xCvbpJrGjVs0QetWu5vSpHSJL2711BifguEgogHF9OIFLIMpGUYK8kaHBunEEsFo Edi6c+tSx5UXrwpevQJR+8ekGotEYa8DDI1hr4bmDf/QrNixr49dUXigULmQULmL/h4T 15Iw== X-Gm-Message-State: AKS2vOxphZDs9Nh3oc8ZnWHoGR1DLguLbz89xMtqdZmXu0pFQ/ddNuX2 Hf1DcnYHQrgvWSdQ X-Received: by 10.101.73.135 with SMTP id r7mr8298381pgs.224.1497575885367; Thu, 15 Jun 2017 18:18:05 -0700 (PDT) Received: from [192.168.178.21] ([118.149.110.59]) by smtp.gmail.com with ESMTPSA id v69sm844432pfd.63.2017.06.15.18.18.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 18:18:04 -0700 (PDT) Subject: Re: Tussles in IPv6 Land To: "Manfredi, Albert E" References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Cc: ipv6@ietf.org Message-ID: <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> Date: Fri, 16 Jun 2017 13:18:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:18:08 -0000 On 16/06/2017 08:20, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert > >> I'd also point out that giving the host more bits for entropy >> means the the network side gets less. So while it might be >> hard to guess a host address, if it's easy to guess the prefix >> assigned to the device which can then that could be an avenue to >> for DOS attack on the device. > > I agree with this general line of thinking, and I'd also point out that as computers become faster, this security benefit will decrease and then vanish. Really, to create a vast address space, and then after the fact, The /64 boundary was established by RFC2373 (July 1998). Hardly after the fact. > establish "rules" that require that vast address space to be only **very** sparsely used, is counterproductive? Why isn't is better to use real security measures, such as TLS? Because sparse addresses and e2e security solve very, very different security problems. Sparse subnet prefixes might also have some value, as Tom implies. I'm not aware of any analysis of that, in RFC7707 or elsewhere. Brian From nobody Thu Jun 15 18:36:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE01205F1 for ; Thu, 15 Jun 2017 18:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlOCCq5_vCj3 for ; Thu, 15 Jun 2017 18:36:47 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 B7D071205D3 for ; Thu, 15 Jun 2017 18:36:47 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v18so14051449pgb.1 for ; Thu, 15 Jun 2017 18:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6Tr89M//VjtnAHSXcPxNIFaxnf47Cb93lV8JA5JdRq8=; b=QOkF43QYRYq4AIv3H4lwgA3icvw8v+yLQtsAXL3FHlVBsuYI52jf2Z6kDtUlJ9NtIm Q4uUrRtRJHnbt8VdVm2oyZEVUkWZH2OW2H+jXfmn73vq1+iJi5/udLyLawwAAEiyFqZe oZ9H+kbAaiGYY15nVG06IcVhky+1Ex7wx+rGILrlQi659iSoJ2AOXulkegDlPz0X9Yde wVy+p5lMQy5xhq96jwWCDszkIqlqfXLQEIXvgCHUXs8h+7MoEo6kNAiXCWVv5tG7Jgl2 2CYIYIqsT2d6EY1ZKJ8zB9fvQJn8S7kXQxpwhGap3bSC+rcjHTuf6lGV9UmRuIrqBQ8l lY7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6Tr89M//VjtnAHSXcPxNIFaxnf47Cb93lV8JA5JdRq8=; b=PkMPvrRI6O46/0ocgdKWWq9g5ptI5uOnxfrq5Z9SYS3FE9ppd2GMKXoglj45Hprmmi be7AJqr8PVNuz5tCYN/lDO8Bd1ck+cmc15AQmUbA4JWfoUg1FkdDEcSm2bPm8NZFy/qD Py3n17G+5+zz+QCA4lnqIRsXC4yPO5hfpgP92DdOMvlt5hPVg07wKGNAmBeo6lRsm4bZ OGZ2CS1S0AUbyafGO4xVfMFl1Ft34lyTP0A7MOKsShwvKWacqMmq+GCYppoz1zyO1XGl n9ipLhRrJp7lewUHpeQL+DzDt+yRB8aQgJwzvYGVdkddiNhId8vDbG6U2Aq8WE2BDmNn gKpw== X-Gm-Message-State: AKS2vOzg1ir9JSglX/haetaYcmoK7fCjXuC/YnnRxvTI6JmJ87M5Qq7e UlNItIJoPYEuDw== X-Received: by 10.98.61.88 with SMTP id k85mr8239884pfa.90.1497577007294; Thu, 15 Jun 2017 18:36:47 -0700 (PDT) Received: from [192.168.178.21] ([118.149.110.59]) by smtp.gmail.com with ESMTPSA id h71sm873755pfk.126.2017.06.15.18.36.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 18:36:46 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Lorenzo Colitti Cc: IETF IPv6 Mailing List , Peter Hessler References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 16 Jun 2017 13:36:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:36:49 -0000 On 14/06/2017 22:12, Lorenzo Colitti wrote: > On Wed, Jun 14, 2017 at 6:59 PM, Peter Hessler wrote: > >> I'm already running non-/64 subnets on my personal networks. I'm also >> running non-/64 subnets on my $work networks. >> >> mandating /64 subnets in the _architectural specification_ is a bug, >> period. >> >> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century >> as well. >> > > Brian (and everyone on this thread, really): QED. QED indeed, if the proposition to be proved is that a rigid boundary is not required. > Peter, thanks for writing this email so clearly. I think we now have a > clear example of what some operators will feel encouraged to do if we > change "is /64" to "should be /64". With the the current state of affairs, > such networks happen to work but are not guaranteed to interoperate, and > host implementations are not required to work on them. If we change the > standards to admit that subnets may be non-64 bits, there will be pressure > on implementations to conform. I think that portability out of the box is a much stronger argument. Peter has chosen to hand-craft his networks. Most people (99.99%) simply unwrap their new device, ignore the "quick start" guide, and switch it on. There is an enormous market incentive for that to work 100% of the time, which is an enormous incentive to stick with /64. > Even if this sort of opinion were a minority opinion among network > operators, it is the nature of networking software development that host > implementations adapt to the lowest common denominator. Let's not do that > here. There is no technical reason to do so. > > This is exactly the sort of scarcity thinking that the 64-bit boundary is > intended to avoid. Not to mention the late lamented /48 recommendation to ISPs. Again, nobody is trying to sabotage /64 as the norm for SLAAC networks, and nobody is trying to sabotage SLAAC as the norm for plug and play. > Let's ensure that such limitations - which as Peter > says, belong to the last century - stay in the last century and do not > enter this one. I agree. But at the same time we need to be honest in our specs. RFC4291 does not describe the deployed architecture accurately, which is why we have to fix it if we're serious about Internet Standard status. Brian From nobody Thu Jun 15 19:38:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B83912941D for ; Thu, 15 Jun 2017 19:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB4bVNpf-sWo for ; Thu, 15 Jun 2017 19:38:50 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE64129408 for ; Thu, 15 Jun 2017 19:38:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5G2cnmX043552; Thu, 15 Jun 2017 19:38:49 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5G2cemY043514 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 15 Jun 2017 19:38:40 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Jun 2017 19:38:39 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 15 Jun 2017 19:38:39 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: "ipv6@ietf.org" Subject: RE: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS5hKhwQnicctxIEa/s3kHx814saImWwSAgADLBAD//5j88A== Date: Fri, 16 Jun 2017 02:38:39 +0000 Message-ID: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> In-Reply-To: <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 02:38:52 -0000 QnJpYW4sIGxldCBtZSByZWNvbnN0cnVjdCBteSBwb3N0IGFzIGl0IHdhcyB3cml0dGVuOg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0 bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KDQo+PiBJIGFncmVlIHdpdGggdGhpcyBn ZW5lcmFsIGxpbmUgb2YgdGhpbmtpbmcsIGFuZCBJJ2QgYWxzbyBwb2ludA0KPj4gb3V0IHRoYXQg YXMgY29tcHV0ZXJzIGJlY29tZSBmYXN0ZXIsIHRoaXMgc2VjdXJpdHkgYmVuZWZpdCB3aWxsDQo+ PiBkZWNyZWFzZSBhbmQgdGhlbiB2YW5pc2guIFJlYWxseSwgdG8gY3JlYXRlIGEgdmFzdCBhZGRy ZXNzIHNwYWNlLA0KPj4gYW5kIHRoZW4gYWZ0ZXIgdGhlIGZhY3QsIGVzdGFibGlzaCAicnVsZXMi IHRoYXQgcmVxdWlyZSB0aGF0IHZhc3QNCj4+IGFkZHJlc3Mgc3BhY2UgdG8gYmUgb25seSAqKnZl cnkqKiBzcGFyc2VseSB1c2VkLCBpcw0KPj4gY291bnRlcnByb2R1Y3RpdmU/DQo+DQo+IFRoZSAv NjQgYm91bmRhcnkgd2FzIGVzdGFibGlzaGVkIGJ5IFJGQzIzNzMgKEp1bHkgMTk5OCkuIEhhcmRs eQ0KPiBhZnRlciB0aGUgZmFjdC4NCg0KVGhlIDY0LWJpdCBib3VuZGFyeSBpcyBub3QgdGhlIGlz c3VlIGhlcmUuIFRoZSBpc3N1ZSBpcyB0aGF0IHRoaXMgMTI4LWJpdCBhZGRyZXNzIHNwYWNlIHdh cyBub3QgaW5pdGlhbGx5IGludGVuZGVkIHRvIGJlIGZvcmV2ZXIgdmVyeSBzcGFyc2VseSBwb3B1 bGF0ZWQsIGZvciBhIHNlY3VyaXR5IHJlYXNvbi4gSW4gZmFjdCwgd2hlbiB0aGUgSUlEIHdhcyBt ZWFudCB0byBjb25zaXN0IG9mIGEgTUFDIGFkZHJlc3MgcGx1cyBhIGZpeGVkIHVwcGVyIDE2IGJp dHMsIHRob3NlIDY0IGJpdCBJSURzIHdlcmUgaGFyZGx5IGFueSBzb3J0IG9mIHNlY3VyaXR5IG1l YXN1cmUuIFdlJ3JlIG5vdyBzYXlpbmcsIGluIHNwaXRlIG9mIHRoZSBoeXBlIGFib3V0IHRoaXMg dmFzdCBhZGRyZXNzIHNwYWNlLCB0aGF0IGF0IGxlYXN0IHRoZSBib3R0b20gNjQgYml0cyBvZiBp dCwgaWYgbm90IGFsc28gdGhlIHByZWZpeCA2NCBiaXRzLCBtdXN0IGJlIHZlcnkgc3BhcnNlbHkg cG9wdWxhdGVkLiBTbyBtdWNoIGZvciB2YXN0IGFkZHJlc3Mgc3BhY2UsIHJpZ2h0Pw0KDQpTbywg d2hlbiBJIHNhaWQgImFmdGVyIHRoZSBmYWN0LCIgSSB3YXMgdGFsa2luZyBhYm91dCB0aGUgc2Vj dXJpdHkgcmF0aW9uYWxlLiBUaGF0IGRlZmluaXRlbHkgY2FtZSBhZnRlciB0aGUgZmFjdC4NCg0K Pj4gV2h5IGlzbid0IGlzIGJldHRlciB0byB1c2UgcmVhbCBzZWN1cml0eSBtZWFzdXJlcywgc3Vj aCBhcyBUTFM/DQo+DQo+IEJlY2F1c2Ugc3BhcnNlIGFkZHJlc3NlcyBhbmQgZTJlIHNlY3VyaXR5 IHNvbHZlIHZlcnksIHZlcnkgZGlmZmVyZW50DQo+IHNlY3VyaXR5IHByb2JsZW1zLg0KDQpXZWxs LCBJIGNvbnRlbmQgdGhlcmUncyBzb21lIGludGVyc2VjdGlvbiBvZiBzZXRzIHRoZXJlLiBBbm9u eW1pdHkgYmVjb21lcyBsZXNzIGNydWNpYWwgaWYgdGhlIGNvbnRlbnQgaXMgZW5jcnlwdGVkLiBB bmQgdGhlcmUgYXJlIG90aGVyIHdheXMsIHByb2JhYmx5IGJldHRlciB3YXlzLCBvZiBhY2hpZXZp bmcgYW5vbnltaXR5LCB0aGFuIHNwYXJzZSB1c2FnZSwgc3VjaCBhcyBzaG9ydCBhZGRyZXNzIGxp ZmV0aW1lcy4gUGx1cywgYXMgc2VjdXJpdHkgbWVhc3VyZSwgNjQgYml0cyBiZWNvbWVzIGxlc3Mg YW5kIGxlc3MgYmVsaWV2YWJsZSwgaW4gYSB0aW1lIHdoZW4gd2UgbXVzdCB1c2UgMTI4IG9yIHBy ZWZlcmFibHkgMjU2IGJpdHMgZm9yIGVmZmVjdGl2ZSBzZWN1cml0eSBrZXlzLiBTbyB3ZSByZWFs bHkgbmVlZCB0byBwdXQgdGhpcyBvbmUgc2VjdXJpdHkgYWlkIGluIHBlcnNwZWN0aXZlLCBJIHRo aW5rLiBJdCBzZWVtcyB0byBiZSBnaXZlbiBtb3JlIGVtcGhhc2lzIHRoYW4gaXQgZGVzZXJ2ZXM/ DQoNCkJlcnQNCg0K From nobody Thu Jun 15 20:09:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69B3127BA3 for ; Thu, 15 Jun 2017 20:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOf-ihrkrOxK for ; Thu, 15 Jun 2017 20:09:49 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D1C126C3D for ; Thu, 15 Jun 2017 20:09:48 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id 63so14123496ywr.0 for ; Thu, 15 Jun 2017 20:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ru94BiqkLwLSs2M8E6FWvxtY1VLAsMLpY3ytbuD28V8=; b=t29+M5IKkTvFV7JU9q37fra7wDBTzTZrGO8GhBsIT71cvnqPBugXkirKJMh5fYWTt/ mE3OFfEXGdI5qdijBntaER/ysiXTt5B7LXV0dY56wzy6FNNAjUwIYkPrDA14uMIxX1hU O7trUHuzda4apgJ/M5ewCsOXvXjZd2o3ilO6ZG/td0wcXq/0X3mX30f5hf11QOoTSn0T lvLudJYv0KGzsipZrukj/CJ12GCEtPnrXutBgIi9TLLP/n+JnqBc2cVCDGiLwPRje7nL 2Tz5F5w259L7w4eUz2kpDcN6wS2PKjp0rUeGH1fSgVBrAZmZW8jyUTw7JDV7d7aRUncO ALCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ru94BiqkLwLSs2M8E6FWvxtY1VLAsMLpY3ytbuD28V8=; b=FNbJFeN1tGWIBpuzwzAS0o9jIUqsxzkYVUZ8m62jxplB1TOMnfKfMG4SCIqP0+YqhW eSdMMCESX1VUpVi8V6qXVct9rk64lkRDZBStAzc4ANKQeMoW6hzIJTwTTFuWFWwKHwUc DXNGSuzU5v+zaZ0EYkQ2eR3ArjKuyXAya02KuLrRNsoACf0CDW5s9C5N/z6nboRiDox9 DZrYQZFY1HLgutNikJlCURN4/t6WSJyvkeiIe5q4IsdzYx1MGXxAVuIK0j3JaFio1dBP C/nQ6MXpzod9JODxGExiAckosRKR1lHYr4GU8/8J6IJ0KtNmmu7d0e5+0QnTvcCiubIf vSeQ== X-Gm-Message-State: AKS2vOzn2RwvkFVO4D1XYbO5HElrNBBb61A18eMSsCH/PgJMLGZRot/G F4QcuotMmt1jNH3V6uuimnOJSf84kmZa X-Received: by 10.129.46.143 with SMTP id u137mr6721871ywu.302.1497582588149; Thu, 15 Jun 2017 20:09:48 -0700 (PDT) MIME-Version: 1.0 References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> In-Reply-To: From: Ca By Date: Fri, 16 Jun 2017 03:09:37 +0000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Brian E Carpenter , "Manfredi, Albert E" Cc: "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a1145a1ce3048d805520b1eb2" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 03:09:52 -0000 --001a1145a1ce3048d805520b1eb2 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 7:39 PM Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > Brian, let me reconstruct my post as it was written: > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > >> I agree with this general line of thinking, and I'd also point > >> out that as computers become faster, this security benefit will > >> decrease and then vanish. Really, to create a vast address space, > >> and then after the fact, establish "rules" that require that vast > >> address space to be only **very** sparsely used, is > >> counterproductive? > > > > The /64 boundary was established by RFC2373 (July 1998). Hardly > > after the fact. > > The 64-bit boundary is not the issue here. The issue is that this 128-bit > address space was not initially intended to be forever very sparsely > populated, for a security reason. In fact, when the IID was meant to > consist of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs were > hardly any sort of security measure. We're now saying, in spite of the hype > about this vast address space, that at least the bottom 64 bits of it, if > not also the prefix 64 bits, must be very sparsely populated. So much for > vast address space, right? > > So, when I said "after the fact," I was talking about the security > rationale. That definitely came after the fact. > > >> Why isn't is better to use real security measures, such as TLS? > > > > Because sparse addresses and e2e security solve very, very different > > security problems. > > Well, I contend there's some intersection of sets there. Anonymity becomes > less crucial if the content is encrypted. And there are other ways, > probably better ways, of achieving anonymity, than sparse usage, such as > short address lifetimes. Plus, as security measure, 64 bits becomes less > and less believable, in a time when we must use 128 or preferably 256 bits > for effective security keys. So we really need to put this one security aid > in perspective, I think. It seems to be given more emphasis than it > deserves? > > Bert > Recently, on the internet, there was a very effective and harmful worm called "wannacry". This worm was only on ipv4, and it's particular ilk will only ever be on densely populated ipv4. And, it could never be effective on sparsely populated ipv6. You see, it used a random number generator to feed an ipv4 hunter function that would attempt to connect to computers on open port 445. In ipv6, that hunter is fruitlesss. The wannacry story is very instructive, from its CIA / NSA roots, to being dumped to the public, and then maliciously operationalized against ... hospitals...and others. Yes, there are ways to narrow the search for ipv6 hosts and key parties can discover addresses. Google probably knows most of the alive ipv6 address on the 'net at any one time, Akamai has published some work in this space (showing addresses are not very preditable) but a random worm does not and will not be able to guess the space and feed a hunter function. So, yes, imho, 64 random bits is a killer security app. Just like stripes on a zebra or spots on a cheetah were not part of some grand design, the 64 bits value's security value is emergent. I have personally been able to effectively use the sparse addressing as part of a very large network's security posture for several years. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1145a1ce3048d805520b1eb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jun 15, 2017 = at 7:39 PM Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote:
Brian, let me reconstruct my post as it was written:

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]

>> I agree with this general line of thinking, and I'd also point=
>> out that as computers become faster, this security benefit will >> decrease and then vanish. Really, to create a vast address space,<= br> >> and then after the fact, establish "rules" that require = that vast
>> address space to be only **very** sparsely used, is
>> counterproductive?
>
> The /64 boundary was established by RFC2373 (July 1998). Hardly
> after the fact.

The 64-bit boundary is not the issue here. The issue is that this 128-bit a= ddress space was not initially intended to be forever very sparsely populat= ed, for a security reason. In fact, when the IID was meant to consist of a = MAC address plus a fixed upper 16 bits, those 64 bit IIDs were hardly any s= ort of security measure. We're now saying, in spite of the hype about t= his vast address space, that at least the bottom 64 bits of it, if not also= the prefix 64 bits, must be very sparsely populated. So much for vast addr= ess space, right?

So, when I said "after the fact," I was talking about the securit= y rationale. That definitely came after the fact.

>> Why isn't is better to use real security measures, such as TLS= ?
>
> Because sparse addresses and e2e security solve very, very different > security problems.

Well, I contend there's some intersection of sets there. Anonymity beco= mes less crucial if the content is encrypted. And there are other ways, pro= bably better ways, of achieving anonymity, than sparse usage, such as short= address lifetimes. Plus, as security measure, 64 bits becomes less and les= s believable, in a time when we must use 128 or preferably 256 bits for eff= ective security keys. So we really need to put this one security aid in per= spective, I think. It seems to be given more emphasis than it deserves?

Bert


Recently, on the internet, there was a very effective and harmf= ul worm called "wannacry". This worm was only on ipv4, and it'= ;s particular ilk will only ever be on densely populated ipv4. And, it coul= d never be effective on sparsely populated ipv6. You see, it used a random = number generator to feed an ipv4 hunter function that would attempt to conn= ect to computers on open port 445.=C2=A0 In ipv6, that hunter is fruitlesss= .=C2=A0 The wannacry story is very instructive, from its CIA / NSA roots, t= o being dumped to the public, and then maliciously operationalized against = ... hospitals...and others.=C2=A0

Yes, there are ways to narrow the search for ipv6 hosts and key p= arties can discover addresses.=C2=A0 Google probably knows most of the aliv= e ipv6 address on the 'net at any one time, Akamai has published some w= ork in this space (showing addresses are not very preditable) but a random = worm does not and will not be able to guess the space and feed a hunter fun= ction.=C2=A0

So, yes, im= ho, 64 random bits is a killer security app. Just like stripes on a zebra o= r spots on a cheetah were not part of some grand design, the 64 bits value&= #39;s security value is emergent.=C2=A0

I have personally been able to effectively use the sparse a= ddressing as part of a very large network's security posture for severa= l years.=C2=A0


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--001a1145a1ce3048d805520b1eb2-- From nobody Thu Jun 15 20:31:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ECB1205F0 for ; Thu, 15 Jun 2017 20:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqCV1t62riSi for ; Thu, 15 Jun 2017 20:31:16 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 BC180127BA3 for ; Thu, 15 Jun 2017 20:31:15 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id x70so14693411wme.0 for ; Thu, 15 Jun 2017 20:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lSJSJWZlFk+fxq7YNfPwo98+0JHPIaEreWewjYCULiA=; b=YqPgU6hQHAh1lPr9xlYTYtHZukp2nozgMcq03msaATkgvzbInC/q0FANu/sSDmaHAe mwgZR1eY9gpmritiaWAZql78UqsuWy6d+EFN5r/WhQzhR7yg5UzvHjEKKzIB8c4nvj4I 8Gon0/Ox+MRYu9pOAlbH5xg81qae0g9J9nQWVevKEQs9GYYxCOKm4IhVvVwEWZZuIp9q YKXGN8ZzRPuEV2VjxuDBPjCS3Sl8vs50ISzBJHnw067Ms4BcXxgjT0OkOc9ZdK3VRrl4 sdQzKXm+nUgcBhF7d76bJXOlryKX0IcK0j8foj3NdrTejsElcmrnsB6zcTp8U4OjgtiD qi6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lSJSJWZlFk+fxq7YNfPwo98+0JHPIaEreWewjYCULiA=; b=t09sEFQ/DJ/BdF6PPZk45nzc8djCAGzz3UschkqcNjddSS6iaS8p+8pmp6guOhlucA vG2YBpTVbcCu3VblbyyZQ3GNNM0XQmfft0Q1V6UCk3BzW1Z+7lg0llIKF/9H7MQqpiar WQFNs+86kX4EU0XA7Eg7ljrg6pNhopl0kLc4Yfa0Xn7It9sQnuxIc7auSP8KJcnPZE7H vX+COzH4JCexn6PFaIG8nR/B9lGVl/Z+BdYoV6pSw4S69J88CkfDE9YicxLXCpnJQaRZ 6CH4AnG3DvE5uT1qM+yoAVHYd3a4drrYkcwpxdP4tNEeoDwZ0u6NoDPTQtxZOhsNA9F/ Xx+g== X-Gm-Message-State: AKS2vOwua72ZZR9uYwpQPqxUCgrAUv0o5xYQS9y8vev4bwrMOipyNA8g qvbo3AdDirtXJ4Dg7AwaCmXWZraSv/9f X-Received: by 10.28.87.72 with SMTP id l69mr5304082wmb.111.1497583874071; Thu, 15 Jun 2017 20:31:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Thu, 15 Jun 2017 20:31:12 -0700 (PDT) In-Reply-To: <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> From: Tom Herbert Date: Thu, 15 Jun 2017 20:31:12 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Brian E Carpenter Cc: "Manfredi, Albert E" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 03:31:18 -0000 On Thu, Jun 15, 2017 at 6:18 PM, Brian E Carpenter wrote: > On 16/06/2017 08:20, Manfredi, Albert E wrote: >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert >> >>> I'd also point out that giving the host more bits for entropy >>> means the the network side gets less. So while it might be >>> hard to guess a host address, if it's easy to guess the prefix >>> assigned to the device which can then that could be an avenue to >>> for DOS attack on the device. >> >> I agree with this general line of thinking, and I'd also point out that as computers become faster, this security benefit will decrease and then vanish. Really, to create a vast address space, and then after the fact, > > The /64 boundary was established by RFC2373 (July 1998). Hardly after the fact. > >> establish "rules" that require that vast address space to be only **very** sparsely used, is counterproductive? Why isn't is better to use real security measures, such as TLS? > > Because sparse addresses and e2e security solve very, very different security problems. > > Sparse subnet prefixes might also have some value, as Tom implies. I'm not aware of any analysis of that, in RFC7707 or elsewhere. > Brian, I believe both IPwave and the upcoming IDEAS BOF are discussing methods to obfuscate addresses for the purpose to prevent tracking of mobile devices (like tracking the location of a car as it drives down the road). It's the device's prefix that needs to be obfuscated in this case, so the host randomizing its addresses in a sparse space doesn't help. Tom > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jun 15 20:51:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63125128B8D for ; Thu, 15 Jun 2017 20:51:36 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUYBDrEeW6A0 for ; Thu, 15 Jun 2017 20:51:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D9C127BA3 for ; Thu, 15 Jun 2017 20:51:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4758534930F; Fri, 16 Jun 2017 03:51:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2A658160069; Fri, 16 Jun 2017 03:51:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E22BB16007A; Fri, 16 Jun 2017 03:51:30 +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 318DcmP6gfGz; Fri, 16 Jun 2017 03:51:30 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 49050160069; Fri, 16 Jun 2017 03:51:30 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7F0FE7BCB631; Fri, 16 Jun 2017 13:51:28 +1000 (AEST) To: "Manfredi, Albert E" Cc: Brian E Carpenter , "ipv6@ietf.org" From: Mark Andrews References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> Subject: Re: Tussles in IPv6 Land In-reply-to: Your message of "Fri, 16 Jun 2017 02:38:39 +0000." Date: Fri, 16 Jun 2017 13:51:28 +1000 Message-Id: <20170616035128.7F0FE7BCB631@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 03:51:36 -0000 In message , "M anfredi, Albert E" writes: > Brian, let me reconstruct my post as it was written: > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > >> I agree with this general line of thinking, and I'd also point > >> out that as computers become faster, this security benefit will > >> decrease and then vanish. Really, to create a vast address space, > >> and then after the fact, establish "rules" that require that vast > >> address space to be only **very** sparsely used, is > >> counterproductive? > > > > The /64 boundary was established by RFC2373 (July 1998). Hardly > > after the fact. > > The 64-bit boundary is not the issue here. The issue is that this 128-bit > address space was not initially intended to be forever very sparsely > populated, for a security reason. In fact, when the IID was meant to > consist of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs > were hardly any sort of security measure. We're now saying, in spite of > the hype about this vast address space, that at least the bottom 64 bits > of it, if not also the prefix 64 bits, must be very sparsely populated. > So much for vast address space, right? The security properties of 48 bit mac addresses were very much discussed when the prefix size was being choosen. They still prevented remote scanning of the subnet space to find the hosts in the subnet. Random assignmemt just improved on that by removing clustering effects. So no it wasn't after the fact, it was part of the rational for the original assignment size. > So, when I said "after the fact," I was talking about the security rationale. > That definitely came after the fact. No. > >> Why isn't is better to use real security measures, such as TLS? > > > > Because sparse addresses and e2e security solve very, very different > > security problems. > > Well, I contend there's some intersection of sets there. Anonymity > becomes less crucial if the content is encrypted. And there are other > ways, probably better ways, of achieving anonymity, than sparse usage, > such as short address lifetimes. Plus, as security measure, 64 bits > becomes less and less believable, in a time when we must use 128 or > preferably 256 bits for effective security keys. So we really need to put > this one security aid in perspective, I think. It seems to be given more > emphasis than it deserves? Anonymity isn't the only possible benefit. You only get anonymity when you share the subnet with lots of other people which isn't the case most of the time. This was well known when the /64 decision was made. > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 15 20:57:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39BA128B8D for ; Thu, 15 Jun 2017 20:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbwLMTTPaPfO for ; Thu, 15 Jun 2017 20:57:41 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F876127286 for ; Thu, 15 Jun 2017 20:57:40 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id p62so16617809vkp.0 for ; Thu, 15 Jun 2017 20:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rGyxz/pp1JqYq2PEstKOb0EsRQEFYF3z/P+v9GtXcOg=; b=fOVav61BFX2dnp/LlkdMFex3Dw+b7wgnTeE2Q+5B0x8kKCs36lmmfLeGLAk8r4DU3G nC2luU8gHDiXFKOWBcyURANj/IYSBAprFvr7sDb3e9ikshHBszEJP5EPMVTeCWcQ2xa0 mCTGHRx6FIvIaI0vzOay0sFdWJclrpw6uW6+WGsexVruCMUMwVacsCtwDPW1F9DK3cs7 KQfQHMn5h0XZyZfGWkw2J8fEtHK4iPZGRiixg6kQGEEgrS5db5aXgf1j77beKXO1R3sJ jZJojAFEL6OMhrgDJXxstpYUIMGYLuOncjbBQZ1nUmHuhdaScc/ZCeOiGzhg5i73dqBj R5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rGyxz/pp1JqYq2PEstKOb0EsRQEFYF3z/P+v9GtXcOg=; b=BlURwYYotzzv/d7evSMwBtoYfl50OP7KQODHvQOPv1dSug3XMkam3wO/vCIJWyVEhr lIWjjN0uwxSZHw0/9k68afe1iYhFH4rDVtO/znx+F2xMKb8dtdb9ZLbA09/WepOYfFzu jDJcfzc7dEtpKmTfEOaWHpASE5CnlusSOv7nravX+mmVPz6dBDVTm0TXrWnPanWw3lBZ K0R0RPo3UPr8OTRej5DZBITlc0GPSq9XNA07piQpsx9WervNb3BHBrYg7yHvzsf4W6et PCdrmXwJOrA/PnEC2chPUkhWKCyoF2Udr8doEeSH01CSv+rwZtKX9+mFmdqgZtGWz7b4 FUsw== X-Gm-Message-State: AKS2vOyWklTl3vz11Yt5KRF4Owe1d4DFSbeXvWfZQUalFSoDMOrOC2n2 b5+dk51hW3JUTahTrPMM/qgvaCYN98sj X-Received: by 10.31.236.193 with SMTP id k184mr4811777vkh.96.1497585459921; Thu, 15 Jun 2017 20:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 15 Jun 2017 20:57:18 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> From: Lorenzo Colitti Date: Fri, 16 Jun 2017 12:57:18 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Brian E Carpenter , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c08b3d25c86ce05520bc987" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 03:57:43 -0000 --94eb2c08b3d25c86ce05520bc987 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 16, 2017 at 12:31 PM, Tom Herbert wrote: > I believe both IPwave and the upcoming IDEAS BOF are discussing > methods to obfuscate addresses for the purpose to prevent tracking of > mobile devices (like tracking the location of a car as it drives down > the road). It's the device's prefix that needs to be obfuscated in > this case, so the host randomizing its addresses in a sparse space > doesn't help. > How are they planning to solve the mobility problem if the device's prefix changes all the time? --94eb2c08b3d25c86ce05520bc987 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 16, 2017 at 12:31 PM, Tom Herbert <tom@herbertland.com> wrote:
I believe both IPwave and th= e upcoming IDEAS BOF are discussing
methods to obfuscate addresses for the purpose to prevent tracking of
mobile devices (like tracking the location of a car as it drives down
the road). It's the device's prefix that needs to be obfuscated in<= br> this case, so the host randomizing its addresses in a sparse space
doesn't help.

How are they planning= to solve the mobility problem if the device's prefix changes all the t= ime?
--94eb2c08b3d25c86ce05520bc987-- From nobody Thu Jun 15 21:40:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4420124D6C for ; Thu, 15 Jun 2017 21:40:07 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRRzoaVJV9vO for ; Thu, 15 Jun 2017 21:40:05 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 9151A1200F3 for ; Thu, 15 Jun 2017 21:40:05 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id j53so5783410uaa.2 for ; Thu, 15 Jun 2017 21:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/tbDLqGzf0tYJKSmLgVJVUMx66z6FTs25Rjh4yTjefA=; b=bNNIrOCrF+1sHrOWzoGtMZZ4s3CTCDYimECfkjjgyNcsOm1qkrJOz8RBvl7MGTaAPQ F+28YiL+ISLL7hxKtLUfI4ougPInS7+Ds/7Hch3UHoqQOY/Q9jjhxi5dPX6hSKjHc/Kk C3Oe70Guai68T7UMeCRppTZoZKMQ5jHdStlGAUzqjZUPSCGU6JGmZg5KG0X4hm+JYSZb tRpMyf7vz2q8U/ketI2sLhU6Gic5l0VZCyYDa0Nu54H9xwHI0sdw2MKfUY1CH4tiJfiQ YX9dt/qxMHcJlNDW4Nku+95ipohfYJVuAd0JHdYTuKcEMNFQ1Hy+NLIIL9iZT0dUp1Ie 5tKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/tbDLqGzf0tYJKSmLgVJVUMx66z6FTs25Rjh4yTjefA=; b=p/rNxWM0eQwzTF24oMPmMkGVdG/MbaGGPDQqtv3iQXtOIg9Dj0KVTs0UgRlLZFpBT7 GRl4xkR4FsgUiWCgSRjeeN49M7AccF4LB4kq3FHZAzzDw1+JIOh23jDci23HKUZEBPgv lzkfD2pjAXy/X0SHDXlrBY0rfIHnR8UaYJtLNNF2mN5adq4YKd5FcluBwjsqP+k2/+vM ecQgIuoecRqyT/COYa84qf6HCnP4+27AXXqwC8FptG90bX/ktqvelbT6oJbZmd14BX1E +CHtENWXmc3CBOOCchxfu+FBI8C6ykm/nEtCj21ZkBIM7+gkgIrOJzsximQIErHIti5/ DS8Q== X-Gm-Message-State: AKS2vOwlnO+qQw5ykaWG69b3xK8Z+MLE+Xszn2CzOuAzOCabWb6AVQLk uNBtVIUjmVo8BPNcpJXHqK7SEQWKgyWV X-Received: by 10.176.83.16 with SMTP id x16mr5904611uax.11.1497588004482; Thu, 15 Jun 2017 21:40:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 15 Jun 2017 21:39:43 -0700 (PDT) In-Reply-To: References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> From: Lorenzo Colitti Date: Fri, 16 Jun 2017 13:39:43 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Brian E Carpenter Cc: IETF IPv6 Mailing List , Peter Hessler Content-Type: multipart/alternative; boundary="94eb2c18f1ac07502605520c61ac" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 04:40:08 -0000 --94eb2c18f1ac07502605520c61ac Content-Type: text/plain; charset="UTF-8" On Fri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I think that portability out of the box is a much stronger argument. Peter > has chosen to hand-craft his networks. ... and hand-crafting networks is precisely what network operators do. It is, after all, their job. > Most people (99.99%) simply unwrap > their new device, ignore the "quick start" guide, and switch it on. There > is an enormous market incentive for that to work 100% of the time, which is > an enormous incentive to stick with /64. > Your premise is correct but your conclusion is wrong. Yes, there is an enormous incentive for things to work 100% of the time. But that does not mean stick to /64. Quite the opposite - it means "work regardless of the prefix length on the network". Before you disagree with me, observe the fact that most implementations work on Peter's network, today, even though Peter's network is in complete violation of RFC 4291. Not to mention the late lamented /48 recommendation to ISPs. Again, > nobody is trying to sabotage /64 as the norm for SLAAC networks, and > nobody is trying to sabotage SLAAC as the norm for plug and play. > I know that you're not *trying* to do that. I'm trying to make you realize that by pushing for a non-fixed boundary you *are* doing it. As for "nobody" - it's not true that nobody is trying to do it. If you read Job and Peter's statements carefully, you'll see that they are. > I agree. But at the same time we need to be honest in our specs. RFC4291 > does not describe the deployed architecture accurately, which is why > we have to fix it if we're serious about Internet Standard status. > That's not true for any value of "accurate" that is meaningful in the real world. I'd argue that RFC 4291 (with the exception made in 6164), is accurate for at least 99.9% of links on the public Internet. Making it accurate for the remaining 0.1% is not worth removing the text in the standard that stops operators like Peter being able to claim that hosts should support addressing models that are bad for their users. --94eb2c18f1ac07502605520c61ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
I think that portability out of the box is a much stronger arg= ument. Peter
has chosen to hand-craft his networks.

... = and hand-crafting networks is precisely what network operators do. It is, a= fter all, their job.
=C2=A0
Most people (99.99%) simply unwrap
their new device, ignore the "quick start" guide, and switch it o= n. There
is an enormous market incentive for that to work 100% of the time, which is=
an enormous incentive to stick with /64.

Your premise is correct but your conclusion is wrong. Yes, there is an en= ormous incentive for things to work 100% of the time. But that does not mea= n stick to /64. Quite the opposite - it means "work regardless of the = prefix length on the network". Before you disagree with me, observe th= e fact that most implementations work on Peter's network, today, even t= hough Peter's network is in complete violation of RFC 4291.
<= br>
Not to mention t= he late lamented /48 recommendation to ISPs. Again,
nobody is trying to sabotage /64 as the norm for SLAAC networks, and
nobody is trying to sabotage SLAAC as the norm for plug and play.

I know that you're not *trying* to do that. = I'm trying to make you realize that by pushing for a non-fixed boundary= you *are* doing it.

As for "nobody" - i= t's not true that nobody is trying to do it. If you read Job and Peter&= #39;s statements carefully, you'll see that they are.
=C2=A0<= /div>
I agree. But at the = same time we need to be honest in our specs. RFC4291
does not describe the deployed architecture accurately, which is why
we have to fix it if we're serious about Internet Standard status.
<= /blockquote>

That's not true for any value of "= accurate" that is meaningful in the real world. I'd argue that RFC= 4291 (with the exception made in 6164), is accurate for at least 99.9% of = links on the public Internet.

Making it accurate f= or the remaining 0.1% is not worth removing the text in the standard that s= tops operators like Peter being able to claim that hosts should support add= ressing models that are bad for their users.
--94eb2c18f1ac07502605520c61ac-- From nobody Thu Jun 15 22:07:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C284129420 for ; Thu, 15 Jun 2017 22:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5vTMZmBNw1a for ; Thu, 15 Jun 2017 22:07:26 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6358B1200F3 for ; Thu, 15 Jun 2017 22:07:21 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id d64so1259010wmf.1 for ; Thu, 15 Jun 2017 22:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eTYFG4efwi9Gp1+XNhTYHwhRJfh2JHIUzJzlLfLlxOw=; b=Vc43VIi4BKlhouR+6LmzS9ZNjykW8IvpGOnHaGr9fIC9PX1f4gEtCUvfBdAslPmw39 fO6v4rKGw7yjc1IhevhXtA+tO3TB4on6Eeyhl7IALB4F7O3oBtqDY9LgGOf3VeJtr4gI aGCruW9uE9w6Rl1YrpdyUr+bhFp9Ma76bCXv3HhPL2f9ciqm5Kx3EqUW2Ho1gCOu6H2o d3wfTvsi/2y6dWQm0B8O127pQSn3tH2PoGvTBZIURcysJyki7T5mtXTix2COZM0+w5ZU msifBcLIcaDu72nM+J1uMQdb7iC4xPrxGzvRNPycT3yB8FSiYIhuAzXHW++miGpO744o SNMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=eTYFG4efwi9Gp1+XNhTYHwhRJfh2JHIUzJzlLfLlxOw=; b=pSkTLXRDlQXru/CmZKZvSnlyUY0I3ldBtfTz0o47N6TXPQ10ikZ54aIozlNsufSkhW Ncrm/CIZ//bE0yQp4ybbWablGvZbNJNmPVrDRL4hQdCgifyil6mRoRcIs50uuioMXhV7 rhGwuAsdb7CNFtOd8dgwqzlx/tv26F7UmpVAnZEidevb25Xlu1QkPiZvdpX+8S4s4pS9 fchtgFg1G0IZjgtu0fe38eXo0wyS/9XKvdDJJcWeKzH/ZfKfd4SS7vlx+vCpYNFwAF67 emZ/X7dUmuQNd+AEcdxRBL1ptwrik3vKZgdfMh60kGRqrVMF+UpAHt+nceugJGowIJvV fIwg== X-Gm-Message-State: AKS2vOwtjMUHXuFEtJMRmL01isVbUtEztolawdf8Y2R523SimIFYfi2w 0k5sG44bvHhQRPYI X-Received: by 10.80.151.71 with SMTP id d7mr5974028edb.163.1497589639857; Thu, 15 Jun 2017 22:07:19 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:48ae:a8c:82e7:c07b]) by smtp.gmail.com with ESMTPSA id m30sm732859edd.11.2017.06.15.22.07.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 22:07:18 -0700 (PDT) Date: Fri, 16 Jun 2017 07:07:18 +0200 From: Job Snijders To: Lorenzo Colitti Cc: Brian E Carpenter , IETF IPv6 Mailing List , Peter Hessler Subject: Re: draft-bourbaki-6man-classless-ipv6-00 Message-ID: <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170428 (1.8.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 05:07:28 -0000 On Fri, Jun 16, 2017 at 01:39:43PM +0900, Lorenzo Colitti wrote: > On Fri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter wrote: > > Most people (99.99%) simply unwrap their new device, ignore the > > "quick start" guide, and switch it on. There is an enormous market > > incentive for that to work 100% of the time, which is an enormous > > incentive to stick with /64. > > Your premise is correct but your conclusion is wrong. Yes, there is an > enormous incentive for things to work 100% of the time. But that does > not mean stick to /64. Quite the opposite - it means "work regardless > of the prefix length on the network". Before you disagree with me, > observe the fact that most implementations work on Peter's network, > today, even though Peter's network is in complete violation of RFC > 4291. > > > Not to mention the late lamented /48 recommendation to ISPs. Again, > > nobody is trying to sabotage /64 as the norm for SLAAC networks, and > > nobody is trying to sabotage SLAAC as the norm for plug and play. > > I know that you're not *trying* to do that. I'm trying to make you > realize that by pushing for a non-fixed boundary you *are* doing it. > > As for "nobody" - it's not true that nobody is trying to do it. If you > read Job and Peter's statements carefully, you'll see that they are. That is quite the accusation. > > I agree. But at the same time we need to be honest in our specs. > > RFC4291 does not describe the deployed architecture accurately, > > which is why we have to fix it if we're serious about Internet > > Standard status. > > That's not true for any value of "accurate" that is meaningful in the > real world. I'd argue that RFC 4291 (with the exception made in 6164), > is accurate for at least 99.9% of links on the public Internet. Even if it is as low as 0.1%, has it ever occurred to you that that small number might serve a majority of IPv6 users in non-trivial matters? For example, their ability to reach each other? It is a shame to see such blatant disregard for this group of IPv6 users. I've shown before that 6164 accomodates some, but not all cases for both historic and pragmatic reasons. 6164 does not solve all operational challenges. > Making it accurate for the remaining 0.1% is not worth removing the > text in the standard that stops operators like Peter being able to > claim that hosts should support addressing models that are bad for > their users. You realise that the above remarks come across as extremely judgemental? Who do you think you are to know what is good for all groups of users? I still simply argue that nobody can know what is needed in every context in every situation, pretending otherwise would be folly. It is painful to see you view operators as some kind of minority (a nuisance even?), and as such they don't need or deserve to be accommodated by standards. Regards, Job From nobody Thu Jun 15 23:16:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C65120724 for ; Thu, 15 Jun 2017 23:16:34 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykpp9ZM2G3Kf for ; Thu, 15 Jun 2017 23:16:32 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 5BDBC129447 for ; Thu, 15 Jun 2017 23:16:32 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id g40so20279316uaa.3 for ; Thu, 15 Jun 2017 23:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xk6nHXKbMm2grL5ApwCGeuuHly8u55SSxuAkqluHapU=; b=Jlblq0xc3D7Q/AoUiN2Z6UC2mOxFbnCmdnYRe4ex+iqs4xh6oJL8A44Azyr0CasM6m JS6IeCc2qlseM0cDiURq2teTskD6nEPKO5H8/hHzq5V2dbhEuqX8E8N2aeY1J3byY6EO AxRDVCCxeVDwbSR6nnnK8fuoaSYsjoxothIXoSk37CJyJ4t8H1R/WNalxsEJ+AcNR2WD igo5Zpg5WbTAL6+E2rFijrejPA2RKGTMGb3pGT7ad+eM03LOt8tzST6Y9LP3SZIA/OUr /7P15eaAO+p2fQpqel53gEHfYp3wohIfjS7khy+mrqz98IVaECs/Z7oOfZoEQwnAs7ad 3Jbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xk6nHXKbMm2grL5ApwCGeuuHly8u55SSxuAkqluHapU=; b=c4QVQMQY1V9446X3i+HlgJm2aUkNbToRoLiombeiMIRFRnu7mD8ZOqLYME/n1zJTAp rMg+p3IN/wyGKwE4CMSxkB1hhpwlTkOh+VWQG56zECsClBYiUKCVUhmp8IKuk1+KJpvf UehoYad+yWxot7lUvs6CGe3vlPEdCIEg/CVPcfJpF62mEdkr6LsilG4WZkDk0H3E8wrh u0XDwTQI28SZefGcFK6omuZyp/gORT/MSPx4j7GjU3+xnZ7e4X/WEEFqNxCzYicA6jCF 0WITJKz64OuvPpUytSV9Asnxg59EM5BXMxeMaxcjZOt6oob5Fikwf/kU+jA/f0rvVRIm GagQ== X-Gm-Message-State: AKS2vOwGgAB4Zq57SfsED2oHYQqmyQ7Q3UuF7HLEsRSatD4kIkVbFAaL OhHP7qu/Gr3PzqGm2WTQior+EZAFxEn+ X-Received: by 10.176.27.90 with SMTP id n26mr5671510uai.94.1497593791341; Thu, 15 Jun 2017 23:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Thu, 15 Jun 2017 23:16:10 -0700 (PDT) In-Reply-To: <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> From: Lorenzo Colitti Date: Fri, 16 Jun 2017 15:16:10 +0900 Message-ID: Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Job Snijders Cc: Brian E Carpenter , IETF IPv6 Mailing List , Peter Hessler Content-Type: multipart/alternative; boundary="f403045ea092f3c7a605520db945" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 06:16:35 -0000 --f403045ea092f3c7a605520db945 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 16, 2017 at 2:07 PM, Job Snijders wrote: > > > Not to mention the late lamented /48 recommendation to ISPs. Again, > > > nobody is trying to sabotage /64 as the norm for SLAAC networks, and > > > nobody is trying to sabotage SLAAC as the norm for plug and play. > > > > I know that you're not *trying* to do that. I'm trying to make you > > realize that by pushing for a non-fixed boundary you *are* doing it. > > > > As for "nobody" - it's not true that nobody is trying to do it. If you > > read Job and Peter's statements carefully, you'll see that they are. > > That is quite the accusation. > I don't see any other interpretation of your statement "can expand the routed network at the edges, in absence of PD" in these slides . Unless you mean that those extended networks are not going to be plug and play. > > Making it accurate for the remaining 0.1% is not worth removing the > > text in the standard that stops operators like Peter being able to > > claim that hosts should support addressing models that are bad for > > their users. > > You realise that the above remarks come across as extremely judgemental? > Who do you think you are to know what is good for all groups of users? > My apologies, I thought it was clear that I'm not talking about all users. To clarify: I'm talking about users of general purpose client devices. My statement that operators should not be able to claim that implementers of those devices need to support addressing models that are bad for their users. I stand by that statement. Right now those practices are not allowed by the standards, and I'd like to keep it that way. > It is painful to see you view operators as some kind of minority (a > nuisance even?), and as such they don't need or deserve to be > accommodated by standards. > Networking standards do not accommodate people, they specify the behaviour of networking devices. So let's focus on the technical needs. >From a technical perspective, the main desire I've heard from operators so far is that they would like to use non-/64 prefix lengths on router interfaces. It's not necessary to change the 64-bit boundary for that to be allowed. Saying that the limitation does not cover manually-configured addresses would meet that need. As I've said many, many times before - if there are other problems that need to be solved, let's start from those and design solutions for them. Saying (as the draft does) that the 64-bit boundary "is the last remnant of IPv6 classful addressing" might conceivably be accurate, but it says nothing about which problems, if any, it causes, and thus says nothing about what solutions we need. It's clear what solutions the draft authors think we need, but unless we come to consensus on that solution, that's not useful. --f403045ea092f3c7a605520db945 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 16, 2017 at 2:07 PM, Job Snijders <job@instituu= t.net> wrote:
> > Not to mention= the late lamented /48 recommendation to ISPs. Again,
> > nobody is trying to sabotage /64 as the norm for SLAAC networks, = and
> > nobody is trying to sabotage SLAAC as the norm for plug and play.=
>
> I know that you're not *trying* to do that. I'm trying to make= you
> realize that by pushing for a non-fixed boundary you *are* doing it. >
> As for "nobody" - it's not true that nobody is trying to= do it. If you
> read Job and Peter's statements carefully, you'll see that the= y are.

That is quite the accusation.

=
I don't see any other interpretation of your statement "can e= xpand the routed network at the edges, in absence of PD" in these slides. Unless you mean that tho= se extended networks are not going to be plug and play.
=C2=A0
> Making it accurate for t= he remaining 0.1% is not worth removing the
> text in the standard that stops operators like Peter being able to
> claim that hosts should support addressing models that are bad for
> their users.

You realise that the above remarks come across as extremely judgemen= tal?
Who do you think you are to know what is good for all groups of users?
<= /blockquote>

My apologies, I thought it was clear= that I'm not talking about all users. To clarify: I'm talking abou= t users of general purpose client devices. My statement that operators shou= ld not be able to claim that implementers of those devices need to support = addressing models that are bad for their users. I stand by that statement. = Right now those practices are not allowed by the standards, and I'd lik= e to keep it that way.
=C2=A0
It is painful to see you view operat= ors as some kind of minority (a
nuisance even?), and as such they don't need or deserve to be
accommodated by standards.

Netwo= rking standards do not accommodate people, they specify the behaviour of ne= tworking devices. So let's focus on the technical needs.

=
From a technical perspective, the main desire I've hear= d from operators so far is that they would like to use non-/64 prefix lengt= hs on router interfaces. It's not necessary to change the 64-bit bounda= ry for that to be allowed. Saying that the limitation does not cover manual= ly-configured addresses would meet that need.

As I've said many, many times before - if there are other problems th= at need to be solved, let's start from those and design solutions for t= hem.=C2=A0 Saying (as the draft does) that the 64-bit boundary "is the= last remnant of IPv6 classful addressing" might conceivably be accura= te, but it says nothing about which problems, if any, it causes, and thus s= ays nothing about what solutions we need.

It's= clear what solutions the draft authors think we need, but unless we come t= o consensus on that solution, that's not useful.
--f403045ea092f3c7a605520db945-- From nobody Fri Jun 16 01:54:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFAE13170D for ; Fri, 16 Jun 2017 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri4BYs2rpPyZ for ; Fri, 16 Jun 2017 01:54:40 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532C213170C for ; Fri, 16 Jun 2017 01:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1497603276; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=R2AhwjEQCbDR8XdKcGUPTKSlNMPJG2a/j69+fNVbptU=; b=XRXRCXqyZrnHYdbbqYcM7hJAgGJmz2NrhLygqZUHf938QIKpskddF2BK2js4aJ7z/viYAzMdy1G1qIoBxT4Vuqpa9F4CK+5zHHNMmq66Tc/7KoUYewtbym7jupX3Ts0iQ6ZVZUCDHEUhLc0A1gZwSYU8WtYl+0nyWjTw9b0668k= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0177.outbound.protection.outlook.com [213.199.180.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-4-X1VzomagPmOiI1e-qrAiOA-1; Fri, 16 Jun 2017 09:54:34 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0727.eurprd07.prod.outlook.com (10.160.6.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Fri, 16 Jun 2017 08:54:32 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd%14]) with mapi id 15.01.1199.006; Fri, 16 Jun 2017 08:54:32 +0000 From: Tim Chown To: Simon Hobson CC: 6man WG Subject: Re: Hitting the tech news Thread-Topic: Hitting the tech news Thread-Index: AQHS5fVw2TF0w2KAlk6DA3vikAG5MqImIMQAgABYJgCAALd9AA== Date: Fri, 16 Jun 2017 08:54:32 +0000 Message-ID: <66F1A83F-3847-4461-91D7-3B494FAAD842@jisc.ac.uk> References: <7B18897F-5B90-4BF8-AE87-1F116A825F27@consulintel.es> <0EDD104B-7D4C-4749-9548-6D5C24033298@thehobsons.co.uk> In-Reply-To: <0EDD104B-7D4C-4749-9548-6D5C24033298@thehobsons.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [94.117.107.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0727; 7:NwNasP481ku9Ilb59jjJETf6/LVTzIo7FqU5bYMwt/6ae3FnxeKCf3o8rKvYqCTDCoeMqlmIBuenpS/JyX0bdawnqppW9l/jsNKqIsLDyVqIyQHAlzSCLloFmlbDL2z2YtxBR0mzt3Q6fBQFtI73LwfjWmVgR19xNw8vfH9XkRMNN4MGJR9ItX22luPqDKFeL8TtA7EcReIKJAZINtDyVITP0GHAlzGSwkk5ad5dDpqGj7ajdokBylKByLAmgn3b/HDL1QZMVCJ+Kh88XG6Mv3js8lXVCENDIvYcrZQgcP8Ks17NF5RCDgjh7de5dCRDQm8atRDz2HKGVP/lUsv+qw==; 20:Wk2/bFDbBvkXDmANRZ+vBbVTHL6+DZm/c6d32162ww7AArFpXdEGp/hoB3GdzqqKYxgtq88D2m83No3XfWMPVst9z7duW0zgzN0rpXDPU9cBrA+wCxcpHpxJ0C7AsMK6SbwGkOuJ6Ydy9VlNnv5PWbLYxkLV5odidc2sf8gw2Ag= x-ms-office365-filtering-correlation-id: 3dd77ea4-2945-4b74-8fa4-08d4b4954e37 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB0727; x-ms-traffictypediagnostic: AM3PR07MB0727: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0727; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0727; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39400400002)(24454002)(8936002)(5250100002)(53936002)(42882006)(189998001)(81166006)(83716003)(2906002)(229853002)(66066001)(50226002)(86362001)(3480700004)(6916009)(2950100002)(38730400002)(6246003)(305945005)(33656002)(110136004)(6486002)(82746002)(2900100001)(7736002)(8676002)(76176999)(50986999)(53546009)(3846002)(102836003)(25786009)(74482002)(6116002)(3660700001)(99286003)(36756003)(6436002)(14454004)(4326008)(6512007)(478600001)(6306002)(72206003)(966005)(6506006)(3280700002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0727; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <018E956334E30C45A4E49E8A560DA267@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2017 08:54:32.0422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0727 X-MC-Unique: X1VzomagPmOiI1e-qrAiOA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 08:54:44 -0000 PiBPbiAxNSBKdW4gMjAxNywgYXQgMjI6NTcsIFNpbW9uIEhvYnNvbiA8bGludXhAdGhlaG9ic29u cy5jby51az4gd3JvdGU6DQo+IA0KPiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRA Y29uc3VsaW50ZWwuZXM+IHdyb3RlOg0KPiANCj4+IFRoZSBhdXRob3Igb2YgdGhlIGFydGljbGUg Y2hhbmdlZCBteSBmYW1pbHkgbmFtZSDigKYNCj4gDQo+IEkgaW1hZ2luZSB0aGF0IHdvdWxkIGJl IGEgY29tbW9uIHByb2JsZW0gd2hlbiBkZWFsaW5nIHdpdGggdXMgcGVza3kgbmF0aXZlIGVuZ2xp c2ggc3BlYWtlcnMuIFRCSCBpdCdzIG9ubHkgYWNjaWRlbnRhbCAoaGF2aW5nIHJlYWQgYWJvdXQg aXQgc29tZXdoZXJlIHNvbWUgdGltZSBhZ28pIHRoYXQgSSBrbm93IGVub3VnaCB0byByZWFsaXNl IHdoYXQncyBiZWVuIGRvbmUgdGhlcmUuDQo+IA0KPiBGV0lXIEkgY29tcGxldGVseSBhZ3JlZSB3 aXRoIHlvdXIgY2FsbCBmb3IgcGFydGljaXBhdGlvbi4gTm8gb2ZmZW5jZSBpbnRlbmRlZCB0byB0 aG9zZSB0aGF0IGFscmVhZHkgcGFydGljaXBhdGUsIGJ1dCBpdCBpcyBjbGVhciB0aGF0IHRoZSBk aXNjdXNzaW9ucyBhcmUgZG9taW5hdGVkIGJ5IHBlb3BsZSB3b3JraW5nIHdpdGggImJpZyBuZXR3 b3JrcyIgYW5kIHdpdGggYSAiYmlnIG5ldHdvcmsvb3BlcmF0aW9uIiBtZW50YWxpdHkuIFBpY2tp bmcgdXAgb24ganVzdCBvbmUgcG9pbnQgaW4geW91ciBwb3N0IG9uIHRoZSBOQU5PRyBsaXN0LCBz cGVha2luZyBhcyBhIHRlY2huaWNhbGx5IGxpdGVyYXRlIGluZGl2aWR1YWwgLSBpZiBhbiBJU1Ag aW5zaXN0cyB0aGF0IEkgaGF2ZSB0byB1c2UgdGhlaXIgcm91dGVyLCB0aGVuIHRoZXkgZG9uJ3Qg Z2V0IG15IGJ1c2luZXNzPHBlcmlvZD4uIFNldmVyYWwgSVNQcyBpbiB0aGUgVUsgZG8ganVzdCB0 aGF0IC0gYW5kIEkgY2FuIHNlZSBzb21lIGNvbW1lcmNpYWwganVzdGlmaWNhdGlvbiBmb3IgaXQg LSBidXQgb2YgYWxsIHRoZSBvbmVzIHRoYXQgSSBoYXZlIGFueSBleHBlcmllbmNlIHdpdGggKHdp dGggbXkgb3RoZXIgaGF0IG9uIGFzIGFuIGVtcGxveWVlIG9mIGEgc21hbGwgSVQgc2VydmljZXMg cHJvdmlkZXIpIGhhdmUgc2lnbmlmaWNhbnQgImlzc3VlcyIgKG1vc3RseSBhIGNyYXAgQ1BFIHRo YXQganVzdCBkb2Vzbid0IHN1cHBvcnQgYW55dGhpbmcgcGFzdCAiZ2l2aW5nIGludGVybmV0IGFj Y2VzcyB0byBkZXZpY2Vz4oCdKS4NCg0KSeKAmXZlIGNvbWUgYWNyb3NzIGEgZmV3IGluIHRoZSBV SyB0aGF0IHNheSDigJx3ZSB3b27igJl0IHN1cHBvcnQgeW91IGlmIHlvdSBydW4gc29tZXRoaW5n IG90aGVyIHRoYW4gdGhlIHJvdXRlciB3ZSBzZW5kIHlvdeKAnSwgd2hpY2ggaXMgYSBsaXR0bGUg ZGlmZmVyZW50IHRvIGluc2lzdGluZyB5b3UgdXNlIHRoZWlyIGVxdWlwbWVudC4NCg0KSSBub3Rl ZCBpbiBTa3nigJlzIFVLTk9GIHByZXNlbnRhdGlvbigqKSBvbiB0aGVpciBVSyBJUHY2IGRlcGxv eW1lbnQsIG92ZXIgOTAlIG9mIHRoZWlyIDVNIG9yIHNvIGN1c3RvbWVycyBoYWQgSVB2NiBlbmFi bGVkLCBidXQgMiUgd2VyZSB1c2luZyB0aGVpciBvd24gZXF1aXBtZW50LCBzbyBtYXkgb3IgbWF5 IG5vdCBoYXZlIElQdjYuICBUaGF04oCZcyAxMDAsMDAwIHVzZXJzLg0KIA0KPiBPbmUgZXhhbXBs ZSBvZiBkZWZpY2llbmNpZXMgaW4gQ1BFIHJvdXRlcnMgKGF0IGxlYXN0IGluIHRoZSBJUHY0IHNw YWNlKSBpcyBub3QgaGF2aW5nIGFueSBtZWFucyB0byBmb3J3YXJkIGFueXRoaW5nIG90aGVyIHRo YW4gVURQIG9yIFRDUCB0cmFmZmljIC0gd2hpY2ggbWVhbnMgeW91IGNhbid0IHJ1biBhIEdSRSB0 dW5uZWwgdGhyb3VnaCB0aGVtIGluIG9yZGVyIHRvIGdldCBJUHY2IHZpYSAoaW4gdGhpcyBjYXNl KSBIdXJyaWNhbmUgRWxlY3RyaWMncyB0dW5uZWxicm9rZXIgc2VydmljZS4gT3Igd2l0aCBteSB3 b3JrIGhhdCBvbiwgbm8gcHJvcGVyIHN1cHBvcnQgZm9yIHNpdGUtc2l0ZSBWUE5zIHdoaWNoIGFy ZSByZWFsbHkgY29tbW9uIGluIHRoZSBzbWFsbCBidXNpbmVzcyB3b3JsZC4gQXQgbGVhc3QgaWYg dGhlIElTUCBzdXBwb3J0cyB1c2luZyBhbm90aGVyIHJvdXRlciB0aGVuIHlvdSBjYW4gd29yayBh cm91bmQgdGhpcyAtIGJ1dCB1bmZvcnR1bmF0ZWx5IGF0IHdvcmsgd2UndmUgaGFkIGNhc2VzIHdo ZXJlIHRoaXMgbGltaXRhdGlvbiBvbmx5IGNvbWVzIHRvIGxpZ2h0IHdoZW4geW91IGFzayBmb3Ig KGluIG91ciBjYXNlLCB1c3VhbGx5IERTTCkgYWNjZXNzIGRldGFpbHMgYW5kIHRoZSBJU1AgcmVm dXNlcyB0byBwcm92aWRlIHRoZW0gYW5kIGl0J3MgdG9vIGxhdGUgdG8gdGVsbCB0aGVtIHdoZXJl IHRvIHNob3ZlIHRoZXkgc2VydmljZSAoaW4gbWFueSBjYXNlcywgdGhlIGN1c3RvbWVyIGhhcyBv cmRlcmVkIHRoZSBpbnRlcm5ldCBzZXJ2aWNlLCBhbmQgd2UgbGF0ZXIgZ2V0IHRhc2tlZCB3aXRo IG1ha2luZyBpdCBkbyB0aGluZ3Mgb3RoZXIgdGhhbiAiZ2l2ZSBpbnRlcm5ldCBhY2Nlc3MgdG8g ZGV2aWNlcyIpLg0KDQpUaGUgc2l0ZS10by1zaXRlIFZQTiBpc3N1ZSBpcyBvbmUgYSB2ZXJ5IG11 Y2ggYWdyZWUgd2l0aCENCg0KVGltDQoNCigqKSBodHRwczovL2luZGljby51a25vZi5vcmcudWsv ZXZlbnQvMzUvbWF0ZXJpYWwvc2xpZGVzLzE/Y29udHJpYklkPTU= From nobody Fri Jun 16 02:31:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930F7129B31 for ; Fri, 16 Jun 2017 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxkcw2X_01nP for ; Fri, 16 Jun 2017 02:31:46 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9D513176A for ; Fri, 16 Jun 2017 02:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497605502; x=1498210302; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=JMg/srzZtARZD2hm0X+PeieEj g1Q/0ZQ5YctzrUagV0=; b=XpcEDrZGuiyjRGIMuZEnr4XZ6sSR/EjgmTs0jTf8D x1YteD14i7KmKJ4lyFfpV7CvDpNGVCv+lNucljMSrlqqUwC1Qb/tnQB1HfCXdEVB HIYvQMkRG3vLlLKn/SXT9Q74lSxZ1h9v4yklhrcPyUnz7Nz3kszKis/tqL6tsd06 gg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=GPrMRaKOJR/lMZg9MpPhni3oGdp7ryddKzYC9i2I1bL6hW0yciYsW2ohZD6d Pe0FDr+sP8JKpiXaEDSw7AoE4USrl2/EzTiPHsaIVxBviVp3g5L3ipfCM H/KcBasI0ghAESxwGzOPc+VBR0OHdtXxo+RRjOo/VcHGi8cmgfMq1M=; X-MDAV-Processed: mail.consulintel.es, Fri, 16 Jun 2017 11:31:42 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 16 Jun 2017 11:31:40 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452128.msg for ; Fri, 16 Jun 2017 11:31:40 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170616:md50005452128::Wxht/74L5JA2P55x:00002ort X-Return-Path: prvs=1340bc8c94=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Fri, 16 Jun 2017 11:31:40 +0200 Subject: Re: Hitting the tech news From: JORDI PALET MARTINEZ To: 6man WG Message-ID: <1765E687-B6B2-4DC7-BDAA-BE1DE0B9EEF6@consulintel.es> Thread-Topic: Hitting the tech news References: <7B18897F-5B90-4BF8-AE87-1F116A825F27@consulintel.es> <0EDD104B-7D4C-4749-9548-6D5C24033298@thehobsons.co.uk> <66F1A83F-3847-4461-91D7-3B494FAAD842@jisc.ac.uk> In-Reply-To: <66F1A83F-3847-4461-91D7-3B494FAAD842@jisc.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 09:31:49 -0000 Responding in-line to both, Simon and Tim =E2=80=A6 -----Mensaje original----- De: ipv6 en nombre de Tim Chown Responder a: Fecha: viernes, 16 de junio de 2017, 10:54 Para: Simon Hobson CC: 6man WG Asunto: Re: Hitting the tech news > On 15 Jun 2017, at 22:57, Simon Hobson wrote= : >=20 > JORDI PALET MARTINEZ wrote: >=20 >> The author of the article changed my family name =E2=80=A6 >=20 > I imagine that would be a common problem when dealing with us pesky n= ative english speakers. TBH it's only accidental (having read about it some= where some time ago) that I know enough to realise what's been done there. [Jordi] Not an issue, I explained to the article author, also that he typed= something strange instead of CPE and both have been corrected overnight! >=20 > FWIW I completely agree with your call for participation. No offence = intended to those that already participate, but it is clear that the discus= sions are dominated by people working with "big networks" and with a "big n= etwork/operation" mentality. Picking up on just one point in your post on t= he NANOG list, speaking as a technically literate individual - if an ISP in= sists that I have to use their router, then they don't get my business. Several ISPs in the UK do just that - and I can see some commercial ju= stification for it - but of all the ones that I have any experience with (w= ith my other hat on as an employee of a small IT services provider) have si= gnificant "issues" (mostly a crap CPE that just doesn't support anything pa= st "giving internet access to devices=E2=80=9D). [Jordi] There is a very simple solution to that. If we have MUST instead of= SHOULD in our basic requirements, then all the CPEs will be interoperable,= so an ISP will not have a problem with any device (their own device or the= one you want to use, in fact they may not notice that you changed it). The= y may have *additional* functionalities, and that=E2=80=99s why you pay mor= e for one model or the other one (just a few examples more LAN ports, extra= WAN ports, support for USB 3, USB C, support for memory cards, backup with= an LTE interface, more powerful WiFi, etc., etc.), but also more =E2=80=9C= software=E2=80=9D options, nicer GUI, built in statistics, etc., etc. I=E2= =80=99ve worked with some very low cost Chinese products/vendors, and imple= mented for some trials, using OpenWRT, all the transition mechanism, all th= e =E2=80=9Cshould=E2=80=9D as =E2=80=9Cmust=E2=80=9D, etc., etc., etc., and= we didn=E2=80=99t had problems with memory, CPU, etc., etc. Those products= are available from 20USD (even cheaper if you use 100Mbps Ethernet instead= of 1Gig) and I=E2=80=99m sure in high volume prices will drop. Unfortunate= ly, we don't like MUST. =20 I=E2=80=99ve come across a few in the UK that say =E2=80=9Cwe won=E2=80= =99t support you if you run something other than the router we send you=E2= =80=9D, which is a little different to insisting you use their equipment. [Jordi] That=E2=80=99s ok, but still non ideal. =20 I noted in Sky=E2=80=99s UKNOF presentation(*) on their UK IPv6 deploym= ent, over 90% of their 5M or so customers had IPv6 enabled, but 2% were usi= ng their own equipment, so may or may not have IPv6. That=E2=80=99s 100,00= 0 users. [Jordi] Again, may be interoperability issue =E2=80=A6 =20 > One example of deficiencies in CPE routers (at least in the IPv4 spac= e) is not having any means to forward anything other than UDP or TCP traffi= c - which means you can't run a GRE tunnel through them in order to get IPv= 6 via (in this case) Hurricane Electric's tunnelbroker service. Or with my = work hat on, no proper support for site-site VPNs which are really common i= n the small business world. At least if the ISP supports using another rout= er then you can work around this - but unfortunately at work we've had case= s where this limitation only comes to light when you ask for (in our case, = usually DSL) access details and the ISP refuses to provide them and it's to= o late to tell them where to shove they service (in many cases, the custome= r has ordered the internet service, and we later get tasked with making it = do things other than "give internet access to devices"). [Jordi] I guess you mean 6in4 (protocol 41, the one used for HE, I run into= the same issue many times), not GRE (protocol 47), but in both cases, is a= matter of using a =E2=80=9CDMZ=E2=80=9D or =E2=80=9Cvirtual servers=E2=80= =9D. In most of the situations I=E2=80=99ve been, this option was available= , but not very well documented, or not working for anything different than = UDP/TCP/ICMP =E2=80=A6 Actually, we will need to check if there is an IPv4 = CPE RFC which states something about that =E2=80=A6 never looked at it, to = be honest! Same for VPNs =E2=80=A6 just different protocols. =20 The site-to-site VPN issue is one a very much agree with! =20 Tim =20 (*) https://indico.uknof.org.uk/event/35/material/slides/1?contribId=3D= 5 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Fri Jun 16 02:40:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458F213178A for ; Fri, 16 Jun 2017 02:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJdGqpEh0cA8 for ; Fri, 16 Jun 2017 02:40:00 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0105.outbound.protection.outlook.com [104.47.0.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8167313178E for ; Fri, 16 Jun 2017 02:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KZJWLXddr0T8Vj1DLGGHSNZrC9xITCx8RGSF9xsMHVs=; b=fOx//Ix5y5JZQCzjXSh/lqfiJKOSDmFJIWeDLxtaYtxwivRZ0179CQpBOUb+x9eja8LyxxHwlROjZ/T/V9F0Hhm3jNfwJsrvUy0ocbCzZxhUyuLuTF+GELQTxnW7cm+MBogsAgth5HFA/DQcq0eg3j9+3HZtg6O44iPr1N6nBWQ= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Fri, 16 Jun 2017 09:39:48 +0000 Message-ID: <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ca By" , "Brian E Carpenter" , "Manfredi, Albert E" Cc: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> Subject: Re: Tussles in IPv6 Land Date: Fri, 16 Jun 2017 10:36:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6PR0601CA0012.eurprd06.prod.outlook.com (2603:10a6:4:7b::22) To AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17) X-MS-Office365-Filtering-Correlation-Id: b52dfb6d-819e-4070-8ef3-08d4b49ba15d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:Q5yG24KAL05n4SmtBh/1PKdUszmQQyQEspMBZpHaaaz4/LNdxY3toBti8bgz7J+/9M40cFlvio99H+rcDmtCSKDCU5nJJKAKOIxuvgPkf7O8ruoYlJyDsNWpoMhC/BU6WM9htCX6oAWKXPtzBRuMyMNMdznsF/TAE5A9ylaRh6Ax6V8bIwvKGMENOAyW0Q0a5z+RvvP1qTyOXSSVx0CDvmZkh+ZbGkiIQg9gilPUrQ1RI5X2I3INkiKjNWjBVDEE2ibh099/UinMWUwVGIF0WI9lQH6JRsduageIs9Dt1yCXADDrJorpCo4Q+HKDmY6U4nOp+gt5ynVVXnO+iOmNZA==; 25:s47leqaDXkmpUZj3inLAgOFyGuAgkm/140OTzyZaSE8vaOne7Khg4w6Zmi5XLIlZhdhUI1q9KXbo40egmoZmlm2pVB+YwmVGk+wReV1ycKnuuNjPL6XS2K3t0DiUlU6Q4pp1MfVnwwXTvZCOK/YvZDKd2/FOwUIltXSZ62yLqWWdFjC3Es0AzczWYFciPPikQeeW7414oVmxJInp8D43XP52xVmIyQ/T8Q0mQ1dVZ9rxhDyptCt6ZX6iKnVLBu/rXgJkWT41EHx+5osnbFaAE6agYBuJoDWoNiJbHoFsX2Vm29x8dofJCnKQkYraPQwa8aOzq0Nn9I4POmBYgk6Hz20ytvOmsljc7PHXhjx5cXN0573gZCFndiF5wxsJsRfpPwxMvgMCxhATFWzTVZGuo/b+YjspnMm6BtqLhnEgPkrHa/5QasxD8HTYAYeYXqLacuenIpmer+nGj3sPS3SDgvWlr81SCfwrY+9Qn+lkdYw= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM5PR0701MB2995: X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 31:1PLQ9IiPizIP3oqZrKHp9roErQGYLqne187neiQc9w9M2OWyBofci9DihNUXacssJ1LJfMebqEtlD/B9n/nKb2KSkwbYqjnY3wlCMbH/iPIP54MyJQqZU+vHYGwzgwUeM/4Deo09k3uTxIicAaTmK1wUUPj6cY9OnrIOoEPXg0s3jLqubm2q1Pbklaln+e/sudZ6f0njOMHJf0jr52xUcuqCjvkx0lbpg3K9qCCatDLyOlwnRBbarRzfxX6XxXD1fOW4kIUuFwgBHc3DFGxWXQ==; 20:ItbzP37zNklcb+HOMtLPgzyfsFDnzWRrEi598WefRkzw7Aow0BA5Oq1+g001Cq0E9O+C5Phje6MqlyemmnoSUjZ/y2GLo7o8jQ+6wo1BM9V1eVvZEZGGqNfu/WWHa9VP3/2sTJfL9K7NrnqaHuAUDfm4rXhNZz8nAq48NheFZ3w= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(192374486261705)(21532816269658); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTU7NDpkcVQ5NXExaTJZQWd4dUxOMGZYVmlOTERX?= =?utf-8?B?Wkg5SFFQaG9VMWNSVGJGZy8wZFA1R280TDhqS3R4Lzl0K2xMcm5HUTdzazM1?= =?utf-8?B?NmN6M2lnOVNzNnBVS0RZL2FpSUlMOS90aGQ3NW5Ic3hJTzhEL0FVdzFQeVg5?= =?utf-8?B?aEJKWjZaMkNDSlRVMXBhVllYVW1keGpyQmdiNlJWYzlKRit4anZUcDRiSnF6?= =?utf-8?B?Y2tqODFrUjByaGVsRytHd3BnMmlVTjFqcjdMckZ4amk0aEVMTld1alRRMmN2?= =?utf-8?B?OXRUcjQ1SXU3azZhbkE4UnFURm5NT0hHR05tSXhPZ0MxNU9vVURsbFVGcFJt?= =?utf-8?B?Zm4yOFJocUEzR0plbVprdFZaMlFtM0V6bnRqWHdQWlRDVTAvTDRobUU4ME1Q?= =?utf-8?B?MFJiZWRBOWJNNFlnUVJXR2Q0blZ0dWtJRWwyN05DdHEzRXRmUkh1dkVEQStB?= =?utf-8?B?WUo3d2pxQnByZTB2amFVSHZ4YlhKUHY3ZnU3N2o4Mm9sS3dQTGk0T29aQWJv?= =?utf-8?B?dURWbE1sbGtWbnJFd3NVY0VxSERpRkQvWC9EMFd1SU5tZnE3Qis5cWVTM2g5?= =?utf-8?B?QlVrZkxFRFZWbE1FK3RlQ0xDMS9jVmZySno0VHl1QWpMOGtHcnR1RlZ0Q2hT?= =?utf-8?B?dU10MENESEQ5VUlvclNDMVZpVmtqUzlXNVp5UC9rYVdGODFyU09BTmFZcnNm?= =?utf-8?B?aHV4YkFkK1NieE0wTlo1cFlPSTE3eGVZR29zSWxvOFYyakxNL09OSXBwdFR0?= =?utf-8?B?VlNPdDZBZTJUYTJVQVBqWUJhQW02R3I0RXdYUEVSeVArR01OR3RjeURpMmVo?= =?utf-8?B?RXJ3UU1MOXF3UU53QzBic1hWSmVkU0o2OVk5RHZZaituV29XOUNRTk16aFZk?= =?utf-8?B?NVlNckJsd3B6QkxpU1AvNkcxMUppSkpuak9Oc0tTOXN1c25VZ29RS3kzRTRQ?= =?utf-8?B?MFNnaGZWM1g5UFM0QXZycDBScG8zaUI3cFNXQTU0cUV2Uk9Hc2FxWnVhZFFa?= =?utf-8?B?NEMwZkpwVjA1NG5VendmTzBSbzZ0SDNJMlVQbVI2K284OWZHTDhjSmkvMHAr?= =?utf-8?B?aUI5dkxCMHRzTlRvOVZHN1JNUUE4WjEyWEllSWhlN25sYTQxUWdwUnZKcUlN?= =?utf-8?B?Y1R6TjNYRGM0aVR1VTBNaVZEU3JxQWJCcVljNlNSeHZzVGpNNDRoZlFHWDRU?= =?utf-8?B?QVU3K3Bmd0h3dkVGL0w5UlNsVGdacFRVeU4rL0xMYUZCay9ndFZoeWRGWHdm?= =?utf-8?B?OGtjbW1VQ2ZZUFA3cHdvYktta2E3dmIya1YvU3Ywczk4aDFkNDNyZjRQT255?= =?utf-8?B?WDVjRk5YazVLZG01cWRKQld0c25pYXZybDFma1QwWEdndCtBamRraktaZ1U3?= =?utf-8?B?NHA1UzZlK3hwRXh1bExObTJoc2tOaGN6MEYvYWVtNFpmOXJSVTRHeUhQVmds?= =?utf-8?B?SDJpbWNLS3B6dC9TbllzejdSVHRJNGdlalhNd0NPbUFpNEV0aFBENHRGWUdH?= =?utf-8?B?eUNtTGRnRi94Njh5cTllVjBVZ1RIZ3o4U3I5OE5XYWVDeEttUkhSR0dINmJt?= =?utf-8?B?amVKNkdvTXlBUDV1VUlnTUREQXArYlJRSWVLMGdsT1FqZ1NIMk0zRW45K0dl?= =?utf-8?B?cE1rdWRVd0VuTzNseUZ6My9KcVk0Vk1EQ2owVUtpM0xYSG9ZemNaWnlCL3ph?= =?utf-8?Q?rLsMZLZjJAk7mDdGuV+gOr5/aXu45k3PLAngkaSY?= X-Forefront-PRVS: 0340850FCD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39860400002)(39400400002)(39840400002)(39850400002)(39410400002)(13464003)(377454003)(4326008)(86362001)(2906002)(81816999)(8676002)(81166006)(1456003)(76176999)(50466002)(81686999)(50226002)(50986999)(23676002)(1556002)(44716002)(97736004)(229853002)(25786009)(47776003)(84392002)(66066001)(62236002)(5820100001)(189998001)(6486002)(7736002)(4720700003)(53936002)(6666003)(61296003)(478600001)(8666007)(3846002)(42186005)(5660300001)(230700001)(6496005)(966005)(44736005)(6246003)(38730400002)(33646002)(14496001)(305945005)(68736007)(116806002)(6116002)(93886004)(9686003)(6306002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTU7MjM6U1FWV2N3NnhXSGtDdmUxRzFWREpZMDJQ?= =?utf-8?B?VkNkcUxIUUJwVDByNk5vWVptR0tOcUFXampaL0pQeXNsUkJ0d0E1SEJiYitl?= =?utf-8?B?TkRUN29ZQWpBYm5pdzY4eVpibWQ0Nk9LR3pINk50VnUvQmx5Nm5BMmQ3SDI5?= =?utf-8?B?UnBSNys2amZJUi9PeVRubWpqMngzT0RKNTExZDYvZ0NSWXRiZWVsRGd0Tlg0?= =?utf-8?B?UUl6SnBhaHZKbGM5RlliallOSENUVWlRdmJ6NzhWdk9lelAvTFNja0RhMzN5?= =?utf-8?B?MUo3bUIvRjhMU3Q1bGpXU1JzV3J0OXpUVVRsYk5pVlVMQnVYQ1hrbWRZcXRx?= =?utf-8?B?anFwU3NGUzBBQml4ZEpCa2cxaTRLQVZIeXBTeU5uNFpwRDdVWSs1aDBHbWFt?= =?utf-8?B?VGJTVm13aHpHa1FuV0t0VFJCTmdKeVRQQ1VaNTZkckZ3UFNYSXRaN1VlWDhk?= =?utf-8?B?OXQwQzhrMmpCdkwyVkNEQ3ltYXlYak9WMzBWY0V5U0NWMC9wUTdIckRxNFJz?= =?utf-8?B?bUZVaFk0Y0ZPZ1duVHliUW9YcG1BQXZseERvTU5VUFNSR2RKbHBqcmJMcThR?= =?utf-8?B?YldGVWRISUJjOWJmRTUzVFB5U2x2b01kUDJ6ZXlkWHptVGdBbTlyZWxPSkF5?= =?utf-8?B?N0VYa21BV1dzdFlDeUo5d2tQODJJZ2lFNWswZEZHUmFOYWtrRm55N0pOV0hD?= =?utf-8?B?RGdodVI0K1hGeTBwSW5VSlMrWklMVkNVVjMrMytXaUVCMHZ1OStmUHF5UnN2?= =?utf-8?B?alIzSTVTUHBnNkZsMkErWTZCMncxMDRNK0dic05yNkhod2IyZWkvTkpxQlJJ?= =?utf-8?B?bHg3YytSMEVpWUUxMDhPbTQrREc2NHNsMFNqM1VlV0hZaE5SVVh6WUZDbll0?= =?utf-8?B?cUVYYUFLd0pPNjMwL3A1cnRYYURmWmppVnUybnZ3UzRCWGtzL05obFUwY3N1?= =?utf-8?B?dnp3QUVHcngzVUJRQy9SaFptL2YzTEZvSWVaV2xTVnlNN3FWSzk0VkRBU2x2?= =?utf-8?B?VHNhQWFHWjNlQkd4YjcwWThwSWxSMGYvNlNvQy9GOXE2dEpHd3NHMEJqTXlj?= =?utf-8?B?UnordWtmTG5TbDRsWkk2cmtjZjZERkFzSVdRZzZzMjVEWU9OY1JBcXpMU2Yx?= =?utf-8?B?ZkZZV1ZNUUEzUlRlTzMwZnlGLzV3NHBMaE9MUTluWXJoMDVhWXVKOHVOaVhq?= =?utf-8?B?d1lXU0V3NTF2VGEwRWJGeU9xMTJZNnNWR1pmWFhkMnNBUjNUakhpellXdFdR?= =?utf-8?B?a3F2WmtYZzNtOU5QbjNMU2gwS2lPWWJkNEt3b2wvU2pNVGFSNUg4UFZmVFRI?= =?utf-8?B?dHRxQUhUVDFMOCttaGhOTWZrSkhFaUo5VlZ2YytMMjY4R2FFQmk1L0ovZU9Q?= =?utf-8?B?QjhxY255b3pzQ2Y3d2tiaC9iVm9udlQ1ZkJRVFpIbmFjU2ZlYUJKdytrYlB1?= =?utf-8?B?dTJibFdZMmRJay9VU3lVWXJHb3dBaUcyQjBMMjFSZGFESnZ5YkU5ZndpelNi?= =?utf-8?B?UUp0RnlpcmwwdC9EM1RRVWo3ZVdHOUhjalN0a3dCSG1UN2pQc2YyWXlFa2FG?= =?utf-8?B?b09Sb011VFd6RGg2YXhGL0N4bFNNenFvOUpSbVdONDM1TzZJa0lrYmhFaWhu?= =?utf-8?B?bHhJbnUvSHJYeVZSVG5KbFA2VUkyRXJNdDVudUhiN3hkRVREOFg3SCs1STla?= =?utf-8?B?UDRocjdjK1V5aG5Veld4bDdWQm0rU09mUWhyZ0FTYklra0NIMjE1ckZrcFJm?= =?utf-8?B?YXFJbEV1VVVST1JQVGt4eSs2b1c3ZVlHNDRoRHBsS09PbUFoZ0pnWXFWd1pZ?= =?utf-8?B?amdVL2xidStxWXF3U05HZDVNZEpFWWNlS2Fya2NRWFFCVXF4dERyN2toWldi?= =?utf-8?B?NGZKdlFNY3FiTDJQRlZCaWdFMWd6SERzRHI5eXMwVHI2NW1jVHlPR0VYNGRW?= =?utf-8?B?K2lQbHlDdzdOUWJqSGVmc2VwdTBzZnlCbHd6STgrTE9aOS9mMG54WkZZL2pQ?= =?utf-8?B?WnpRVUxWVVA2bmlZVGZkaHJMWmM0Q0tDdEI1WWdRPT0=?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTU7NjpxMVR3REVrRGx2K2VlSkxjVEZVYzluZjY2?= =?utf-8?B?Nlc2TlU3TGxLaUdqeDdTdUEzY3dWMU1pRVFPWCtjdm50Z05UaFVtRUhEUFFm?= =?utf-8?B?ZGhzR2ZFTWlCM3JCS3JXUFBiLy9KQ1gzMlYzQUwxZWhwYy9CUTZIemRvNGhK?= =?utf-8?B?VzIyTkN6S0dUVFdhWjNVL3VRb3NqZk1pMitidzFKSzFRUFVWM1dGZmFBb09J?= =?utf-8?B?VVVQRHUxdkY3THdLYmpQMEhNSithTERQVjBIalFjY2ovU0FDdmlINHQ0TGVL?= =?utf-8?B?VHdRUXk0R2pPWkUybGl4ZnQ4RzJuYVhYSDlSUHpLRXJURUY0enpWbitBU3lu?= =?utf-8?B?N2JaYUJLbnRSWFpYUXlDY2ZxTWk1NHhiTktIa1hsZVhMM3FUWkwyOGNmb3VL?= =?utf-8?B?ekxTdXgvRzEyeVhyMzVRSzVmNmdVUjNoZ0lrOG85VWZBanBZcS9UVnJHTTc3?= =?utf-8?B?Qlo3dENkZmpTR3Rqd2JPdzZ4VGVXczBUZmFCMkZKNGxmbyt5b0Vxc3VHb0Z2?= =?utf-8?B?eXFZajlneHFkL1Y3TXBJV3JRWTBnZ0xzYVhad1dFU3BkRFlYZ2tLdmdqd3Ny?= =?utf-8?B?VndFaXMwSlIwdnhWQUFUcGEvd0c2QzRlcmRUSTkvaFpoNmFxMk9VVHJncVBM?= =?utf-8?B?aVZYWjAya2tORzVaVUx4SnZFU0JTZWsvQWVkK1krRUU0UEpIOFp2TEVNa2dG?= =?utf-8?B?bVIzS05mcVJyNU5MbjdoWHFSbExBR2xialcwWnJDdm15aFM3MGtPalJoejB3?= =?utf-8?B?eVN5aE9UdlZpQzNsek5KblVEVnFGakwxaldNZTEwN3l2bUJMRVVQTjFhaS9T?= =?utf-8?B?UHdNd0JueGtNOGt3bTFxMlRpaHRKRDdWTGpzV082VW44bHdRcnI0bGtrUmJH?= =?utf-8?B?L28vY2pjMm9EdE00Zk5xelRVUmcyeFZnUzRXR3cybWV3bHZuZ3czR2JZZWM2?= =?utf-8?B?Tyt2TU1UL1laMEVpeUJnWkRsTVJmdzkwN0V3T2h6Y0pZUjdabEVuK2c5aEdn?= =?utf-8?B?Q0VRa2ZRZm1YN2pUV0M0L0M3TDBidm04ZGQwZ09jTHpZZWdGa2g4ZXVVdXZR?= =?utf-8?B?aWY5bS96VHZMQnpDYU1FSk14UllZWERscmhEekkyRW1LT0NhdjJmVzlveTR0?= =?utf-8?B?ZEVFWVlzMmZxYlZ0U3F3OUQ2ckRMZnoxWCtnSjZobnlVZ2RINE02U0VuRDBE?= =?utf-8?B?Nit0QjUraHM3MkRibWxjRTdlV0xObWRjZUZ5aFptd010THRJWDgzamlvdXJa?= =?utf-8?B?d3pacTRzMkxIeThaYnc3aVFWb1VFR0dqUnFXcUdiM2phTlBISk9sdnp2R09W?= =?utf-8?Q?1Y1eh7e9f7b8FSubBjIdaRluAdsuh8xAE=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 5:BGQVWQvO0A1l27TD1sV73BDJO6sECeOiIjTIlFtCHmCmz/OSC4vKkdyclFx7SUCFEoxDbnqabXUckXnzJoXa6GtytU3e3eKP//POVkLBqapFdF+EkE4YsSqjCGIXlkPW2ug8W5ykwWtgnRNwsPJg6XfyaTz4M4/bRzCGZdWwP8ZxA57CQGDH544OCmx2tXs0pNV/VwZYokk5/QlMb1ONG9bgsrboGXRBDWba1tpZ0fQlVA7AUuSdDlqS1d+2/PxidyLG+CkAEsoNjgep5BCH7uOO0jzErCECFGuqwXTb0m781znwPjbERV8RB01GgeuDmplRkfOIG5pXH6s5ya2T03HtI+3OqqQqChfNSWmoadFGNycI/l1Yn1wgjxvKui6k1yVfF+Cg15z2q3Ip7Xv4Naphq4Qr3+KiGt3rhDSIXv3aF4GPmbL9q8Gk9uqD33reH7UqPD9sS4e7vdzKlME+qRdKW6FkpDnkdbrDEgY0sT4GhehOQl2mLHo1OG723rFy; 24:2XGToZlLuor8LOGyCxqnZOzXRjNjfmUheYKOhNQozIkwhqXTLV/XgrLzt875UZ2Fld327ggTGmhYfgEuMWAjFBGvzvz/akDgnRQmdU2Rl+c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 7:jrisMMo+q/QmRXeJ1B6Q4oDf/xZNhQmPD5/wr9aHBlZgVo0zptI83bRLJTNUkTlcoVlupy3TLmnQPF5D5d+GHDSw+QhOhHssNjIGydAtRAdCMEixciKkN1xSTZYReMZMmDhwDnkuURmpcmSZZ30nTZ8jRyp47ZyR3KDApMYv4Rd5yzF1Fuf2jPfk35ZVNk8aS0vkP/dTNXLrWjYZoSGW53LJT/3iCQfVBmKPA4ZYNoT2W+IKfCqoA8sR+m7RxY5Sq6/bZOHrWg+SRS63E69Dv8An1SS9Ps8ftZ7cEccTjujh4mqzFqGPVQ02lv7aA5bB6y4fmwA8Ewrj5XLBRp8MrffDjLBKT5Po8HktfMxogs7BwS7RJ8kpnJ/8y+01GQx6WYhEoQLs/KrdzQCvj+AAF3mvlxG8PsmcWrVx8OGWhBDkDZVgXXj0eJfrZ+XPzVWM1/fzGRuttmy3k5jf0Oh6V1Z4TkQKtVBrUxpJCFDJj/NCxO7VJanoceP9uAqAPTdhR9ZlOsRKNocc24iXKGTOmEqKoKA4Lug7TJlC/lFp0Ec7DWwdJBV9+bDt8vGGN7Xv3ZVqJhYZisN+WcsE9DnCm/+ICYht+1ESqGNx9A6+UPA7J5RO1A1rdMwddvZRUeVUxfy0h9DLKXPFtlC9v8i+VMjtVz4G+V4uN3rDj9c9FkgKI000KndIyCafLE7lT5aC6x5Xjg+P4jgro5CRrv9HuCHwwKGKmlQRgwK8eX//iUSRXz11xfDZ4/vOcjpGB+8bLXJ6fOn25WHV6MKTZu6dF6rMs7B/XD+zgvi0sJASI9U= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2017 09:39:48.1744 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 09:40:03 -0000 ----- Original Message ----- From: "Ca By" Sent: Friday, June 16, 2017 4:09 AM > Recently, on the internet, there was a very effective and harmful worm > called "wannacry". This worm was only on ipv4, and it's particular ilk will > only ever be on densely populated ipv4. And, it could never be effective on > sparsely populated ipv6. You see, it used a random number generator to feed > an ipv4 hunter function that would attempt to connect to computers on open > port 445. In ipv6, that hunter is fruitlesss. The wannacry story is very > instructive, from its CIA / NSA roots, to being dumped to the public, and > then maliciously operationalized against ... hospitals...and others. > > Yes, there are ways to narrow the search for ipv6 hosts and key parties can > discover addresses. Google probably knows most of the alive ipv6 address > on the 'net at any one time, Akamai has published some work in this space > (showing addresses are not very preditable) but a random worm does not and > will not be able to guess the space and feed a hunter function. > > So, yes, imho, 64 random bits is a killer security app. Just like stripes > on a zebra or spots on a cheetah were not part of some grand design, the 64 > bits value's security value is emergent. > > I have personally been able to effectively use the sparse addressing as > part of a very large network's security posture for several years. Until the criminals find a large enoough target to be worth attacking, when, skilful as they are, they will find a way around it. Early reports of "wannacry" said that it targeted Windows XP, which seemed unlikely to me as so few systems now run that, perhaps 5%. (I would also have been sceptical if they had said Windows 8:-). Later reports said the target was Windows 7 which made sense, since that is what I see organisations using. If and when IPv6 with sparse addressing becomes a big enough target to be worth attacking, then it will be attacked. Until then, people may believe in security by obscurity. Tom Petch > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > From nobody Fri Jun 16 03:28:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1921317F9 for ; Fri, 16 Jun 2017 03:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAcIt0rlFdNM for ; Fri, 16 Jun 2017 03:28:06 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 E682A1317F1 for ; Fri, 16 Jun 2017 03:28:05 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id j53so9484636uaa.2 for ; Fri, 16 Jun 2017 03:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mi7Ju4O3aFxEGfelFyt9ihjmGP62WCZLZdRYdwSrUSY=; b=IDzfVHHmu+wjnXfEU7JoAPV+pzRlsEYEm0T89uyhw+yzN7ccCm2eqYUHjMebozJaPD W5YeG3+ah2yhHnxzny3ZKBYn7M6nWv41vCBpeS/1rFfquSrVs/cHqRhZVItYHzl4djrG ysYygkzNRvJ1+orgF3IjntDeHbwlAzSqbqTkbkYw8IIsjfa0thQExuucX7ky09eSZE66 4qCoEhgZccLpE0Oe1hnJvet4S/8gSJpmWvnwcgkCIy+Y85JqkSRW3aoe9tDjfL6Qp6CN pye4C/grD3rwb50TNNrfLYfLH/VB3zmtQ/MpPVESxL8w+u4Gy8Uk1z6pdK9u6QmNuDNA cIww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mi7Ju4O3aFxEGfelFyt9ihjmGP62WCZLZdRYdwSrUSY=; b=Wmzr6skG/AFJYKRuMLemjENVQuWzB1TQ6//TnNhPxZdYnmoSfUZyJuLz4VEjg2yHUI Ke1hlwNII9u6Yu7+wTgOGbrGMRUDQafhNEM6Kye7ZLlvC94gZeyreqU4F2Fr2vvlF1lW Sx4yFoTbx29w4IafnTWX6T3YFe0HOhzyJ/KDJZyR+E/JywErsr77rZCU0sfWCfmrCYMW 5kvMyYJ11ZYenOHHxu3wXd0AndkhYtjB25Y07VJlRGOsJcaMgNAC6gmwLlY5o1v5Bk4N LnUM3avYcBjXBbOGgYezhP8jKVGJL8KYzMqCmi1ZvBi0wNasyxecwiyHdvGRG58JV+a5 O9FA== X-Gm-Message-State: AKS2vOzfXJCDCBlmgE84w7sYL/dkOQZHbqapyjPIepym4UkCt5KYNxew 8DI4btDxKGR0XAYDmpdmIbOQ+TNfdw== X-Received: by 10.159.55.233 with SMTP id q96mr5415055uaq.70.1497608885038; Fri, 16 Jun 2017 03:28:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Fri, 16 Jun 2017 03:28:02 -0700 (PDT) Received: by 10.176.81.100 with HTTP; Fri, 16 Jun 2017 03:28:02 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Mark Smith Date: Fri, 16 Jun 2017 20:28:02 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: "t.petch" Cc: "Manfredi, Albert E" , Ca By , ipv6@ietf.org, Brian E Carpenter Content-Type: multipart/alternative; boundary="94eb2c0405f29af5480552113d3a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 10:28:08 -0000 --94eb2c0405f29af5480552113d3a Content-Type: text/plain; charset="UTF-8" On 16 Jun. 2017 19:40, "t.petch" wrote: ----- Original Message ----- From: "Ca By" Sent: Friday, June 16, 2017 4:09 AM > Recently, on the internet, there was a very effective and harmful worm > called "wannacry". This worm was only on ipv4, and it's particular ilk will > only ever be on densely populated ipv4. And, it could never be effective on > sparsely populated ipv6. You see, it used a random number generator to feed > an ipv4 hunter function that would attempt to connect to computers on open > port 445. In ipv6, that hunter is fruitlesss. The wannacry story is very > instructive, from its CIA / NSA roots, to being dumped to the public, and > then maliciously operationalized against ... hospitals...and others. > > Yes, there are ways to narrow the search for ipv6 hosts and key parties can > discover addresses. Google probably knows most of the alive ipv6 address > on the 'net at any one time, Akamai has published some work in this space > (showing addresses are not very preditable) but a random worm does not and > will not be able to guess the space and feed a hunter function. > > So, yes, imho, 64 random bits is a killer security app. Just like stripes > on a zebra or spots on a cheetah were not part of some grand design, the 64 > bits value's security value is emergent. > > I have personally been able to effectively use the sparse addressing as > part of a very large network's security posture for several years. Until the criminals find a large enoough target to be worth attacking, when, skilful as they are, they will find a way around it. Early reports of "wannacry" said that it targeted Windows XP, which seemed unlikely to me as so few systems now run that, perhaps 5%. (I would also have been sceptical if they had said Windows 8:-). Later reports said the target was Windows 7 which made sense, since that is what I see organisations using. If and when IPv6 with sparse addressing becomes a big enough target to be worth attacking, then it will be attacked. Until then, people may believe in security by obscurity. There's nothing actually wrong with security by obscurity as a defence in depth measure. If you already prevent ICMPv4 echo requests inbound, you're using it. As are zebras, giraffes, cheetahs and many (probaby all) armies around the world, namely camouflage. The meme of there is no security in obscurity is a distortion of Kerckoffs'principle, and there is still an obscurity - the (secret) key. https://en.m.wikipedia.org/wiki/Kerckhoffs%27s_principle?wprov=sfla1 So, in this context, if you're relying on not being discovered by packet probing, it's a single point of failure. However, if you have other measures in place, such as host based firewalls, authentication at the IP or higher layers, meaning transport or application layers, then obscurity adds another level of defence. That wasn't possible in IPv4 because of its much smaller address space. Wannacry demonstrates a this. It is an emergent property of IPv6 addresses as long as we give IPv6 hosts enough addresses to have it. Regards, Mark. --94eb2c0405f29af5480552113d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 16 Jun. 2017 19:40, "t.petch" <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Ca By" <cb.list6@= gmail.com>
Sent: Friday, June 16, 2017 4:09 AM

<snip>

> Recently, on the internet, there was a very effective and harmful worm=
> called "wannacry". This worm was only on ipv4, and it's = particular ilk
will
> only ever be on densely populated ipv4. And, it could never be
effective on
> sparsely populated ipv6. You see, it used a random number generator to=
feed
> an ipv4 hunter function that would attempt to connect to computers on<= br> open
> port 445.=C2=A0 In ipv6, that hunter is fruitlesss.=C2=A0 The wannacry= story is
very
> instructive, from its CIA / NSA roots, to being dumped to the public,<= br> and
> then maliciously operationalized against ... hospitals...and others. >
> Yes, there are ways to narrow the search for ipv6 hosts and key
parties can
> discover addresses.=C2=A0 Google probably knows most of the alive ipv6=
address
> on the 'net at any one time, Akamai has published some work in thi= s
space
> (showing addresses are not very preditable) but a random worm does not=
and
> will not be able to guess the space and feed a hunter function.
>
> So, yes, imho, 64 random bits is a killer security app. Just like
stripes
> on a zebra or spots on a cheetah were not part of some grand design, the 64
> bits value's security value is emergent.
>
> I have personally been able to effectively use the sparse addressing as
> part of a very large network's security posture for several years.=

Until the criminals find a large enoough target to be worth attacking= ,
when, skilful as they are, they will find a way around it.

Early reports of=C2=A0 "wannacry" said that it targeted Windows X= P, which
seemed unlikely to me as so few systems now run that, perhaps 5%.=C2=A0 (I<= br> would also have been sceptical if they had said Windows 8:-). Later
reports said the target was Windows 7 which made sense, since that is
what I see organisations using.

If and when IPv6 with sparse addressing becomes a big enough target to
be worth attacking, then it will be attacked.=C2=A0 Until then, people may<= br> believe in security by obscurity.

There's nothing actually wrong w= ith security by obscurity as a defence in depth measure.

If you already prevent ICMPv4 echo request= s inbound, you're using it. As are zebras, giraffes, cheetahs and many = (probaby all) armies around the world, namely camouflage.

The meme of there is no security in obscu= rity is a distortion of Kerckoffs'principle, and there is still an obsc= urity - the (secret) key.


So, in thi= s context, if you're relying on not being discovered by packet probing,= it's a single point of failure. However, if you have other measures in= place, such as host based firewalls, authentication at the IP or higher la= yers, meaning transport or application layers, then obscurity adds another = level of defence.

That w= asn't possible in IPv4 because of its much smaller address space. Wanna= cry demonstrates a this. It is an emergent property of IPv6 addresses as lo= ng as we give IPv6 hosts enough addresses to have it.

Regards,
Mark.
--94eb2c0405f29af5480552113d3a-- From nobody Fri Jun 16 05:31:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8277F129BA5 for ; Fri, 16 Jun 2017 05:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CW_snui3vcP for ; Fri, 16 Jun 2017 05:31:03 -0700 (PDT) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) (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 B1DBD129B83 for ; Fri, 16 Jun 2017 05:31:03 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id v5GCV0el021349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Jun 2017 08:31:00 -0400 Received: (qmail 11009 invoked by uid 0); 16 Jun 2017 12:31:00 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 16 Jun 2017 12:31:00 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 16 Jun 2017 08:30:55 -0400 Subject: Re: Tussles in IPv6 Land From: Lee Howard To: Ca By , Brian E Carpenter , "Manfredi, Albert E" CC: "ipv6@ietf.org" Message-ID: Thread-Topic: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3580446659_1606990" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:31:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3580446659_1606990 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: ipv6 on behalf of Ca By Date: Thursday, June 15, 2017 at 11:09 PM To: Brian E Carpenter , "Manfredi, Albert E" Cc: "ipv6@ietf.org" Subject: Re: Tussles in IPv6 Land >=20 > On Thu, Jun 15, 2017 at 7:39 PM Manfredi, Albert E > wrote: >> Brian, let me reconstruct my post as it was written: >>=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>=20 >>>> >> I agree with this general line of thinking, and I'd also point >>>> >> out that as computers become faster, this security benefit will >>>> >> decrease and then vanish. Really, to create a vast address space, >>>> >> and then after the fact, establish "rules" that require that vast >>>> >> address space to be only **very** sparsely used, is >>>> >> counterproductive? >>> > >>> > The /64 boundary was established by RFC2373 (July 1998). Hardly >>> > after the fact. >>=20 >> The 64-bit boundary is not the issue here. The issue is that this 128-bi= t >> address space was not initially intended to be forever very sparsely >> populated, for a security reason. In fact, when the IID was meant to con= sist >> of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs were hard= ly >> any sort of security measure. We're now saying, in spite of the hype abo= ut >> this vast address space, that at least the bottom 64 bits of it, if not = also >> the prefix 64 bits, must be very sparsely populated. So much for vast ad= dress >> space, right? >>=20 >> So, when I said "after the fact," I was talking about the security ratio= nale. >> That definitely came after the fact. >>=20 >>>> >> Why isn't is better to use real security measures, such as TLS? >>> > >>> > Because sparse addresses and e2e security solve very, very different >>> > security problems. >>=20 >> Well, I contend there's some intersection of sets there. Anonymity becom= es >> less crucial if the content is encrypted. And there are other ways, prob= ably >> better ways, of achieving anonymity, than sparse usage, such as short ad= dress >> lifetimes. Plus, as security measure, 64 bits becomes less and less >> believable, in a time when we must use 128 or preferably 256 bits for >> effective security keys. So we really need to put this one security aid = in >> perspective, I think. It seems to be given more emphasis than it deserve= s? >>=20 >> Bert >=20 >=20 > Recently, on the internet, there was a very effective and harmful worm ca= lled > "wannacry". This worm was only on ipv4, and it's particular ilk will only= ever > be on densely populated ipv4. And, it could never be effective on sparsel= y > populated ipv6. You see, it used a random number generator to feed an ipv= 4 > hunter function that would attempt to connect to computers on open port 4= 45. > In ipv6, that hunter is fruitlesss. Don=E2=80=99t overestimate the power of hiding in large numbers. It has been show= n that it=E2=80=99s not too hard to reduce the available numbers to a more easily guessable set: =20 https://tools.ietf.org/html/rfc7707 Network Reconnaissance in IPv6 Networks http://www.internetsociety.org/deploy360/blog/2015/02/ipv6-security-myth-4-= i pv6-networks-are-too-big-to-scan/ >=20 > So, yes, imho, 64 random bits is a killer security app. Just like stripes= on a > zebra or spots on a cheetah were not part of some grand design, the 64 bi= ts > value's security value is emergent. I agree that a bit of randomization can slow down an attacker. Like a cheetah, you also need to outrun the attacker, or like a zebra, you need to make it harder to find a specific attack point. As somebody else said, there=E2=80=99s nothing wrong with it as a complement to a sound defense in depth plan. Lee --B_3580446659_1606990 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


From: ipv6 <ipv6-bounces@ietf.org> on behalf of Ca By <cb.list6@gmail.com>
Date: Thursday, June 15, 2017 at 11:09 PM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Manfredi, Albert E"= <albert.e.manfredi@boeing.= com>
Cc: "ipv6@ietf.org" <ipv6@iet= f.org>
Subject: Re: Tussles= in IPv6 Land


On Thu, Jun 15, 2= 017 at 7:39 PM Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote:
Brian, let me reconstruct my post as it was written:

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]

>> I agree with this general line of thinking, and I'd also point
= >> out that as computers become faster, this security benefit will >> decrease and then vanish. Really, to create a vast address space,<= br> >> and then after the fact, establish "rules" that require that vast<= br> >> address space to be only **very** sparsely used, is
>> counterproductive?
>
> The /64 boundary was established by RFC2373 (July 1998). Hardly
> after the fact.

The 64-bit boundary is not the issue here. The issue is that this 128-bit a= ddress space was not initially intended to be forever very sparsely populate= d, for a security reason. In fact, when the IID was meant to consist of a MA= C address plus a fixed upper 16 bits, those 64 bit IIDs were hardly any sort= of security measure. We're now saying, in spite of the hype about this vast= address space, that at least the bottom 64 bits of it, if not also the pref= ix 64 bits, must be very sparsely populated. So much for vast address space,= right?

So, when I said "after the fact," I was talking about the security rational= e. That definitely came after the fact.

>> Why isn't is better to use real security measures, such as TLS? >
> Because sparse addresses and e2e security solve very, very different > security problems.

Well, I contend there's some intersection of sets there. Anonymity becomes = less crucial if the content is encrypted. And there are other ways, probably= better ways, of achieving anonymity, than sparse usage, such as short addre= ss lifetimes. Plus, as security measure, 64 bits becomes less and less belie= vable, in a time when we must use 128 or preferably 256 bits for effective s= ecurity keys. So we really need to put this one security aid in perspective,= I think. It seems to be given more emphasis than it deserves?

Bert


Recently, on the internet, there was a very effective and harm= ful worm called "wannacry". This worm was only on ipv4, and it's particular = ilk will only ever be on densely populated ipv4. And, it could never be effe= ctive on sparsely populated ipv6. You see, it used a random number generator= to feed an ipv4 hunter function that would attempt to connect to computers = on open port 445.  In ipv6, that hunter is fruitlesss. 

Don’t overestimate the= power of hiding in large numbers. It has been shown that it’s not too= hard to reduce the available numbers to a more easily guessable set:  =

http= s://tools.ietf.org/html/rfc7707 Network Reconnaissance in IPv6 Netw= orks



So, yes, imho, 64 rand= om bits is a killer security app. Just like stripes on a zebra or spots on a= cheetah were not part of some grand design, the 64 bits value's security va= lue is emergent. 

<= div>I agree that a bit of randomization can slow down an attacker. Like a ch= eetah, you also need to outrun the attacker, or like a zebra, you need to ma= ke it harder to find a specific attack point. As somebody else said, there&#= 8217;s nothing wrong with it as a complement to a sound defense in depth pla= n.

Lee
--B_3580446659_1606990-- From nobody Fri Jun 16 05:44:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D747129BC4 for ; Fri, 16 Jun 2017 05:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmRc1U82uJJ4 for ; Fri, 16 Jun 2017 05:44:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7833E129BBB for ; Fri, 16 Jun 2017 05:44:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dLqbv-0000GBC; Fri, 16 Jun 2017 14:44:23 +0200 Message-Id: To: ipv6@ietf.org Cc: Job Snijders Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> In-reply-to: Your message of "Fri, 16 Jun 2017 07:07:18 +0200 ." <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> Date: Fri, 16 Jun 2017 14:44:22 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:44:27 -0000 >Even if it is as low as 0.1%, has it ever occurred to you that that >small number might serve a majority of IPv6 users in non-trivial >matters? For example, their ability to reach each other? It is a shame >to see such blatant disregard for this group of IPv6 users. Job, I'm curious what use you have for SLAAC with prefixes longer than /64. Using pseudo random IIDs for router interfaces seems like a complete maintainance nightmare to me. Or are you talking about other infrastructure devices? The most contentious point in draft-bourbaki-6man-classless-ipv6-00 is that it tries to change the IID length used for SLAAC. As far as I know, any type of address assignment that is not SLAAC already supports arbitrary prefix lengths, and therefore is compatible with the goal of this draft. From nobody Fri Jun 16 08:06:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA6126B6D for ; Fri, 16 Jun 2017 08:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eJG7sFHyHwd for ; Fri, 16 Jun 2017 08:06:54 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923A1124D85 for ; Fri, 16 Jun 2017 08:06:54 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m125so28767770wmm.1 for ; Fri, 16 Jun 2017 08:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hm3ew+XBkmSoJ8xJai3swPcoCMHrKj3fxW9ByK/G8zg=; b=ZN0VOMcZ0NUmJTPNzNKj/LUryDsQCA2/JXAXu8Jv6drIShLITvNynAfhGRrNDUWgqw X6XDGUlox9JLtvwZN7+wcNvzyAFDiPhFHEscSFHXNQeCXr27hFv5mb7eRvLpDdTP03PE 2Gvz0Ntop0eULmSgcUYazpTCCzLb+nwQObGjj2jHrjkF1ulI5U3jAmT7GMXquFN91wyu CljyumRPD0J01I3BjaIb4AZILzeHE/ydH1nY9/Sm7ZDVsaD4ShPcgkXC0xw3seXcP39R Lm1YhxewiGqM/GVI0WeA0+fkHMw6iuZmXdP7lye7Sgv4EOAQln8w0AQlJpNYQg49fjMp w/sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hm3ew+XBkmSoJ8xJai3swPcoCMHrKj3fxW9ByK/G8zg=; b=dXk7AYba4CWoWRoAlbM3HHFRHPbYNbdDQyZhPPLKMAb9fZv5jEpLnCULxAUvZB0rsn CPjhzHJQgKwAfx/s3owmWGJt41UuMAQdwaxd+OfhpZon6gRMZg4EE6wIyIc7imh4H9b0 s+E5aoEtJRAq4/30BBIng6hswU1KCvY/giFkHnZ4cdriiTsORvggOAm75bDdUlEK+as6 4W+ZoKXGmHj3PboW9bYETWqYkEz3ZXKYtF3Pmy8RsXaG7zsNVa6EKseejehxql1kT2tV 6fJ2V5f1IyM1o6K5eV5IR+9pogTRfY4HqgUpMtGjoyjQ+VE4hy/4rfxmnEZnAR0divvz FwnA== X-Gm-Message-State: AKS2vOxUO4BJW07kiNoQ+lco+ph9xBgPtCOJJu6lkhNMLJyw5BeQc1jG k4kM8P/0K/Krd4jbhopy+3kKxAcqi/+0 X-Received: by 10.28.54.204 with SMTP id y73mr7774562wmh.53.1497625613002; Fri, 16 Jun 2017 08:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Fri, 16 Jun 2017 08:06:51 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Tom Herbert Date: Fri, 16 Jun 2017 08:06:51 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Mark Smith Cc: "t.petch" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 15:06:57 -0000 > There's nothing actually wrong with security by obscurity as a defence in > depth measure. > > If you already prevent ICMPv4 echo requests inbound, you're using it. As are > zebras, giraffes, cheetahs and many (probaby all) armies around the world, > namely camouflage. > Mark, Zebras are still in the main diet of lions. Camouflage is not the same thing as armor or weapons. Credit cards have long numbers that aren't guessable, but that is little comfort every time I get a letter from a merchant about a breach and how my number was stolen. > The meme of there is no security in obscurity is a distortion of > Kerckoffs'principle, and there is still an obscurity - the (secret) key. > There is no secret key in address randomization. > https://en.m.wikipedia.org/wiki/Kerckhoffs%27s_principle?wprov=sfla1 > Kerckhoff's principle is "a cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known." Since IP addresses are sent in the clear, they are essentially public knowledge. If somehow the IID is set to a cryptographic hash over the rest of the IP addresses then maybe Kerckoff's principle would be applicable. Tom From nobody Fri Jun 16 11:01:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD41295A0 for ; Fri, 16 Jun 2017 11:01:23 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSSp9EhBor4a for ; Fri, 16 Jun 2017 11:01:22 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 0BFD612EA67 for ; Fri, 16 Jun 2017 11:01:22 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id m31so30141455uam.1 for ; Fri, 16 Jun 2017 11:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4PyJvMhX19RtXSO4mxjYjPZAwY0BngU606UCUdlPGso=; b=I6SUD1SsoggUOgfMf6xNA/VoimFzeO+5aqN/su84EGcXlgRSpb3gRzUWd4RhAHBDhZ qUTtv73s1zKLh/95P7L+BdAQl+pp+5qCZstcE/dt0G3DVALJvq9W+xp9W9SWwUxMEIVE y7Kv5YY1vNnuN1opUZOMXwCNh9wOpHyCvcz+8kAXXao3mzeasPVDlvUGGYvOmfdpJT4G nqYheJJqMQ4Q6WqBGwUK0dFftZiVLPTEFNJ/JDg5q2rrrAZiLW326NcvvcW3FYam3lJd qtxWf/TXuoe6+YbsUKzQFUegvoDNgzqzbReC8olIKaMpVjI8jNdSwsGCXjLh3ye+Ejr5 X3AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4PyJvMhX19RtXSO4mxjYjPZAwY0BngU606UCUdlPGso=; b=KMpEDfH6bzKTjHVzDtgdYrep6buEOmn6DBzv9VMzHkAJoPV+dXnNp5VWqUN8SopmQ1 Ckh9vkNVcGvYd1OS0b2HzKvJ3dx/cS6yL9IJOjYLZTMIAmXaUW1Ck7j53z3iDF7ldof8 hN8V1lKY1y5PADX59lH2pC8MXhdRFDP9bZ4wgZplzyx8O+KQuM1B8pi4d/EVuuCxr6gE ZzEI/zKysaGhZ8oPaxe8ue0ibfXemK4Pi1fNWXUGlMpBMF41oXFEDSlWXYVStY1CyBWv OrVU5y3Y8uU70JEyvX/cp57yvk6PBQ/0/LWXDAdtWHfTS030sDo7Q8Te5UW7tMwR2ppr BUrQ== X-Gm-Message-State: AKS2vOz1tQSYT6zRvJgx17uPdyPFOe98QK5xaEg5n9jAzyJW0JaEa2vK b6MHqSMAdUNifp0MqMy5Ph59pB+GaA== X-Received: by 10.159.60.82 with SMTP id w18mr7567009uah.19.1497636080970; Fri, 16 Jun 2017 11:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Fri, 16 Jun 2017 11:00:50 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> From: Mark Smith Date: Sat, 17 Jun 2017 04:00:50 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lee Howard Cc: Ca By , Brian E Carpenter , "Manfredi, Albert E" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 18:01:24 -0000 On 16 June 2017 at 22:30, Lee Howard wrote: > > > From: ipv6 on behalf of Ca By > Date: Thursday, June 15, 2017 at 11:09 PM > To: Brian E Carpenter , "Manfredi, Albert E" > > Cc: "ipv6@ietf.org" > Subject: Re: Tussles in IPv6 Land > > > On Thu, Jun 15, 2017 at 7:39 PM Manfredi, Albert E > wrote: >> >> Brian, let me reconstruct my post as it was written: >> >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> >> >> I agree with this general line of thinking, and I'd also point >> >> out that as computers become faster, this security benefit will >> >> decrease and then vanish. Really, to create a vast address space, >> >> and then after the fact, establish "rules" that require that vast >> >> address space to be only **very** sparsely used, is >> >> counterproductive? >> > >> > The /64 boundary was established by RFC2373 (July 1998). Hardly >> > after the fact. >> >> The 64-bit boundary is not the issue here. The issue is that this 128-bi= t >> address space was not initially intended to be forever very sparsely >> populated, for a security reason. In fact, when the IID was meant to con= sist >> of a MAC address plus a fixed upper 16 bits, those 64 bit IIDs were hard= ly >> any sort of security measure. We're now saying, in spite of the hype abo= ut >> this vast address space, that at least the bottom 64 bits of it, if not = also >> the prefix 64 bits, must be very sparsely populated. So much for vast >> address space, right? >> >> So, when I said "after the fact," I was talking about the security >> rationale. That definitely came after the fact. >> >> >> Why isn't is better to use real security measures, such as TLS? >> > >> > Because sparse addresses and e2e security solve very, very different >> > security problems. >> >> Well, I contend there's some intersection of sets there. Anonymity becom= es >> less crucial if the content is encrypted. And there are other ways, prob= ably >> better ways, of achieving anonymity, than sparse usage, such as short >> address lifetimes. Plus, as security measure, 64 bits becomes less and l= ess >> believable, in a time when we must use 128 or preferably 256 bits for >> effective security keys. So we really need to put this one security aid = in >> perspective, I think. It seems to be given more emphasis than it deserve= s? >> >> Bert > > > > Recently, on the internet, there was a very effective and harmful worm > called "wannacry". This worm was only on ipv4, and it's particular ilk wi= ll > only ever be on densely populated ipv4. And, it could never be effective = on > sparsely populated ipv6. You see, it used a random number generator to fe= ed > an ipv4 hunter function that would attempt to connect to computers on ope= n > port 445. In ipv6, that hunter is fruitlesss. > > > Don=E2=80=99t overestimate the power of hiding in large numbers. It has b= een shown > that it=E2=80=99s not too hard to reduce the available numbers to a more = easily > guessable set: > > https://tools.ietf.org/html/rfc7707 Network Reconnaissance in IPv6 Networ= ks > http://www.internetsociety.org/deploy360/blog/2015/02/ipv6-security-myth-= 4-ipv6-networks-are-too-big-to-scan/ > They're why RFC7212, " A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", is now the recommended default (per RFC8064) for SLAAC stable addresses. > > > So, yes, imho, 64 random bits is a killer security app. Just like stripes= on > a zebra or spots on a cheetah were not part of some grand design, the 64 > bits value's security value is emergent. > > > I agree that a bit of randomization can slow down an attacker. Like a > cheetah, you also need to outrun the attacker, or like a zebra, you need = to > make it harder to find a specific attack point. As somebody else said, > there=E2=80=99s nothing wrong with it as a complement to a sound defense = in depth > plan. > > Lee > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 16 12:15:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF9C1300F0 for ; Fri, 16 Jun 2017 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ-zbXjPtZVu for ; Fri, 16 Jun 2017 12:15:14 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67D6131722 for ; Fri, 16 Jun 2017 12:15:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5GJF0AE026304; Fri, 16 Jun 2017 12:15:00 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5GJEouj025891 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 16 Jun 2017 12:14:51 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 12:14:49 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 16 Jun 2017 12:14:50 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS5p5UIhyxMTqVw0yqEKMytwSwxKIn1hWw Date: Fri, 16 Jun 2017 19:14:50 +0000 Message-ID: <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 19:15:17 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > Job, > > I'm curious what use you have for SLAAC with prefixes longer than /64. By no means attempting to answer for Job, my answer is simple. SLAAC is a p= lug and play technique, and I see no reason why that plug and play techniqu= e cannot be applied to other than /64 networks. There's no reason to make n= on-/64 networks always an exception, only available for manual configuratio= n, or even only available with this DHCP-PD that isn't much supported. To expand a routed network at the edges easily, and allow subnetting in the= expanded network, and allow plug and play operation in the expanded part, = SLAAC should be one element of the solution. DHCP-PD recycles the same tech= nique used in IPv4, and it's a good additional option, especially useful wh= en the client addresses must be known to the network operator. Given that variable length IID SLAAC is just not difficult to implement, in= a graceful, backward-compatible manner, I can only conclude that oppositio= n to it is opposition to allow for easily moving the 64-bit boundary. > The most contentious point in draft-bourbaki-6man-classless-ipv6-00 > is that it tries to change the IID length used for SLAAC. That should hardly be contentious, on technical grounds, because the proble= m is not difficult to solve. It might be contentious only tangentially, in = the sense that it makes variable prefix lengths so easy to contend with? Bert From nobody Fri Jun 16 12:43:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CEF131618 for ; Fri, 16 Jun 2017 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kByaBBupiEe for ; Fri, 16 Jun 2017 12:42:58 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D025D12EAF9 for ; Fri, 16 Jun 2017 12:42:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5GJgwNZ024194; Fri, 16 Jun 2017 12:42:58 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5GJguxU024181 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 16 Jun 2017 12:42:56 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 12:42:54 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 16 Jun 2017 12:42:55 -0700 From: "Manfredi, Albert E" To: Mark Andrews CC: "ipv6@ietf.org" Subject: RE: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS5hKhwQnicctxIEa/s3kHx814saImWwSAgADLBAD//5j88IAAHJmDgAEDGrA= Date: Fri, 16 Jun 2017 19:42:54 +0000 Message-ID: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> In-Reply-To: <20170616035128.7F0FE7BCB631@rock.dv.isc.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: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 19:43:01 -0000 -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 > The security properties of 48 bit mac addresses were very > much discussed when the prefix size was being choosen. > They still prevented remote scanning of the subnet space > to find the hosts in the subnet. Random assignmemt just > improved on that by removing clustering effects. Well, clearly. In the original EUI-64, it would have been easy enough to id= entify all hosts from a given vendor, or down to the device itself, on a gi= ven subnet. If you randomize those 48 bits for all hosts, then that techniq= ue won't work. And if you shorten the lifespan of IIDs, even as infrequentl= y as a new IID every time you reboot the host, that does the same thing. Which only says to me, at least that one security rationale for long IIDs c= an be trivially met in /80 networks. Compared with the original EUI-64 IID,= even such things as collision likelihood are no worse in an /80 implementa= tion. > So no it wasn't after the fact, it was part of the > rational for the original assignment size. To be overly pedantic, didn't the IID randomization idea come well after th= e decision to adopt an IPX-like address structure? > Anonymity isn't the only possible benefit. And it won't work with DNS anyway. Operators and equipment vendors may have motivations I'm not aware of. But = to me, the best outcome of sticking to "default" or "mandatory" or "the onl= y easy option" /64 is mostly to try to prevent the race to the bottom. I su= ppose there's something to that. Bert From nobody Fri Jun 16 15:14:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80831292FD for ; Fri, 16 Jun 2017 15:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNKTT4ofQMzi for ; Fri, 16 Jun 2017 15:14:54 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 CF1BA129439 for ; Fri, 16 Jun 2017 15:14:54 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id f185so25632807pgc.0 for ; Fri, 16 Jun 2017 15:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LkTCxqAeCYqZASl2YbaStJoBJyZbBDPGqjJbMYx190Y=; b=Mu/3crTuJb+OL24XRD//dsyRZRUZnZOwSoMBoapkUKMTjlaX1l+CaDNLkcGmnveVgI MxOiXkOWfX+jMG2R+ou7yq/L8pzd0h01UDs8l3PcAEkg/G527Hldz0/Ft8a9g0O5Xrmc 8nI/VS+ATQpTXPKpnMW5Jyx5mNw2iVYvfhhHl3ktobRBedof4zp2XG/6mGhs0BTWPN8D CwH6z+ZlYR2NQEF4qx0102TWb3YFa4jyO0rfHhHfXY+or7eMrpi4NCYMmlVKhfTic7ng 9aeCxoKjJp4ojLv1r9B4np+9nK5d4lB79SW8MozmpFeP01gKR5+A+CT+WWq6C4b+dC5u IHCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LkTCxqAeCYqZASl2YbaStJoBJyZbBDPGqjJbMYx190Y=; b=obG6C70aSwNFlZWgYW5r0waDRoJs6WIGlSUcouUUM4uYVJ7qPna57RlUuk/g8mJCNw lm74ccwixosW7Jd6J3a03vDT/76qoo8/wLNJlMnYbUnjvNZVquFrKsSwWx5dkrGVGnyQ NBymd75Fc0pyd6VpLfgpGuLJ4X01cJMKhswETOBZ3v7wl/lX+A19/u+fv7uJ083Q8GY/ 92QLN85Z3/6EkGwmXNmrFRugXzN0zy1J62uVQ70DYR4rc7CfgUwP8SkKskbkJJP11CO/ GUA88tnxqeiI2ruzjm2giMdr5g9jkXfR5a4cUXiM5gYOUFHbcUUdXAvLO/HSB9smICQj Azbg== X-Gm-Message-State: AKS2vOxDKlEnNsDruNef3SsaO8TBtMFB30RYFoMxZNKrkDXIYcptLcry 9RyijPc9sOcpEWI9 X-Received: by 10.98.60.139 with SMTP id b11mr13343172pfk.170.1497651294187; Fri, 16 Jun 2017 15:14:54 -0700 (PDT) Received: from ?IPv6:2406:e001:3d1c:1:28cc:dc4c:9703:6781? ([2406:e001:3d1c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b82sm6464267pfd.111.2017.06.16.15.14.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 15:14:52 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" , Philip Homburg , "ipv6@ietf.org" References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> Date: Sat, 17 Jun 2017 10:15:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 22:14:57 -0000 On 17/06/2017 07:14, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg ... >> The most contentious point in draft-bourbaki-6man-classless-ipv6-00 >> is that it tries to change the IID length used for SLAAC. I find this allegation hard to reconcile with the following sentence in the Recommendations section of the draft: "But operationally we recommend, barring strong considerations to the contrary, using 64-bits for SLAAC..." > That should hardly be contentious, on technical grounds, because the problem is not difficult to solve. Most problems can be solved as a "small matter of programming", but given that the deployed base of IPv6, which assumes /64 for SLAAC, is now much larger** than the whole Internet was when the /64 boundary was defined, I really don't think that is going to happen for any existing technology. This draft is not actually about *changing* /64. It's about setting the the right balance between scenarios where /64 is appropriate and those where it isn't, given that routing is already defined to handle any prefix length. > It might be contentious only tangentially, in the sense that it makes variable prefix lengths so easy to contend with? I don't understand that sentence. ** I haven't worked out the ratio, but in any case it's apparent that the operational IPv6 network is already much bigger than the IPv4 network was when CIDR & BGP4 were deployed in 1993. We'd be playing with fire to change anything fundamental for the existing deployment. Brian > > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 16 15:59:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95E31294CF for ; Fri, 16 Jun 2017 15:59:38 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQp7brz8fEiO for ; Fri, 16 Jun 2017 15:59:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D081294CD for ; Fri, 16 Jun 2017 15:59:36 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CDB383494AD; Fri, 16 Jun 2017 22:59:08 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B3259160097; Fri, 16 Jun 2017 22:59:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9FC11160098; Fri, 16 Jun 2017 22:59:08 +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 Qax7qUaslRgq; Fri, 16 Jun 2017 22:59:08 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 220FF160097; Fri, 16 Jun 2017 22:59:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C51F97BD5040; Sat, 17 Jun 2017 08:59:04 +1000 (AEST) To: "Manfredi, Albert E" Cc: "ipv6@ietf.org" From: Mark Andrews References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> Subject: Re: Tussles in IPv6 Land In-reply-to: Your message of "Fri, 16 Jun 2017 19:42:54 +0000." Date: Sat, 17 Jun 2017 08:59:04 +1000 Message-Id: <20170616225904.C51F97BD5040@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 22:59:39 -0000 In message , "Manfredi, Albert E" writes: > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > > > The security properties of 48 bit mac addresses were very > > much discussed when the prefix size was being choosen. > > They still prevented remote scanning of the subnet space > > to find the hosts in the subnet. Random assignmemt just > > improved on that by removing clustering effects. > > Well, clearly. In the original EUI-64, it would have been easy enough to > identify all hosts from a given vendor, or down to the device itself, on > a given subnet. If you randomize those 48 bits for all hosts, then that > technique won't work. And if you shorten the lifespan of IIDs, even as > infrequently as a new IID every time you reboot the host, that does the > same thing. As I said, we were well aware of all of this when we went with /64 in the first place. Nothing prevented operators choosing addresses for hosts randomly then assigning those addresses manually. > Which only says to me, at least that one security rationale for long IIDs > can be trivially met in /80 networks. Compared with the original EUI-64 > IID, even such things as collision likelihood are no worse in an /80 > implementation. Only if you believed that 64 bit macs would not eventually be in use. > > So no it wasn't after the fact, it was part of the > > rational for the original assignment size. > > To be overly pedantic, didn't the IID randomization idea come well after > the decision to adopt an IPX-like address structure? It came after to prevent tracking of machines from one subnet to another. It also improved the ability to not be discovered from ~48 bits to 64 bits of randomness. > > Anonymity isn't the only possible benefit. > > And it won't work with DNS anyway. Having the name of the machine does not identify the user of the machine. In the networks where you get anonymity due to there being lots of people you quite often don't have PTR records. This is true even if you add AAAA records for the machine so that it can be reached if you know the name. > Operators and equipment vendors may have motivations I'm not aware of. > But to me, the best outcome of sticking to "default" or "mandatory" or > "the only easy option" /64 is mostly to try to prevent the race to the > bottom. I suppose there's something to that. There is a lot to that. There is also a lot to say for giving each site a /48 regardless of if it is a home, a cell phone or a business. > Bert -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 16 16:05:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7599129451 for ; Fri, 16 Jun 2017 16:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15ASyxzae-tI for ; Fri, 16 Jun 2017 16:05:28 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473561275C5 for ; Fri, 16 Jun 2017 16:05:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5GN5R1J023479; Fri, 16 Jun 2017 16:05:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5GN5Pw6023475 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 16 Jun 2017 16:05:25 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 16:05:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 16 Jun 2017 16:05:23 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS5u4DMNo02PJmWUqMngy/MtW5KqIoEXQg Date: Fri, 16 Jun 2017 23:05:23 +0000 Message-ID: References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> In-Reply-To: <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 23:05:29 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPj4gVGhhdCBzaG91bGQgaGFyZGx5 IGJlIGNvbnRlbnRpb3VzLCBvbiB0ZWNobmljYWwgZ3JvdW5kcywgYmVjYXVzZQ0KPj4gdGhlIHBy b2JsZW0gaXMgbm90IGRpZmZpY3VsdCB0byBzb2x2ZS4NCj4NCj4gTW9zdCBwcm9ibGVtcyBjYW4g YmUgc29sdmVkIGFzIGEgInNtYWxsIG1hdHRlciBvZiBwcm9ncmFtbWluZyIsDQo+IGJ1dCBnaXZl biB0aGF0IHRoZSBkZXBsb3llZCBiYXNlIG9mIElQdjYsIHdoaWNoIGFzc3VtZXMgLzY0IGZvcg0K PiBTTEFBQywgaXMgbm93IG11Y2ggbGFyZ2VyKiogdGhhbiB0aGUgd2hvbGUgSW50ZXJuZXQgd2Fz IHdoZW4gdGhlDQo+IC82NCBib3VuZGFyeSB3YXMgZGVmaW5lZCwgSSByZWFsbHkgZG9uJ3QgdGhp bmsgdGhhdCBpcyBnb2luZyB0bw0KPiBoYXBwZW4gZm9yIGFueSBleGlzdGluZyB0ZWNobm9sb2d5 Lg0KDQpTaW5jZSB5b3UgbWVudGlvbiBpbiB5b3VyIGZvb3Rub3RlIENJRFIgZGVwbG95bWVudCB3 aXRoIElQdjQsIHdoaWNoIHdhcyBhbHNvIHdoYXQgY2FtZSB0byBtaW5kIHRvIG1lLCBJIHRoaW5r IHRoYXQgdGhpcyBub24tNjQtYml0LUlJRCBTTEFBQyBzaG91bGQgYmUgZWFzaWVyIHRvIGludHJv ZHVjZSB0aGFuIENJRFIgd2FzLiBGb3Igb25lIHRoaW5nLCByb3V0ZXJzIGFscmVhZHkga25vdyBo b3cgdG8gcm91dGUgdmFyaWFibGUgbGVuZ3RoIHByZWZpeGVzIHdpdGggSVB2Ni4gQnV0IGVpdGhl ciB3YXksIHRoZXNlIGNoYW5nZXMgY2FuIGhhcHBlbiwgd2l0aCBzb2Z0d2FyZSB1cGRhdGVzLCBh cyB0aGV5IGhhdmUgaGFwcGVuZWQgaW4gdGhlIHBhc3QuDQoNCkkgc2VlIHRoaXMgSUlELWFnbm9z dGljIFNMQUFDIGFzIGJlaW5nIGxpbWl0ZWQgdG8gYSBsb2NhbCBzdWJuZXQgaXNzdWUsIHdoaWNo IGEgdHJ1bHktbm90LWRpZmZpY3VsdCBzb2Z0d2FyZSB1cGRhdGUgdG8gdGhlIGxvY2FsIGhvc3Rz IGNhbiBzb2x2ZS4gUHJlZml4IGxlbmd0aCBhZ25vc3RpYyBTTEFBQyBjYW4gYmUgc3dpdGNoZWQg b24gaW4gYSB2ZXJ5IHdlbGwgY29udHJvbGxlZCBtYW5uZXIsIGJ5IHRoZSByb3V0ZXIsIHdoZW4g dGhlIG5ldCBhZG1pbiBkZXRlcm1pbmVzIHRoYXQgdGhlIGF0dGFjaGVkIGhvc3RzIGFyZSByZWFk eSwgb3IgZW5vdWdoIG9mIHRoZW0gYXJlIHJlYWR5LiBVbnRpbCBzdWNoIGEgdGltZSwgYWxsIHVw Z3JhZGVkIGhvc3RzIGNvbnRpbnVlIHRvIHdvcmsganVzdCBmaW5lLCB3aXRoIDY0LWJpdCBJSURz Lg0KDQpJIGxhcmdlbHkgYWdyZWUgd2l0aCB0aGlzIGRyYWZ0LCByZWFsbHkuIEJ1dCwgZm9yIGV4 YW1wbGU6DQoNCiAgIElQdjYgdW5pY2FzdCBpbnRlcmZhY2VzIG1heSB1c2UgYW55IHN1Ym5ldCBs ZW5ndGggdXAgdG8gMTI4IGV4Y2VwdA0KICAgZm9yIHNpdHVhdGlvbnMgd2hlcmUgYW4gSW50ZXJu ZXQgU3RhbmRhcmQgZG9jdW1lbnQgbWF5IGltcG9zZSBhDQogICBwYXJ0aWN1bGFyIGxlbmd0aCwg Zm9yIGV4YW1wbGUgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24NCiAgIChTTEFB QykgW1JGQzQ4NjJdLA0KDQpJIHdvdWxkIHNheSBpbnN0ZWFkLCBldmVuIFJGQyA0ODYyIGNhbiBi ZSBtb2RpZmllZCwgd2l0aCBtaW5pbWFsIGNoYW5nZXMsIHRvIG5vdCBpbXBvc2Ugc3VjaCBhIHJl c3RyaWN0aW9uLiBUaGF0IHJlc3RyaWN0aW9uIHdhcyBtb3RpdmF0ZWQgYnkgUkZDIDI0NjQuIFRo ZSBpbnRlbnQgb2YgUkZDIDI0NjQgbm8gbG9uZ2VyIGFwcGxpZXMuIFRoZSByYXRpb25hbGUgZm9y IGEgcGFydGljdWxhciBJSUQgbGVuZ3RoLCB3aXRoIElQdjYgb3ZlciBFdGhlcm5ldCwgSUVFRSA4 MDIuMTEsIGFuZCBtb3N0IG90aGVyIGxpbmsgbGF5ZXJzLCB0aGVyZWZvcmUgYWxzbyBubyBsb25n ZXIgYXBwbGllcy4NCg0KVGhlIHJlY29tbWVuZGF0aW9ucyBvZiBTZWN0aW9uIDQgYXJlIGdlbmVy YWxseSBub24tY29udHJvdmVyc2lhbCAodG8gbWUpLCBhbHRob3VnaCBwcm9iYWJseSBvdmVybHkg Y29uc2VydmF0aXZlLg0KDQo+PiBJdCBtaWdodCBiZSBjb250ZW50aW91cyBvbmx5IHRhbmdlbnRp YWxseSwgaW4gdGhlIHNlbnNlIHRoYXQgaXQNCj4+IG1ha2VzIHZhcmlhYmxlIHByZWZpeCBsZW5n dGhzIHNvIGVhc3kgdG8gY29udGVuZCB3aXRoPw0KPg0KPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhh dCBzZW50ZW5jZS4NCg0KQmVjYXVzZSBTTEFBQyB3aXRoIHZhcmlhYmxlIElJRCBsZW5ndGhzIHNl ZW1zIHNvIHN0cmFpZ2h0Zm9yd2FyZCB0byBpbXBsZW1lbnQsIEkgY2FuIG9ubHkgdGhpbmsgdGhh dCB0aGlzIGlzIGNvbnRlbnRpb3VzIGJlY2F1c2UgaXQgbWFrZXMgbW92aW5nIHRoYXQgNjQtYml0 IGJvdW5kYXJ5IHRvbyBlYXN5PyBUaGUgYm91bmRhcnkgd291bGQgYmUgbW9yZSBkaWZmaWN1bHQg dG8gY2hhbmdlLCBpZiB0aGUgb25seSB3YXlzIHRvIGRvIHNvIHJlcXVpcmVkIG1hbnVhbCBjb25m aWd1cmF0aW9uIG9mIGhvc3RzLg0KDQpCZXJ0DQoNCg== From nobody Fri Jun 16 16:24:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3471275C5 for ; Fri, 16 Jun 2017 16:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvBCgWyf9ocl for ; Fri, 16 Jun 2017 16:24:01 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58C51242F5 for ; Fri, 16 Jun 2017 16:24:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5GNO0ai004277; Fri, 16 Jun 2017 16:24:00 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5GNNsJe004261 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 16 Jun 2017 16:23:54 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 16:23:52 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 16 Jun 2017 16:23:52 -0700 From: "Manfredi, Albert E" To: Mark Andrews CC: "ipv6@ietf.org" Subject: RE: Tussles in IPv6 Land Thread-Topic: Tussles in IPv6 Land Thread-Index: AQHS5hKhwQnicctxIEa/s3kHx814saImWwSAgADLBAD//5j88IAAHJmDgAFAwH2AAANLkA== Date: Fri, 16 Jun 2017 23:23:52 +0000 Message-ID: <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> <20170616225904.C51F97BD5040@rock.dv.isc.org> In-Reply-To: <20170616225904.C51F97BD5040@rock.dv.isc.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: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 23:24:03 -0000 -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 > There is also a lot to say for giving each site a /48 regardless > of if it is a home, a cell phone or a business. Exactly. So here's today's question. Is this remotely likely to happen? No,= from what I've been able to determine. So what's the next best thing, which is (IMO) considerably more likely to h= appen, without incurring any significant penalties compared with that /48 p= ossibility? My answer is, /64 from the operator, which can locally be increased to /80,= with no credible downside. I don't know how the IETF can force operators t= o do anything, but I have to believe it's more realistic to hope for /64s t= o every subscriber, given how prevalent that has become? And then parenthetically, if local nets want to increase the prefix even mo= re, they can, and they know the security issues, which may be a big who car= es for them. Now we can sleep better knowing that the IPv4 address length has effectivel= y been doubled at least. As opposed to only increased in length by 50%. Bert From nobody Fri Jun 16 16:33:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C8112969E for ; Fri, 16 Jun 2017 16:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCUj0NjxnXIF for ; Fri, 16 Jun 2017 16:33:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1412956C for ; Fri, 16 Jun 2017 16:33:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dM0jp-0000EwC; Sat, 17 Jun 2017 01:33:13 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> In-reply-to: Your message of "Sat, 17 Jun 2017 10:15:00 +1200 ." <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> Date: Sat, 17 Jun 2017 01:33:11 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 23:33:20 -0000 >>> The most contentious point in draft-bourbaki-6man-classless-ipv6-00 >>> is that it tries to change the IID length used for SLAAC. > >I find this allegation hard to reconcile with the following sentence >in the Recommendations section of the draft: > >"But operationally we recommend, >barring strong considerations to the contrary, using 64-bits for >SLAAC..." The way I understand the draft, it tries to make the IID length purely a decision of the operator. Operators are adviced to use 64 bits, but the draft tries to give operators the freedom to advertise a /120 and have the host use an 8 bit IID. For obvious reasons, Lorenzo is not happy with that. I'm not happy with that either. But what I find curious, is that as far as I know Job has no operational need for SLAAC. Mostly likely, Randy doesn't have an operational need for SLAAC either. So why is this mixed in a single draft? What prefix related issues are encoutered by people who operate core routers? That's a discussion that should be easy to solve. On the other hand, there seems to be very little consensus on how to move forward with SLAAC. From nobody Fri Jun 16 17:00:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22A129540 for ; Fri, 16 Jun 2017 17:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C96du4Bx3qmI for ; Fri, 16 Jun 2017 17:00:32 -0700 (PDT) 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 6D5C7128B51 for ; Fri, 16 Jun 2017 17:00:32 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s66so28849438pfs.1 for ; Fri, 16 Jun 2017 17:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kYS+4eb6mpdY5MNjP+psjOKQ/4Muv0CA/j0acPbMQ/s=; b=I3kr4t88ZJuNys5Z/MoU8pWv40XFSgCkGIcBz0/jVjf6YFFA6IFepMOzcnIZdugs9u Jej6cJFWzrHz0k2bcA7nE0fRm5WQ3RgOcLSIwrBw4dycckuq23nriXhnHiJ2B4WaFooI 2rDXke0cOuifhAstYcS86ZiUw7UPAYQmMKIA+2bKFQe5ZHCUnXr5W5VXue6xaD8ydDVH nVJUVaQP+VDCMAHg8zjP6RgtqyYcBnWd2kLvotkk/vCE51bhCY5dyYQDSIMvd5alAYty YEiQs/Qzf+SOED+RzHVhki4XsqXHGKBV89ichrYZPG39Q8UMwD3WsHJpXH5+2g2Ii11p lM3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=kYS+4eb6mpdY5MNjP+psjOKQ/4Muv0CA/j0acPbMQ/s=; b=FaxWZIV0UbXAwJXLAejnre4IRmipsgqx3O1m+fpOD7+AqDI7pAVVDbXK4XB4sZmHWO 7v0t5VG+GRJcK9qLgSViO/z/H0rtp1qQvo00f3vpKHQ3yzB4aEzbgNnorLz69wIQbAWw v3aF7tpaKVjRZTFnIAgK895UmKB4Vah0rgRSDHkNM7U+tCG843TO7sjYsLQup6vraGQ/ nuhhaou585VTuq3CaLHRs0wVjxIdbTm5d2E4xLUtOde2PLbMzM4cktnLc20ZoFmSeaef pEOMg8BWvNfKK2cl/GUhY+Go8ltqo3QKMrYT7mVgcJ9Ne6iPzywVfgJLgV7DVqDPbxrf 3MsA== X-Gm-Message-State: AKS2vOye1Y07XU4NSmnT3Bw2HLMX5iC2qu29TUYJZHAN5gs1aBhOqm1c jnkqQhfyIajUeNVN X-Received: by 10.98.23.73 with SMTP id 70mr13504387pfx.76.1497657631682; Fri, 16 Jun 2017 17:00:31 -0700 (PDT) Received: from ?IPv6:2406:e007:53e7:1:28cc:dc4c:9703:6781? ([2406:e007:53e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b3sm6448333pfg.47.2017.06.16.17.00.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 17:00:31 -0700 (PDT) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 To: Philip Homburg , ipv6@ietf.org References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 17 Jun 2017 12:00:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:00:34 -0000 On 17/06/2017 11:33, Philip Homburg wrote: >>>> The most contentious point in draft-bourbaki-6man-classless-ipv6-00 >>>> is that it tries to change the IID length used for SLAAC. >> >> I find this allegation hard to reconcile with the following sentence >> in the Recommendations section of the draft: >> >> "But operationally we recommend, >> barring strong considerations to the contrary, using 64-bits for >> SLAAC..." > > The way I understand the draft, it tries to make the IID length purely > a decision of the operator. > > Operators are adviced to use 64 bits, but the draft tries to give operators > the freedom to advertise a /120 and have the host use an 8 bit IID. > > For obvious reasons, Lorenzo is not happy with that. I'm not happy with > that either. > > But what I find curious, is that as far as I know Job has no operational > need for SLAAC. Mostly likely, Randy doesn't have an operational need for > SLAAC either. > > So why is this mixed in a single draft? Because, I think, the word 'prefix' has three distinct aspects in IPv6: a prefix used by a routing protocol, a prefix used by a node to determine if another node is connected to the same link, and a prefix used to construct the complete address of a node. We have generally been a bit careless in distinguishing these three aspects. Brian > What prefix related issues are encoutered by people who operate core routers? > That's a discussion that should be easy to solve. > > On the other hand, there seems to be very little consensus on how to > move forward with SLAAC. > > > From nobody Fri Jun 16 18:43:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED908129577 for ; Fri, 16 Jun 2017 18:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.802 X-Spam-Level: X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik4oA835G1ov for ; Fri, 16 Jun 2017 18:43:12 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 397BB12741D for ; Fri, 16 Jun 2017 18:43:11 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 7A631C83 for ; Sat, 17 Jun 2017 01:43:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEtZk8akuZJZ for ; Fri, 16 Jun 2017 20:43:11 -0500 (CDT) Received: from mail-io0-f199.google.com (mail-io0-f199.google.com [209.85.223.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 54135698 for ; Fri, 16 Jun 2017 20:43:11 -0500 (CDT) Received: by mail-io0-f199.google.com with SMTP id 16so39358121iok.9 for ; Fri, 16 Jun 2017 18:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e50vrNr/FewB86uklhc17PWFm8KJlDL9Os5mbe3kyfw=; b=foHiEFQXnIp/bNsqWMiZ1b0zJRR6jMHK1ryv7aCXOjvydJtMNNj96GGGQUuE9i3eZ2 OeUHFyWx4Qy9NCrlFczVlEeA4tKdj4uRc7PJHX9IrNRepAHPCbpYc/urVqs8RwUNnprl MFskEv5bmi3v+8R3Jgln83DBBYgjcM0KpZChfwsd1wtcQyrbh2u2i1E5tauXGoZ9AulP fB4GL/qJv5xw1Wts8YjzmIOqUIBq4/YMuVHFzLLEgThAl+fYbttZMMvHFTqynXAToH/W 2KRdClk67L9yZZwbRnfM8A9IxbCEVlIPaafJeAhfDHaE+Sbd8ijsfihJyDN8uYDBp8OA MAVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e50vrNr/FewB86uklhc17PWFm8KJlDL9Os5mbe3kyfw=; b=muUiG18HiKjqvIUfQfMw1hi5csfAZApeHhT4n8qCx6H25yDVj5TUCIpXYxMjN9juiL VNu2veA/pT88B82Zvlag0AFOxdLz7v/pCmevHFAQKkouJpab2653oKqucPdM1MZaUrC2 f4h0bztFP8L6fRtiMpl32LKyfWCkOvIZr3iHxRDD6N+7L+qJTWIH9mV5TTgdUS1TeZ2R CukcegAnHq1Gvbyk/l/6LruRHyAtuqA6Z4WLFVvb2KpcUsovzntvGtxQA6C1OnwyuA4j MCAsY3rKywYh1EyP/S0Xo6hGeSp+UrAA9t6hTS1c58EfhId4FiGXcFat3EhPtGjdNfvV YpoQ== X-Gm-Message-State: AKS2vOzWMw5csIgZDhtDF+ABsjq9nbNRuyOHLxpTCGdrGqfJe/4320pn rpuAKdyxpA915nadk1p6YN+zVtHpkBzpsnFy5Av+g+FzRh7s8klW//O9Uuz0p94ouw9ucAiIpFo = X-Received: by 10.36.181.78 with SMTP id j14mr13613320iti.82.1497663790546; Fri, 16 Jun 2017 18:43:10 -0700 (PDT) X-Received: by 10.36.181.78 with SMTP id j14mr13613314iti.82.1497663790365; Fri, 16 Jun 2017 18:43:10 -0700 (PDT) Received: from [172.20.20.20] ([73.94.201.14]) by smtp.gmail.com with ESMTPSA id v125sm2732859ita.13.2017.06.16.18.43.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 18:43:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: draft-bourbaki-6man-classless-ipv6-00 From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Fri, 16 Jun 2017 20:43:08 -0500 Cc: Philip Homburg , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <17746CF1-DBA4-4F69-87B6-D375F7046300@umn.edu> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> <557643ff-8dd8-6b21-5cc8-7ad0f4f12ced@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 01:43:14 -0000 Sent from my iPhone > On Jun 16, 2017, at 19:00, Brian E Carpenter = wrote: >=20 > Because, I think, the word 'prefix' has three distinct aspects in > IPv6: a prefix used by a routing protocol, a prefix used by a > node to determine if another node is connected to the same link, > and a prefix used to construct the complete address of a node. > We have generally been a bit careless in distinguishing these > three aspects. >=20 > Brian Also, in the last two aspects of an IPv6 prefix, the part of the address lef= tover, the righthand side, can quite reasonably be referred to as an Interfa= ce Identifier (IID) in both cases. And, of those two aspects of IID, only th= e last one is currently defined to be 64 bits, the other can have any length= from 0 to 128 but it Is 64 bit as well in most cases.=20 This is all exasperated, by using the term subnet prefix in RFC4291 and it's= predecessors, because in IPv4 the last to aspects of a IPv6 prefix, and the= two aspects of IID, are bound together and called a subnet prefix, and in I= Pv6 those two aspects are supposed to be separate. While I could support a variable length addressing prefix and IID that is no= small change and is not something to be included in RFC4291bis, but clearly= resolving the ambiguity of the three aspects of an IPv6 prefix and the two a= spects of an IPv6 IID is required to move RFC4291bis forward to Internet Sta= ndard. Thanks. David Farmer From nobody Sat Jun 17 00:16:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4942126D45 for ; Sat, 17 Jun 2017 00:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvCtL9PPOkLf for ; Sat, 17 Jun 2017 00:16:55 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 C7E2F12025C for ; Sat, 17 Jun 2017 00:16:54 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id m31so36657565uam.1 for ; Sat, 17 Jun 2017 00:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aVCwrm/lDj88hHBVet06mGWVm5fDznJ85MvawxJj/Q0=; b=f0hRZ3lZKtNY9+uat0jmiy2ZVw7O8985NMjtc39QDVkUTUmbLZjIQvAIGPgj2fjchq AkmlG1DI1/GKSGcfgYBiL5St68bGpNxwfmdGYdDovBMTeIpGwpqbo0iiNUnRtC2U/eMl 8ilCE7ce/QtMF8pvDV6BoiOVkdPFkbVwCje/HBPYLW+u1fQbYIkLxYaTK8HYgatFwuwr qNnSAIHeVgbr7CrGqk+lucBeEGN2//oE95WQQSMqHYu20xWxqejfmKDr1MHKrbuEf0Sh 6eh0hBrS3vx92QgMU5MoVX4dmhS6JFjKMP6wdgMf10dPMFNLNlGXEA3TVKDO2GfTINy3 zNbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aVCwrm/lDj88hHBVet06mGWVm5fDznJ85MvawxJj/Q0=; b=dYwnYROr/XNMp7bK5y/z1ZO3hAtUuF6kQQP+4HmHjuLQZG9EsiPecQAN1zJVDbt3vy g+8yUX3JiyEbr5x8Q748rxlVIVyv2kbvYK1MLM4L2GUtDFsFDdZCEEo8LjOzwspRjUDQ iii2G5MhmXn8y4Ubd8K+VtcYSlsG4y0Ua37ygswcHWZUQxZTY4xk/HdTst0Z3jYFZsMD 1qwqB0CJIDC8oWbKyH+8Scc1WgKTm9jsu+y+5adE0cltakVJTlpZpGmfNptF5N9eXcwJ h4Tg6B+nS81KHKnK9/NiHwoVKMC/r/d5PxvF2IGJB0mTWKLkRAzFN/v0xq4cG/tkI6YF T4lg== X-Gm-Message-State: AKS2vOxnm+8XP3gHSz/ojL1HXtoXQ8PahwKiaen858oxKZuYBRXRF3Ja mj2kOt7BFB9m5HeP+chlVPZx7Gi1Dw== X-Received: by 10.176.23.25 with SMTP id j25mr1581878uaf.32.1497683813936; Sat, 17 Jun 2017 00:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Sat, 17 Jun 2017 00:16:53 -0700 (PDT) Received: by 10.176.81.100 with HTTP; Sat, 17 Jun 2017 00:16:53 -0700 (PDT) In-Reply-To: <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> From: Mark Smith Date: Sat, 17 Jun 2017 17:16:53 +1000 Message-ID: Subject: RE: draft-bourbaki-6man-classless-ipv6-00 To: "Manfredi, Albert E" Cc: 6man WG , Philip Homburg Content-Type: multipart/alternative; boundary="f40304361a9eb73777055222afca" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 07:16:57 -0000 --f40304361a9eb73777055222afca Content-Type: text/plain; charset="UTF-8" On 17 Jun. 2017 05:15, "Manfredi, Albert E" wrote: -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > Job, > > I'm curious what use you have for SLAAC with prefixes longer than /64. By no means attempting to answer for Job, my answer is simple. SLAAC is a plug and play technique, and I see no reason why that plug and play technique cannot be applied to other than /64 networks. There's no reason to make non-/64 networks always an exception, only available for manual configuration, or even only available with this DHCP-PD that isn't much supported. To expand a routed network at the edges easily, and allow subnetting in the expanded network, and allow plug and play operation in the expanded part, SLAAC should be one element of the solution. DHCP-PD recycles the same technique used in IPv4, and it's a good additional option, especially useful when the client addresses must be known to the network operator. * DHCPv6 does not record addresses in use on a link. It will not record link local addresses or manually configured addresses. It is only recording hosts that asked to acquire addresses via DHCP. * You're overlooking the cost and service impact of renumbering to increase the size of the subnet if it isn't large enough. That can be a large cost and large impact if many hosts are involved. So large, I've seen people avoid paying it when there were in the order of 1000 hosts involved on an IPv4 network - the hosts were spread across 4 x /24s on the same Ethernet segment. Given that variable length IID SLAAC is just not difficult to implement, in a graceful, backward-compatible manner, I can only conclude that opposition to it is opposition to allow for easily moving the 64-bit boundary. > The most contentious point in draft-bourbaki-6man-classless-ipv6-00 > is that it tries to change the IID length used for SLAAC. That should hardly be contentious, on technical grounds, because the problem is not difficult to solve. It might be contentious only tangentially, in the sense that it makes variable prefix lengths so easy to contend with? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f40304361a9eb73777055222afca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 17 Jun. 2017 05:15, "Manfredi, Albert E" <albert.e.manfredi@boeing.com&g= t; wrote:
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ie= tf.org] On Behalf Of Philip Homburg

> Job,
>
> I'm curious what use you have for SLAAC with prefixes longer than = /64.

By no means attempting to answer for Job, my answer is simple. SLAAC = is a plug and play technique, and I see no reason why that plug and play te= chnique cannot be applied to other than /64 networks. There's no reason= to make non-/64 networks always an exception, only available for manual co= nfiguration, or even only available with this DHCP-PD that isn't much s= upported.

To expand a routed network at the edges easily, and allow subnetting in the= expanded network, and allow plug and play operation in the expanded part, = SLAAC should be one element of the solution. DHCP-PD recycles the same tech= nique used in IPv4, and it's a good additional option, especially usefu= l when the client addresses must be known to the network operator.

* DHCPv6 does not record addresses in use on a lin= k. It will not record link local addresses or manually configured addresses= . It is only recording hosts that asked to acquire addresses via DHCP.

* You're overlooking the= cost and service impact of renumbering to increase the size of the subnet = if it isn't large enough. That can be a large cost and large impact if = many hosts are involved. So large, I've seen people avoid paying it whe= n there were in the order of 1000 hosts involved on an IPv4 network - the h= osts were spread across 4 x /24s on the same Ethernet segment.



<= blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex">
Given that variable length IID SLAAC is just not difficult to implement, in= a graceful, backward-compatible manner, I can only conclude that oppositio= n to it is opposition to allow for easily moving the 64-bit boundary.

> The most contentious point in draft-bourbaki-6man-classless-ipv6-= 00
> is that it tries to change the IID length used for SLAAC.

That should hardly be contentious, on technical grounds, because the = problem is not difficult to solve. It might be contentious only tangentiall= y, in the sense that it makes variable prefix lengths so easy to contend wi= th?

Bert


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

--f40304361a9eb73777055222afca-- From nobody Sat Jun 17 16:09:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3F31242F7 for ; Sat, 17 Jun 2017 16:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCrb-EwNpw2p for ; Sat, 17 Jun 2017 16:09:26 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA36126C23 for ; Sat, 17 Jun 2017 16:09:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5HN9QEE061111; Sat, 17 Jun 2017 16:09:26 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5HN9LB2061107 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 17 Jun 2017 16:09:21 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 17 Jun 2017 16:09:20 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sat, 17 Jun 2017 16:09:21 -0700 From: "Manfredi, Albert E" To: Mark Smith CC: 6man WG Subject: RE: draft-bourbaki-6man-classless-ipv6-00 Thread-Topic: draft-bourbaki-6man-classless-ipv6-00 Thread-Index: AQHS5zm239DMh3ew1k62cio97F1JUaIpqudA Date: Sat, 17 Jun 2017 23:09:20 +0000 Message-ID: <3fc473c3dc2b4d86ba6e20b5fd49a0c9@XCH15-06-11.nw.nos.boeing.com> References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 23:09:28 -0000 RnJvbTogTWFyayBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dIA0KDQo+ICog REhDUHY2IGRvZXMgbm90IHJlY29yZCBhZGRyZXNzZXMgaW4gdXNlIG9uIGEgbGluay4gSXQgd2ls bCBub3QNCj4gcmVjb3JkIGxpbmsgbG9jYWwgYWRkcmVzc2VzIG9yIG1hbnVhbGx5IGNvbmZpZ3Vy ZWQgYWRkcmVzc2VzLiBJdA0KPiBpcyBvbmx5IHJlY29yZGluZyBob3N0cyB0aGF0IGFza2VkIHRv IGFjcXVpcmUgYWRkcmVzc2VzIHZpYSBESENQLg0KDQpPa2F5LCBsaWtlIERIQ1B2NC4gQnV0IHdo ZW4gdGhlIHN5c3RlbSBhZG1pbiBuZWVkcyBzdGFibGUgYWRkcmVzc2VzIGZvciBob3N0cyBpbiB0 aGUgbmV0d29yaywgZS5nLiBhIHBlZXItcGVlciBuZXR3b3JrIHRoYXQgZG9lcyBub3QgdXNlIGEg RE5TLCBESENQdjYgUEQgaXMgYSBnb29kIHRvb2wgdG8gaGF2ZS4NCg0KPiAqIFlvdSdyZSBvdmVy bG9va2luZyB0aGUgY29zdCBhbmQgc2VydmljZSBpbXBhY3Qgb2YgcmVudW1iZXJpbmcgdG8NCj4g aW5jcmVhc2UgdGhlIHNpemUgb2YgdGhlIHN1Ym5ldCBpZiBpdCBpc24ndCBsYXJnZSBlbm91Z2gu IFRoYXQgY2FuDQo+IGJlIGEgbGFyZ2UgY29zdCBhbmQgbGFyZ2UgaW1wYWN0IGlmIG1hbnkgaG9z dHMgYXJlIGludm9sdmVkLiBTbw0KPiBsYXJnZSwgSSd2ZSBzZWVuIHBlb3BsZSBhdm9pZCBwYXlp bmcgaXQgd2hlbiB0aGVyZSB3ZXJlIGluIHRoZQ0KPiBvcmRlciBvZiAxMDAwIGhvc3RzIGludm9s dmVkIG9uIGFuIElQdjQgbmV0d29yayAtIHRoZSBob3N0cyB3ZXJlDQo+IHNwcmVhZCBhY3Jvc3Mg NCB4IC8yNHMgb24gdGhlIHNhbWUgRXRoZXJuZXQgc2VnbWVudC4NCg0KRGVwZW5kcyBvbiB0aGUg c2NlbmFyaW8uIEluIG15IHJlYWxpdHksIGV4cGFuZGluZyBhIG5ldHdvcmsgYXQgdGhlIGVkZ2Vz IGVhc2lseSwgd2l0aG91dCBpbnZvbHZpbmcgaW4gYW55IHdheSB0aGUgYXV0aG9yaXR5IHRoYXQg YWxsb2NhdGVzIGJsb2NrcyBvZiBhZGRyZXNzZXMsIGlzIHF1aXRlIHZhbHVhYmxlLiBBIHNjaGVt ZSB0aGF0IG1ha2VzIHRoaXMgZGlmZmljdWx0IGlzIGluc3RlYWQgYSBudWlzYW5jZS4NCg0KV2hh dCdzIGJlaGluZCB0aGlzIGRlYmF0ZSwgZnJvbSBteSBwb2ludCBvZiB2aWV3LCBpcyBhIG5lZWQg Zm9yIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSBOQVQgaW4gSVB2NCwgYnV0IHdp dGhvdXQgaW5jdXJyaW5nIHRoZSBwZW5hbHRpZXMgb2YgdXNpbmcgTkFULiBBIGZpeGVkIElJRCBs ZW5ndGggb2YgNjQgYml0cywgd2hlbiAvNjRzIG9yIG1heWJlIGV2ZW4gLzU2cyBhcmUgd2hhdCBj dXN0b21lcnMgYXJlIGdpdmVuLCBpcyBhIGJpdCBsaWtlIG5ldmVyIGhhdmluZyBpbnZlbnRlZCBO QVQgZm9yIElQdjQuIEl0J3MgbGltaXRpbmcuIEkgcmVhbGl6ZSB0aGlzIHZpZXcgaXMgbm90IGV2 ZXJ5b25lJ3MgY29uY2Vybi4NCg0KQmVydA0KDQo= From nobody Sun Jun 18 16:48:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFB127078 for ; Sun, 18 Jun 2017 16:48:54 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB8o2JgC-ZAS for ; Sun, 18 Jun 2017 16:48:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 29D35126B6D for ; Sun, 18 Jun 2017 16:48:53 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 8FC0C24AE08; Sun, 18 Jun 2017 23:47:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 634DD160045; Sun, 18 Jun 2017 23:47:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2CBCD160055; Sun, 18 Jun 2017 23:47:32 +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 4mpqowBAfNDR; Sun, 18 Jun 2017 23:47:32 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D65FA160045; Sun, 18 Jun 2017 23:47:31 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DCA517BDECFD; Mon, 19 Jun 2017 09:47:28 +1000 (AEST) To: "Manfredi, Albert E" Cc: Mark Smith , 6man WG From: Mark Andrews References: <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <20170614094034.GC30896@gir.theapt.org> <20170614095910.GE30896@gir.theapt.org> <20170616050718.wbpb2oqhfrvsk6fv@hanna.meerval.net> <16648f96a35a4f41a20526fa04395996@XCH15-06-11.nw.nos.boeing.com> <3fc473c3dc2b4d86ba6e20b5fd49a0c9@XCH15-06-11.nw.nos.boeing.com> Subject: Re: draft-bourbaki-6man-classless-ipv6-00 In-reply-to: Your message of "Sat, 17 Jun 2017 23:09:20 +0000." <3fc473c3dc2b4d86ba6e20b5fd49a0c9@XCH15-06-11.nw.nos.boeing.com> Date: Mon, 19 Jun 2017 09:47:28 +1000 Message-Id: <20170618234728.DCA517BDECFD@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 23:48:55 -0000 In message <3fc473c3dc2b4d86ba6e20b5fd49a0c9@XCH15-06-11.nw.nos.boeing.com>, "M anfredi, Albert E" writes: > From: Mark Smith [mailto:markzzzsmith@gmail.com] > > > * DHCPv6 does not record addresses in use on a link. It will not > > record link local addresses or manually configured addresses. It > > is only recording hosts that asked to acquire addresses via DHCP. > > Okay, like DHCPv4. But when the system admin needs stable addresses for > hosts in the network, e.g. a peer-peer network that does not use a DNS, > DHCPv6 PD is a good tool to have. > > > * You're overlooking the cost and service impact of renumbering to > > increase the size of the subnet if it isn't large enough. That can > > be a large cost and large impact if many hosts are involved. So > > large, I've seen people avoid paying it when there were in the > > order of 1000 hosts involved on an IPv4 network - the hosts were > > spread across 4 x /24s on the same Ethernet segment. > > Depends on the scenario. In my reality, expanding a network at the edges > easily, without involving in any way the authority that allocates blocks > of addresses, is quite valuable. A scheme that makes this difficult is > instead a nuisance. > > What's behind this debate, from my point of view, is a need for the same > functionality offered by NAT in IPv4, but without incurring the penalties > of using NAT. A fixed IID length of 64 bits, when /64s or maybe even /56s > are what customers are given, is a bit like never having invented NAT for > IPv4. It's limiting. I realize this view is not everyone's concern. Go complain to the ISP, really. The IETF allocation scheme was a /48 for every site and additional /48s if you needed them. Thats 10's of thousands of /48's per person on the planet. Thats 100 of millions of subnets. If your ISP isn't supplying you with a /48 and additional /48's if needed they are not doing their job. Just because something is technically possible, can be made to work, it doesn't mean that it is a good thing. There a plenty of examples of where it is a bad thing. > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jun 18 19:07:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BDB1200F3 for ; Sun, 18 Jun 2017 19:07:25 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI_WUQgG3Mwa for ; Sun, 18 Jun 2017 19:07:24 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 73AA31200C5 for ; Sun, 18 Jun 2017 19:07:24 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id EC261349315; Mon, 19 Jun 2017 02:07:20 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B73D2160045; Mon, 19 Jun 2017 02:07:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 70B9116004F; Mon, 19 Jun 2017 02:07:20 +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 VsVDOUs-JjJF; Mon, 19 Jun 2017 02:07:20 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DB469160045; Mon, 19 Jun 2017 02:07:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A2D5D7BDFE5A; Mon, 19 Jun 2017 12:07:17 +1000 (AEST) To: "Manfredi, Albert E" Cc: "ipv6@ietf.org" From: Mark Andrews References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> <20170616225904.C51F97BD5040@rock.dv.isc.org> <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com> Subject: Re: Tussles in IPv6 Land In-reply-to: Your message of "Fri, 16 Jun 2017 23:23:52 +0000." <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com> Date: Mon, 19 Jun 2017 12:07:17 +1000 Message-Id: <20170619020717.A2D5D7BDFE5A@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 02:07:25 -0000 In message <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com>, "M anfredi, Albert E" writes: > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=20 > > > There is also a lot to say for giving each site a /48 regardless > > of if it is a home, a cell phone or a business. > > Exactly. So here's today's question. Is this remotely likely to happen? > No, from what I've been able to determine. We have ISPs that hand out /48s to anyone on the planet just by requesting one. There are ISP's that handout /56s. There ISPs that handout /64s though most of them are only doing so because they are dealing with limitations on existing hardware and they intend to offer short prefixes in the future. So yes, I do believe shorter than /64 prefixes will become the norm. > So what's the next best thing, which is (IMO) considerably more likely to > happen, without incurring any significant penalties compared with that > /48 possibility? > > My answer is, /64 from the operator, which can locally be increased to > /80, with no credible downside. I don't know how the IETF can force > operators to do anything, but I have to believe it's more realistic to > hope for /64s to every subscriber, given how prevalent that has become? And then the operator will just hand the consumer a /80 because they can and someone like you will come along and argue "We can make it a /96 for the user, thats more than enough address space". > And then parenthetically, if local nets want to increase the prefix even > more, they can, and they know the security issues, which may be a big who > cares for them. > > Now we can sleep better knowing that the IPv4 address length has > effectively been doubled at least. As opposed to only increased in length > by 50%. So what? Increasing the prefix to 48 bits results in more than enough sites per person on the planet. > Bert > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jun 18 19:43:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B739126C83 for ; Sun, 18 Jun 2017 19:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9IBVPelupUX for ; Sun, 18 Jun 2017 19:43:34 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 2D103126B6D for ; Sun, 18 Jun 2017 19:43:34 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 68so51126491uas.0 for ; Sun, 18 Jun 2017 19:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WzdSH6Jvbq/OdJoPoTwdObPe6nUXOzT0GijghrKv9Ag=; b=R5cExRObxcyFZGEF8ik1y4Zz7QxilD7liVOcvoFJ5brNvhL4060fJ94kscWkjo5EHo d8iX/7RyG4lcj/i4EQAxwvMgURjl9nER0LlXhyOAbwhFS+s5hFpE0zfqOL3j9oTrc0u2 5IlQFdYcxz+rsN5guGixGAtR8kIboqWAqfla3+FehRTFHi13ttQOZPU1q6mU2evED6Uy 9XecytmK0EG0WkSbGvKYUinaLC6STVW+jOieshz1ZEm8ag1J0SL0puoSkTSBfigY7rJ7 Qxqo1sHdIEoUwpmaolTrg29O8kLVlwaVkxVL7Iy6IZKzccFbzta6e4CZLHbtpvj36l8e VBCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WzdSH6Jvbq/OdJoPoTwdObPe6nUXOzT0GijghrKv9Ag=; b=aIog+nxF0eT4Rd5StT7HykZw9qRCrtqjFdU/Ytl2sOemXsoLdbGTZbecIqSiowNUH0 HuWXe5Q/4SDukajXbbWwkbXXjWSMJL7ojTVZxqt5EFnncN1Iw1fcflpXBskV890t/ieU GMDiRbaDfC5KECtt5LYz7S/rxcaXR3VSagFWTZqBwyJLu/uFFEL7GHExB1h1ON6W5nMK s3MN6LEjU0ohQbGuggPqC7GrdJ/ANqfT84ZQ0zgiLcAEsbTJrk8Otcz4Duyr/0bKeqgO 6h1yKmaXv/oUL1HwWSxEA9NRyXu6JVIMxNNY+u289VUVaNONYYkHTukhorFsqciPoaS3 Cp6A== X-Gm-Message-State: AKS2vOyKxfYdaJUwweXRJ26JAhPeWeJBYP7/8YcZWprg1L0ZQ4+ZJHNr gDryYOn6nWbhNzNvd9NkN1I3S6vL+6C0 X-Received: by 10.176.83.16 with SMTP id x16mr14444352uax.11.1497840213026; Sun, 18 Jun 2017 19:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.12.139 with HTTP; Sun, 18 Jun 2017 19:43:11 -0700 (PDT) In-Reply-To: <20170619020717.A2D5D7BDFE5A@rock.dv.isc.org> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> <20170616225904.C51F97BD5040@rock.dv.isc.org> <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com> <20170619020717.A2D5D7BDFE5A@rock.dv.isc.org> From: Lorenzo Colitti Date: Mon, 19 Jun 2017 11:43:11 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Mark Andrews Cc: "Manfredi, Albert E" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c18f1acd4b0ac0552471979" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 02:43:36 -0000 --94eb2c18f1acd4b0ac0552471979 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 11:07 AM, Mark Andrews wrote: > > My answer is, /64 from the operator, which can locally be increased to > > /80, with no credible downside. I don't know how the IETF can force > > operators to do anything, but I have to believe it's more realistic to > > hope for /64s to every subscriber, given how prevalent that has become? > > And then the operator will just hand the consumer a /80 because they can > and someone like you will come along and argue "We can make it a /96 for > the user, thats more than enough address space". > Exactly. --94eb2c18f1acd4b0ac0552471979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 19, 2017 at 11:07 AM, Mark Andrews <marka@isc.org> wrote= :
> My answer is, /64= from the operator, which can locally be increased to
> /80, with no credible downside. I don't know how the IETF can forc= e
> operators to do anything, but I have to believe it's more realisti= c to
> hope for /64s to every subscriber, given how prevalent that has become= ?

And then the operator will just hand the consumer a /80 because they= can
and someone like you will come along and argue "We can make it a /96 f= or
the user, thats more than enough address space".
=
Exactly.
--94eb2c18f1acd4b0ac0552471979-- From nobody Sun Jun 18 21:50:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208A9126DC2 for ; Sun, 18 Jun 2017 21:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1CHvpm4wFuw for ; Sun, 18 Jun 2017 21:50:11 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 5FA73127599 for ; Sun, 18 Jun 2017 21:50:11 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g40so52068219uaa.3 for ; Sun, 18 Jun 2017 21:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UO+amAe7p97ZCI8wWivpH/fgzMNmaQSe+DCW48FMWBc=; b=UcBbnnhZrk28KXrsnTiClbTCLr7ZG7Rh7V1L48n1JnWlV3Ar03aNBEviGnNHKjh/rC QrcsKBY8E9haYO2aQGDjNNyOjBL1sQ+G4YQ4744mfPGKjiShrRnhoyjD9SzfOYsW12ZL LXhURcElkS6HN39MvM+HmtGzXSixymib4ZYpQYmuJ0rigQkXJnWjhkO8h7abSu8/DlLh v4neTwnU15NkL1rVsWVIn9P6TBM5qo3f/4nSLdq1fwUW7ni3grL/7sOowz83w0EY6Qxp iqIkGvTlluvqW94p6aivYrxkluVP8uF9XhOMr/Us1dVVG83+qGZW7PP0PoPGk7U/qxnf 4OpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UO+amAe7p97ZCI8wWivpH/fgzMNmaQSe+DCW48FMWBc=; b=gva4yBTrT3kqty9upU8eqD1gwlI50XF7GQ9l/VMLumV+PxY2jLu34VWwyWllH5uBQd YsFGE8jrQJAfWmx+3hJyMLr6sR3qTcBAae+wUWFN1/tNg0KZzDDFeKEYOy9PtdcnO5Dr yu31l8vrZMeYrmEhAP879/ux9D6s0RVsIcyVkpXRoVJKfiR87t/IuiZ61eQ1XQqRi2bK qK6dDG/vNUjWDWGBpQHrtvlAet6epumbFE0i/RUGKP9loduMoB2Sgisvncg/eJYWrhBh Q36mtejl4VFXgCKPy20fh2omtcgg7fOx6SIjqjhVeyARRA5c323pgI72pbE/qEOlPFkM CuYg== X-Gm-Message-State: AKS2vOxhWH6uckizMwl1QYYkem9sZpG8VnWPuxVuvTxSYyiaU5VoSLUx YbT10eSXeAwUOEduQrE958J+em9NxJEs X-Received: by 10.176.26.24 with SMTP id a24mr13815205uai.96.1497847810350; Sun, 18 Jun 2017 21:50:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.90.18 with HTTP; Sun, 18 Jun 2017 21:50:09 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:3909:6eca:225e:ae68] In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> <20170616225904.C51F97BD5040@rock.dv.isc.org> <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com> <20170619020717.A2D5D7BDFE5A@rock.dv.isc.org> From: George Michaelson Date: Mon, 19 Jun 2017 14:50:09 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Lorenzo Colitti Cc: Mark Andrews , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 04:50:16 -0000 I'm not a believer in the reification of the H/D ratio. I feel it was a pragmatic observance of practices which applied at the time it was defined, and doesn't represent a reality (to me at least) in how we structure address plans, or deploy networks at scale (I hasten to add, I do neither. I only believe this based on what little I understand of how other people describe what they do) I just wanted to come here and say that nothing, absolutely nothing we do in address policy, drives to /80 or /96. N O T H I N G. Its arguable in RIR policy world, the /56 thing was a mistake. If so, I apologize, although its a community consensus position, not my own. Its true that some aspects of RIR policy took TLA, tore it up, and replaced it with OTHER magic numbers (of course, this is a partisan and fragmented take on a conversation which involved many fine meetings and differences of opinion) like /48 and /56. But thats in a context where completely other people took 128 and turned it back into 8+8 for entirely fine, pragmatic reasons and many fine meetings and lunches lie in that decision too. Do we have an exhaustion problem in IPv6? No. We're in a tiny fragment of 512 goes inside the /3 we decided to play in. We have no lack of ability to give out /64s for everyone and /56s for everyone, and very probably /48s for everyone sensibly able to control their destiny, if thats what we want. Do we have a deployment problem on the edge with IPv6? Yes. We have people who seem to think we have to be super prudent and only give a single instance to a single device, and who don't chose to reflect on what a /56 or a /48 is capable of, because it doesn't suit their mental model. We have people who don't want to have to think about how to manage intermediary devices which have to do PD. We have people who want to operate choke points, or not allow things, Who want the IMEI and APN to imply a contract of limitations. Price and Cost disfunction is huge here. Why does one bit of silicon and plastic magically allow an iPad to do wondrous things, and prevents a MiFi from doing these wondrous things? Because money. But nothing, N O T H I N G in address policy globally drives them there. We don't say "give each customer a /128" and we don't want to be taken to saying it, the 3GPP and other bodies not withstanding. The decision about "how much" is a pretty odd question really. Why are we having this conversation? I totally don't get it. -G On Mon, Jun 19, 2017 at 12:43 PM, Lorenzo Colitti wrote: > On Mon, Jun 19, 2017 at 11:07 AM, Mark Andrews wrote: >> >> > My answer is, /64 from the operator, which can locally be increased to >> > /80, with no credible downside. I don't know how the IETF can force >> > operators to do anything, but I have to believe it's more realistic to >> > hope for /64s to every subscriber, given how prevalent that has become? >> >> And then the operator will just hand the consumer a /80 because they can >> and someone like you will come along and argue "We can make it a /96 for >> the user, thats more than enough address space". > > > Exactly. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jun 19 03:48:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81C9129AB2; Mon, 19 Jun 2017 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccVQR-gzHBJE; Mon, 19 Jun 2017 03:48:34 -0700 (PDT) Received: from accordion.employees.org (cowbell.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60703129AAD; Mon, 19 Jun 2017 03:48:34 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id ABC772D4F93; Mon, 19 Jun 2017 10:48:32 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 088C3D5CA8FC; Mon, 19 Jun 2017 12:48:29 +0200 (CEST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_AFBC9CE8-A82B-464B-918C-D0DCAB9207B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: [2nd] 6MAN IETF99 Call for agenda items Date: Mon, 19 Jun 2017 12:48:28 +0200 References: <62638EF2-B3A3-4DBC-A9E4-D65C80C1EBB0@employees.org> Cc: 6man-chairs@ietf.org To: 6man WG Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 10:48:36 -0000 --Apple-Mail=_AFBC9CE8-A82B-464B-918C-D0DCAB9207B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The 6MAN chairs are planning the meeting in Prague at IETF99. If you have a draft you would like to discuss, please send your request = for agenda time to the 6man chairs. Please include in the request, the = title of the presentation, file name of the draft, the speaker's name = (and email), and how much time you would like. We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. We expect at least half of each talk=E2=80=99s presentation time to be = used for open discussion, please plan your presentation accordingly. New drafts not discussed on the mailing list prior to the meeting, or drafts that do not appear to have support from the working group are = unlikely to get time at the meeting. Please have agenda items to us by 2017-07-05. Remember the draft cut-off date 2017-07-03 (2 weeks before the meeting). Regards, Bob & Ole --Apple-Mail=_AFBC9CE8-A82B-464B-918C-D0DCAB9207B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZR6v8AAoJEL7aWKiYQt92f/gQAJJstTxDO4NCsrde92OERgBz DujZ+ThaA50dik8v+x3yYCsQ98sCaKYoJlOyWC9rZ+RfuqVmKnWw4qNDAtjjqroJ deePbtPD0rScD0lqjNMmsLfd0YTSX/M/tRcQJOGsI6T7TOV+PT5PfjRDxzogli4d oGF4ddzUvFtznxkq4r4oJRwv5XLWetbc+c/MsfmeOjUZhvuv7DkWg8+7YY4hvKOT ahzHmAovT4/djkFIdU9PcAcqwaGbWgiAsPpWuvavxVIqdFnVR0jFTpc6v6I9cp+r Kp22jDg7evDYrEJCHDJarwI1IIvhd66HruXg1ppOiEEX4v7egSLtYBMb/CXZnYnh MVIX6JhoKpngmlNT7QT3omvF5XM7QiSmsrgljIZx0O2SzBjCGTUwqHjYVqisYoRd VfuAhnIy4PAKd1xd6DuRlwWWRxkhtRYSXL9zMG3/WwmwK6B4QI9kB7JdkI82FCBG NqU/nW50BXvtAaAnFyk+UOr375bDfwR245FTLk7CcU1HyWTywRFl6hV4DhfgZC6E jQWwsoV1MN7hZqjSQV2nSGLKG4lkGNZXcZAFlMw7w4Oaj4nLaQMocDSE1gBQ5uc1 DJBLmyyIDb6kU0njpaVp3dOY320zhLVcVwa2587db5pOuC2PQPhQURL88N4eXdbW spMBYXCI3Y2X2Ib94hbn =RMr9 -----END PGP SIGNATURE----- --Apple-Mail=_AFBC9CE8-A82B-464B-918C-D0DCAB9207B3-- From nobody Mon Jun 19 05:04:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D013512EB86 for ; Mon, 19 Jun 2017 05:04:45 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akgu7h1zga3l for ; Mon, 19 Jun 2017 05:04:44 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 B729912EB87 for ; Mon, 19 Jun 2017 05:04:42 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id u19so108566565qta.3 for ; Mon, 19 Jun 2017 05:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uPmB2Udp+NqrVouU50W0gyfhlXvpbkztg0cdlFflCzI=; b=JvE/lev+/COrFLFgXYGLgkjUs3GdiLMzwXKuYCUcbQvwm9HOox271d025tIgLStBh5 JtmKm45ywO699b/VtJSHi8zb1NreZOEY/hlOFSppagovyxKoiRJBHN+84JYEDbYW8Mvc PnLiLZMSRNNlWqgvkVtwhfKsG5Ww96432EEyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uPmB2Udp+NqrVouU50W0gyfhlXvpbkztg0cdlFflCzI=; b=dj8Q5pAufoHspv/oN5zdF/IJv3KPt83Izm23slrT711Qk3riiD5Uqzlz+6CeXpPt6m MkIf59LulG19nxW19C+x6GgvVe4lKqDBpJ+ZQFMGRYk7SGDV6v7B19P2Pj7QyMkZMZz8 e1njPAAmm1GH8atmgqY5zPpjxo8y1WiJhivg3dEyr4KHfdzetT4IZkkMIQhpPcPH+Lep g4rjidXKWVtXHDT3g8L3jlJz2zFfvkN5ACRu1GP46QPw3ERkW0CcplNqX57JN0aBv9wZ 0USl34DrPNDWXhAliuYuyNQPdXuQcj8WOkD15vFJkAD51mU7jqQtXlvoxeaGe0TKgCGr ibMw== X-Gm-Message-State: AKS2vOyX0U55WxoGgpA6/u7UC4E8qVidNtDDAWAsrAMtMg6WlsUdkQf1 FY8Q2ZU4k78WnaldPHPq8rO3Yh3Pvhuj X-Received: by 10.200.49.81 with SMTP id h17mr26069980qtb.13.1497873881764; Mon, 19 Jun 2017 05:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.38.228 with HTTP; Mon, 19 Jun 2017 05:04:20 -0700 (PDT) In-Reply-To: References: <62638EF2-B3A3-4DBC-A9E4-D65C80C1EBB0@employees.org> From: Timothy Winters Date: Mon, 19 Jun 2017 08:04:20 -0400 Message-ID: Subject: Re: [2nd] 6MAN IETF99 Call for agenda items To: Ole Troan Cc: 6man WG , 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113a7cd6a42f0c05524ef012" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 12:04:46 -0000 --001a113a7cd6a42f0c05524ef012 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ole, Thanks for the reminder, we'll make sure to have at least one new version before the deadline. ~Tim On Mon, Jun 19, 2017 at 6:48 AM, Ole Troan wrote: > The 6MAN chairs are planning the meeting in Prague at IETF99. > > If you have a draft you would like to discuss, please send your request > for agenda time to the 6man chairs. Please include in the request, the > title of the presentation, file name of the draft, the speaker's name (an= d > email), and how much time you would like. > > We will prioritise drafts that are working group items and drafts that > have been actively discussed on the list. > > We expect at least half of each talk=E2=80=99s presentation time to be us= ed for > open discussion, > please plan your presentation accordingly. > > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group are > unlikely to get time at the meeting. > > Please have agenda items to us by 2017-07-05. > Remember the draft cut-off date 2017-07-03 (2 weeks before the meeting). > > Regards, > > Bob & Ole > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a113a7cd6a42f0c05524ef012 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ole,

Thanks for the reminder, we'= ;ll make sure to have at least one new version before the deadline.

~Tim

On Mon, Jun 19, 2017 at 6:48 AM, Ole Troan <otroan@emp= loyees.org> wrote:
The 6MAN chairs are planning the meeting in Prague at IETF99.

If you have a draft you would like to discuss, please send your request for= agenda time to the 6man chairs.=C2=A0 =C2=A0Please include in the request,= the title of the presentation, file name of the draft, the speaker's n= ame (and email), and how much time you would like.

We will prioritise drafts that are working group items and drafts that have= been actively discussed on the list.

We expect at least half of each talk=E2=80=99s presentation time to be used= for open discussion,
please plan your presentation accordingly.

New drafts not discussed on the mailing list prior to the meeting,
or drafts that do not appear to have support from the working group are unl= ikely to get time at the meeting.

Please have agenda items to us by 2017-07-05.
Remember the draft cut-off date 2017-07-03 (2 weeks before the meeti= ng).

Regards,

Bob & Ole


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




--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a113a7cd6a42f0c05524ef012-- From nobody Mon Jun 19 06:01:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2712EE44 for ; Mon, 19 Jun 2017 06:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvKYlwZRLr66 for ; Mon, 19 Jun 2017 06:01:29 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 D2977129BDD for ; Mon, 19 Jun 2017 06:01:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 10AB84A; Mon, 19 Jun 2017 15:01:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1497877272; bh=A8fi/HUkdTM2Qu9xdXz qryatebhnzcFdcnyCX1slKeI=; b=sd6nplRpQZRCmtuvJdtrOs5UQNKNvGpfvyK 1WHYv+NpX5rCL+EqcmW9cbTbFD6lHwaylpmnayehQxqLrJCHHag3dKxRm41MyYot DsQjbw4d/NW7dbdHcZmVDAi5HCscwD8mYVzRrndN9dNcs3XEu9RNgzCEEkgaJ2xf g3i4vGe8= 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 qVfQCEL3WGdm; Mon, 19 Jun 2017 15:01:12 +0200 (CEST) Received: from [192.168.0.149] (unknown [46.44.175.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 2FE8849; Mon, 19 Jun 2017 15:01:11 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F0F5169C-713D-4EFA-875B-91002024567D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land Date: Mon, 19 Jun 2017 15:01:11 +0200 In-Reply-To: Cc: "ipv6@ietf.org" To: George Michaelson References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <20170616035128.7F0FE7BCB631@rock.dv.isc.org> <20170616225904.C51F97BD5040@rock.dv.isc.org> <7e6738fbf88949218b7beae12ba959b6@XCH15-06-11.nw.nos.boeing.com> <20170619020717.A2D5D7BDFE5A@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 13:01:31 -0000 --Apple-Mail=_F0F5169C-713D-4EFA-875B-91002024567D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi George, > But nothing, N O T H I N G in address policy globally drives them > there. We don't say "give each customer a /128" and we don't want to > be taken to saying it, the 3GPP and other bodies not withstanding. > > The decision about "how much" is a pretty odd question really. Thank you for stating this, I concur. Sander Steffann RIPE Address Policy Working Group co-chair --Apple-Mail=_F0F5169C-713D-4EFA-875B-91002024567D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZR8sXAAoJEB7hi8LTyHy2SNMH/1LD325JJrsDwde+oqFx/VZa CoEwE4M7Oqbnd75+35M64DIABjGTw8q39uTL/f4U3+KUdTJCtH+gGiU1Vqv3dsB2 BEsbhkqInDd5mOPTuPnmySSNXy6GgRE605fMDSot/gHJ+P83f5qWaBqVdMxqlsjl IE6rT7grhYZNSG2zqUiURdbNIduVDqJG2z7HgpAeyayw2+RwEpcYkE2p3zrhV8Or oQu5KSGeGUNNIKL1U4fLLow6HcjgnoRGB0zMBs3TXZMgPlDqeFsYF2yLJYrggIQA XlGqHalG403SQNCAr2EVn+jKGkd6hFX4t6o7S6F/XvMjkbcpFycBJaVixbLGo90= =wut4 -----END PGP SIGNATURE----- --Apple-Mail=_F0F5169C-713D-4EFA-875B-91002024567D-- From nobody Mon Jun 19 09:26:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E473C13156D for ; Mon, 19 Jun 2017 09:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODazmHHPZmQX for ; Mon, 19 Jun 2017 09:26:47 -0700 (PDT) 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 B358D13155A for ; Mon, 19 Jun 2017 09:26:46 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id g66so54989963vki.1 for ; Mon, 19 Jun 2017 09:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JV2pZVfCms6UBlxtWQ3OVC0mhiR0Ht3PSYVzBWOoFOg=; b=LZ6jw5cmUYMhq3Z/zJS/cfdH14EYo1ZIzE9jQZSL+0Z4qZZvrSaomiJZDudgRDClxa sE1ABYzVRg5gO982yxflOeoG/EclEdPjlPAbB/C9/tmU1Jf45erH5MGYrWZ10Q0bDiRU D2gRhPPXjzN9LoIJ39XlK7Aw1mwSOWq+RWi052S/Qul6havpBw5sbKH5kiy+P4Xf6KBS P0cIgeTopWTntnGojemWhtDxFC1ZyS1IYIcURU0d2HTtzqfUDLuYYOWs4x5ie8Qg8FqK cMbto/WNiCyBdzvzODqGYJsOfdpAIGSktq/hYV95RVeQhxGKd/CpcE7lI9GyYtaK+lgA 3U+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JV2pZVfCms6UBlxtWQ3OVC0mhiR0Ht3PSYVzBWOoFOg=; b=s4eSVWt+xIOpx+QMTKqNDVy4nMYL0c0rE7JbajhN57lS6LHpA2RdyJDgUWJS5xe7sl fnR5NDGQIkI1jXvbnKlHdl+1xYWdwGjLDU0HcKxu0qL6n16rrVQ/hdI84HNh1oo4XN9q tL1GXnOUyfqwZhrj6kQ+9DH4eXXQIiqaT5SmHRpraOBthqCzvAoU3KqlG8DGikXdTRdx WSNQ0YP2B8C4TvP15686+gEuGkSsfLjwEoNR5hoL2w0CxEdbHmtAXdkIZr0yvVA0GkvB HeN6vqU8zXT8qBG9nCcjMzkiM96p9d8VnRY+tg0Icd8GJ6J22lGFXyzP2AMFaJN7i4TO SCIw== X-Gm-Message-State: AKS2vOypRFxejmsLi1wEoIHQwuLSafnNYo1jIdPgzIHWmU3jfHUbCc73 yz9gIdTl189QaW2y4VYKsm3McOCphNoA X-Received: by 10.31.137.207 with SMTP id l198mr1517947vkd.32.1497889605485; Mon, 19 Jun 2017 09:26:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.12 with HTTP; Mon, 19 Jun 2017 09:26:24 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> From: Erik Kline Date: Tue, 20 Jun 2017 01:26:24 +0900 Message-ID: Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Cc: Ole Troan , 6man WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144e6e8e07dad05525299a8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:26:49 -0000 --001a1144e6e8e07dad05525299a8 Content-Type: multipart/alternative; boundary="001a1144e6e8d97ad10552529974" --001a1144e6e8d97ad10552529974 Content-Type: text/plain; charset="UTF-8" > > I'd also note once again that this discussion has nothing to do with > the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This > operation configures a 128-bit IPv6 address with 120-bit on-link > prefix. On-link prefixes have always been variable, and they have > nothing to do with IID length or SLAAC. We don't have to update > addr-arch or RFC4862 because of this. (draft-bourbaki-6man- > classless-ipv6-00 > seems to be confused on this point, and I suspect it increases the > confusion and controversy in this whole thread). > Agreed. --001a1144e6e8d97ad10552529974 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd also note once again that this discussio= n has nothing to do with
the fact that we can perform 'ifconfig en0 2001:db8::1/120'.=C2=A0 = This
operation configures a 128-bit IPv6 address with 120-bit on-link
prefix.=C2=A0 On-link prefixes have always been variable, and they have
nothing to do with IID length or SLAAC.=C2=A0 We don't have to update addr-arch or RFC4862 because of this.=C2=A0 (draft-bourbaki-6man-class= less-ipv6-00
seems to be confused on this point, and I suspect it increases the
confusion and controversy in this whole thread).

<= /div>
Agreed.
--001a1144e6e8d97ad10552529974-- --001a1144e6e8e07dad05525299a8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg7dYHSS8tLaPfZrnY9hsH3jz+wM1Zdvhl F+Fg9jGS0ocwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjE5 MTYyNjQ1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBANBKauSdZI2BBWAbDQSZDmJgu4NIM7Ugezll3fnscsOo6nDN6rKh H1EzEQuK4o0o2+Eznuih90WQWyHFxj4WeKB/0nMhQJrz7SsXowP/ZV2TqvBEHKxJvrt/0fqMqdsp /0jTigXzetqm9MeL4EnjBTRbO+cf5aXDXGGlB+m3nOPBOZYQImgdXQVjlFW6x0gLXNKEeQCeXrbY D2P8aw1dPslNik+b4NoonNKQnYicfcvz/SUgQTcqemlQBDLH01yxSOoQ4hE7S3WOC3ZEoL0EWz1A Qx3WuKzPDYvTn3zZFIsYTjyQK7ZI2SIrwoKghfhW5e7lNKewik77K6ks9sMnBKo= --001a1144e6e8e07dad05525299a8-- From nobody Mon Jun 19 09:49:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DF01315F4 for ; Mon, 19 Jun 2017 09:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgqFg0H20q3I for ; Mon, 19 Jun 2017 09:49:11 -0700 (PDT) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 9E0921316A8 for ; Mon, 19 Jun 2017 09:45:18 -0700 (PDT) Received: by mail-wm0-f46.google.com with SMTP id m125so82122117wmm.1 for ; Mon, 19 Jun 2017 09:45:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nhQtZsFvwg+sW1u62D8Ie9Waaw7KV42KNiDVvsxXIX8=; b=tcOn+hCWdEh5sjcPcwZBmm89gWFtTE5JPsQ+R550aBT4A6PBCqPg5NWfCVHaXiLlMG sktphKihXqetzMAMoM0WsmFApkxtR2ZgTcx64aGRXs1Cug8K6uxEjDvV/YeJBi7vEMRU uai3MwKr3m3o/jlFS5llWueBnAuRoAAmQ4MaOqKM50hJsdSVpkXlZXmZkaRmJYeHGHRu HE1b/V1F6XsFXKfU/B4Zvdow22wvK3Sipv3d14rOTF15+G9Yhti4pg1a4+5ZKaLD/I74 HSo6r3XF7jKnk+ibtc0o8X/6WXhGOc1fPA5dEN1D51Plox40b7p0EmPNrt+ICd3Wm5RL iCBg== X-Gm-Message-State: AKS2vOzlEc1JEaarc5o78zwdwsaaL1TY9zSUqiEUkpkELz6uJKGba8RI 9EJykdW+/1XJYKzfACQMyg== X-Received: by 10.80.135.183 with SMTP id a52mr18101373eda.90.1497890716958; Mon, 19 Jun 2017 09:45:16 -0700 (PDT) Received: from localhost ([89.200.40.6]) by smtp.gmail.com with ESMTPSA id l4sm5957311edb.35.2017.06.19.09.45.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 09:45:15 -0700 (PDT) Date: Mon, 19 Jun 2017 18:45:12 +0200 From: Job Snijders To: Erik Kline Cc: JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= , 6man WG Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) Message-ID: <20170619164512.hbysyxqfps7jh7rc@Vurt.local> References: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:49:14 -0000 On Tue, Jun 20, 2017 at 01:26:24AM +0900, Erik Kline wrote: > > I'd also note once again that this discussion has nothing to do with > > the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This > > operation configures a 128-bit IPv6 address with 120-bit on-link > > prefix. On-link prefixes have always been variable, and they have > > nothing to do with IID length or SLAAC. We don't have to update > > addr-arch or RFC4862 because of this. (draft-bourbaki-6man- > > classless-ipv6-00 seems to be confused on this point, and I suspect > > it increases the confusion and controversy in this whole thread). > > Agreed. Is there a document that states that IPv6 routers and hosts must support on-link prefixes of all sizes? Kind regards, Job From nobody Mon Jun 19 10:14:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C811316A9 for ; Mon, 19 Jun 2017 10:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apTcFW_A8qK9 for ; Mon, 19 Jun 2017 10:14:50 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68FF131646 for ; Mon, 19 Jun 2017 10:14:16 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 0133466F for ; Mon, 19 Jun 2017 17:14:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU1_Ywfue9Pb for ; Mon, 19 Jun 2017 12:14:15 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id C51CC7CA for ; Mon, 19 Jun 2017 12:14:15 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id o68so37814154vkc.8 for ; Mon, 19 Jun 2017 10:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x1xX2bzDbRWNVQ1r7epTb8EzuaSJSQf79s28Yeps9rw=; b=JlOtBzAkvjg56qWCYng5ixYh5Iik/zTJYHDRjbEkKi3M/Hoc1gSe3qz6M9w00nNqBh 403F/8mTGrRrrFlP7hGm6/9U6uN5qlttQUzq6J9xfgkTNglOJB6VQvaYQ2yt1+6lAACa r1zPd38mqTmchz5YbpNdtY9jiYE4K1e5w5/yu8/LoyJSXgF9S7uAWi/4oqAi22yGYeqO rQukc0cUhVL26ShSb4f7X+gIYkdatPwoF7uVK6QIx3KBZ2fjAu3V0z5LHKdqlJyS/2WN J8CUaKKe8IiWqWsZeRYWEXxSBhA4tCrXGSOcI/lfIz4fh0AXZiyeWsvDpg0sjE6QwyiQ fULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x1xX2bzDbRWNVQ1r7epTb8EzuaSJSQf79s28Yeps9rw=; b=MRvJZQ9noywGyU3Xg6J3P7121L+8YxodVawXTWJnljyWLQkSs4iyV8QkETsBJ3AFMB TiISvOko8Y9DLL2dx2jkJo9JsxjpecLTAp4+XljfsvhfCIUdOvvryuV5WB3Bz4DCxWHO c1kHUuRNVxX8JpVt2hjbKvXPt96YqeoqgTE886RVUMmsn+TRCFw9syPVlvxXXoIXmurZ JvEnHUX46NE8rIjFS+BZsZbdarxcrJNQ+AZAdZH9izwxTfwMsQVPoFIvD7wDHgNaVRz5 2A7KESaAleeDuAsM82oEVRhv2jZYGG7Epl8M/juv0EUsbFq/jfYWummZrAUnSTJ1ApbG n4Og== X-Gm-Message-State: AKS2vOx9n23255stO3CgE1ZI2XKx1o9F+Z7w0WXk+4/IHQSrn5+jIXTt qDUj0D/LpyfmzyVDoJVomrBpw1qLVcZ33Db6oXd+nJ2jaZJIjFfQI67n/zTjlD4riSNph6+SwHJ ZLEzCi8I3cI3mwU0= X-Received: by 10.31.98.2 with SMTP id w2mr13921776vkb.24.1497892454886; Mon, 19 Jun 2017 10:14:14 -0700 (PDT) X-Received: by 10.31.98.2 with SMTP id w2mr13921762vkb.24.1497892454690; Mon, 19 Jun 2017 10:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Mon, 19 Jun 2017 10:14:14 -0700 (PDT) In-Reply-To: References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <20170604093119.nt733rb3ymmjssww@Vurt.local> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> From: David Farmer Date: Mon, 19 Jun 2017 12:14:14 -0500 Message-ID: Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) To: Erik Kline Cc: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , 6man WG Content-Type: multipart/alternative; boundary="94eb2c096f40ac859305525343ce" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:14:52 -0000 --94eb2c096f40ac859305525343ce Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 11:26 AM, Erik Kline wrote: > I'd also note once again that this discussion has nothing to do with >> the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This >> operation configures a 128-bit IPv6 address with 120-bit on-link >> prefix. On-link prefixes have always been variable, and they have >> nothing to do with IID length or SLAAC. We don't have to update >> addr-arch or RFC4862 because of this. (draft-bourbaki-6man-classless >> -ipv6-00 >> seems to be confused on this point, and I suspect it increases the >> confusion and controversy in this whole thread). >> > > Agreed. > While I agree this is confused in draft-bourbaki-6man-classless-ipv6-00, I believe the root of the confusion is the use of the term Subnet Prefix in RFC4291 and it's predecessors. Therefore, I can not agree that addr-arch (RFC4291bis) doesn't need to be updated, the updated doesn't need to fundamentally change anything, but it very much has to clarify this issue. I think they way to do this is to remove the term subnet prefix when related to IPv6 and only use it related to IPv4. Also add a discussion of on-link prefixes. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c096f40ac859305525343ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 19, 2017 at 11:26 AM, Erik Kline <ek@google.com>= wrote:
I'd also note once again that this dis= cussion has nothing to do with
the fact that we can perform 'ifconfig en0 2001:db8::1/120'.=C2=A0 = This
operation configures a 128-bit IPv6 address with 120-bit on-link
prefix.=C2=A0 On-link prefixes have always been variable, and they have
nothing to do with IID length or SLAAC.=C2=A0 We don't have to update addr-arch or RFC4862 because of this.=C2=A0 (draft-bourbaki-6man-classless<= wbr>-ipv6-00
seems to be confused on this point, and I suspect it increases the
confusion and controversy in this whole thread).

<= /div>
Agreed.

While I agree this = is confused in draft-bourbaki-6man-classless-ipv6-00, I believe the ro= ot of the confusion is the use of the term Subnet Prefix in RFC4291 and it&= #39;s predecessors.=C2=A0 Therefore, I can not agree that addr-arch (RFC429= 1bis) doesn't need to be updated, the updated doesn't need to funda= mentally change anything, but it very much has to clarify this issue.=C2=A0= I think they way to do this is to remove the term subnet prefix when relat= ed=C2=A0to IPv6 and only use it related to IPv4. Also add a discussion of o= n-link prefixes.

Thanks

--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecom= munication Services
Office of Information Technology
University of Mi= nnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 P= hone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-= 9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--94eb2c096f40ac859305525343ce-- From nobody Mon Jun 19 10:18:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39E4131709 for ; Mon, 19 Jun 2017 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-nMNvojz2vc for ; Mon, 19 Jun 2017 10:18:06 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 2621C131713 for ; Mon, 19 Jun 2017 10:16:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 9875AB48 for ; Mon, 19 Jun 2017 17:16:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg1s00zQcMC3 for ; Mon, 19 Jun 2017 12:16:22 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 6A6B5B2D for ; Mon, 19 Jun 2017 12:16:22 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id y14so7378802uag.3 for ; Mon, 19 Jun 2017 10:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=35qO/l33zHAj80OzNb67DtRHECPdTwsfAQxFA5G1dwg=; b=p47brGG1JEa3ZLou7QAwgP6tFHP9NDGTB2ccsWLHfQU8E4pGuJeHXNuGR5+s5DoHSq hbgk5xHZ/54Ad6kMD7mOFUIECguonX2cXR+5zpqIcCaOVd0QCyJiwxCe5tQObZ/K3Yqr pPKsox8zqm/GZef6uBPDR04Pv58K3rIVD9f2T3gZI5DawpXAjEyRLWY9oAb0CyUVhAiV a4/lTXm5InNgFu8hybjegMviU1PqbJxtgeIXXSA8jMjbblCYW/l4EfppTHoYJG4+GqXB fIVzJC+pH9urKC+bKMZnixYYfKYOOo8nkbEhaNYmH9PICyO2GHQRXDdrerWXzl9lLePx 20Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=35qO/l33zHAj80OzNb67DtRHECPdTwsfAQxFA5G1dwg=; b=miJYqIN7/qQ5i5+e4VUeEiQLHlIudt56mLEDu+hVLM0ntN7BI1wm81TYCZKEHu6P+n CJ0MtcOyFNP2nw4Vk7zap9vpYMpCJ0yxYkwCea7q8KnlIvWaycD9FT9o+xs3Ukijs9UO OxR4tdfiwN5WRDiif7OzhSn5vyooWSzMBxfLQ0Vgo8GKbKhe0XV7et8UBmPygmDM2uEh iDsjGezD4cNSVcCDsV/JKoq5Kd/b8xvbfZki78pX1cPCTuE/HMWtgn5O4S2Nc6fgTbBQ mBl+KrWf0Neyn3f7tFBD68N+1uwpddfqjG46Nwu28xe0FMe8E1sIoO+NK94xmm10nB/q LedQ== X-Gm-Message-State: AKS2vOwDX+V6fIu977wX2YOdttH6nZqAbEc0C6MFh9VipAvj7Da613r8 3pOVUvC0AVDCPk/DuXXHFoAkFXM1VuMaHb2v91F64FfzHl3q6xr//Qc1jtnK6STOGj+6GFrF5pV Nef9408B1ulQ4kNU= X-Received: by 10.31.54.140 with SMTP id d134mr11813065vka.15.1497892581572; Mon, 19 Jun 2017 10:16:21 -0700 (PDT) X-Received: by 10.31.54.140 with SMTP id d134mr11813057vka.15.1497892581430; Mon, 19 Jun 2017 10:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.183.11 with HTTP; Mon, 19 Jun 2017 10:16:20 -0700 (PDT) In-Reply-To: <20170619164512.hbysyxqfps7jh7rc@Vurt.local> References: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <20170619164512.hbysyxqfps7jh7rc@Vurt.local> From: David Farmer Date: Mon, 19 Jun 2017 12:16:21 -0500 Message-ID: Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) To: Job Snijders Cc: Erik Kline , 6man WG , =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Content-Type: multipart/alternative; boundary="001a1143b5223a721b0552534bab" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:18:10 -0000 --001a1143b5223a721b0552534bab Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 11:45 AM, Job Snijders wrote: > On Tue, Jun 20, 2017 at 01:26:24AM +0900, Erik Kline wrote: > > > I'd also note once again that this discussion has nothing to do with > > > the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This > > > operation configures a 128-bit IPv6 address with 120-bit on-link > > > prefix. On-link prefixes have always been variable, and they have > > > nothing to do with IID length or SLAAC. We don't have to update > > > addr-arch or RFC4862 because of this. (draft-bourbaki-6man- > > > classless-ipv6-00 seems to be confused on this point, and I suspect > > > it increases the confusion and controversy in this whole thread). > > > > Agreed. > > Is there a document that states that IPv6 routers and hosts must support > on-link prefixes of all sizes? > > Kind regards, > > Job > I believe this is what RFC7608 says, except I don't think it uses the term on-link, which it probably should. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1143b5223a721b0552534bab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 19, 2017 at 11:45 AM, Job Snijders <job@ntt.net> w= rote:
On Tue, Jun 20, 2017 at 01:26:24AM = +0900, Erik Kline wrote:
> > I'd also note once again that this discussion has nothing to = do with
> > the fact that we can perform 'ifconfig en0 2001:db8::1/120= 9;.=C2=A0 This
> > operation configures a 128-bit IPv6 address with 120-bit on-link<= br> > > prefix.=C2=A0 On-link prefixes have always been variable, and the= y have
> > nothing to do with IID length or SLAAC.=C2=A0 We don't have t= o update
> > addr-arch or RFC4862 because of this.=C2=A0 (draft-bourbaki-6man-=
> > classless-ipv6-00 seems to be confused on this point, and I suspe= ct
> > it increases the confusion and controversy in this whole thread).=
>
> Agreed.

Is there a document that states that IPv6 routers and hosts must support on-link prefixes of all sizes?

Kind regards,

Job

I believe this is what RFC7608 says= , except I don't think it uses the term on-link, which it probably shou= ld.

Thanks. =C2=A0

--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farme= r=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networ= king & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--001a1143b5223a721b0552534bab-- From nobody Mon Jun 19 10:27:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B364D131604 for ; Mon, 19 Jun 2017 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08fewCwBHaDp for ; Mon, 19 Jun 2017 10:27:12 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 C9F471316DF for ; Mon, 19 Jun 2017 10:25:39 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CD9C13493A2; Mon, 19 Jun 2017 17:25:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BABFE160048; Mon, 19 Jun 2017 17:25:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A2C4116006D; Mon, 19 Jun 2017 17:25:36 +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 SyhYkaSBN2_l; Mon, 19 Jun 2017 17:25:36 +0000 (UTC) Received: from jmb.localhost (unknown [104.129.198.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 3BC57160048; Mon, 19 Jun 2017 17:25:36 +0000 (UTC) Date: Mon, 19 Jun 2017 10:25:36 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Job Snijders Cc: Erik Kline , 6man WG Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) In-Reply-To: <20170619164512.hbysyxqfps7jh7rc@Vurt.local> References: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <20170619164512.hbysyxqfps7jh7rc@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:27:15 -0000 At Mon, 19 Jun 2017 18:45:12 +0200, Job Snijders wrote: > > > I'd also note once again that this discussion has nothing to do with > > > the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This > > > operation configures a 128-bit IPv6 address with 120-bit on-link > > > prefix. On-link prefixes have always been variable, and they have > > > nothing to do with IID length or SLAAC. We don't have to update > > > addr-arch or RFC4862 because of this. (draft-bourbaki-6man- > > > classless-ipv6-00 seems to be confused on this point, and I suspect > > > it increases the confusion and controversy in this whole thread). > > > > Agreed. > > Is there a document that states that IPv6 routers and hosts must support > on-link prefixes of all sizes? In my own draft draft-jinmei-6man-prefix-clarify-00 I tried to explain that's at least the case for configuring on-link prefixes on a host advertised via Router Advertisements. RFC4861, or any other RFCs that I know of, doesn't have an exact phrase like "a host MUST support on-link prefixes of all lengths", but I believe I provided sufficient evidences that that's the reasonable interpretation of the current specification and it matches what's currently implemented. For manual configuration on hosts and routers, I don't think there is an RFC that has this exact phrase or equally strong evidence as the host autoconfiguration case. But at least for host implementations I believe it's quite natural to extend that interpretation to manual configuration. And same for routers - after all, it's a router to advertise an on-link prefix of arbitrary lengths via RA PIO. So, it shouldn't be unreasonable to assume it should be able to use that prefix for its own on-link determination. And, perhaps more important in the context of draft-bourbaki-6man-classless-ipv6-00, (as far as I know) no one, even strong 64bit-IID advocates, disagrees on this interpretation. -- JINMEI, Tatuya From nobody Mon Jun 19 12:53:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D6127868 for ; Mon, 19 Jun 2017 12:53:12 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcf7oBaHDCoV for ; Mon, 19 Jun 2017 12:53:10 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 99C8B124217 for ; Mon, 19 Jun 2017 12:53:10 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 132so18979772pgb.2 for ; Mon, 19 Jun 2017 12:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/XnlpUEXU+1XVA6IRBxzQx3lYghedtW/fFxdJYRSKXM=; b=YhEcl1Kw9gONvQbyVA7eOCERSckj12FW46eQUNawpjIlEa77725VAGcQMsqrgJioHd pJqFFyvLQ8cMmt6gRrpT8+nu+SpskmdM+vkwTv7do7AKKT9FyNI5u/YxgLGqjYu6po1E tDhG/Fi/zRDnKT5t3BU+CfULmDJq0AgdBngOzFdwGO2PyUSASMm+HsO/xpudt6GGVk7p YJEoeYkmaxb0jilYj8ErlzNHAV3MnkU6zCSPFrdbzuCmi3ImQ/M3wnD0tpolXEQxRgm7 nlXcjDo165V09piK4YPxPX3yoBP6RlZjAr/L0d4XnwnRiByjQqoSDl6u+Ag9D12NLXfr bDsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/XnlpUEXU+1XVA6IRBxzQx3lYghedtW/fFxdJYRSKXM=; b=Dgc2+KiK2KcYP3C8q6vccGP38o7vN0g7UT88vIoGFRILROyJIHZbXfQ96yVYE55cmd XaGMosLiYfeiNHU+nwv1ISXiYBWCGJSvFcfj6j6itYZORfey9oGaG918Rr7DK+EedZqf FDeCcpe6yu2YkyPyApqQ8AgI7IZ0+z5hsuSzTa6VMWO0FwhIxFYKIoKN9F/DqyZXu5zl XJlu2Ra6SewygGKRrCpPlHgBacrt+wiRFc+16HWG5Ezc2VOa0kUCvSceYPvSc3dVM2SR XYdSbCDyst+emZuoJHaPmKoFSyI3HSaS+vXeVIVWCkGaA+NkblfxiEN1qlbQQrfb1KV0 rvxQ== X-Gm-Message-State: AKS2vOz/2anR4OCyWrH72s6GVQoH/56bKw968M6ha/D1kucseJyuVpHg T0Rocc8ktJ20Pr7f X-Received: by 10.84.135.129 with SMTP id 1mr31297267plj.12.1497901989963; Mon, 19 Jun 2017 12:53:09 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id l85sm23149364pfi.134.2017.06.19.12.53.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 12:53:09 -0700 (PDT) Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <20170619164512.hbysyxqfps7jh7rc@Vurt.local> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4b6c64fa-98ee-1b25-6c3c-97eacf7774b5@gmail.com> Date: Tue, 20 Jun 2017 07:53:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 19:53:12 -0000 On 20/06/2017 05:25, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= wrote: > At Mon, 19 Jun 2017 18:45:12 +0200, > Job Snijders wrote: >=20 >>>> I'd also note once again that this discussion has nothing to do with= >>>> the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This >>>> operation configures a 128-bit IPv6 address with 120-bit on-link >>>> prefix. On-link prefixes have always been variable, and they have >>>> nothing to do with IID length or SLAAC. We don't have to update >>>> addr-arch or RFC4862 because of this. (draft-bourbaki-6man- >>>> classless-ipv6-00 seems to be confused on this point, and I suspect >>>> it increases the confusion and controversy in this whole thread). >>> >>> Agreed. >> >> Is there a document that states that IPv6 routers and hosts must suppo= rt >> on-link prefixes of all sizes?=20 >=20 > In my own draft draft-jinmei-6man-prefix-clarify-00 I tried to explain > that's at least the case for configuring on-link prefixes on a host > advertised via Router Advertisements. RFC4861, or any other RFCs that > I know of, doesn't have an exact phrase like "a host MUST support > on-link prefixes of all lengths", but I believe I provided sufficient > evidences that that's the reasonable interpretation of the current > specification and it matches what's currently implemented. >=20 > For manual configuration on hosts and routers, I don't think there is > an RFC that has this exact phrase or equally strong evidence as the > host autoconfiguration case. But at least for host implementations I > believe it's quite natural to extend that interpretation to manual > configuration. And same for routers - after all, it's a router to > advertise an on-link prefix of arbitrary lengths via RA PIO. So, it > shouldn't be unreasonable to assume it should be able to use that > prefix for its own on-link determination. >=20 > And, perhaps more important in the context of > draft-bourbaki-6man-classless-ipv6-00, (as far as I know) no one, > even strong 64bit-IID advocates, disagrees on this interpretation. I would say it is a completely separate issue that the draft simply doesn't care about. Brian =20 From nobody Mon Jun 19 13:01:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B41294C8 for ; Mon, 19 Jun 2017 13:01:03 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKqAr_4nR8ZJ for ; Mon, 19 Jun 2017 13:01:01 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 A5414129486 for ; Mon, 19 Jun 2017 13:01:01 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id f185so52683838pgc.0 for ; Mon, 19 Jun 2017 13:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aotGLDy0ptSybROfi7ZVzo1vn/6Zr+Pbei+Qyj/rIGk=; b=m+T/YHQptvuhZ6061EbnK8ovhvNRunqRXY2nkPD2LdymULqdKuMyW9GCInm5KGOwLK IAi0Y6AoSkQdLWLm96wyDQ1/Fk5YolbwfxK7dh/ejPNGc4q/C0WF7qayDUPUvusknZVW 7sTLUn3wrrfUiSiyb3FFMp0q56DZob3udYKMuET+jhuJV6Flz3E55/RKYpB3Q8W66Pxc QW2Cfjqsr7Cwb0s/CCEnNcEsn3C1yzVoXQ7cvJsmgr80RbqVS+8XTvcpxMub//E/8hOK SVJ3yDxzlaU8pygx+RJuw+MEzn82co2bf/EIM4hY510gHXVIIZSASWOg4/2DJIFEU9EE fejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=aotGLDy0ptSybROfi7ZVzo1vn/6Zr+Pbei+Qyj/rIGk=; b=Fy2CPTde5FeJkjgW0EHIUM5KaK/fYzNYvouFDydMD3vIo29stXWymPYx/doQPD2aa5 0OFhBMiGzgjgAAFFJpgH54v0i16jKh/cyPepkWxqb/phnbqTlXx/WNdvTNTOhr6NxUw5 63zR/sOxx5wMctK0OfS/XAp5zP8HSe+eNn5ioKyQLXF2ez4PlySrT5k0Cfo4y6uLpR2F 5VB5m9x9V/AKT/P4dt9EnhVy90DSAbgeECuR8zidX9pSxYAI527IbgVsptF5Cy29JJZH /Ox2oLy15txUOAaUnrzEzMccCZoXM/SMv9XhyP1v1sULruvherAW7Vubh+MNFVkMyeKQ 1IOQ== X-Gm-Message-State: AKS2vOxzXFoof1fZa6QyE5BOmK0BsA0YnuMQkWys367pfzAIJvCoVN8z aos56vykVYZD2mue X-Received: by 10.99.149.83 with SMTP id t19mr1893618pgn.247.1497902460889; Mon, 19 Jun 2017 13:01:00 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id n63sm22352075pfa.62.2017.06.19.13.00.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 13:01:00 -0700 (PDT) Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00) To: ipv6@ietf.org References: <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <20170619164512.hbysyxqfps7jh7rc@Vurt.local> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 20 Jun 2017 08:00:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 20:01:03 -0000 On 20/06/2017 05:16, David Farmer wrote: > On Mon, Jun 19, 2017 at 11:45 AM, Job Snijders wrote: > >> On Tue, Jun 20, 2017 at 01:26:24AM +0900, Erik Kline wrote: >>>> I'd also note once again that this discussion has nothing to do with >>>> the fact that we can perform 'ifconfig en0 2001:db8::1/120'. This >>>> operation configures a 128-bit IPv6 address with 120-bit on-link >>>> prefix. On-link prefixes have always been variable, and they have >>>> nothing to do with IID length or SLAAC. We don't have to update >>>> addr-arch or RFC4862 because of this. (draft-bourbaki-6man- >>>> classless-ipv6-00 seems to be confused on this point, and I suspect >>>> it increases the confusion and controversy in this whole thread). >>> >>> Agreed. >> >> Is there a document that states that IPv6 routers and hosts must support >> on-link prefixes of all sizes? >> >> Kind regards, >> >> Job >> > > I believe this is what RFC7608 says, except I don't think it uses the term > on-link, which it probably should. Consistent terminology for the different uses of the word "prefix" is emerging as a major problem in this debate. I don't see any distinction in RFC7608 between the on-link prefix and the prefix used for address assignment purposes such as SLAAC. The distinction in 7608 is between an amalgam of those two and the prefix used in routing protocols. Brian From nobody Tue Jun 20 05:04:52 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B237129C4B; Tue, 20 Jun 2017 05:04:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc4291bis-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149796028333.23658.1453166537210484082@ietfa.amsl.com> Date: Tue, 20 Jun 2017 05:04:43 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:04:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IP Version 6 Addressing Architecture Authors : Robert M. Hinden Stephen E. Deering Filename : draft-ietf-6man-rfc4291bis-08.txt Pages : 33 Date : 2017-06-20 Abstract: This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 20 05:14:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADDA129C5C for ; Tue, 20 Jun 2017 05:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79en1Nd3LZyi for ; Tue, 20 Jun 2017 05:14:51 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 564FE12E872 for ; Tue, 20 Jun 2017 05:14:23 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id m125so20176427wmm.1 for ; Tue, 20 Jun 2017 05:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=YootthP8Y5qmuWlI00b/BzMbtZNG+2SW19ELcS7GXv8=; b=rxZW/vdiEO0xpflT/qklpQaETVbEn/oNuta6tZVgBVQtTRRm8FY6kZqet0Ki65djLw GP3mSFRCmt5tVSBmlZnTKa6/3nGXMXATp6g5qvDgX8Cq6uRLvE0LHogPAOdm/OQ9/Lm0 K+Ox3rM43gLGFgt2spAUdYn2BOpMF+mdAKLrsLhENUpjQonEWCLZFr6lS5dTOZozeVJZ iiyL7Sm1zCe5UwMgZ2X7PU6XWMbcDwUOG/krGRfDUwPimUiKDcHabNW4n2TeRrUOXhtC Z5sWL6HqzUNx/ADMfB+viTA0Z6hKHIYqtay/j/3/PKTYunwjFCHZDvBPcEMbgDnSz0Sp Pc4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=YootthP8Y5qmuWlI00b/BzMbtZNG+2SW19ELcS7GXv8=; b=n4WuQzkS4m0FAz39ijVxTwce1FCUwpBPajQZyrdxAVpuhIJUSzP9iV1X8NDI88zb+v DwhQr9Y5MnE8yW8iKJ2UUicHgIUvEQDvGUGrPskoyUHgGVVx455HwbKlFTIzWYbv0tYw hUfUpv4CYH52oMDTw2O7pGtOUCJac4NZahkkRu4a5JagFyEB1MYpR59UgrA8ECn7BQEl Z/IJCu3Td0/d/hvTJfKKSEsv/vF2OfOBRh0cABCEP4+SrVWdTKgxBhUpmQ3Nr/9vzc+F zToJ6yzDcy6nbraqNM0FuoWmgvaqfPnyr9ltVt2lTxMbzaIGZVBToC/y+vxGQiT0L7o4 j5/g== X-Gm-Message-State: AKS2vOwVLH1kdy19nfAAopPVRQajTUgXovDGpWOYk6wp0mu8T4Sa0rRu WTTkjVHp0Ol2kTl65P4= X-Received: by 10.28.19.11 with SMTP id 11mr2445002wmt.123.1497960861551; Tue, 20 Jun 2017 05:14:21 -0700 (PDT) Received: from [172.24.228.74] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id f21sm20017469wra.5.2017.06.20.05.14.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jun 2017 05:14:20 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_E7C0D247-3B97-4799-B7F9-A864D375F889"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Date: Tue, 20 Jun 2017 15:14:18 +0300 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> Cc: Bob Hinden To: IPv6 List Message-Id: <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:14:54 -0000 --Apple-Mail=_E7C0D247-3B97-4799-B7F9-A864D375F889 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new 6man w.g. version (-08) of the RFC4291bis draft. See = links below. The summary of the changes are: o Added Note: to Section 2 that the term "prefix" is used in different contexts in IPv6: a prefix used by a routing protocol, a prefix used by a node to determine if another node is connected to the same link, and a prefix used to construct the complete address of a node. o Based on results of IETF last call and extensive w.g. list discussion, revised text to clarify that 64 bit Interface IDs are used except when the first three bits of the address are 000, or addresses are manually configured, or when defined by a standard track document. This text was moved from Section 2.4 and is now consolidated in Section 2.4.1. Also removed text in Section 2.4.4 relating to 64 bit Interface IDs. o Removed instruction to IANA fix error in Port Number assignment. IANA fixed the error on 4 March 2017. o Editorial changes. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-08 This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A new version of I-D, draft-ietf-6man-rfc4291bis-08.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc4291bis > Revision: 08 > Title: IP Version 6 Addressing Architecture > Document date: 2017-06-20 > Group: 6man > Pages: 33 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-08.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-08 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-08 >=20 > Abstract: > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. The document includes the IPv6 = addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and = an > IPv6 node's required addresses. >=20 > This document obsoletes RFC 4291, "IP Version 6 Addressing > Architecture". --Apple-Mail=_E7C0D247-3B97-4799-B7F9-A864D375F889 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEbBAEBCgAGBQJZSRGaAAoJEK7rdBF357uoX40H+O9moF/D0j+G+HH8p64O+rns 0D0HGCDypVKV+lbH0+6t+WTHNB3Wjmfd7tCoI/cRTlnIsnBQBJHQaiyFWzApty+w G5MVtmvNFqwoqi5qQkCA1/B/ZgmQb1BTC9iWeOSnDDKwuE5lz21DK0D3gv5rCFO6 /sOatlaFsRyHb7biB8KVbIECty27rryAGWS8zDAYKT0EEX4p3+tNfHbnrzbhaEJQ L3Gd5zsS1vGwkbG3QBc3dLAzYcVS39GxIMrnO/XpMn+fLXTxvsXt//hN/50grj45 mQee0BerxytOaGvRtBWmekZF7g14sVq6iPrgdNu2c64Tz0e4+UyA8up48Zo8hA== =MZsM -----END PGP SIGNATURE----- --Apple-Mail=_E7C0D247-3B97-4799-B7F9-A864D375F889-- From nobody Tue Jun 20 14:34:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4A81294EC for ; Tue, 20 Jun 2017 14:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8FUfiZE8vSf for ; Tue, 20 Jun 2017 14:34:16 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 1CB9812EC58 for ; Tue, 20 Jun 2017 14:34:15 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 6C47611F for ; Tue, 20 Jun 2017 21:34:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUwa_ylP75Mf for ; Tue, 20 Jun 2017 16:34:15 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 222DE713 for ; Tue, 20 Jun 2017 16:34:14 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id y14so16648869uag.3 for ; Tue, 20 Jun 2017 14:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qvYhh6d35TZfVOR3yqy7EwwTEQx+ST1cJa9wZWtzFNw=; b=Wz0Y9X1APR9IVxg7nDyEgeKAtu4q8oMncnXA5Um0fAZHnSzyMTWmTW6aodMEANh+S4 N7bOowmxjwFiG5rlbrxkelEMcYM4HoCgRJJX/DYph4K2q8SXKcn+XotpdrsyXVvD5W4u BAc5DHSYOYysQFVfqrO6Hcnf2ky/6Z3bytWXUxsswEeP+jIqP9KiKYeBWGU0vpyi/nqk V0gg+b06WDqxDSHbYCXeLK0qPua/+85LniWdZTvsraE1M5D44t5igVzktSEc3Z1WLGfW ivPX8nexhLMlnpEtFiE3n3XhL2L/yy+i1a7YshCvFuMbLvlqF5kSSD7MobemXLuhhOnZ ed6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qvYhh6d35TZfVOR3yqy7EwwTEQx+ST1cJa9wZWtzFNw=; b=bMyyujpgMVuYENfDZkrtKQMDzEHqoa721vVgr3LdCjKLAG2wltvE4kFFmDCg6O1xr/ x98Nb+/W/+2rAejdf5P0hkPb995SOH/dky2EoDCf2Bg5+batonT3Sp0z/gE4N5o6NG9+ ZlfQx3CrOufqAPxMBEdT89ydmWC4mXQSYqoqA4K0dHKVc0znL9qvdaK5jRbJwYfS53Av JairS6/ZW3bYY60LgWLCMcJzoL2KOvIKLZVNzrmSI6THLJGbFbv8FqtY4tZxvgb+c+gU TVHv+7mGE+xPYJ7Dp3Kt6PGWTg4XX+F2YeAsB2hUrxLWKE93jsLqQNvE9jLK8T6yXc0Q 0RGQ== X-Gm-Message-State: AKS2vOwccHYSnjs395kE0yItYRlvBBfbf7KYDxDUhyGmVpg8NFXc+m1V iNvCba777Sra7RChoSmRzFpgveu/R+As+KhWo0bUsIO+zLQciLw+sB1A4AZP/COsfl/WoOMo5d4 iITcVaNnmNwP/kn8= X-Received: by 10.159.34.227 with SMTP id 90mr14411043uan.131.1497994454158; Tue, 20 Jun 2017 14:34:14 -0700 (PDT) X-Received: by 10.159.34.227 with SMTP id 90mr14411027uan.131.1497994453859; Tue, 20 Jun 2017 14:34:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Tue, 20 Jun 2017 14:34:13 -0700 (PDT) In-Reply-To: <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> From: David Farmer Date: Tue, 20 Jun 2017 16:34:13 -0500 Message-ID: Subject: Re: To: Bob Hinden Cc: IPv6 List Content-Type: multipart/alternative; boundary="94eb2c03cb584ca8b305526b03d8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:34:19 -0000 --94eb2c03cb584ca8b305526b03d8 Content-Type: text/plain; charset="UTF-8" I think this is getting really close. However, there still seems to be an implication that a subnet must be /64 or 64 bits for both address generation and on-link determination. Subnetting (for IPv4) is discussed in a series of RFCs[1], culminating in the Internet Standard Subnetting Procedure [RFC950]. The closest thing to a definition for the term subnet comes in the overview for RFC950. Subnets "are logically visible sub-sections of a single Internet network." However, it seems clear that the term is equally important to two of the aspects we are talking about, it is about both address generation and on-link determination. If RFC4291bis is going to use the term subnet, it's use should either be consistent with the meaning in RFC950, or it should be abundantly clear how the use of the term differs from it's use in RFC950. There should be no ambiguity, unless clearly stated otherwise, the term subnet means what it means in RFC950. In fact let's be clear, the reason the term is being used here is because of the comfort level that comes from the decades of use of the term as derived from it's RFC950 meaning. Because the current use of the term "subnet" in RFC4291bis-08 doesn't seem to distinguish between address generation and on-link determination, there still seems to be an implication that a subnet must be /64, or 64 bits, for both address generation and on-link determination. One possible way to break this improper implication, would be to qualify the statement that Interface Identifiers are 64 bits long to address generation and add to the note that for on-link determination prefixes and IIDs can be any length. How about something like this; When generating an address, Interface Identifiers are required to be 64 bits long except if the first three bits of the address are 000, when addresses are manually configured, or by exceptions defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421 ]. An example of a standards track exception is [RFC6164 ] that standardizes 127 bit prefixes on inter-router point-to-point links. Note: In the case of on-link determination and as a result when a prefix length is provide with a manually configured address, the Prefix and Interface Identifier can be any length as long as they add up to 128, but are recommended to be 64 bits. Also, based on the definition of subnet, in section 2.4.4 it seems critical that m>=1. If it is not and m=0, then we can't be talking about /64 subnets, we are talking about a /64 network. Therefore, "m" must be greater than or equal to 1, for you to even be properly talking about the term subnet in IPv6 addressing. Besides adding that point to this section, a reference to RFC6177 seems appropriate too. Thanks David Farmer [1] RFC917, RFC925, RFC932, RFC936, RFC940 https://tools.ietf.org/html/rfc917 https://tools.ietf.org/html/rfc925 https://tools.ietf.org/html/rfc932 https://tools.ietf.org/html/rfc936 https://tools.ietf.org/html/rfc940 https://tools.ietf.org/html/rfc950 On Tue, Jun 20, 2017 at 7:14 AM, Bob Hinden wrote: > Hi, > > I published a new 6man w.g. version (-08) of the RFC4291bis draft. See > links below. > > The summary of the changes are: > > o Added Note: to Section 2 that the term "prefix" is used in > different contexts in IPv6: a prefix used by a routing > protocol, a prefix used by a node to determine if another > node is connected to the same link, and a prefix used to > construct the complete address of a node. > > o Based on results of IETF last call and extensive w.g. list > discussion, revised text to clarify that 64 bit Interface IDs > are used except when the first three bits of the address are > 000, or addresses are manually configured, or when defined by > a standard track document. This text was moved from > Section 2.4 and is now consolidated in Section 2.4.1. Also > removed text in Section 2.4.4 relating to 64 bit Interface > IDs. > > o Removed instruction to IANA fix error in Port Number > assignment. IANA fixed the error on 4 March 2017. > > o Editorial changes. > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08 > > This is part of the project to move the core IPv6 specifications to > Internet Standard. > > Thanks, > Bob > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c03cb584ca8b305526b03d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is getting really close.=C2=A0 However, there= still seems to be an implication that a subnet must be /64 or 64 bits for = both address generation=C2=A0and on-link determination.=C2=A0

Subnetting (for IPv4) is discussed in a series of RFCs[1], culmi= nating in the Internet Standard Subnetting Procedure [RFC950].=C2=A0 The cl= osest thing to a definition for the term subnet comes in the overview for R= FC950. Subnets "are logically visible sub-sections of a single Interne= t network." However, it seems clear that the term is equally important= to two of the aspects we are talking about, it is about both address gener= ation=C2=A0and on-link determination.

If RFC4291bis is going to use the term subnet, it's use should either= be consistent with the meaning in RFC950, or it should be abundantly clear= how the use of the term differs from it's use in RFC950.=C2=A0 There s= hould be no ambiguity, unless clearly stated otherwise, the term subnet mea= ns what it means in RFC950. In fact let's be clear, the reason the term= is being used here is because of the comfort level that comes from the dec= ades of use of the term as derived from it's RFC950 meaning.
=
Because the current use of the term "subnet" in RF= C4291bis-08 doesn't seem to distinguish between address generation and = on-link determination, there still seems to be=C2=A0an implication that a s= ubnet must be /64, or 64 bits, for both address generation=C2=A0and on-link= determination.=C2=A0

One possible way to break th= is improper implication, would be to qualify the statement that Interface I= dentifiers are 64 bits long to address generation and add to the note that = for on-link determination prefixes and IIDs=C2=A0can be any length.=C2=A0 H= ow about something like this;

   When generating a=
n address, Interface Identifiers are required to be 
   64 bits long except if the first three bits of the addr=
ess are 000, 
   when address=
es are manually configured, or by exceptions defined in 
   standards track documents. The rationale for using =
64 bit Interface
   Identifiers can be found in [RFC7421].  An example of a standards
track exception is [RFC6164] that standardizes 127 bit prefixes = on 
   inter-router point-to-point links.

      Note: In the case of on-link determination and as a result when 
      a prefix length is provide with a manually configured address, the 
      Prefix and Interface Identifier can be any=
 length as long as they
      add up=
 to 128, but are recommended to be 64 bits.

= Also, based on the definition of subnet, in section 2.4.4 it seems critical= that m>=3D1.=C2=A0 If it is not and m=3D0, then we can't be talking= about /64 subnets, we are talking about a /64 network.=C2=A0 Therefore, &q= uot;m" must be greater than or equal to 1, for you to even be properly= talking about the term subnet in IPv6 addressing. Besides adding that poin= t to this section, a reference to RFC6177 seems appropriate too. =C2=A0

Thanks

David Farmer

[1] RFC917, RFC925, RFC932, RFC936, RFC940

On Tue, Jun 20, 201= 7 at 7:14 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
Hi,

I published a new 6man w.g. version (-08) of the RFC4291bis draft.=C2=A0 Se= e links below.

The summary of the changes are:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Added Note: to Section 2 that the term = "prefix" is used in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different contexts in IPv6: a pref= ix used by a routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol, a prefix used by a node = to determine if another
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0node is connected to the same link= , and a prefix used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0construct the complete address of = a node.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Based on results of IETF last call and = extensive w.g. list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussion, revised text to clarif= y that 64 bit Interface IDs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are used except when the first thr= ee bits of the address are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0000, or addresses are manually con= figured, or when defined by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a standard track document.=C2=A0 T= his text was moved from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 2.4 and is now consolidate= d in Section 2.4.1. Also
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0removed text in Section 2.4.4 rela= ting to 64 bit Interface
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IDs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Removed instruction to IANA fix error i= n Port Number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assignment.=C2=A0 IANA fixed the e= rror on 4 March 2017.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Editorial changes.

A diff from the previous version is available at:

=C2=A0 https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-6man-rfc4291bis-08

This is part of the project to move the core IPv6 specifications to Interne= t Standard.

Thanks,
Bob

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication = Services
Office of Information Technology
University of Minnesota=C2= =A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-6= 26-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
--94eb2c03cb584ca8b305526b03d8-- From nobody Tue Jun 20 21:31:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5004126D05 for ; Tue, 20 Jun 2017 21:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbkLltpg39zE for ; Tue, 20 Jun 2017 21:31:53 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 A5BF91204DA for ; Tue, 20 Jun 2017 21:31:53 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 70so35330803uau.0 for ; Tue, 20 Jun 2017 21:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kRM5jcvs7HdYdw/IMcLto1bo8UQmUqxqZYFj3TSHUbw=; b=jg8Z7dBRGEnWpMFmy2qCjeUKvLeHyKxeBIggRDiMCzxchEbTSOTSJf07+ZfoFuE0bz mEavllyzNFcxtsZ00tAw6D9Mz5h0o3kCbd9FWOSjivZ/LSyUmerluou38vC5mMQeblO8 mavx3CnmBo2NetmYDGD5GpydP/VZoDTWUhv7z8EpXRsqpSCAOhm2VKhfwsYo66+NxIgQ tp0gvJYPrjsV+8s2w9jDIfO4cAART6n9AkRub2fqlE0zpG5gA6gzkLNM0sFjmPxELSkJ ZGyplWQ/6+gl68zik97fSvRl/6p1B+UTxQ6BvSBhJQJC4wAtw+luf7kAG5zYgY1YspzU Ql5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kRM5jcvs7HdYdw/IMcLto1bo8UQmUqxqZYFj3TSHUbw=; b=sApvUcNxccMVl/VTbMKXF/FPKigBcc3ZoRz0B3jfZ1VyP0xh3fV+vp7DYNewWTFDZt p4sUCUamdVKS4e/m8MOJ6Iqja/SgGC6o2Rdzz/pml3shjnsKblGYAO4WlyKLfBzX3/gO 2b8OvmG8dQDwJwTK13wFm4yg2tYOdyVYY6OpsYUCykpUfJRPvhKlQXHSY9j7KJnHC3Fo /E3djNHAxMA9gVv7VP9whd5kbf+vdOHcqfF3HmJrel7rDNQDUll3l4VJZ5DTq2p17NNY MdJzof/84HtdWS3bsNpJ8iorNRu8yMMtcUjGp3OV3hKWqcynoaq3TDxZdoo43BJzGTNr x7mw== X-Gm-Message-State: AKS2vOxGxQw6sQJfdBT/e6bAlP6xwST2t744hEjYh1tRnBfJBH9cTPa2 eTD9arXDSyjINeQfe7d/woLVj94TfQ== X-Received: by 10.176.67.98 with SMTP id k89mr5519698uak.103.1498019512688; Tue, 20 Jun 2017 21:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Tue, 20 Jun 2017 21:31:21 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Mark Smith Date: Wed, 21 Jun 2017 14:31:21 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: "t.petch" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 04:31:56 -0000 Hi Tom, On 17 June 2017 at 01:06, Tom Herbert wrote: >> There's nothing actually wrong with security by obscurity as a defence in >> depth measure. >> >> If you already prevent ICMPv4 echo requests inbound, you're using it. As are >> zebras, giraffes, cheetahs and many (probaby all) armies around the world, >> namely camouflage. >> > Mark, > > Zebras are still in the main diet of lions. Camouflage is not the same > thing as armor or weapons. Credit cards have long numbers that aren't > guessable, but that is little comfort every time I get a letter from a > merchant about a breach and how my number was stolen. > So what I think you're doing here is adding and mixing up threats, and then using those to evaluate the security measure. Once you do that, the measure may be completely ineffective and entirely inappropriate. The specific threat where large IIDs and random addresses is an effective mitigation is device discovery via brute force unsolicited packet probing. It is not going to be an effective mitigation to addresses discovery by somebody in a position to discover addresses by tapping the traffic flow, or somebody who can use service log entries that recorded service clients that connected to the service. They are different threats and require different mitigations, because large and random IIDs are not effective against them. Unsolicited inbound packet probing has been successfully used to discover unknown IPv4 devices on the Internet since at least 2009. https://en.wikipedia.org/wiki/Shodan_(website) DerbyCon 2012: The Wild West by HD Moore https://speakerdeck.com/hdm/derbycon-2012-the-wild-west Also in 2012, a 420 000 node botnet was created using unsecured home CPE and then that was used to scan the entire IPv4 address space: https://en.wikipedia.org/wiki/Carna_botnet And we've recently seen the Wannacry malware leverage the same technique to exploit the SMBv1 vulnerability. Given how long that Internet wide IPv4 address sweeps have been occurring and have been successful at discovering unsecured services (e.g., "The Wild West by HD Moore") I still get surprised how insecure devices are that are likely to have been bought and deployed within the last 5 years: "Practical ways to misuse a router" http://blog.ptsecurity.com/2017/06/practical-ways-to-misuse-router.html If the above devices had Internet addresses that couldn't be successfully discovered via brute force scanning, it would have provided them with a base level of protection from further inspection. Other techniques would have to be used to discover these devices, and that means the specific threat - discovery by brute force unsolicited packet probing - has been mitigated successfully. Those other techniques will not be as easy to execute compared to brute force address scanning, otherwise they'd have been used instead and in the first place. People have been using guessable IPv6 IIDs has been used recently to discover open DNS resolvers. I think that demonstrates that people aren't considering the consequences of picking guessable IIDs when using GUA addresses. If the were, then they'd be securing the DNS resolver itself too. https://blog.apnic.net/2017/06/15/open-resolvers-ipv6-not-hidden-think/ It would have been better if these DNS resolvers had random 64 bit IIDs rather than easily guessable ones like ::53. To be able to use them as an open resolver, you'd have to successfully discover it first. I understand the convenience of using significant IID values, however I don't think they're justified by saying they should be easy for end-users to remember or type. Network engineers or host operators are a different audience, and should be willing to put up with some operational inconvenience if it results in a more available and secure service for their end-users. In this DNS example, I think end-users having to remember or write down and then enter IPv6 service address such as DNS server addresses is about as user friendly as hand cranking cars with a handle was to start them. You can buy retail cars that can drive themselves on public roads, yet we can't manage to successfully and reliably automatically configure routers and hosts with DNS resolver addresses, such that we need to make them easy remember, write down or type? Regards, Mark. From nobody Tue Jun 20 23:40:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBD21315D0 for ; Tue, 20 Jun 2017 23:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbWQi9KJ9K-t for ; Tue, 20 Jun 2017 23:40:15 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id E18C41315A1 for ; Tue, 20 Jun 2017 23:40:14 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 72A3FE6065; Wed, 21 Jun 2017 08:40:12 +0200 (CEST) Date: Wed, 21 Jun 2017 08:40:12 +0200 (CEST) Message-Id: <20170621.084012.74667681.sthaug@nethelp.no> To: markzzzsmith@gmail.com Cc: ipv6@ietf.org Subject: Re: Tussles in IPv6 Land From: sthaug@nethelp.no In-Reply-To: References: 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 06:40:18 -0000 > People have been using guessable IPv6 IIDs has been used recently to > discover open DNS resolvers. I think that demonstrates that people > aren't considering the consequences of picking guessable IIDs when > using GUA addresses. If the were, then they'd be securing the DNS > resolver itself too. > > https://blog.apnic.net/2017/06/15/open-resolvers-ipv6-not-hidden-think/ > > It would have been better if these DNS resolvers had random 64 bit > IIDs rather than easily guessable ones like ::53. To be able to use > them as an open resolver, you'd have to successfully discover it > first. Some of us are using easily guessable IPv6 resolver addresses very much on purpose - primarily because this is one of the few addresses that may need to be specified manually, given to customers over the phone, etc. At least in our case these IPv6 resolver addreseses are *not* open resolvers: The DNS service is only reachable within our AS. > I understand the convenience of using significant IID values, however > I don't think they're justified by saying they should be easy for > end-users to remember or type. Network engineers or host operators are > a different audience, and should be willing to put up with some > operational inconvenience if it results in a more available and secure > service for their end-users. You may want use difficult-to-guess IID values in your network. You shouldn't expect all operators to agree. Steinar Haug, AS2116 From nobody Wed Jun 21 01:25:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2F1318BC for ; Wed, 21 Jun 2017 01:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGGmvEl7wIQ1 for ; Wed, 21 Jun 2017 01:25:16 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 E7AB61318AD for ; Wed, 21 Jun 2017 01:24:50 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id z22so9644791uah.1 for ; Wed, 21 Jun 2017 01:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WDTrquxRKRrxYJMS/EI56ssJknl8VcP2+welxoQLi3U=; b=O7au8T9slP0JkluxsY9qWd3+B5pVuYqGTdCNXSD6DrK/Npj4ylSP9/cv1SR4J4LXa3 zw5Eah+X/emBrR78IkFotwphOA69wtcTYL/YUM9FbG3q0r55QohkVkxuLGYcP4PU/b5S TncCco1P0Qu8gmJ9n38DPqJHY1NznqfPNKwVDjogYtHcJoyPux3hRrLrVN5q15Td3pi2 pKgwn0S5AbUQbr1jkq4NesBANvxy/WkN362DOIKOTDfVmqB3vfx5vRvsoQ42Srm2eHa4 Kx3x8xKIhADASfQzzeWThPNvvR4OksGNF8BNRLtXtu0J/X2ItP2K4hWNn0Uex1Q9Npfw 0hNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WDTrquxRKRrxYJMS/EI56ssJknl8VcP2+welxoQLi3U=; b=k0BdQZ4WPl35qb9Q93NDG7LfCz96FZQUiLy9ome+qF7de1twBq3i2p65ACsYGLE5dO x579+0PUdZvm5oXVbhMSCvdm/54qQs7YoFnzwma7umuqdwtrTtPXIWwg0/km7YO0FFgf WkOme1gMRbW7DKMn4KQjvyaEIGdCygkPgnV9E34imJQAfQJGchXGQab/OhlvS6RECrNW TmbIpGTwbiw/kT5/TU1pHGj6dLKKopoebii3Gdd3CEmPi5OtcDrF0UJUxBHzo3Sl/ZB9 7qhzuHgGAaBqsm+7FPAsHM6XHra5BHU/aqpOyQr1T+v4MnRhZNsRYu63PjFR/3jsXPne uSEQ== X-Gm-Message-State: AKS2vOxeU5RCM1tTiOTOErdcZ4F8cb4pNroFk4nDOiOV/YAqiKVS4UdK tau11JxSjzaz6WvDK4kB9MPL5GYe4g== X-Received: by 10.176.23.25 with SMTP id j25mr15682442uaf.32.1498033489806; Wed, 21 Jun 2017 01:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Wed, 21 Jun 2017 01:24:18 -0700 (PDT) In-Reply-To: <20170621.084012.74667681.sthaug@nethelp.no> References: <20170621.084012.74667681.sthaug@nethelp.no> From: Mark Smith Date: Wed, 21 Jun 2017 18:24:18 +1000 Message-ID: Subject: Re: Tussles in IPv6 Land To: sthaug@nethelp.no Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 08:25:18 -0000 On 21 June 2017 at 16:40, wrote: >> People have been using guessable IPv6 IIDs has been used recently to >> discover open DNS resolvers. I think that demonstrates that people >> aren't considering the consequences of picking guessable IIDs when >> using GUA addresses. If the were, then they'd be securing the DNS >> resolver itself too. >> >> https://blog.apnic.net/2017/06/15/open-resolvers-ipv6-not-hidden-think/ >> >> It would have been better if these DNS resolvers had random 64 bit >> IIDs rather than easily guessable ones like ::53. To be able to use >> them as an open resolver, you'd have to successfully discover it >> first. > > Some of us are using easily guessable IPv6 resolver addresses very > much on purpose - primarily because this is one of the few addresses > that may need to be specified manually, On those rare occasions, cut-and-paste works fine. > given to customers over the > phone, etc. Been there, done that, I don't think it is a good idea. In my residential ISP experience, helpdesk staff don't apply much intelligence to troubleshooting because they're incentivised to increase their phone call/hour throughput. So they try random things until one of them works, and don't reverse other ineffectual changes they made. So you end up having to punch a couple of old DNS resolver /32s out of a /24 (which pretty much prevents you from using the /24 as a /24 anywhere else) you want to use somewhere else because customers now have them set manually rather than using the reliable and proven autoconfiguration method/system. Again, self driving cars, yet ISP customers have to be exposed to under the hood/bonnet settings? If people aren't getting DNS settings set correctly by the autoconfiguration system, which is better - the helpdesk band-aiding over it using manual settings, or the fault being fixed properly by the operations teams? I've had the experience of a helpdesk band-aiding over a problem on me for 6 months, and only found out about it 2 weeks before we were going to be launching a product that the hidden fault was going to cause catastrophic problems to, which it did, because there was too much inertial against stopping the product launch. Making DNS server addresses hard to type increases the chances of the proper team being able to fix the problem properly because it'll be escalated. > > At least in our case these IPv6 resolver addreseses are *not* open > resolvers: The DNS service is only reachable within our AS. > >> I understand the convenience of using significant IID values, however >> I don't think they're justified by saying they should be easy for >> end-users to remember or type. Network engineers or host operators are >> a different audience, and should be willing to put up with some >> operational inconvenience if it results in a more available and secure >> service for their end-users. > > You may want use difficult-to-guess IID values in your network. You > shouldn't expect all operators to agree. > I don't think I said anything about seeking agreement. What I'm highlighting is that even for manually configured addresses e.g., server interfaces or router interfaces, there is a security value in having a large IID space available. I'm pointing it out to make sure it is recognised by those who are lobbying for arbitrary IPv6 prefix/IID sizes. Regards, Mark. From nobody Wed Jun 21 06:55:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33254129B25 for ; Wed, 21 Jun 2017 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpQ2PPOmj02U for ; Wed, 21 Jun 2017 06:54:52 -0700 (PDT) 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 6CE55129B10 for ; Wed, 21 Jun 2017 06:54:52 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v5LDskQn005345 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2017 14:54:46 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <594A7AA4.6020403@foobar.org> Date: Wed, 21 Jun 2017 14:54:44 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Mark Smith CC: "ipv6@ietf.org" Subject: Re: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:54:56 -0000 Mark Smith wrote: > So what I think you're doing here is adding and mixing up threats, and > then using those to evaluate the security measure. Once you do that, > the measure may be completely ineffective and entirely inappropriate. > > The specific threat where large IIDs and random addresses is an > effective mitigation is device discovery via brute force unsolicited > packet probing. While you quote specific examples of how easy it is to scan the entire ipv4 address space, you also omit to mention that scan + connect worm behaviour is not how the lion's share of vulnerabilities are spread these days, and also you don't mention that a single compromised device on an ipv6 network is enough to be able to spread to all other devices on the network due to being able to get other local addresses via ipv6 LL traffic, ND and all that. There are multiple references to this on the web which I'm not going to going to go to the effort of looking up right now, but they exist and the problem is real. You also don't acknowledge that many hosts are dual-stacked and compromise via ipv4 is just the same as compromise via ipv6, nor that there are plenty of other mechanisms which provide name to address mapping (dynamic dns, etc) or address lists (existing neighbor caches). So when you have: - single stack, ipv6 only - scan + connect worm threat only - no host level or network level firewalling - all addresses fully randomised on network - no other way of guessing addresses - no way of trapping LL traffic ... it is true that large address spaces with truly random addressing selection schemes can provide a modicum of security through obscurity. In pretty much all other situations, long mask lengths with random addresses have no impact whatever on security. Nick From nobody Wed Jun 21 07:10:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE4B12943D for ; Wed, 21 Jun 2017 07:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9uWbYXZF9Tc for ; Wed, 21 Jun 2017 07:10:01 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 F31F6129B2E for ; Wed, 21 Jun 2017 07:04:11 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id r103so136510923wrb.0 for ; Wed, 21 Jun 2017 07:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l7MDe/DV9febF71c6c6wvOA5yjNX1jKAjS/of7XWgzo=; b=AvpFrwcJKH4kJM1kJ4nchv3MqQAe3sRh1suHH8jx5oZJuVKosihPRN4aVtmPgwQJF8 w+FZyH/jWpNGxf807moPO3NmBmwIBn3Rys59/n/Fv5IUvgxVU3dsoaaPgmhi3lWn1Wr/ H2u3xsdzNdjpYZtuxPS4AWCiY2tHTlcSXUaMM7OPFXShQFUHUTahO2FjQ8aEDCl5sCxn 0XqJRtlraYpYC68RPFbLRHCZbC71xLFxV3zRD0iyZOXHfMu1zN52IynIqPfKuu4RsSOe gc2rQt/IvdOY0NlRePzxZBtwAn5cH4WegX9g6BxuUJfz3OQ13B0PA62VclkapYb2X14W I9qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l7MDe/DV9febF71c6c6wvOA5yjNX1jKAjS/of7XWgzo=; b=f8kI9nW4554uFNsDfxb/2Yy7cx50M/i+yqJnS/ksdRzYxR1niUuaKIKt/CK/oKJ9e3 LUDWWdDhdr6SRvYnzyE/LayluXC6v+z+fheQuDRMasoYDeSUd8omxmWBf9Ddhq5ZPovb bMuuf1S8nwL844EphypcCKb4KkU3DWutgJZl34MSPGul5edLkyaN7x++Sq7lSBzPCB4B xldCQX6mXzlS08Td2XjnJwPO0Qdo8CIipwuFYr5ngB+STp4GWk7/ChY+rCcO49YWPBHr 86Oxd0tSmxVWngZadPA2BBcYV9eEnYKg99Tc742dBaexD3ShFlSAakbSsCFCLS3DGLXI CZiw== X-Gm-Message-State: AKS2vOzAJUDx5DuV6p26QjuMcducT4qck9s3md0LWQSs1WgFIw+npPa3 4EmEYuoQ7TgA4uM4PYogvhVlIdGaXALK X-Received: by 10.223.183.2 with SMTP id l2mr5460700wre.115.1498053850445; Wed, 21 Jun 2017 07:04:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Wed, 21 Jun 2017 07:04:09 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Tom Herbert Date: Wed, 21 Jun 2017 07:04:09 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Mark Smith Cc: "t.petch" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:10:03 -0000 On Tue, Jun 20, 2017 at 9:31 PM, Mark Smith wrote: > Hi Tom, > > On 17 June 2017 at 01:06, Tom Herbert wrote: >>> There's nothing actually wrong with security by obscurity as a defence in >>> depth measure. >>> >>> If you already prevent ICMPv4 echo requests inbound, you're using it. As are >>> zebras, giraffes, cheetahs and many (probaby all) armies around the world, >>> namely camouflage. >>> >> Mark, >> >> Zebras are still in the main diet of lions. Camouflage is not the same >> thing as armor or weapons. Credit cards have long numbers that aren't >> guessable, but that is little comfort every time I get a letter from a >> merchant about a breach and how my number was stolen. >> > > So what I think you're doing here is adding and mixing up threats, and > then using those to evaluate the security measure. Once you do that, > the measure may be completely ineffective and entirely inappropriate. > > The specific threat where large IIDs and random addresses is an > effective mitigation is device discovery via brute force unsolicited > packet probing. > > It is not going to be an effective mitigation to addresses discovery > by somebody in a position to discover addresses by tapping the traffic > flow, or somebody who can use service log entries that recorded > service clients that connected to the service. They are different > threats and require different mitigations, because large and random > IIDs are not effective against them. > Right, that's exactly the crux of the argument that the measure is not worth it. Address randomization is only effective against one form of attack, but as you point out there are other ways an attacker can accomplish the same goal of discovery. It might be worth it if we got this mechanism for free, but dedicating half of the bits in the IP address space to this one deterrent for a single narrow attack vector is too high a price. Tom From nobody Wed Jun 21 07:31:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99457129B62 for ; Wed, 21 Jun 2017 07:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Y8fu33tsBx for ; Wed, 21 Jun 2017 07:31:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id AE7EC129B63 for ; Wed, 21 Jun 2017 07:31:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dNgf1-0000JKC; Wed, 21 Jun 2017 16:31:11 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Tussles in IPv6 Land From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gat eway.2wire.net> In-reply-to: Your message of "Wed, 21 Jun 2017 07:04:09 -0700 ." Date: Wed, 21 Jun 2017 16:31:10 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:31:31 -0000 >Right, that's exactly the crux of the argument that the measure is not >worth it. Address randomization is only effective against one form of >attack, but as you point out there are other ways an attacker can >accomplish the same goal of discovery. It might be worth it if we got >this mechanism for free, but dedicating half of the bits in the IP >address space to this one deterrent for a single narrow attack vector >is too high a price. In the context of SLAAC, if you want your pseudo random IIDs to be essentially collission free, then you need enough bits that it also protects against scanning. DHCPv6 can handle way longer prefixes, so there the trade-off becomes real. Though it is not clear if we have a better use for those bits. It would require serious specs and experiments to see how those bits can be used and how the revised address archtecture interacts with existing assumptions about IPv6. From nobody Wed Jun 21 07:59:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E58129C4B for ; Wed, 21 Jun 2017 07:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1potUDg2mvd for ; Wed, 21 Jun 2017 07:59:17 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 53E2212E034 for ; Wed, 21 Jun 2017 07:55:06 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id s9so1454826ybe.3 for ; Wed, 21 Jun 2017 07:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bbdoBlpiBb5Q/Il/vJMvLK9VYa+1qPZrlw2YF2vQye8=; b=gnSYgiCvmIXC5Lj9Hfs7Gl14ruAJsLhHq+l+jVIrUEM7dtVE8uH1Runq5Z5Vxk7Mqw CTUlduDQxbGhs80F29Xs0uwU4+RI56USW+18YXzA7XLF2uHpHb71mk4He0VCl8KLrQoV waqru492IO+klw2pfbSZ9gAWe5AO/gz0IBIyVoevvN6lfTcGWqhm3QXxtK0/WvjyrZgO XleV+CNJvef/m7+lBUKm4olC3E9uYdb6GAbqUvXt/d5SuAN7gVybb2ydE04rl2Ts83Zf a6ByEHtnTBxpz7EWmxTeWvEAe9XBiYkX6+Mnx2ibQ/N2GtauGqFJJygr6QaR0ws1sshZ nYrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bbdoBlpiBb5Q/Il/vJMvLK9VYa+1qPZrlw2YF2vQye8=; b=GN9kYGEkaQVQtVl8293A+56BSw+zMBhDof0yfF3PpY/Omg/pW5DhYSASP4KwpUJ3ZP 21GPvj7rV2DQJi2KNGXK8YaSYxc/8YV7z7+m8EuFcYlnlmTiQfjNJ9L+OnUR86qDOYRO YXJw0L1dPw6iESIZddCdRCeCYPPT5YTN5a4bEt9faVDyLYdqcURVY70gwL2wj0Yn4sWj yo9gf+HEMKBYyFDlNewlx2OzmDM9EfvRUNa34YjdKmPkMeRhhVeyntoXL94ggkt2ayVX 9VcDPdx5DCrpS0G+v6toXieda2x2AkjNATGtnFTBSJUN0FCvuCEgD7WgnG7FoyEz0GKx eJHA== X-Gm-Message-State: AKS2vOxh92cMiAUqBItbeliVtzKH1IFwq237qoK6gsdCA4B8UTJ0T8gr Wq3TbBaBnvIGJ/WsvvRYEKtAdUQPxQ== X-Received: by 10.37.77.4 with SMTP id a4mr28137482ybb.2.1498056905586; Wed, 21 Jun 2017 07:55:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.133 with HTTP; Wed, 21 Jun 2017 07:55:04 -0700 (PDT) In-Reply-To: <594A7AA4.6020403@foobar.org> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> From: Ca By Date: Wed, 21 Jun 2017 07:55:04 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Nick Hilliard Cc: Mark Smith , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a113c5a96b6029b0552798dc6" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:59:19 -0000 --001a113c5a96b6029b0552798dc6 Content-Type: text/plain; charset="UTF-8" Acknowledging the state of the world where discussing security in public is very much needed, yet arch of the conversation here is just about as muddled as a have anticipated, inline On Wed, Jun 21, 2017 at 6:54 AM, Nick Hilliard wrote: > Mark Smith wrote: > > So what I think you're doing here is adding and mixing up threats, and > > then using those to evaluate the security measure. Once you do that, > > the measure may be completely ineffective and entirely inappropriate. > > > > The specific threat where large IIDs and random addresses is an > > effective mitigation is device discovery via brute force unsolicited > > packet probing. > > While you quote specific examples of how easy it is to scan the entire > ipv4 address space, you also omit to mention that scan + connect worm > behaviour is not how the lion's share of vulnerabilities are spread > these days, and also you don't mention that a single compromised device > on an ipv6 network is enough to be able to spread to all other devices > on the network due to being able to get other local addresses via ipv6 > LL traffic, ND and all that. There are multiple references to this on > the web which I'm not going to going to go to the effort of looking up > right now, but they exist and the problem is real. > > You also don't acknowledge that many hosts are dual-stacked and > compromise via ipv4 is just the same as compromise via ipv6, nor that > there are plenty of other mechanisms which provide name to address > mapping (dynamic dns, etc) or address lists (existing neighbor caches). > > So when you have: > > - single stack, ipv6 only > - scan + connect worm threat only > - no host level or network level firewalling > - all addresses fully randomised on network > - no other way of guessing addresses > - no way of trapping LL traffic > > Yes, you have exactly described 56 million of my 70 million mobile users. Not kidding. And this proportion of ipv6-only users will grow in my network and other networks as well. I understand this is perhaps not a network architecture many are highly familiar with, but it has been present to the IETF by several people several times, it has also been presented in several *NOGs. I am not saying all the other stuff is going away, but i am saying the picture you painted is alive and well and growing and benefiting from long random addresses. CB > ... it is true that large address spaces with truly random addressing > selection schemes can provide a modicum of security through obscurity. > > In pretty much all other situations, long mask lengths with random > addresses have no impact whatever on security. > Nick > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113c5a96b6029b0552798dc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Acknowledging the state of the world where discussing secu= rity in public is very much needed, yet arch of the conversation here is ju= st about as muddled as a have anticipated, inline

On Wed, Jun 21, 2017 at 6:54 AM, Nick H= illiard <nick@foobar.org> wrote:
Mark Smith wrote:
> So what I think you're doing here is adding and mixing up threats,= and
> then using those to evaluate the security measure. Once you do that, > the measure may be completely ineffective and entirely inappropriate.<= br> >
> The specific threat where large IIDs and random addresses is an
> effective mitigation is device discovery via brute force unsolicited > packet probing.

While you quote specific examples of how easy it is to scan the enti= re
ipv4 address space, you also omit to mention that scan + connect worm
behaviour is not how the lion's share of vulnerabilities are spread
these days, and also you don't mention that a single compromised device=
on an ipv6 network is enough to be able to spread to all other devices
on the network due to being able to get other local addresses via ipv6
LL traffic, ND and all that.=C2=A0 There are multiple references to this on=
the web which I'm not going to going to go to the effort of looking up<= br> right now, but they exist and the problem is real.

You also don't acknowledge that many hosts are dual-stacked and
compromise via ipv4 is just the same as compromise via ipv6, nor that
there are plenty of other mechanisms which provide name to address
mapping (dynamic dns, etc) or address lists (existing neighbor caches).

So when you have:

- single stack, ipv6 only
- scan + connect worm threat only
- no host level or network level firewalling
- all addresses fully randomised on network
- no other way of guessing addresses
- no way of trapping LL traffic


Yes, you have exactly described 56 mil= lion of my 70 million mobile users.

Not kidding. A= nd this =C2=A0proportion of ipv6-only users will grow in my network and oth= er networks as well.=C2=A0

I understand this is pe= rhaps not a network architecture many are =C2=A0highly familiar with, but i= t has been present to the IETF by several people several times, it has also= been presented in several *NOGs. =C2=A0

I am not = saying all the other stuff is going away, but i am saying the picture you p= ainted is alive and well and growing and benefiting from long random addres= ses. =C2=A0=C2=A0

CB
=C2=A0
... it is true that large address spaces with truly random addressing
selection schemes can provide a modicum of security through obscurity.

In pretty much all other situations, long mask lengths with random
addresses have no impact whatever on security.=C2=A0
Nick

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

--001a113c5a96b6029b0552798dc6-- From nobody Wed Jun 21 08:35:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBFE12EB5B for ; Wed, 21 Jun 2017 08:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L88cSUmv-zP3 for ; Wed, 21 Jun 2017 08:35:04 -0700 (PDT) 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 2F4AD12EB5F for ; Wed, 21 Jun 2017 08:31:36 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v5LFVTx8017024 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2017 16:31:29 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <594A914F.1020403@foobar.org> Date: Wed, 21 Jun 2017 16:31:27 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ca By CC: "ipv6@ietf.org" Subject: Re: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:35:12 -0000 Ca By wrote: > Yes, you have exactly described 56 million of my 70 million mobile users. two sides to this: 1. you are describing a specific and - despite the enormous numbers involved - atypical use case. When you scale up to those numbers, the issues and constraints you run into are not typical of the rest of the world. I don't get the impression that I'm alone in thinking that the sort of solutions required to fix the problems that cellular networks run into with IPv6 assignment are different to the solutions required for many other categories of ipv6 networks, and suspect that a good deal of the angst going on in v6ops relates to cellular ipv6 deployment viewpoints vs non cellular. 2. out of curiosity, i'd be interested to see the output of smart application of a hash collision algorithm. Nick From nobody Wed Jun 21 08:52:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CEC12EB05 for ; Wed, 21 Jun 2017 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL4tan4cPzTG for ; Wed, 21 Jun 2017 08:51:59 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 B320A12EAB0 for ; Wed, 21 Jun 2017 08:50:51 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id g40so116721350uaa.3 for ; Wed, 21 Jun 2017 08:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pIi9qnPVkGwYYT4WF7gg788Ru/7FDqk1gYzFpS+uySA=; b=ZIZMeK19uhVIY+SHXsejebKuZOAQ9VOilafXyXhckd/SIDjI5Gv6jOzv7B5dlYM2AQ RU8imN+cMwlk8DslUPAO9zFq7b3R3AEPlYjvB/kuGoJ/WYtcvnzPkDpTJQZ/39xLqvY4 iCJP6egzclEkgCHfvXwH553+DWC7uDXDbetGZUg7WcFONUMoAPJqOPEsLjljwDV5bsra lKyT0vM+4bFroEcPNqYZoxP1ZV7ncTrHXtStOGhMTmKPiLFJtw5lxtQOjOTBjdaEsqWG af9vTCtWRh0TipZUBtOBQoZsqb25ECZdJayWOH7Krg1cTg25CGKkINZEmA+PEciRFL0C n+qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pIi9qnPVkGwYYT4WF7gg788Ru/7FDqk1gYzFpS+uySA=; b=EdpI5EtywtACY3fdxwjEikOwI+wLG7MQrL/zKvojUCSeu0/ya3dh33YEyDuvz8XLEs W6bzOg6mXteCVBtrZTpiFgu2dRQoz/go4iSdGutkqVVFcl6OxbYRj9J2dR3hF6bGRHgU kiIRZYhKfvCMRCfR5XZ69mMASCHARTFSrKvIX7g47CgLorBhI56Bjb+NrlQ7LnuZSxms 1oyTONjDfzC1tVUWh7QeiMjQijGjBSf1+4B2r0Xybokn7+zCIIiuMrdDdKUEb313jQ5C JEwGlJOtXd2RruBFGYm/UW0v7cOqbjFxcs2916Wwf4gEde/49FIlti5tJn7aBvz2TP9J eFmg== X-Gm-Message-State: AKS2vOy29nXruJ5/yj14KTQH5KxEjt3ohlxW3LTSG59VRU3dSWWn8xkd 8ekdLrzIU6eZ5zJ9rpEuZkCA4JaROGo3 X-Received: by 10.176.3.212 with SMTP id 78mr9669768uau.20.1498060250540; Wed, 21 Jun 2017 08:50:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Wed, 21 Jun 2017 08:50:29 -0700 (PDT) In-Reply-To: <594A914F.1020403@foobar.org> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> <594A914F.1020403@foobar.org> From: Lorenzo Colitti Date: Thu, 22 Jun 2017 00:50:29 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Nick Hilliard Cc: Ca By , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05e17c16d39305527a55f0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:52:02 -0000 --94eb2c05e17c16d39305527a55f0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 12:31 AM, Nick Hilliard wrote: > 1. you are describing a specific and - despite the enormous numbers > involved - atypical use case. I don't see how you can possibly argue that the case is atypical given that 3GPP networks are where the majority of IPv6 hosts are. I don't get the impression that I'm alone in thinking that the > the sort of solutions required to fix the problems that cellular networks > run into with IPv6 assignment are different to the solutions required > for many other categories of ipv6 networks, and suspect that a good deal > of the angst going on in v6ops relates to cellular ipv6 deployment > viewpoints vs non cellular. > On the contrary, the /64-per-host model is so attractive that operators are starting to use it on non-celluar deployments as well. See draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflects the current state of a very large public wifi deployment. > 2. out of curiosity, i'd be interested to see the output of smart > application of a hash collision algorithm. Collision between what and what? You're looking for one random number in a sea of 2^64. --94eb2c05e17c16d39305527a55f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 12:31 AM, Nick Hilliard <nick@foobar.org> wrote:
1. you are de= scribing a specific and - despite the enormous numbers
involved - atypical use case.

I don't s= ee how you can possibly argue that the case is atypical given that 3GPP net= works are where the majority of IPv6 hosts are.

I don't get the impression t= hat I'm alone in thinking that the
the sort of solutions required to= fix the problems that cellular networks
run into with IPv6 assignment are different to the solutions required
for many other categories of ipv6 networks, and suspect that a good deal of the angst going on in v6ops relates to cellular ipv6 deployment
viewpoints vs non cellular.

On the cont= rary, the /64-per-host model is so attractive that operators are starting t= o use it on non-celluar deployments as well. See draft-ietf-v6ops-unique-ip= v6-prefix-per-host , which AIUI reflects the current state of a very large = public wifi deployment.
=C2=A0
2. out of curiosity, i'd be interested to see the = output of smart
application of a hash collision algorithm.

= Collision between what and what? You're looking for one random number i= n a sea of 2^64.=C2=A0
--94eb2c05e17c16d39305527a55f0-- From nobody Wed Jun 21 09:02:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71012EB60 for ; Wed, 21 Jun 2017 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrLiZHVYz8wG for ; Wed, 21 Jun 2017 09:01:57 -0700 (PDT) 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 ECEAB12EB35 for ; Wed, 21 Jun 2017 09:01:38 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v5LG1Ww7020686 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2017 17:01:32 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <594A985A.10009@foobar.org> Date: Wed, 21 Jun 2017 17:01:30 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: "ipv6@ietf.org" Subject: Re: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> <594A914F.1020403@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:02:00 -0000 Lorenzo Colitti wrote: > I don't see how you can possibly argue that the case is atypical given > that 3GPP networks are where the majority of IPv6 hosts are. atypical in terms of the number of deployments, not by host count of specific deployments. How many 3GPP networks are there in the world? How many other network deployments are there in the world? Once again: the sort of solutions required to fix the problems that cellular networks run into with IPv6 assignment are different to the solutions required for many other categories of ipv6 networks. > On the contrary, the /64-per-host model is so attractive that operators > are starting to use it on non-celluar deployments as well. See > draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflects the > current state of a very large public wifi deployment. "a" very large public wifi deployment. > Collision between what and what? You're looking for one random number in > a sea of 2^64. you're looking at the birthday paradox. The output from this can be surprising. Nick From nobody Wed Jun 21 09:03:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1B412EB35 for ; Wed, 21 Jun 2017 09:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLnpoAvq501p for ; Wed, 21 Jun 2017 09:03:04 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCEF12EC1E for ; Wed, 21 Jun 2017 09:02:49 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id 63so66175828ywr.0 for ; Wed, 21 Jun 2017 09:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KXKWGK0MCe4t0zcuWYToOL+qsuvcVcBMZKAYbM6sOb0=; b=SHPlIdvz0K1qsWAPKEKXKWfjgADeTcMUcGP0ZX4Fcb5ZKMYdP3rtERQsC5gvMvioP6 jAdmYzlRAGNuYyqlaIOz2K47b7/Ojhelw3KfMDVuVthkg9EXmdEmyippmIdsWekF1e/7 SM3fz0PDSFDiIMXsTZ+w9vvUS3r4KYweTFBIsk0kcxF8oxHC8vKwpbXEtc4X+lHRf3X/ d2IA1vPceCMrnqEoF3DLSjmG9+rGdyjje43YihJYS6fbd9WSilTp5F1q+Hyuo95O+Qf/ vQlt7guwjlE7+TqZxdm1p2GaflKtVa+pANrZUWtyAclaxF+26APLNjzpqaLZOd4cMAFn yucg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KXKWGK0MCe4t0zcuWYToOL+qsuvcVcBMZKAYbM6sOb0=; b=XCMRzJIsl4/xfsSGdja7BKWIg/FKDokHeE30SLb4gptGZLI+UnSuR7gmt21P5h0ECm 1R8pFLlPUzEn687/vURPLKX9sXr92E+o5TPFF4MWh5F8k7PQVaV7vD+3s/ndPITwE4YH 6GYGGOhCTnF5BfcIxAuEyb+H1OuuPdpStzndbrBJfFg7Mtyhyfui8DEEUDJrIPECwjpU t16HcKLmRJuDuBl0Zgs/CGk8LSUUe0Nr31k0tA9DdyK6uEpm+f2jUBPyHi9lqpekVgor PZqC968eQJmpLq7j/A8GhDbOdbTKymNRJ3XAKK07v1mdjzX9OL44HbShe4AnqF72cePn HR3A== X-Gm-Message-State: AKS2vOwjOQVL8w5XC/gkauYRLXX+gkTWNB6eG6joHkJOwsYHGwWpXAsK MlvVU7OEm/MbxX6J6TjQDqgnkEDkIQ== X-Received: by 10.129.89.9 with SMTP id n9mr2885424ywb.302.1498060967669; Wed, 21 Jun 2017 09:02:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.133 with HTTP; Wed, 21 Jun 2017 09:02:46 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Ca By Date: Wed, 21 Jun 2017 09:02:46 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Mark Smith , "ipv6@ietf.org" , "t.petch" Content-Type: multipart/alternative; boundary="001a11471a1ed48d8105527a7f3c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:03:07 -0000 --001a11471a1ed48d8105527a7f3c Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 7:04 AM, Tom Herbert wrote: > On Tue, Jun 20, 2017 at 9:31 PM, Mark Smith > wrote: > > Hi Tom, > > > > On 17 June 2017 at 01:06, Tom Herbert wrote: > >>> There's nothing actually wrong with security by obscurity as a defence > in > >>> depth measure. > >>> > >>> If you already prevent ICMPv4 echo requests inbound, you're using it. > As are > >>> zebras, giraffes, cheetahs and many (probaby all) armies around the > world, > >>> namely camouflage. > >>> > >> Mark, > >> > >> Zebras are still in the main diet of lions. Camouflage is not the same > >> thing as armor or weapons. Credit cards have long numbers that aren't > >> guessable, but that is little comfort every time I get a letter from a > >> merchant about a breach and how my number was stolen. > >> > > > > So what I think you're doing here is adding and mixing up threats, and > > then using those to evaluate the security measure. Once you do that, > > the measure may be completely ineffective and entirely inappropriate. > > > > The specific threat where large IIDs and random addresses is an > > effective mitigation is device discovery via brute force unsolicited > > packet probing. > > > > It is not going to be an effective mitigation to addresses discovery > > by somebody in a position to discover addresses by tapping the traffic > > flow, or somebody who can use service log entries that recorded > > service clients that connected to the service. They are different > > threats and require different mitigations, because large and random > > IIDs are not effective against them. > > > Right, that's exactly the crux of the argument that the measure is not > worth it. Address randomization is only effective against one form of > attack, but as you point out there are other ways an attacker can > accomplish the same goal of discovery. It might be worth it if we got > this mechanism for free, but dedicating half of the bits in the IP > address space to this one deterrent for a single narrow attack vector > is too high a price. > > Tom > > Tom, not worth it to an ILA booster, perhaps. TLDR version: As a network operator, the opportunity mitigate (make it more expensive for a hacker) a portion of the network level attacks is very "worth it" to network operators. Allow me to expound on the business and technology death spiral around the world of host network attack surface mitigation 1. The state of information security is horrible, especially network security. The industry is filled with charlatans using FUD to sell magic boxes that are a silver bullet against all manner of real and fake threats. This is frequently known unified threat management of defense in depth (TM) (spare me the link to military history) 2. The most pervasive and invasive form of snake oil is the inline stateful network firewall that will cloak your domain in invincibility from worms such as Wannacry / Nimbda / Slapper / Code Red / Shadow brokers (?) / Snowden (?) .... and other REAL named scars on our collective operational memory. 3. Stateful firewalls, just like NAT, break the e2e principle. Spare me the esoteric views about what e2e really means ... Firewalls break real things, and create the need for ALGs, and ALGs break... other things... and we get into robustness to fragile downward spiral 4. Network firewalls are impossible to scale, especially at 10s of millions of users ... there are technical and money issues. Yet, various large firewall vendors like to pitch to CxOs about terrible threats that are just around the corner, and only their firewall can solve it. What is a CxO to do? 5. The brokeness introduced by middle boxes has spun up multiple working groups and BoFs in the IETF (quic, dots, plus, ideas...) , so firewalls and related middleboxes remain good for the business of all those involved in the arms race . 6. I could provide you a list of public scenarios where network firewalls as well as end-point security measures have introduce major vulnerabilities, very often the infosec medicine is worse than the disease, they made the situation worse. 7. As a real person in a real network, i have been able to sidestep this complexity nose dive and grow my network with IPv6 /64 per host. I am hear to tell that story and how sparse addressing achieves many of the goals of limiting network viability of a host (make it more expensive for hackers) while re-instating the e2e principle (make it cheaper for me, and better for the internet) In summary, network level threat mitigation is very expensive because the network level threats mitigation is hard to do and there is money to be made by charlatans. Threats against the network stack are a huge cost to network operators (wannacry infections are expensive, firewalls are also expensive -- spare me about how patching is cheaper, you dont always have that option), while phishing and social engineering remains the real way hacking gets done. We are literally posed with (1, 10, 100) millions of dollars for network firewall gear to match every packet to a permitted session with DPI (blah blah blah) , or end point protection solution... mind you both network firewalls and end point solutions introduce very real high value vulnerabilities. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11471a1ed48d8105527a7f3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2017 at 7:04 AM, Tom Herbert <tom@herbertland.com> wrote:
On = Tue, Jun 20, 2017 at 9:31 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
> Hi Tom,
>
> On 17 June 2017 at 01:06, Tom Herbert <tom@herbertland.com> wrote:
>>> There's nothing actually wrong with security by obscurity = as a defence in
>>> depth measure.
>>>
>>> If you already prevent ICMPv4 echo requests inbound, you'r= e using it. As are
>>> zebras, giraffes, cheetahs and many (probaby all) armies aroun= d the world,
>>> namely camouflage.
>>>
>> Mark,
>>
>> Zebras are still in the main diet of lions. Camouflage is not the = same
>> thing as armor or weapons. Credit cards have long numbers that are= n't
>> guessable, but that is little comfort every time I get a letter fr= om a
>> merchant about a breach and how my number was stolen.
>>
>
> So what I think you're doing here is adding and mixing up threats,= and
> then using those to evaluate the security measure. Once you do that, > the measure may be completely ineffective and entirely inappropriate.<= br> >
> The specific threat where large IIDs and random addresses is an
> effective mitigation is device discovery via brute force unsolicited > packet probing.
>
> It is not going to be an effective mitigation to addresses discovery > by somebody in a position to discover addresses by tapping the traffic=
> flow, or somebody who can use service log entries that recorded
> service clients that connected to the service. They are different
> threats and require different mitigations, because large and random > IIDs are not effective against them.
>
Right, that's exactly the crux of the argument that the mea= sure is not
worth it. Address randomization is only effective against one form of
attack, but as you point out there are other ways=C2=A0 an attacker can
accomplish the same goal of discovery. It might be worth it if we got
this mechanism for free, but dedicating half of the bits in the IP
address space to this one deterrent for a single narrow attack vector
is too high a price.

Tom


Tom, not worth it to =C2=A0an ILA booster, perhaps.

TLDR version: As a network operator, the opportunity mitigate (make= it more expensive for a hacker) a portion of the network level attacks is = very "worth it" to network operators. =C2=A0

=
Allow me to expound on the business and technology death spiral around= the world of host network attack surface mitigation

1.=C2=A0 The state of information security is horrible, especially netwo= rk security.=C2=A0 The industry is filled with charlatans using FUD to sell= magic boxes that are a silver bullet against all manner of real and fake t= hreats.=C2=A0 This is frequently known unified threat management of defense= in depth (TM) (spare me the link to military history)

=
2.=C2=A0 The most pervasive and invasive form of snake oil is the inli= ne stateful network firewall that will cloak your domain in invincibility = =C2=A0from worms such as Wannacry / Nimbda / Slapper / Code Red / Shadow br= okers (?) / Snowden (?) =C2=A0.... and other REAL named scars on our collec= tive operational memory.

3. =C2=A0 Stateful firewa= lls, just like NAT, break the e2e principle.=C2=A0 Spare me the esoteric vi= ews about what e2e really means ... Firewalls break real things, and create= the need for ALGs, and ALGs break... other things... and we get into robus= tness to fragile downward spiral

4.=C2=A0 Network = firewalls are impossible to scale, especially at 10s of millions of users .= .. there are technical and money issues.=C2=A0 Yet, various large firewall = vendors =C2=A0like to pitch to CxOs about terrible threats that are just ar= ound the corner, and only their =C2=A0firewall can solve it.=C2=A0 What is = a CxO to do?

5.=C2=A0 The brokeness introduced by = middle boxes has spun up multiple working groups and BoFs in the IETF (quic= , dots, plus, ideas...) , so firewalls and related middleboxes remain good = for the business of all those involved in the arms race .

6.=C2=A0 I could provide you a list of public scenarios where netwo= rk firewalls as well as end-point security measures have introduce major vu= lnerabilities, very often the infosec medicine is worse than the disease, t= hey made the situation worse.

7.=C2=A0 As a real p= erson in a real network, i have been able to sidestep this complexity nose = dive and grow my network with IPv6 /64 per host. I am hear to tell that sto= ry and how sparse addressing achieves many of the goals of limiting network= viability of a host (make it more expensive for hackers) while re-instatin= g the e2e principle (make it cheaper for me, and better for the =C2=A0inter= net)

In summary, network level threat mitigation i= s very expensive because the network level threats mitigation is hard to do= and there is money to be made by charlatans.=C2=A0 Threats against the net= work stack are a huge cost to network operators (wannacry infections are ex= pensive, firewalls are also expensive -- spare me about how patching is che= aper, you dont always have that option), while phishing and social engineer= ing remains the real way hacking gets done.=C2=A0 We are literally posed wi= th (1, 10, 100) millions of dollars for network firewall gear to match ever= y packet to a permitted session with DPI (blah blah blah) , or end point pr= otection solution... mind you both network firewalls and end point solution= s introduce very real =C2=A0high value vulnerabilities.




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

--001a11471a1ed48d8105527a7f3c-- From nobody Wed Jun 21 09:18:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC0D128961 for ; Wed, 21 Jun 2017 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMVubIYJ3Keq for ; Wed, 21 Jun 2017 09:18:19 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927431276AF for ; Wed, 21 Jun 2017 09:18:19 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id v7so66366788ywc.2 for ; Wed, 21 Jun 2017 09:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0gHPfFhejFN8Rn/kNjzc6qF9ZRvWWJMcqQdGDQSOOz8=; b=S7X2hpYN/6MnN7xy8AZsbBN3xtbSgJlAYz+cHrXRfBhiIkj+KA6xBfr2fCGx9cnOfP TtVc96X3eaYHMTrM67r/gzNZFZQbhoH5fNKypCx3j/XQmf2+hixh6o+C/VYm7kii/OUn 3ukrDuPK+44Nwpza7cWLiPN6XFHS4kKKdFSP5WDnKf63oegvf7JUbEgi5uwBARpjWKIL BFaCdOdaiZtWm4B2rOxQY6QJRGrR7nGRFMoBXZsfWOZxQoBzzuEwA5fEM0JaNz0woNt7 5DI/nc2yoeFXWl377lx4KgcB4JjV2MbKdCmIKBhMfDdlkETn2xLOa+ReedLBn8QJTJmG Vb9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0gHPfFhejFN8Rn/kNjzc6qF9ZRvWWJMcqQdGDQSOOz8=; b=AsOSyW8Rm5oQSInFVNG0sJDdxsaqHYz5Hxva3YlUDGgmyOkA5794ujCEtTK9Ff+ttE J/H2aNMjXoA8BNAE58z12s6/Jad9JtEUIERgc39+u8h/XxovSV4dv0rKPwEY4DoFfbrW 59dOUuOZaUqeMYp0aEQjxYJV7LGGOQknBnpn58GrIhjo3D+5CU8Un/DJSbzlPVgLLNGx gVqt7DgAIIUqfFqBVl5+5XHF1XPUuPGD8nt8yG1Eb4w9LnSL9GJn6yhxGrZ/9p3oIRSl S7H70gz2XgNcIptYwt6G+MgD3DGD/OsUoMIZdhG9Y0WwjiSIA8Y/6zmCNZ7X+kojhDxJ Sjcw== X-Gm-Message-State: AKS2vOxHESNAbKV7Kemmp4Bnwce6MBK09R4nIwh/HpSOj8fohDvjpleu 9h/OPIKP8r6nuY+aQ0VWXQ/7TpPNJyVjrEQ= X-Received: by 10.129.80.193 with SMTP id e184mr28660030ywb.44.1498061898830; Wed, 21 Jun 2017 09:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.133 with HTTP; Wed, 21 Jun 2017 09:18:17 -0700 (PDT) In-Reply-To: <594A985A.10009@foobar.org> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> <594A914F.1020403@foobar.org> <594A985A.10009@foobar.org> From: Ca By Date: Wed, 21 Jun 2017 09:18:17 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Nick Hilliard Cc: Lorenzo Colitti , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a1147e4e254d9ff05527ab7bd" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:18:22 -0000 --001a1147e4e254d9ff05527ab7bd Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 9:01 AM, Nick Hilliard wrote: > Lorenzo Colitti wrote: > > I don't see how you can possibly argue that the case is atypical given > > that 3GPP networks are where the majority of IPv6 hosts are. > > atypical in terms of the number of deployments, not by host count of > specific deployments. How many 3GPP networks are there in the world? > How many other network deployments are there in the world? > > Once again: the sort of solutions required to fix the problems that > cellular networks run into with IPv6 assignment are different to the > solutions required for many other categories of ipv6 networks. > > > On the contrary, the /64-per-host model is so attractive that operators > > are starting to use it on non-celluar deployments as well. See > > draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflects the > > current state of a very large public wifi deployment. > > "a" very large public wifi deployment. > > > Collision between what and what? You're looking for one random number in > > a sea of 2^64. > > you're looking at the birthday paradox. The output from this can be > surprising. > > Nick > Nick, Dave Plonka has done a some work in this space, and he is uniquely positioned to have very good data https://www.akamai.com/us/en/multimedia/documents/technical-publication/entropy-ip-uncovering-structure-in-ipv6-addresses.pdf "5.6 Predicting IPv6 Client Prefixes The addresses in the sample client networks (C1-C5) extensively use pseudo-random interface identifiers, and thus there is no point in trying to guess the full address." > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1147e4e254d9ff05527ab7bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2017 at 9:01 AM, Nick Hilliard <nick@foobar.org><= /span> wrote:
Lorenzo Colitti wrote:
> I don't see how you can possibly argue that the case is atypical g= iven
> that 3GPP networks are where the majority of IPv6 hosts are.

atypical in terms of the number of deployments, not by host count of=
specific deployments.=C2=A0 How many 3GPP networks are there in the world?<= br> How many other network deployments are there in the world?

Once again: the sort of solutions required to fix the problems that
cellular networks run into with IPv6 assignment are = different to the
solutions required for many other categories of ipv6 networks.

> On the contrary, the /64-per-host model is so attractive that operator= s
> are starting to use it on non-celluar deployments as well. See
> draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflect= s the
> current state of a very large public wifi deployment.

"a" very large public wifi deployment.

> Collision between what and what? You'= ;re looking for one random number in
> a sea of 2^64.

you're looking at the birthday paradox.=C2=A0 The output from th= is can be
surprising.

Nick

Nick,=C2=A0
=
Dave Plonka has done a some work in this space, and he is un= iquely positioned to have very good data


"5.6 = Predicting IPv6 Client Prefixes
The addresses in the sample clien= t networks (C1-C5)
extensively use pseudo-random interface identi= fiers, and
thus there is no point in trying to guess the full add= ress."

=C2=A0

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

--001a1147e4e254d9ff05527ab7bd-- From nobody Wed Jun 21 09:20:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A648112EAEF for ; Wed, 21 Jun 2017 09:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evt8lUr-VhMn for ; Wed, 21 Jun 2017 09:20:42 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 6984E129C5D for ; Wed, 21 Jun 2017 09:20:42 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g40so117739199uaa.3 for ; Wed, 21 Jun 2017 09:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CGkKeHIc8Pangnz0cHXpW/n0l00aWJv8WVeiQlrZzr0=; b=dRGf0KkOzZHl+tUJ47VrUZCNwporupdf7+VTcAPRiychRxtUeslfJLECATzDQvZTfP hHkFwTDUNNBQy6nAXjfmjQZWXTukJeaQnvKXpCbDRaMxArnct1Z9shDy9+d9n7e5syuS YQKy+qbISmNLCnSRfHmpHTZBSVLFUNb8kQsF3/ca0I15TB6WZcydpOE26XB72+AThW4d ZuuN7pmHMWF7p1yVWoNu6VBOGmIQd7+X06Yn11WH/K4YojcHqQWKSWXDUz2jP3B5malk 1r+V/hWWbyrx2RHiUFg+bRddk8ICgISkmUZJwAzwNEHi0JBmBY2UV4BTxB0ayofYw7k4 XVtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CGkKeHIc8Pangnz0cHXpW/n0l00aWJv8WVeiQlrZzr0=; b=RHZRS2365nuPAurPRjdW98Xtp4z/9VRDIb6V2DGJQTg21tWLoz+ltu00AJNRA3xciX 7utVKREGYrXAIePhUJdP7bZIjsVhvou2kh6dN8t28S/hwbNzF0MxZwlApgCKcc7Vgd+J +RgxouUByZ1K8gtjVPN/d2xY77RPvs9arYDys3j/8z/uxejNnaXEjQPQuM2XNdrs7vuQ jUN2s1hEwYpp0rtfQPHKDWTavFBTwWmJtk3yHyFKM1Z0EYUqZQubL4H67Ky0HbyTHi99 zK2rLTQhsFOTFjOWssQ6/L+poh2tBNFA4JwWPzRE24yWAvUyJb1kcIwVWpfd/y+7i94N GG8w== X-Gm-Message-State: AKS2vOyn0CXsau258ybXWqm0Qm/CoYn1lpwSDL0TkvejKHUtPJiEiEBS wPt6t8SRCviHWJW/vy0ldPKkk6+TaAQLT1dVbA== X-Received: by 10.176.9.213 with SMTP id e21mr23195285uah.52.1498062041213; Wed, 21 Jun 2017 09:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Wed, 21 Jun 2017 09:20:20 -0700 (PDT) In-Reply-To: <594A985A.10009@foobar.org> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> <594A914F.1020403@foobar.org> <594A985A.10009@foobar.org> From: Lorenzo Colitti Date: Thu, 22 Jun 2017 01:20:20 +0900 Message-ID: Subject: Re: Tussles in IPv6 Land To: Nick Hilliard Cc: "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="f403043eeca8d2582305527abff4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:20:45 -0000 --f403043eeca8d2582305527abff4 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 1:01 AM, Nick Hilliard wrote: > > I don't see how you can possibly argue that the case is atypical given > > that 3GPP networks are where the majority of IPv6 hosts are. > > atypical in terms of the number of deployments, not by host count of > specific deployments. How many 3GPP networks are there in the world? > How many other network deployments are there in the world? > I see. So you're saying that because these networks are very common and widely used, the practices they use should be less influential less than ones that are less rarely-used? That argument rings pretty hollow to me. > Once again: the sort of solutions required to fix the problems that > cellular networks run into with IPv6 assignment are different to the > solutions required for many other categories of ipv6 networks. > Actually, they very well on other types of networks as well. Certainly if you decide to deploy on /120 subnets and DHCPv6, then you can't enjoy the benefits of those solutions (or of IPv6 in general really), but that doesn't mean that the solutions are different. It just means you chose not to use them. > > On the contrary, the /64-per-host model is so attractive that operators > > are starting to use it on non-celluar deployments as well. See > > draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflects the > > current state of a very large public wifi deployment. > > "a" very large public wifi deployment. > I'd suggest that the way to think of it as a model that others will follow, just like Cameron's network is a model that others have followed. > > Collision between what and what? You're looking for one random number in > > a sea of 2^64. > > you're looking at the birthday paradox. The output from this can be > surprising. > You're not looking at the birthday paradox at all. The birthday paradox would be applicable if you had lots of hosts on the network. Here you only have one, and given that the IIDs are random (yes, random - not RFC7217. I can point you at the code if you want), then the chance is one in 2^64 per attempt. --f403043eeca8d2582305527abff4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 1:01 AM, Nick Hilliard <nick@foobar.org> w= rote:
> I don't see how you can possibly argue that the case is aty= pical given
> that 3GPP networks are where the majority of IPv6 hosts are.

atypical in terms of the number of deployments, not by host count of=
specific deployments.=C2=A0 How many 3GPP networks are there in the world?<= br> How many other network deployments are there in the world?
=

I see. So you're saying that because these networks= are very common and widely used, the practices they use should be less inf= luential less than ones that are less rarely-used? That argument rings pret= ty hollow to me.
=C2=A0
Once again: the sort of solutions required to fix the problem= s that
cellular networks run into with IPv6 assignment are = different to the
solutions required for many other categories of ipv6 networks.

Actually, they very well on other types of n= etworks as well. Certainly if you decide to deploy on /120 subnets and DHCP= v6, then you can't enjoy the benefits of those solutions (or of IPv6 in= general really), but that doesn't mean that the solutions are differen= t. It just means you chose not to use them.
=C2=A0
> On the= contrary, the /64-per-host model is so attractive that operators
> are starting to use it on non-celluar deployments as well. See
> draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflect= s the
> current state of a very large public wifi deployment.

"a" very large public wifi deployment.

I'd suggest that the way to think of it as a model tha= t others will follow, just like Cameron's network is a model that other= s have followed.
=C2=A0
> Collision between what and what? = You're looking for one random number in
> a sea of 2^64.

you're looking at the birthday paradox.=C2=A0 The output from th= is can be
surprising.

You're not looking at t= he birthday paradox at all. The birthday paradox would be applicable if you= had lots of hosts on the network. Here you only have one, and given that t= he IIDs are random (yes, random - not RFC7217. I can point you at the code = if you want), then the chance is one in 2^64 per attempt.
--f403043eeca8d2582305527abff4-- From nobody Wed Jun 21 09:52:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A0F128C82 for ; Wed, 21 Jun 2017 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMy22JEMPzdM for ; Wed, 21 Jun 2017 09:52:47 -0700 (PDT) Received: from mta00.svc.cra.dublin.eircom.net (mta00.svc.cra.dublin.eircom.net [159.134.118.55]) by ietfa.amsl.com (Postfix) with SMTP id C088C128BB6 for ; Wed, 21 Jun 2017 09:52:46 -0700 (PDT) Received: (qmail 17491 messnum 12190085 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 21 Jun 2017 16:52:44 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (HELO avas01) (213.94.190.12) by mta00.svc.cra.dublin.eircom.net (qp 17491) with SMTP; 21 Jun 2017 16:52:44 -0000 Received: from [192.168.1.5] ([86.40.118.133]) by Cloudmark Gateway with SMTP id NirzdhVKZcTICNis0d6b73; Wed, 21 Jun 2017 17:52:44 +0100 X-CNFS-Analysis: v=2.2 cv=DPn/22Fb c=1 sm=1 tr=0 a=GiPPpUk0tzTpajBNWewD7A==:117 a=GiPPpUk0tzTpajBNWewD7A==:17 a=IkcTkHD0fZMA:10 a=a-SJ-uLkAAAA:8 a=cPp0QeKPkiqGO3tevbkA:9 a=QEXdDO2ut3YA:10 a=yc4HgI7j53qWSGAcJiko:22 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Tussles in IPv6 Land From: Ross Chandler In-Reply-To: <594A985A.10009@foobar.org> Date: Wed, 21 Jun 2017 17:52:43 +0100 Cc: "ipv6@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55324F81-FD45-4936-AA31-4F2BBDC59FAC@eircom.net> References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> <594A914F.1020403@foobar.org> <594A985A.10009@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfDElZCOEHZcGiSvTZ4NVqTzgYL3s/TiaBjaS3IetW+2MXSzk+ECy8RHCLqlu34JGdbAwKEeh3UO1xcvHRlHHhLE7S8QfJe6WJJEzquz4eSXTmkIalELS /VO959ZdR/NxhWTNTovaZoXc+2ZaUfUnO6jibGtCFQo/3TTv0Ao73WKiaCSkofwr4eyKUP45dTHepA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:52:49 -0000 > On 21 Jun 2017, at 17:01, Nick Hilliard wrote: >=20 >> On the contrary, the /64-per-host model is so attractive that = operators >> are starting to use it on non-celluar deployments as well. See >> draft-ietf-v6ops-unique-ipv6-prefix-per-host , which AIUI reflects = the >> current state of a very large public wifi deployment. >=20 > "a" very large public wifi deployment. There is a very small deployment of it Ireland and I=E2=80=99ve heard of = others elsewhere.=20 Ross= From nobody Wed Jun 21 09:57:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1B2128D8B for ; Wed, 21 Jun 2017 09:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZh-zPUS7_QT for ; Wed, 21 Jun 2017 09:57:06 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 9CC7A128CF0 for ; Wed, 21 Jun 2017 09:57:05 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id y25so103686315wrd.2 for ; Wed, 21 Jun 2017 09:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=son13AaAIdhV0bQTOHgU6XAnt/i1jmVT66AY32k2QqE=; b=XBVn7VDDli+5nMcZBMDEIKKmYzuqhg/h1FrZQavm2DSf+tCdJ7z7HfcEWMwOmmLUKM K5MrLkqjoBlXzxCYaWxhbmJhw3izCJX+R6xt9l+20lZFdbWT8teNlT1cemwCVf4f4OCH t3C03+bY7PlblJ8/vHwUHfCws9i7Z3vBlhad4tGXY4XuNmU7CLrqn01z1wtBlMCo0rs4 GiKhGnw1We4nx9fJRLKQ3Spp5TQ7THl7XPOqGiyYZVY3JVKdUeWcu1Z0hmQ/83L/gDYC Fagoae39DVVdkbf0GfNUlMT9QBsKjwFH/f2z+jpTQA7MeEJYGhhMkJcoFp+PE59W4dOn VD8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=son13AaAIdhV0bQTOHgU6XAnt/i1jmVT66AY32k2QqE=; b=bbOU8xcFezCmh/NY/noBuAaEuxNgk4Y/9lf0FCVqTw5rHQyJHKXj9NnrBBCE4M5fD5 0rAJVxIOy0m4A/vc/4eUx9QYoXG5mdiEeR6TfFbdpwkZsV6vrmPliuRwfK+E++X5w9Dw imlT1/cm1XeJx0LKWyC700sr9HodceZaPkOzpJ8zqr15qBqkGLmX8ogw8iq/1nXcQOfi T6xntJdrfP7i/TgaeAJYib9u7x1EcQK1Cqa6gAPM0UzRuxd9Ngb14JHi1eYTLNPZOe8R /LM6vFqD8ibUaM5wlNfsVFHyyuEHTYOBor4VjxFtYZ15KGLCRFVIhLyqHpp8q82hMOJC kTcg== X-Gm-Message-State: AKS2vOzgx4ie4l8SR9D9WG6kFnA5rhX73s7lDMrWfqAonjPDwx8qegM2 xDPVENY27vT6DjPCfGw1QT/N5Jgnz5K1 X-Received: by 10.28.87.72 with SMTP id l69mr6964598wmb.111.1498064223946; Wed, 21 Jun 2017 09:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Wed, 21 Jun 2017 09:57:02 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Tom Herbert Date: Wed, 21 Jun 2017 09:57:02 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Ca By Cc: Mark Smith , "ipv6@ietf.org" , "t.petch" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:57:11 -0000 On Wed, Jun 21, 2017 at 9:02 AM, Ca By wrote: > > > On Wed, Jun 21, 2017 at 7:04 AM, Tom Herbert wrote: >> >> On Tue, Jun 20, 2017 at 9:31 PM, Mark Smith >> wrote: >> > Hi Tom, >> > >> > On 17 June 2017 at 01:06, Tom Herbert wrote: >> >>> There's nothing actually wrong with security by obscurity as a defence >> >>> in >> >>> depth measure. >> >>> >> >>> If you already prevent ICMPv4 echo requests inbound, you're using it. >> >>> As are >> >>> zebras, giraffes, cheetahs and many (probaby all) armies around the >> >>> world, >> >>> namely camouflage. >> >>> >> >> Mark, >> >> >> >> Zebras are still in the main diet of lions. Camouflage is not the same >> >> thing as armor or weapons. Credit cards have long numbers that aren't >> >> guessable, but that is little comfort every time I get a letter from a >> >> merchant about a breach and how my number was stolen. >> >> >> > >> > So what I think you're doing here is adding and mixing up threats, and >> > then using those to evaluate the security measure. Once you do that, >> > the measure may be completely ineffective and entirely inappropriate. >> > >> > The specific threat where large IIDs and random addresses is an >> > effective mitigation is device discovery via brute force unsolicited >> > packet probing. >> > >> > It is not going to be an effective mitigation to addresses discovery >> > by somebody in a position to discover addresses by tapping the traffic >> > flow, or somebody who can use service log entries that recorded >> > service clients that connected to the service. They are different >> > threats and require different mitigations, because large and random >> > IIDs are not effective against them. >> > >> Right, that's exactly the crux of the argument that the measure is not >> worth it. Address randomization is only effective against one form of >> attack, but as you point out there are other ways an attacker can >> accomplish the same goal of discovery. It might be worth it if we got >> this mechanism for free, but dedicating half of the bits in the IP >> address space to this one deterrent for a single narrow attack vector >> is too high a price. >> >> Tom >> > > Tom, not worth it to an ILA booster, perhaps. > > TLDR version: As a network operator, the opportunity mitigate (make it more > expensive for a hacker) a portion of the network level attacks is very > "worth it" to network operators. > > Allow me to expound on the business and technology death spiral around the > world of host network attack surface mitigation > > 1. The state of information security is horrible, especially network > security. The industry is filled with charlatans using FUD to sell magic > boxes that are a silver bullet against all manner of real and fake threats. > This is frequently known unified threat management of defense in depth (TM) > (spare me the link to military history) > > 2. The most pervasive and invasive form of snake oil is the inline stateful > network firewall that will cloak your domain in invincibility from worms > such as Wannacry / Nimbda / Slapper / Code Red / Shadow brokers (?) / > Snowden (?) .... and other REAL named scars on our collective operational > memory. > > 3. Stateful firewalls, just like NAT, break the e2e principle. Spare me > the esoteric views about what e2e really means ... Firewalls break real > things, and create the need for ALGs, and ALGs break... other things... and > we get into robustness to fragile downward spiral > > 4. Network firewalls are impossible to scale, especially at 10s of millions > of users ... there are technical and money issues. Yet, various large > firewall vendors like to pitch to CxOs about terrible threats that are just > around the corner, and only their firewall can solve it. What is a CxO to > do? > > 5. The brokeness introduced by middle boxes has spun up multiple working > groups and BoFs in the IETF (quic, dots, plus, ideas...) , so firewalls and > related middleboxes remain good for the business of all those involved in > the arms race . > > 6. I could provide you a list of public scenarios where network firewalls > as well as end-point security measures have introduce major vulnerabilities, > very often the infosec medicine is worse than the disease, they made the > situation worse. > > 7. As a real person in a real network, i have been able to sidestep this > complexity nose dive and grow my network with IPv6 /64 per host. I am hear > to tell that story and how sparse addressing achieves many of the goals of > limiting network viability of a host (make it more expensive for hackers) > while re-instating the e2e principle (make it cheaper for me, and better for > the internet) > > In summary, network level threat mitigation is very expensive because the > network level threats mitigation is hard to do and there is money to be made > by charlatans. Threats against the network stack are a huge cost to network > operators (wannacry infections are expensive, firewalls are also expensive > -- spare me about how patching is cheaper, you dont always have that > option), while phishing and social engineering remains the real way hacking > gets done. We are literally posed with (1, 10, 100) millions of dollars for > network firewall gear to match every packet to a permitted session with DPI > (blah blah blah) , or end point protection solution... mind you both network > firewalls and end point solutions introduce very real high value > vulnerabilities. > Ca, You'll get no argument from me about stateful firewalls being state oil. But, it's not clear to me that IID randomization isn't expensive snake oil also. As I mentioned IP address are sent in the clear, so from a host perspective, the second we send a packet we need to assume our address is now known to the whole world. I cannot base a host security model in the premise that my network provider and every node in the path are going to keep my address secret. If a host wants secure communications the only answer right now is to encrypt with a sufficiently strong key. Another aspect of security with addresses that is popping up is device tracking. For instance, if a mobile device always uses the same device prefix then it's trivial to correlate connections of the device and possibly even its geo location. This is another motivation for address obfuscation, but randomizing just the IID portion of an address does nothing to prevent device tracking. More of the address needs to be obfuscated. I believe we are going to look at this problem in IDEAS. Tom > > > > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > From nobody Wed Jun 21 10:31:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6CF120725 for ; Wed, 21 Jun 2017 10:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7WboJ5T3MCl for ; Wed, 21 Jun 2017 10:31:49 -0700 (PDT) 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 3A32C1201FA for ; Wed, 21 Jun 2017 10:31:49 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.foobar.org (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v5LHVkZE031668 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2017 18:31:46 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.foobar.org Message-ID: <594AAD81.3010002@foobar.org> Date: Wed, 21 Jun 2017 18:31:45 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: "ipv6@ietf.org" Subject: Re: Tussles in IPv6 Land References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> <594A7AA4.6020403@foobar.org> <594A914F.1020403@foobar.org> <594A985A.10009@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:31:52 -0000 Lorenzo Colitti wrote: > I see. So you're saying that because these networks are very common and > widely used, the practices they use should be less influential less than > ones that are less rarely-used? That argument rings pretty hollow to me. No, what I'm saying is that the sort of solutions required to fix the problems that cellular networks run into with IPv6 assignment are different to the solutions required for many other categories of ipv6 networks. Say, did I mention that before? Nick From nobody Wed Jun 21 12:41:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5BF1241FC for ; Wed, 21 Jun 2017 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPDerX4ExhZr for ; Wed, 21 Jun 2017 12:41:07 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB121252BA for ; Wed, 21 Jun 2017 12:41:06 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id f192so49645257yba.2 for ; Wed, 21 Jun 2017 12:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WVreyh+1YgBePvot8UBEhIzCRLTN7cYeTYstNH33wCE=; b=VPmr8fzJELIbnkE5x7sxzOvTZgzAHwXfbTtKiAq+ru4VeaWviz4Qq5FPlCk5lEk7eB AtwLcdHdzh94HcSX3vDe0i7p1Gc6xDyzWUNkIGG6zzC9ssWxDL6JFFsYaLL9bgD1135p KTXFCrPcCw60YhdUGmTHYqvF/zloSKMYSbCC4aPN2j+zY2L+KUQOtI7cS7UlAS3gtZM+ WaTpVE4ElhPzRGS9jDe7va+B4KQacp0yeBbdL1KYL8jDixkTUULu8zZoEElz8KyNP2F5 Y39GKDK5iwaJxOlBu6vW5t+NT07CbrFeslbqxIdhHZg1xIB3MTC4Qowxh6JJT3EujTd4 qXRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WVreyh+1YgBePvot8UBEhIzCRLTN7cYeTYstNH33wCE=; b=bpCdV2X1s4foUwqyukokTd8A04sqNo2pUxQErwmeDqiU+MFdEbTj7duEir2RVJe2qM +s8Jp+ZNfmChJ7SpjKZc/E/T5NTBAxD8UfMNtdQIshh7n6CnMsVHYw/vGAbcyp80VZjN f/3OJF4eV0+Awvq4dAV/rIw5dbptIK1PVNWQMCdQ2TOK1wsNcGDXcjyreK38TAYUc4R3 rjRaHQQwnzbHmo/awvvais0cVwKAHajEAcnW723TqOEAhcCQRWkuor5Xh0QvzuaTqPa+ 7qwgIuil7Wnvp/Jekf2ahzh8CAqJmXlzebUUAwKiDBkaj96ker0IjRsBpDpr67OH6QlZ sqQA== X-Gm-Message-State: AKS2vOxGPW22L+2eJOm5Nv1sg/iVsiUukFpXhC1bxpg2BPVK3PtbfN/Y zTrSXPmL7kZvg9WZWbmA9CdBUNHyEosB X-Received: by 10.37.77.4 with SMTP id a4mr29219680ybb.2.1498074066169; Wed, 21 Jun 2017 12:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.133 with HTTP; Wed, 21 Jun 2017 12:41:05 -0700 (PDT) In-Reply-To: References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> <47C90BD2-87D8-4B80-9636-DF5EB57D51DB@employees.org> <7b829f31b7cf417aaee3a975c500659d@XCH15-06-11.nw.nos.boeing.com> <91ead6d3-c7c1-08e5-2cd2-eaee521146d8@gmail.com> <014401d2e684$0315d640$4001a8c0@gateway.2wire.net> From: Ca By Date: Wed, 21 Jun 2017 12:41:05 -0700 Message-ID: Subject: Re: Tussles in IPv6 Land To: Tom Herbert Cc: Mark Smith , "ipv6@ietf.org" , "t.petch" Content-Type: multipart/alternative; boundary="001a113c5a968fbdc405527d8ce2" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:41:10 -0000 --001a113c5a968fbdc405527d8ce2 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 9:57 AM, Tom Herbert wrote: > On Wed, Jun 21, 2017 at 9:02 AM, Ca By wrote: > > > > > > On Wed, Jun 21, 2017 at 7:04 AM, Tom Herbert > wrote: > >> > >> On Tue, Jun 20, 2017 at 9:31 PM, Mark Smith > >> wrote: > >> > Hi Tom, > >> > > >> > On 17 June 2017 at 01:06, Tom Herbert wrote: > >> >>> There's nothing actually wrong with security by obscurity as a > defence > >> >>> in > >> >>> depth measure. > >> >>> > >> >>> If you already prevent ICMPv4 echo requests inbound, you're using > it. > >> >>> As are > >> >>> zebras, giraffes, cheetahs and many (probaby all) armies around the > >> >>> world, > >> >>> namely camouflage. > >> >>> > >> >> Mark, > >> >> > >> >> Zebras are still in the main diet of lions. Camouflage is not the > same > >> >> thing as armor or weapons. Credit cards have long numbers that aren't > >> >> guessable, but that is little comfort every time I get a letter from > a > >> >> merchant about a breach and how my number was stolen. > >> >> > >> > > >> > So what I think you're doing here is adding and mixing up threats, and > >> > then using those to evaluate the security measure. Once you do that, > >> > the measure may be completely ineffective and entirely inappropriate. > >> > > >> > The specific threat where large IIDs and random addresses is an > >> > effective mitigation is device discovery via brute force unsolicited > >> > packet probing. > >> > > >> > It is not going to be an effective mitigation to addresses discovery > >> > by somebody in a position to discover addresses by tapping the traffic > >> > flow, or somebody who can use service log entries that recorded > >> > service clients that connected to the service. They are different > >> > threats and require different mitigations, because large and random > >> > IIDs are not effective against them. > >> > > >> Right, that's exactly the crux of the argument that the measure is not > >> worth it. Address randomization is only effective against one form of > >> attack, but as you point out there are other ways an attacker can > >> accomplish the same goal of discovery. It might be worth it if we got > >> this mechanism for free, but dedicating half of the bits in the IP > >> address space to this one deterrent for a single narrow attack vector > >> is too high a price. > >> > >> Tom > >> > > > > Tom, not worth it to an ILA booster, perhaps. > > > > TLDR version: As a network operator, the opportunity mitigate (make it > more > > expensive for a hacker) a portion of the network level attacks is very > > "worth it" to network operators. > > > > Allow me to expound on the business and technology death spiral around > the > > world of host network attack surface mitigation > > > > 1. The state of information security is horrible, especially network > > security. The industry is filled with charlatans using FUD to sell magic > > boxes that are a silver bullet against all manner of real and fake > threats. > > This is frequently known unified threat management of defense in depth > (TM) > > (spare me the link to military history) > > > > 2. The most pervasive and invasive form of snake oil is the inline > stateful > > network firewall that will cloak your domain in invincibility from worms > > such as Wannacry / Nimbda / Slapper / Code Red / Shadow brokers (?) / > > Snowden (?) .... and other REAL named scars on our collective > operational > > memory. > > > > 3. Stateful firewalls, just like NAT, break the e2e principle. Spare > me > > the esoteric views about what e2e really means ... Firewalls break real > > things, and create the need for ALGs, and ALGs break... other things... > and > > we get into robustness to fragile downward spiral > > > > 4. Network firewalls are impossible to scale, especially at 10s of > millions > > of users ... there are technical and money issues. Yet, various large > > firewall vendors like to pitch to CxOs about terrible threats that are > just > > around the corner, and only their firewall can solve it. What is a CxO > to > > do? > > > > 5. The brokeness introduced by middle boxes has spun up multiple working > > groups and BoFs in the IETF (quic, dots, plus, ideas...) , so firewalls > and > > related middleboxes remain good for the business of all those involved in > > the arms race . > > > > 6. I could provide you a list of public scenarios where network > firewalls > > as well as end-point security measures have introduce major > vulnerabilities, > > very often the infosec medicine is worse than the disease, they made the > > situation worse. > > > > 7. As a real person in a real network, i have been able to sidestep this > > complexity nose dive and grow my network with IPv6 /64 per host. I am > hear > > to tell that story and how sparse addressing achieves many of the goals > of > > limiting network viability of a host (make it more expensive for hackers) > > while re-instating the e2e principle (make it cheaper for me, and better > for > > the internet) > > > > In summary, network level threat mitigation is very expensive because the > > network level threats mitigation is hard to do and there is money to be > made > > by charlatans. Threats against the network stack are a huge cost to > network > > operators (wannacry infections are expensive, firewalls are also > expensive > > -- spare me about how patching is cheaper, you dont always have that > > option), while phishing and social engineering remains the real way > hacking > > gets done. We are literally posed with (1, 10, 100) millions of dollars > for > > network firewall gear to match every packet to a permitted session with > DPI > > (blah blah blah) , or end point protection solution... mind you both > network > > firewalls and end point solutions introduce very real high value > > vulnerabilities. > > > Ca, > > You'll get no argument from me about stateful firewalls being state > oil. But, it's not clear to me that IID randomization isn't expensive > snake oil also. > > As I mentioned IP address are sent in the clear, so from a host > perspective, the second we send a packet we need to assume our address > is now known to the whole world. I cannot base a host security model > On-path is a substantial attack surface reduction from the whole world. Just because it is not perfect , does not make it not useful / valuable. If fact, in infosec, nothing is perfect. We simply try to implement features that raise of cost of an attacker being successful. > in the premise that my network provider and every node in the path are > going to keep my address secret. If a host wants secure communications > the only answer right now is to encrypt with a sufficiently strong > key. > Agreed, encryption is a good tool for maintaining confidentiality of a message. This is different from reducing the attack surface / likelihood of attack / discoverability of the network stack, which is what 64 bits of entropy in the lower 64 is about. > Another aspect of security with addresses that is popping up is device > tracking. For instance, if a mobile device always uses the same device > prefix then it's trivial to correlate connections of the device and > possibly even its geo location. This is another motivation for address > obfuscation, but randomizing just the IID portion of an address does > nothing to prevent device tracking. More of the address needs to be > obfuscated. I believe we are going to look at this problem in IDEAS. > Agreed, device tracking may be an issue for some. In my particular deployment the first 64 seldom stays with a user for more than 24 hours since they detach and reattach to the network (move to wifi, lose signal, ...), causing a new first 64 bits to get assigned. The last 64 bits is generally pseudo-random. CB > > Tom > > > > > > > > > > > > > > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > --001a113c5a968fbdc405527d8ce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2017 at 9:57 AM, Tom Herbert <tom@herbertland.com> wrote:
On Wed, Jun 21, 2017 at 9:02 AM, Ca By <cb.list6@gmail.com> wrote:
>
>
> On Wed, Jun 21, 2017 at 7:04 AM, Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Tue, Jun 20, 2017 at 9:31 PM, Mark Smith <markzzzsmith@gmail.com>
>> wrote:
>> > Hi Tom,
>> >
>> > On 17 June 2017 at 01:06, Tom Herbert <tom@herbertland.com> wrote:
>> >>> There's nothing actually wrong with security by o= bscurity as a defence
>> >>> in
>> >>> depth measure.
>> >>>
>> >>> If you already prevent ICMPv4 echo requests inbound, = you're using it.
>> >>> As are
>> >>> zebras, giraffes, cheetahs and many (probaby all) arm= ies around the
>> >>> world,
>> >>> namely camouflage.
>> >>>
>> >> Mark,
>> >>
>> >> Zebras are still in the main diet of lions. Camouflage is= not the same
>> >> thing as armor or weapons. Credit cards have long numbers= that aren't
>> >> guessable, but that is little comfort every time I get a = letter from a
>> >> merchant about a breach and how my number was stolen.
>> >>
>> >
>> > So what I think you're doing here is adding and mixing up= threats, and
>> > then using those to evaluate the security measure. Once you d= o that,
>> > the measure may be completely ineffective and entirely inappr= opriate.
>> >
>> > The specific threat where large IIDs and random addresses is = an
>> > effective mitigation is device discovery via brute force unso= licited
>> > packet probing.
>> >
>> > It is not going to be an effective mitigation to addresses di= scovery
>> > by somebody in a position to discover addresses by tapping th= e traffic
>> > flow, or somebody who can use service log entries that record= ed
>> > service clients that connected to the service. They are diffe= rent
>> > threats and require different mitigations, because large and = random
>> > IIDs are not effective against them.
>> >
>> Right, that's exactly the crux of the argument that the measur= e is not
>> worth it. Address randomization is only effective against one form= of
>> attack, but as you point out there are other ways=C2=A0 an attacke= r can
>> accomplish the same goal of discovery. It might be worth it if we = got
>> this mechanism for free, but dedicating half of the bits in the IP=
>> address space to this one deterrent for a single narrow attack vec= tor
>> is too high a price.
>>
>> Tom
>>
>
> Tom, not worth it to=C2=A0 an ILA booster, perhaps.
>
> TLDR version: As a network operator, the opportunity mitigate (make it= more
> expensive for a hacker) a portion of the network level attacks is very=
> "worth it" to network operators.
>
> Allow me to expound on the business and technology death spiral around= the
> world of host network attack surface mitigation
>
> 1.=C2=A0 The state of information security is horrible, especially net= work
> security.=C2=A0 The industry is filled with charlatans using FUD to se= ll magic
> boxes that are a silver bullet against all manner of real and fake thr= eats.
> This is frequently known unified threat management of defense in depth= (TM)
> (spare me the link to military history)
>
> 2.=C2=A0 The most pervasive and invasive form of snake oil is the inli= ne stateful
> network firewall that will cloak your domain in invincibility=C2=A0 fr= om worms
> such as Wannacry / Nimbda / Slapper / Code Red / Shadow brokers (?) /<= br> > Snowden (?)=C2=A0 .... and other REAL named scars on our collective op= erational
> memory.
>
> 3.=C2=A0 =C2=A0Stateful firewalls, just like NAT, break the e2e princi= ple.=C2=A0 Spare me
> the esoteric views about what e2e really means ... Firewalls break rea= l
> things, and create the need for ALGs, and ALGs break... other things..= . and
> we get into robustness to fragile downward spiral
>
> 4.=C2=A0 Network firewalls are impossible to scale, especially at 10s = of millions
> of users ... there are technical and money issues.=C2=A0 Yet, various = large
> firewall vendors=C2=A0 like to pitch to CxOs about terrible threats th= at are just
> around the corner, and only their=C2=A0 firewall can solve it.=C2=A0 W= hat is a CxO to
> do?
>
> 5.=C2=A0 The brokeness introduced by middle boxes has spun up multiple= working
> groups and BoFs in the IETF (quic, dots, plus, ideas...) , so firewall= s and
> related middleboxes remain good for the business of all those involved= in
> the arms race .
>
> 6.=C2=A0 I could provide you a list of public scenarios where network = firewalls
> as well as end-point security measures have introduce major vulnerabil= ities,
> very often the infosec medicine is worse than the disease, they made t= he
> situation worse.
>
> 7.=C2=A0 As a real person in a real network, i have been able to sides= tep this
> complexity nose dive and grow my network with IPv6 /64 per host. I am = hear
> to tell that story and how sparse addressing achieves many of the goal= s of
> limiting network viability of a host (make it more expensive for hacke= rs)
> while re-instating the e2e principle (make it cheaper for me, and bett= er for
> the=C2=A0 internet)
>
> In summary, network level threat mitigation is very expensive because = the
> network level threats mitigation is hard to do and there is money to b= e made
> by charlatans.=C2=A0 Threats against the network stack are a huge cost= to network
> operators (wannacry infections are expensive, firewalls are also expen= sive
> -- spare me about how patching is cheaper, you dont always have that > option), while phishing and social engineering remains the real way ha= cking
> gets done.=C2=A0 We are literally posed with (1, 10, 100) millions of = dollars for
> network firewall gear to match every packet to a permitted session wit= h DPI
> (blah blah blah) , or end point protection solution... mind you both n= etwork
> firewalls and end point solutions introduce very real=C2=A0 high value=
> vulnerabilities.
>
Ca,

You'll get no argument from me about stateful firewalls being state
oil. But, it's not clear to me that IID randomization isn't expensi= ve
snake oil also.

As I mentioned IP address are sent in the clear, so from a host
perspective, the second we send a packet we need to assume our address
is now known to the whole world. I cannot base a host security model

On-path is a substantial attack surface reduc= tion from the whole world.=C2=A0 Just because it is not perfect , does not = make it not useful / valuable.=C2=A0 If fact, in infosec, nothing is perfec= t. We simply try to implement features that raise of cost of an attacker be= ing successful. =C2=A0
=C2=A0
in the premise that my network provider and every node in the path are
going to keep my address secret. If a host wants secure communications
the only answer right now is to encrypt with a sufficiently strong
key.

Agreed, encryption is a good tool = for maintaining confidentiality of a message.=C2=A0 This is different from = reducing the attack surface / likelihood of attack / discoverability =C2=A0= of the network stack, which is what =C2=A064 bits of entropy in the lower 6= 4 is about.


Another aspect of security with addresses that is popping up is device
tracking. For instance, if a mobile device always uses the same device
prefix then it's trivial to correlate connections of the device and
possibly even its geo location. This is another motivation for address
obfuscation, but randomizing just the IID portion of an address does
nothing to prevent device tracking. More of the address needs to be
obfuscated. I believe we are going to look at this problem in IDEAS.

Agreed, device tracking may be an issue for s= ome.=C2=A0 In my particular deployment the first 64 seldom stays with a use= r for more than 24 hours since they detach and reattach to the network (mov= e to wifi, lose signal, ...), causing a new first 64 bits to get assigned.= =C2=A0 The last 64 bits is generally pseudo-random.

CB=C2=A0

Tom





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

--001a113c5a968fbdc405527d8ce2-- From nobody Wed Jun 21 14:38:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB1A124B0A for ; Wed, 21 Jun 2017 14:38:05 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNG7f4NKHrk6 for ; Wed, 21 Jun 2017 14:38:04 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 10D85124217 for ; Wed, 21 Jun 2017 14:38:04 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id u62so62958804pgb.3 for ; Wed, 21 Jun 2017 14:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PlgGg4/2lsROtYnX/Ao8OPg8eMLi5FqC5P4K47ZQ0M8=; b=c9ee3jh8KW7FN2c4k68LHF8jEFi26a+pr2buqsJgnQ/KbyoKLvHvSg/XeBoBI5Yvt0 6sSXLUPFurofUWYAHP4yJLXCWXu6F+KQqSMF+FwL0fHtOiBS1krNLUD3aHo65r51u9Pt fvUcRS/Rr2nrwfFGllETjOebOXXDrpYkZ6J5SjVnZVZ5SdjItMSvvYBMHadgv6SoWbML QFaQHetgZcofp8NasiZB+cxMOq2CwKZWdG/gHi9ut3uToT+WuK4Hv8YKUo8WYo18Cb2J 3k1vdfQoAen8vaHQQ6Q9ebxuA5kUTDtaZXZ1O+9RyVWDdz31pO1U/gFE3GMBHd3BbAoh qv5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=PlgGg4/2lsROtYnX/Ao8OPg8eMLi5FqC5P4K47ZQ0M8=; b=glSshaJAtXr0EhqbWtnrFoYhKABL7wcMshnruEN3irteMxJd7yrt2MYWyavj/iwPi1 dvULfaiMzaHgsm763C2WHEtGhuEEN4gqjq2raz7KEGAa2rr8R4yQVjISsaRjHFd2ONLC ZlmKoBRtzDmgpBqaItgiXQWLlB9z+gPFXMnJGhcWQuCyDs2hYPGprF64BfJg2hFfCKlB tuElAEzMtFSYKcZt1H25QsYEbADMsqaGLDxSMOjjrMEaJtnIotnQaHiurLdK2fpvH4AB aZdcAiQWO2k9/vwOjZGNMxvQpAgEG1h3sS/b4T5AS9FXg1TJhHzQ4bmERxfNp31ClwQh DU5Q== X-Gm-Message-State: AKS2vOz8G2AXoDhW3Y0QCRBjOyPop+e+09TODc0+2g3WocupYP8bRixf DedRB2HC+s4oskhG X-Received: by 10.98.60.5 with SMTP id j5mr9929415pfa.56.1498081083367; Wed, 21 Jun 2017 14:38:03 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id p23sm34398249pfk.67.2017.06.21.14.38.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 14:38:02 -0700 (PDT) Subject: Re: To: ipv6@ietf.org References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> Date: Thu, 22 Jun 2017 09:38:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:38:06 -0000 On 21/06/2017 09:34, David Farmer wrote: > I think this is getting really close. However, there still seems to be an > implication that a subnet must be /64 or 64 bits for both address > generation and on-link determination. Yes, that's what it says, except for documented exceptions. As far as I understand the motivation of my co-authors on draft-bourbaki, their main objection to the previous rfc4291bis was that it didn't allow for those documented exceptions. Since SLAAC has always assumed that the two lengths are equal, I don't see any discrepancy between rfc4291bis-08 and reality, which is as it should be for an Internet Standard. Brian > > Subnetting (for IPv4) is discussed in a series of RFCs[1], culminating in > the Internet Standard Subnetting Procedure [RFC950]. The closest thing to > a definition for the term subnet comes in the overview for RFC950. Subnets > "are logically visible sub-sections of a single Internet network." However, > it seems clear that the term is equally important to two of the aspects we > are talking about, it is about both address generation and on-link > determination. > > If RFC4291bis is going to use the term subnet, it's use should either be > consistent with the meaning in RFC950, or it should be abundantly clear how > the use of the term differs from it's use in RFC950. There should be no > ambiguity, unless clearly stated otherwise, the term subnet means what it > means in RFC950. In fact let's be clear, the reason the term is being used > here is because of the comfort level that comes from the decades of use of > the term as derived from it's RFC950 meaning. > > Because the current use of the term "subnet" in RFC4291bis-08 doesn't seem > to distinguish between address generation and on-link determination, there > still seems to be an implication that a subnet must be /64, or 64 bits, for > both address generation and on-link determination. > > One possible way to break this improper implication, would be to qualify > the statement that Interface Identifiers are 64 bits long to address > generation and add to the note that for on-link determination prefixes and > IIDs can be any length. How about something like this; > > When generating an address, Interface Identifiers are required to be > > 64 bits long except if the first three bits of the address are 000, > > when addresses are manually configured, or by exceptions defined in > > standards track documents. The rationale for using 64 bit Interface > > Identifiers can be found in [RFC7421 > ]. An example of a standards > > track exception is [RFC6164 ] > that standardizes 127 bit prefixes on > > inter-router point-to-point links. > > > Note: In the case of on-link determination and as a result when > > a prefix length is provide with a manually configured address, the > > Prefix and Interface Identifier can be any length as long as they > > add up to 128, but are recommended to be 64 bits. > > > Also, based on the definition of subnet, in section 2.4.4 it seems critical > that m>=1. If it is not and m=0, then we can't be talking about /64 > subnets, we are talking about a /64 network. Therefore, "m" must be > greater than or equal to 1, for you to even be properly talking about the > term subnet in IPv6 addressing. Besides adding that point to this section, > a reference to RFC6177 seems appropriate too. > > Thanks > > David Farmer > > [1] RFC917, RFC925, RFC932, RFC936, RFC940 > https://tools.ietf.org/html/rfc917 > https://tools.ietf.org/html/rfc925 > https://tools.ietf.org/html/rfc932 > https://tools.ietf.org/html/rfc936 > https://tools.ietf.org/html/rfc940 > https://tools.ietf.org/html/rfc950 > > On Tue, Jun 20, 2017 at 7:14 AM, Bob Hinden wrote: > >> Hi, >> >> I published a new 6man w.g. version (-08) of the RFC4291bis draft. See >> links below. >> >> The summary of the changes are: >> >> o Added Note: to Section 2 that the term "prefix" is used in >> different contexts in IPv6: a prefix used by a routing >> protocol, a prefix used by a node to determine if another >> node is connected to the same link, and a prefix used to >> construct the complete address of a node. >> >> o Based on results of IETF last call and extensive w.g. list >> discussion, revised text to clarify that 64 bit Interface IDs >> are used except when the first three bits of the address are >> 000, or addresses are manually configured, or when defined by >> a standard track document. This text was moved from >> Section 2.4 and is now consolidated in Section 2.4.1. Also >> removed text in Section 2.4.4 relating to 64 bit Interface >> IDs. >> >> o Removed instruction to IANA fix error in Port Number >> assignment. IANA fixed the error on 4 March 2017. >> >> o Editorial changes. >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08 >> >> This is part of the project to move the core IPv6 specifications to >> Internet Standard. >> >> Thanks, >> Bob >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jun 21 15:04:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CF81292FC for ; Wed, 21 Jun 2017 15:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oEOmVni2iyb for ; Wed, 21 Jun 2017 15:04:41 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 7D2E2128B37 for ; Wed, 21 Jun 2017 15:04:41 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id f127so5870947pgc.0 for ; Wed, 21 Jun 2017 15:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BBYhaK2xr2IpOcRNkbz1kZVwhwU54H9kk4tzG7Nwl4g=; b=d3jw4Hyk3HjCIHpr0flR6WGZVgNOLVJ9vhVA001urwH53+VHN/I/7xKKluXObHjCPu h2HZpWQh+vvtjXmr4OJyZC+rfIQV6oxh22NjHougNKwUyvYV/wnLOcidlZSXbuxuVB8H U2zKAxTZYDPO4nJkLxMVVnpC6gpFNSHiYTVeeFV+ElA4eKSKyRrtDpWeINNLliI+BTVT vKANpqwKcSpvFZaNUvfjV72cIdSsQ3ekU1gNG4DQ3/Kbuy3viGbPDagks05YgQoH96s5 DJcdQpTj9GggyAvZ022XvTS8rR23DrNXHv9UlSVPaoOYsAhTJRyxmrvVDv2EpDa8UPXm rdBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BBYhaK2xr2IpOcRNkbz1kZVwhwU54H9kk4tzG7Nwl4g=; b=DiPXvXuBpNZgsWf1+sbHw5S1Q83LeZ8KQLiQGeqtRRe+u+MwDuG5mwPT8/7xnYAoEV oTu+AjQj+ozyQb37nDKCpQrSKdGO9j3QHZT6fqZfjRgeyzKMXDz4o49Bzi6cZDsE4Gqt LoCWxrs9ujNwlmCBaBFgteVntMVLIzMyf5gPFy+ykZYxj3N1lowxnOZ7mvdCp1xx4zdb AJ/t3dtBc6Nj7oj3zlCZOPuKWT6YX2shRXYp9k3syAwmrLbf6FTPTVNY/4TtB6PTljom crpgBwYNHGmdkwi+Lj4k5Co1J6/YZ2w+KZ3X/vp2hF4UhpuLUnQrr7Zwl6QElLlNlrcN MVHQ== X-Gm-Message-State: AKS2vOxgsCYLtjjf3GuLzznti3S1zeH96nlWgP9nmAxONjGGLb4rR9TA OTqEUHW5zzsnc0v2 X-Received: by 10.84.194.165 with SMTP id h34mr43424904pld.65.1498082680838; Wed, 21 Jun 2017 15:04:40 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:952e:51a8:2f03:40e9? ([2620:0:10e7:10:952e:51a8:2f03:40e9]) by smtp.gmail.com with ESMTPSA id t19sm9450374pfk.90.2017.06.21.15.04.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 15:04:38 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_85BA2F12-535D-4933-831A-41C8140FAA2E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 21 Jun 2017 15:04:37 -0700 In-Reply-To: <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> Cc: IPv6 List To: Bob Hinden References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:04:43 -0000 --Apple-Mail=_85BA2F12-535D-4933-831A-41C8140FAA2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 20, 2017, at 05:14, Bob Hinden wrote: >=20 > I published a new 6man w.g. version (-08) of the RFC4291bis draft. = See links below. These changes make some of the improvements I recommended in = > = but they leave a number of my criticisms unaddressed. It also introduces = what I believe are several complications that follow from its new = =E2=80=9Cnote" about interface identifiers in manually configured = addresses having any permissible length provided the prefix and the = identifier add up to 128 bits. I think there are specific requirements = for interface identifiers in RFC 4291 (and this -08 draft too) that are = worded as if they apply regardless of the mechanism used to assign and = configure them, e.g. uniqueness properties, and so on, that entail using = the same length for all interface identifiers for a given link type. = I=E2=80=99m not sure how that language can be interpreted properly if = manual configuration allows for interface identifiers of any arbitrary = length. --james woodyatt > --Apple-Mail=_85BA2F12-535D-4933-831A-41C8140FAA2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 20, 2017, at 05:14, Bob Hinden <bob.hinden@gmail.com> wrote:

I published a new 6man w.g. version (-08) of = the RFC4291bis draft.  See links below.

These changes make some of the = improvements I recommended in <https://mailarchive.ietf.org/arch/msg/ipv6/F_RWP3lNRXyHOCaY8uUG= -ejfwQo> but they leave a number of my criticisms unaddressed. It = also introduces what I believe are several complications that follow = from its new =E2=80=9Cnote" about interface identifiers in manually = configured addresses having any permissible length provided the prefix = and the identifier add up to 128 bits. I think there are specific = requirements for interface identifiers in RFC 4291 (and this -08 draft = too) that are worded as if they apply regardless of the mechanism used = to assign and configure them, e.g. uniqueness properties, and so on, = that entail using the same length for all interface identifiers for a = given link type. I=E2=80=99m not sure how that language can be = interpreted properly if manual configuration allows for interface = identifiers of any arbitrary length.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_85BA2F12-535D-4933-831A-41C8140FAA2E-- From nobody Wed Jun 21 17:28:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0823126DD9 for ; Wed, 21 Jun 2017 17:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j8cnRuJVrdP for ; Wed, 21 Jun 2017 17:28:50 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 8DB9A126E01 for ; Wed, 21 Jun 2017 17:28:50 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id j53so1313027uaa.2 for ; Wed, 21 Jun 2017 17:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=X7RdBvqHn2GcWMkg2zkHqNpvFPwoFUE17EgeyH3WlnI=; b=cLVXzmrT29U7190ky3d2KTUtwc0fIlkzVtZ6R9vHXREqdJRANto/v2y3Euurz8wW/I HBYC/uePChRbWOFzaGFpqrL9TjAg1MpdV0H0+eVPmZ8mX22ngrFFdthX4xqPFv92XIIf 7ZRVe2brvRnakiaimBQGcPZNydfJB7pIKQEg6uDzcM+Srmg2P9NcyQclgqt6HlpXZA3C TEcrgK2DFWZiEG0zayQQOUjsYCKDsabEia6cn10iGIG+7GXjPj7uMJkZTTbNlHSpzdjn WM2XIyZoBvtdqZQMT+pUJ6iErR3hM99jHslKB+OHNLgTq0sAcl/dCZsBUVbQQREzXwDe 0eWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=X7RdBvqHn2GcWMkg2zkHqNpvFPwoFUE17EgeyH3WlnI=; b=uNloklP+IH+wC/o6ASuHG9UQfDGcXnLFcH06jUaIBaAhbcXFDLldo772936RCYA5m7 VT0BCJdfR7jovk52Z6Bs+gA7s/NLSNhSYwxKQcRLB2veFyXqF3Ea5hHlaJplwk9uwq7H JD+f1S615UhJT6Bo33NzV/2fugHE6xNeqpsH3uz8WyFOb/yoheM6Hu/ZP1gN34AzNg7o ssfDp31yYUT8YkKdz1vsyklWjJHOfRXlnIDfjzYci3VVenjjJvGI9ai4jtPj08hV2GuE IpT8xW0KlgFExupFPXpNsa3yjGD/7R6wtmojIu04yW2XtIOl0kg2Cd6JFxbwNe2stk8c wHig== X-Gm-Message-State: AKS2vOwEDRaokRBA6ALmubU2+QUpLLSFI0xr0kIBYokm5CLFEdC3OvN7 f++9k0/upIaulwK+tJ9IGHGNhEkb+RK8 X-Received: by 10.176.67.98 with SMTP id k89mr10014761uak.103.1498091329546; Wed, 21 Jun 2017 17:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Wed, 21 Jun 2017 17:28:19 -0700 (PDT) From: Mark Smith Date: Thu, 22 Jun 2017 10:28:19 +1000 Message-ID: Subject: Mixing up threats, expecting a single perfect mitigation to all of them To: Nick Hilliard Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 00:28:52 -0000 You're doing the same thing Tom did. Changing, mixing up and adding threats, evaluating one specific measure against that set and declaring it useless because it didn't mitigate all of them. Again, this is a specific mitigation against a specific technique that has been used very successfully against IPv4, including by recent malware that was so successful at propagation and infection that it made the world wide main stream press ("WannaCry"), and impacted car factories, hospitals and other significant organisations. If large IPv6 IID with random values is "security snake oil", it might be the first "snake oil" ever that is effective against the threat it is intended to mitigate. "You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet" https://lab.dsst.io/slides/33c3/8061.html "If we cannot scan it, can we observe it?" https://lab.dsst.io/slides/33c3/slides/8061/10.jpg *** Just worked to prevent unsolicited packet scanning *** Another example. Shodan.io have made a business out of selling the ability to scan the IPv4 address space to discover devices. Did they try that approach with IPv6? No, they instead collected IPv6 addresses to probe by adding rogue NTP servers into the pool.ntp.org pools. https://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/ *** Just worked to prevent unsolicited packet scanning *** Note what I said in my original response, "So, in this context, if you're relying on not being discovered by packet probing, it's a single point of failure. However, if you have other measures in place, such as host based firewalls, authentication at the IP or higher layers, meaning transport or application layers, then obscurity adds another level of defence." I'm not and have never claimed that this is the only measure you need or that it is perfect at mitigating all threats, so please don't assert that I am. Bruce Schneier in his Beyond Fear book describes a number of security measure categories and principles: - defence in depth - compartmentalisation - prevention - detection and response - choke points Large random IIDs adds a level of depth to defence and is a prevention mechanism. He also points out that security is a weakest link problem. Scanning IPv4 addresses is a weak link that can be very successfully exploited, as demonstrated by the many have. Large random IIDs in IPv6 strengthens that specific weak link such that people have to go looking for others - the weak link has been moved, and the new weakest link is stronger than the previous one. As a security attack is a return on investment equation, when the ROI has been reduced by increasing the investment needed, it discourages the attacker from making the attack attempt. On 21 June 2017 at 23:54, Nick Hilliard wrote: > Mark Smith wrote: >> So what I think you're doing here is adding and mixing up threats, and >> then using those to evaluate the security measure. Once you do that, >> the measure may be completely ineffective and entirely inappropriate. >> >> The specific threat where large IIDs and random addresses is an >> effective mitigation is device discovery via brute force unsolicited >> packet probing. > > While you quote specific examples of how easy it is to scan the entire > ipv4 address space, you also omit to mention that scan + connect worm > behaviour is not how the lion's share of vulnerabilities are spread > these days, and also you don't mention that a single compromised device > on an ipv6 network is enough to be able to spread to all other devices > on the network due to being able to get other local addresses via ipv6 > LL traffic, ND and all that. There are multiple references to this on > the web which I'm not going to going to go to the effort of looking up > right now, but they exist and the problem is real. > > You also don't acknowledge that many hosts are dual-stacked and > compromise via ipv4 is just the same as compromise via ipv6, nor that > there are plenty of other mechanisms which provide name to address > mapping (dynamic dns, etc) or address lists (existing neighbor caches). > > So when you have: > > - single stack, ipv6 only > - scan + connect worm threat only > - no host level or network level firewalling > - all addresses fully randomised on network > - no other way of guessing addresses > - no way of trapping LL traffic > > ... it is true that large address spaces with truly random addressing > selection schemes can provide a modicum of security through obscurity. > > In pretty much all other situations, long mask lengths with random > addresses have no impact whatever on security. > > Nick From nobody Wed Jun 21 18:27:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40486129410 for ; Wed, 21 Jun 2017 18:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5eSfcRzNmml for ; Wed, 21 Jun 2017 18:27:07 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05677120721 for ; Wed, 21 Jun 2017 18:27:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5M1R6YV014630; Wed, 21 Jun 2017 18:27:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5M1R0Ai014188 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Jun 2017 18:27:00 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 21 Jun 2017 18:26:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 21 Jun 2017 18:26:59 -0700 From: "Manfredi, Albert E" To: Mark Smith CC: "ipv6@ietf.org" Subject: RE: Mixing up threats, expecting a single perfect mitigation to all of them Thread-Topic: Mixing up threats, expecting a single perfect mitigation to all of them Thread-Index: AQHS6u6QXgF54V4SJkGesxzHdEnKtaIwCCQA Date: Thu, 22 Jun 2017 01:26:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:27:09 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith > Again, this is a specific mitigation against a specific technique > that has been used very successfully against IPv4, including by > recent malware that was so successful at propagation and infection > that it made the world wide main stream press ("WannaCry"), and > impacted car factories, hospitals and other significant > organisations. Yes, and other vulnerabilities would have been and are exploited, if that o= ne didn't exist. I see the discussion swaying one way, and then the other, and then back aga= in, because there's no document that "tells it like it is." By which I mean= , gives both sides of all of the points - for and against a hard 64-bit bou= ndary. Perhaps the current Carpenter et al. draft might be a good vehicle f= or that, via a hopefully brief additional section. For example, explain that there are security arguments which favor maintain= ing an extremely sparsely populated IID in IPv6 networks. Explain how the o= ld criterion of 64-bit IIDs, populated with EUI-64, from RFC 2464, has *mor= phed into this new criterion* of sparse usage of the lower 64 bits. Explain= too that this is useful for SLAAC, when SLAAC uses random IIDs vs EUI-64. = Presumably, with EUI-64 IIDs, collisions would be even less likely than the= y might be with randomly selected IIDs. Then, mention how this now impacts the supposed vastness of IPv6 address sp= ace, reducing it, in essence, from 2^128 to 2^64. Explain that while there's no technical reason why SLAAC must use 64-bit II= Ds, having deprecated EUI-64 as IID, the 64-bit IID requirement for SLAAC r= emains primarily to mitigate a "race to the bottom." Since SLAAC is seen as= perhaps the most popular of plug and play address assignment technique in = IPv6, limiting its capability also limits the likelihood of other than /64 = subnets existing at all. In other words, educate the reader as to why such = SLAAC limitations are retained. Otherwise, the reader might wonder why not = allow 48-bit IIDs, or 40-bit IIDs? However, manual techniques can be used, = to create networks with longer than /64 prefixes. Mention how proponents of having /48s assigned to each device believe there= is no problem, but then mention how /48s are not common practice currently= . And how the vast address space would reduce even more, to something close= r to 2^48. Mention how 2^48 could be still be considered vast if applied to= people, but perhaps not so vast if applied to "things." (There are many mo= re "things" than people, after all.) Explain how the current practice of assigning individual /64s, when combine= d with the desire in some quarters to mandating 64-bit IIDs for all but ver= y few exceptions, makes it difficult to expand networks at the edges. For e= xample, a flat address space becomes mandatory, in any user-friendly expans= ion at the edges, unless more /64s can be obtained. In short, tell all. I don't think it takes all that much room, and it would= at least explain to the reader why these decisions were made. Bert From nobody Wed Jun 21 19:38:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AA612946B for ; Wed, 21 Jun 2017 19:38:01 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbmNSk247otb for ; Wed, 21 Jun 2017 19:37:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E43129422 for ; Wed, 21 Jun 2017 19:37:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 395C03494F2; Thu, 22 Jun 2017 02:37:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 25C38160053; Thu, 22 Jun 2017 02:37:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 11377160054; Thu, 22 Jun 2017 02:37:56 +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 H8-rJwN8Z8aw; Thu, 22 Jun 2017 02:37:55 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 98195160053; Thu, 22 Jun 2017 02:37:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DC8897C0BBE4; Thu, 22 Jun 2017 12:37:50 +1000 (AEST) To: "Manfredi, Albert E" Cc: Mark Smith , "ipv6@ietf.org" From: Mark Andrews References: Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them In-reply-to: Your message of "Thu, 22 Jun 2017 01:26:59 +0000." Date: Thu, 22 Jun 2017 12:37:50 +1000 Message-Id: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 02:38:01 -0000 In message , "M anfredi, Albert E" writes: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith > > > Again, this is a specific mitigation against a specific technique > > that has been used very successfully against IPv4, including by > > recent malware that was so successful at propagation and infection > > that it made the world wide main stream press ("WannaCry"), and > > impacted car factories, hospitals and other significant > > organisations. > > Yes, and other vulnerabilities would have been and are exploited, if that > one didn't exist. Ones that are less effective at discovering vulnerable hosts. > I see the discussion swaying one way, and then the other, and then back > again, because there's no document that "tells it like it is." By which I > mean, gives both sides of all of the points - for and against a hard > 64-bit boundary. Perhaps the current Carpenter et al. draft might be a > good vehicle for that, via a hopefully brief additional section. > > For example, explain that there are security arguments which favor > maintaining an extremely sparsely populated IID in IPv6 networks. Explain > how the old criterion of 64-bit IIDs, populated with EUI-64, from RFC > 2464, has *morphed into this new criterion* of sparse usage of the lower > 64 bits. Explain too that this is useful for SLAAC, when SLAAC uses > random IIDs vs EUI-64. Presumably, with EUI-64 IIDs, collisions would be > even less likely than they might be with randomly selected IIDs. Only if you intend to re-write history. From the very beginning you could take advantage of the sparseness of the /64. It was a known property. EUI-64 was only ever ONE WAY of selecting addresses and the limitation of that method against pure random addresses were discussed at the time. > Then, mention how this now impacts the supposed vastness of IPv6 address > space, reducing it, in essence, from 2^128 to 2^64. IPv6 has ALWAYS been 2^128 nodes in 2^64 subnets in 2^48 sites. There is no reducing going on. Only continued misunderstandings on your part. In IPv4 you have ~2^32 public addresses and a site count that is asymptoting to that value as more sites reduce down to single addresses with NAT. > Explain that while there's no technical reason why SLAAC must use 64-bit > IIDs, having deprecated EUI-64 as IID, the 64-bit IID requirement for > SLAAC remains primarily to mitigate a "race to the bottom." Since SLAAC > is seen as perhaps the most popular of plug and play address assignment > technique in IPv6, limiting its capability also limits the likelihood of > other than /64 subnets existing at all. In other words, educate the > reader as to why such SLAAC limitations are retained. Otherwise, the > reader might wonder why not allow 48-bit IIDs, or 40-bit IIDs? However, > manual techniques can be used, to create networks with longer than /64 > prefixes. There is a technical reason for choosing a single value. Hosts need to choose addresses in the absence of RAs. /64 was choosen after evaluating a number of different factors. Even with RAs which could in theory advertise a different value there are still reasons to not do this. > Mention how proponents of having /48s assigned to each device believe > there is no problem, but then mention how /48s are not common practice > currently. And how the vast address space would reduce even more, to > something closer to 2^48. Mention how 2^48 could be still be considered > vast if applied to people, but perhaps not so vast if applied to > "things." (There are many more "things" than people, after all.) No. It's assign each *site* (or potential site) a /48. The cell phones in a site border router. /48's *are* common practice other than for cell phones which haven't moved past the stop gap mechanism of giving each device a /64. > Explain how the current practice of assigning individual /64s, when > combined with the desire in some quarters to mandating 64-bit IIDs for > all but very few exceptions, makes it difficult to expand networks at the > edges. For example, a flat address space becomes mandatory, in any > user-friendly expansion at the edges, unless more /64s can be obtained. Explain how continuing to use stop gap mechanisms (every /64 to a site has been put in place as stop gap mechanism, this includes 3GPP) is preventing IPv6 from being used as it was designed to be used. > In short, tell all. I don't think it takes all that much room, and it > would at least explain to the reader why these decisions were made. > > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 21 20:24:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8E126CD6 for ; Wed, 21 Jun 2017 20:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AazVjjemiqtc for ; Wed, 21 Jun 2017 20:24:09 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75BE1292CE for ; Wed, 21 Jun 2017 20:24:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5M3O9OA019629; Wed, 21 Jun 2017 20:24:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5M3O1sm019622 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Jun 2017 20:24:01 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 21 Jun 2017 20:24:00 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 21 Jun 2017 20:24:00 -0700 From: "Manfredi, Albert E" To: Mark Andrews CC: "ipv6@ietf.org" Subject: RE: Mixing up threats, expecting a single perfect mitigation to all of them Thread-Topic: Mixing up threats, expecting a single perfect mitigation to all of them Thread-Index: AQHS6u6QXgF54V4SJkGesxzHdEnKtaIwCCQAgAAjLpGAAAPfAA== Date: Thu, 22 Jun 2017 03:24:00 +0000 Message-ID: <5897c410db564c4eb4bd6a56d6903e4e@XCH15-06-11.nw.nos.boeing.com> References: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> In-Reply-To: <20170622023750.DC8897C0BBE4@rock.dv.isc.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: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 03:24:12 -0000 -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 > From the very beginning you could take advantage of the > sparseness of the /64. Well, if the IID is made up of a MAC address and a fixed 16 bits, then that= 's what you have to use. The sparseness of that IID space is not quite so u= sable? > IPv6 has ALWAYS been 2^128 nodes Can't have it both ways. If the bottom 64 bit space has to be extremely spa= rsely used, then you have to quit the 2^128 node propaganda. You simply can= 't say both things at the same time. In effect, you have 2^64 maximum "node= s," with possibly a few more if you use schemes like RFC 7278 or manual con= figuration. > In IPv4 you have ~2^32 public addresses and a site count > that is asymptoting to that value as more sites reduce down > to single addresses with NAT. Yes, and IPv6 could do likewise. But perhaps we should also mention, we don= 't want to use NAT with IPv6. Or sure, we could have a truly gargantuan add= ress space, with /128s and an extra 16 bits with NAT. So I agree. Make sure= to include a goal of avoiding NAT, to fix the problem of inadequate flexib= ility for expansion at the edges. > There is a technical reason for choosing a single value. > Hosts need to choose addresses in the absence of RAs. Can't use SLAAC in the absence of RAs. Can only do link local, in the absen= ce of RAs. Link local is not what I was saying. I'm saying, most readers wo= uld wonder why an RFC would claim that fixed 64-bit IIDs are needed for SLA= AC, when it's not at all difficult to devise a more flexible SLAAC. So, exp= lain that while SLAAC with 48-bit IIDs, or what the heck even fewer, would = still work, we're using this limitation for *ulterior motives*. Nothing wro= ng with that. Just be up front. By mandating SLAAC with 64-bit IIDs only, u= ser-friendly address configuration will only work for /64s. That's the ulte= rior motive. > No. It's assign each *site* (or potential site) a /48. The > cell phones in a site border router. Not sure what you're saying. My cell phone will get a /48, if I'm on the go= ? My home router gets a /48? As many have indicated, that's not happening. = Not even /56s. So yes, the problem will go away if these things get /48s. B= ut that amounts to assuming the problem away. > Explain how continuing to use stop gap mechanisms (every /64 to > a site has been put in place as stop gap mechanism, this > includes 3GPP) is preventing IPv6 from being used as it was > designed to be used. Okay, I'll bite. Let's see a draft that claims that /64 assignments are a "= stop gap measure," and then provides a credible mechanism to mandate anythi= ng different. I see people making different unstated assumptions, and then coming to diff= erent conclusions based on those unstated assumptions. So, let's get those = unsated assumptions stated, clearly, and that will show why different peopl= e say different things. As things are now, I keep seeing contradictory stat= ements made. Bert From nobody Wed Jun 21 22:58:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B19126557 for ; Wed, 21 Jun 2017 22:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWznrcegpriL for ; Wed, 21 Jun 2017 22:58:13 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 1A7221200CF for ; Wed, 21 Jun 2017 22:58:13 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id r67so4138087ota.1 for ; Wed, 21 Jun 2017 22:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f9izGlZ+AJWcdC/tzpCUZSwPi8Sl6rZeMG9w2h50NX0=; b=kpAH+4qliJC9t8szguedzIrqLouvC6uOLfxoCZDkb9Fz2T9opfg3QXn2QDmV9M04YV 85hfZ3BERUBXdJEP3ZC5pfx8TYDMxijCtg7u0niIJUPOYn98SZxqvOr94Ntn4oBLTrcR rZTJcTs7R2iGUY6lk7xXYzJt6Cm0l8CxsO2qwbSS821ZxcHRc0MH3BPIcydr+01TLNPx TThX6uA+5dCiDpv7xFm5GrQKxi++4XuquBsEQfmzIbkwsUo/gIK+qyy05j727wJjTgJC lr56BPMpAowj+in2iqMLnO1OBd5/eKT/EManWxG7rbf4qvjNRuAy6cFuCY2zN6S+0PBe q/Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f9izGlZ+AJWcdC/tzpCUZSwPi8Sl6rZeMG9w2h50NX0=; b=mQisSGbatTnoUhnBVsbK8WTxFlPXkUNuiGg+W1xCMULvHSThPuyUo/Rd+t6jjtAq9M xcuGBGsbLREfJmbqsTKqp/u0SXSyVmwJcclZN8adduv3cRHU+78x2naDApdF8ocplRyn sO428i0VMxFB58+7U+g0gA31D8Q3J6gD9GP+NB1X2X+lPzGYXuk0EXP67M14HqnJiSGN ZlXrZX7KlFjfGULLN94OdzrKZ8R1TgThCfCg7V3sRq3IY5LKHoLtn65Ve2KvJc1Ivjzl HyeZZ/Fvay4coSQmF4utkqb9ZM7peeSZB/FHgrzN+DmmCZK9EYU4JUQd/JBd0l//cbn0 zHQQ== X-Gm-Message-State: AKS2vOywLdx3w+XdZD2UkCuwi5xa6DiBgXkCjrd1LXTNLifCp7laHwRS X+ZzhoLFzGktdQ== X-Received: by 10.157.66.18 with SMTP id q18mr473443ote.199.1498111092537; Wed, 21 Jun 2017 22:58:12 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1a2e? ([2600:8802:5600:1e::1a2e]) by smtp.gmail.com with ESMTPSA id c130sm280097oia.10.2017.06.21.22.58.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 22:58:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them From: Fred Baker In-Reply-To: <5897c410db564c4eb4bd6a56d6903e4e@XCH15-06-11.nw.nos.boeing.com> Date: Wed, 21 Jun 2017 22:58:09 -0700 Cc: Mark Andrews , "ipv6@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> <5897c410db564c4eb4bd6a56d6903e4e@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:58:14 -0000 > On Jun 21, 2017, at 8:24 PM, Manfredi, Albert E = wrote: >=20 > Well, if the IID is made up of a MAC address and a fixed 16 bits, then = that's what you have to use. The sparseness of that IID space is not = quite so usable? BTW, if we know it is a MAC address, and if we know anything about an = enterprise network, we can probably guess a small set of OUIs to think = about. It changes from probing 2^64 IIDs to probing N*2^24, where N is = the number of OUIs found in the network. Of course, one could pick a random 64 bit number. *could*.= From nobody Wed Jun 21 23:34:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65200129412 for ; Wed, 21 Jun 2017 23:34:25 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAi8tbYzhBGa for ; Wed, 21 Jun 2017 23:34:23 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 95B94128E19 for ; Wed, 21 Jun 2017 23:34:23 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id j53so6989699uaa.2 for ; Wed, 21 Jun 2017 23:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kg0LbTU8pMU/1ytNIqK72gmMf/8tlo/3rtu4Rozur5w=; b=r7yRldmdCLOxJN9sd4zNkC6cDKaPop5A1gb9KGNqx4wM9gz9mqw9bFZP7Z1LHHnYfK 3dOeikht4rRBtDMhRiNk5I8qIj8sqW8FQCm7X82Dx6LoKNyWIKcxzXjlzpAhsw+O355v +EraEM00zuQu59p5KDSgbJH+uEv+o9kwv+DFPH0VyyeBBcHd96ReBEsudgWMFjmFW8pC WunoMU7v/57CBBz9Zuy94XHYOgWHYL2TdrLVhB66qqmdjFqYS+gaaLURtCQZDBfwxJ0N /r/6MelQ5//wLRcNemA/va+1UNPkBzoJEeJHHoJx7yPJZ0MvMtp59Ze+OSnSCCf+LJTt 2hCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kg0LbTU8pMU/1ytNIqK72gmMf/8tlo/3rtu4Rozur5w=; b=ro/mSyPq2zViwEJSdIEvgarc35MnSpg0bH2fYIRI94Cm2dKkGK/MofmNE6hFhw7Rnt ribVtsmM5hzveXubVwjQa5Qm1u+i+k3c91ta/5aFlYFIZwA/RmoIlhhE03AlVpxkmi3q h/8l7IClAEFahsl/EDDi5FTivsaGbGd9WgLFdV2bD3p1lhxJBulPlYfIgv8zuh7an6AM 4o65v3KGDWmjGol2U+lO3YIvHAnm/8nzONa9GGbTo3qRjAgVuSKkeYxi+2ZfH4bQujPv L067WvWXD3Z0s2HIpq1HI5hVOTk9wST7wgI5Ib9ml/gOMx3mxT3tZvFxEnngkCQ7/juE GbHg== X-Gm-Message-State: AKS2vOwpE1WygERa/lh7/u/EqWm9KnFTmDQ4UoVctacYivFtVuzKl87h D/Iv/gHoX/VZ2F5xF9WWcDDB4cE0jG9A X-Received: by 10.176.17.26 with SMTP id e26mr992969uab.94.1498113262543; Wed, 21 Jun 2017 23:34:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Wed, 21 Jun 2017 23:34:02 -0700 (PDT) In-Reply-To: References: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> <5897c410db564c4eb4bd6a56d6903e4e@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 22 Jun 2017 15:34:02 +0900 Message-ID: Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: Fred Baker Cc: "Manfredi, Albert E" , "ipv6@ietf.org" , Mark Andrews Content-Type: multipart/alternative; boundary="f403045e3e36d94c7a055286ac98" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 06:34:25 -0000 --f403045e3e36d94c7a055286ac98 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 2:58 PM, Fred Baker wrote: > > Well, if the IID is made up of a MAC address and a fixed 16 bits, then > that's what you have to use. The sparseness of that IID space is not quite > so usable? > > BTW, if we know it is a MAC address, and if we know anything about an > enterprise network, we can probably guess a small set of OUIs to think > about. It changes from probing 2^64 IIDs to probing N*2^24, where N is the > number of OUIs found in the network. > Which is precisely why addressing schemes that embed stable MAC addresses are explicitly not recommended in current standards. --f403045e3e36d94c7a055286ac98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --f403045e3e36d94c7a055286ac98-- From nobody Thu Jun 22 03:25:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFA129353 for ; Thu, 22 Jun 2017 03:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55V-V66EGq0A for ; Thu, 22 Jun 2017 03:25:34 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD821292C5 for ; Thu, 22 Jun 2017 03:25:33 -0700 (PDT) Received: from h.hanazo.no (unknown [173.38.220.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 2B3E72D4FA5; Thu, 22 Jun 2017 10:25:32 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9EC1BD9C0741; Thu, 22 Jun 2017 12:25:33 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EAB02651-04D7-4EC1-94BB-6AC9F489DA19"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them Date: Thu, 22 Jun 2017 12:25:32 +0200 In-Reply-To: Cc: Mark Smith , 6man WG To: "Manfredi, Albert E" References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:25:36 -0000 --Apple-Mail=_EAB02651-04D7-4EC1-94BB-6AC9F489DA19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bert, >> Again, this is a specific mitigation against a specific technique >> that has been used very successfully against IPv4, including by >> recent malware that was so successful at propagation and infection >> that it made the world wide main stream press ("WannaCry"), and >> impacted car factories, hospitals and other significant >> organisations. >=20 > Yes, and other vulnerabilities would have been and are exploited, if = that one didn't exist. >=20 > I see the discussion swaying one way, and then the other, and then = back again, because there's no document that "tells it like it is." By = which I mean, gives both sides of all of the points - for and against a = hard 64-bit boundary. Perhaps the current Carpenter et al. draft might = be a good vehicle for that, via a hopefully brief additional section. >=20 > For example, explain that there are security arguments which favor = maintaining an extremely sparsely populated IID in IPv6 networks. = Explain how the old criterion of 64-bit IIDs, populated with EUI-64, = from RFC 2464, has *morphed into this new criterion* of sparse usage of = the lower 64 bits. Explain too that this is useful for SLAAC, when SLAAC = uses random IIDs vs EUI-64. Presumably, with EUI-64 IIDs, collisions = would be even less likely than they might be with randomly selected = IIDs. >=20 > Then, mention how this now impacts the supposed vastness of IPv6 = address space, reducing it, in essence, from 2^128 to 2^64. >=20 > Explain that while there's no technical reason why SLAAC must use = 64-bit IIDs, having deprecated EUI-64 as IID, the 64-bit IID requirement = for SLAAC remains primarily to mitigate a "race to the bottom." Since = SLAAC is seen as perhaps the most popular of plug and play address = assignment technique in IPv6, limiting its capability also limits the = likelihood of other than /64 subnets existing at all. In other words, = educate the reader as to why such SLAAC limitations are retained. = Otherwise, the reader might wonder why not allow 48-bit IIDs, or 40-bit = IIDs? However, manual techniques can be used, to create networks with = longer than /64 prefixes. >=20 > Mention how proponents of having /48s assigned to each device believe = there is no problem, but then mention how /48s are not common practice = currently. And how the vast address space would reduce even more, to = something closer to 2^48. Mention how 2^48 could be still be considered = vast if applied to people, but perhaps not so vast if applied to = "things." (There are many more "things" than people, after all.) >=20 > Explain how the current practice of assigning individual /64s, when = combined with the desire in some quarters to mandating 64-bit IIDs for = all but very few exceptions, makes it difficult to expand networks at = the edges. For example, a flat address space becomes mandatory, in any = user-friendly expansion at the edges, unless more /64s can be obtained. >=20 > In short, tell all. I don't think it takes all that much room, and it = would at least explain to the reader why these decisions were made. I also think writing up the sets of considerations and pros and cons in = a neutral language would be good. How far would that be from rfc7421 though? Ole --Apple-Mail=_EAB02651-04D7-4EC1-94BB-6AC9F489DA19 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZS5sdAAoJEL7aWKiYQt92xGcP/0+SDcK+mPYTr9/iA1IAnyGr TP9AcB2VZ4uC5ogg6KhdPTgKZI9wIej0RjyTP8lmLE6u0DSw9EMN/JPZXkTRNW8X 3iQn0qqnVxENT4s+NJ95F/xjI+GgYR0fR4lU6wbmDWx0WMADDD1NsZ4bfSTHXoRw mA/Z6txnzOgz/ACht67nGamrzQopPdtsyvu4721nK6sXZIXF48qARvCCbszHS2PZ F3tYRDjeDKVimBPwyqOUI2IQyFk7e3hMpNF7mu2pnsr9/Svsf/2ytOX9ToUwDCRv pByFZBFdwNQJmRr26+UtIlFyyXJ7D7wPzibQG3VAYzBOQTgGnScibKmBUJm42C7Z XvNYG1eqkVcqAM14Mf5gRrmCqlPy1fv8jF0EFfpCKjgdgrkLCLsaJz28fmdgBFvK mTAyfec9g3PtK0JJUu0Hm0rKLPGy+e6q3XG0+X2cX0gx3DE7FjFXWAcVDddlrc8n Sd9dQMwXBsFRyWTxLp06FsVxQjhU2QuWRXutlTWKSVFN3vgqj52XCWuQxYabJpxI GdjpWbOQbtCeHGP8URjJi0zasUPstJg9A1h/F7bNDcmC2MFuLtPpwOiVtol4dj8q m22wIWZ4KZucmy5QFXXz5/SnUGIR0aAPqf0hbv/BUYFEtLIlBPMm/bf8k2mqbBje 0RJ0PQEIGJXoIs/nXZY6 =6Zw2 -----END PGP SIGNATURE----- --Apple-Mail=_EAB02651-04D7-4EC1-94BB-6AC9F489DA19-- From nobody Thu Jun 22 03:35:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCAE128AB0 for ; Thu, 22 Jun 2017 03:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXYnZdYXtidJ for ; Thu, 22 Jun 2017 03:35:27 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 EDAD5127698 for ; Thu, 22 Jun 2017 03:35:26 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id i2so8248800qta.3 for ; Thu, 22 Jun 2017 03:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=21DwUJusltLM6cFU3q5cew38xya9WHLGqM8KTvepobY=; b=gMjKMfTsjGF1RwJbcdQgZLj8gPaSKmIbaKA61F9rdPybefbYYPh7Ogv56EfTHG60TI ay14Opq1BZw4jM+KHbafT23+x10mkdEkM71eeMq9DWCaJcEVYGfyHW82PgMQ69SG4bd3 EFfxNkV2baugRnq6L85QDSh3/LqLeXyngOZstEx8xTLeMHfe9+cuNdoDI80v3egfP7/m XYvaKjPrdea6eQQI+MmxgZ2qp+ByJ3WcTA6VzQuKJhNoLZrd5rnKuDPUg8AG/KS6NBnv mb2INwB+eKJLJssOS2KCgqSTqwOD3Qc4Jh5oS4tk6auLIow+ZZ7gHZuMIsSCL6ZCHvp0 89uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=21DwUJusltLM6cFU3q5cew38xya9WHLGqM8KTvepobY=; b=bg37+WEpUBkfEjaUGBvNAOaPiPsrPvQ5v8cLtImZoXkTYd/5JEMss30Ruzop+tEOTP MM0v2hM3FQi5/2UE5eHpwamJ2Ht+2UVWHv0dnp/763bvah8S6ZfhLhgF/8CUU4820075 m7UD1QSyIRwq9tU29va51e6SCjw/t/b8udVA0fJiChLtUlSp+oEqfhZDTZjKfyGOzSsT El3DBlcT1wl70aI4pIT67vYap/z6WkEpVM+QvoNlQt1pVXOTwaPtj5nsZe5CL6FppfkF BpyiZCDMWC2BfqzI8V2OCp+7web58pnUvuXOy6ftZYM+X4zBrIK9Bm51XoNJ7g8MAW/F 6PBw== X-Gm-Message-State: AKS2vOxGaJjANTCKFintGcQAxlRi9j03ejKR5H2+ZAVE6fO8Tn1HSs84 FY+H/Gi8efTXTd0iZYzNursvUkgp8g== X-Received: by 10.237.48.130 with SMTP id 2mr1924385qtf.17.1498127726113; Thu, 22 Jun 2017 03:35:26 -0700 (PDT) MIME-Version: 1.0 Sender: fgont.si6networks@gmail.com Received: by 10.237.42.193 with HTTP; Thu, 22 Jun 2017 03:35:25 -0700 (PDT) Received: by 10.237.42.193 with HTTP; Thu, 22 Jun 2017 03:35:25 -0700 (PDT) In-Reply-To: References: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> <5897c410db564c4eb4bd6a56d6903e4e@XCH15-06-11.nw.nos.boeing.com> From: Fernando Gont Date: Thu, 22 Jun 2017 12:35:25 +0200 X-Google-Sender-Auth: sFV-gNPdhx1Qjx4VMRz0ZJ3C0Ao Message-ID: Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: Fred Baker Cc: Mark Andrews , "Manfredi, Albert E" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0c7b14f176e705528a0a12" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:35:29 -0000 --94eb2c0c7b14f176e705528a0a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please see the scan6 tool from < https://www.si6networks.com/tools/ipv6toolkit> It implements an automatic/smary scanner. Thanks, Fernando El 22 jun. 2017 8:58 a. m., "Fred Baker" escribi=C3=B3: > > > On Jun 21, 2017, at 8:24 PM, Manfredi, Albert E < > albert.e.manfredi@boeing.com> wrote: > > > > Well, if the IID is made up of a MAC address and a fixed 16 bits, then > that's what you have to use. The sparseness of that IID space is not quit= e > so usable? > > BTW, if we know it is a MAC address, and if we know anything about an > enterprise network, we can probably guess a small set of OUIs to think > about. It changes from probing 2^64 IIDs to probing N*2^24, where N is th= e > number of OUIs found in the network. > > Of course, one could pick a random 64 bit number. *could*. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c0c7b14f176e705528a0a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see the scan6 tool from <https://www.si6networks.com/tools/ipv6t= oolkit>

It implements a= n automatic/smary scanner.

Thanks,
Fernando



=

E= l 22 jun. 2017 8:58 a. m., "Fred Baker" <fredbaker.ietf@gmail.com> escribi=C3=B3:

> On Jun 21, 2017, at 8:24 PM, Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote: >
> Well, if the IID is made up of a MAC address and a fixed 16 bits, then= that's what you have to use. The sparseness of that IID space is not q= uite so usable?

BTW, if we know it is a MAC address, and if we know anything about an enter= prise network, we can probably guess a small set of OUIs to think about. It= changes from probing 2^64 IIDs to probing N*2^24, where N is the number of= OUIs found in the network.

Of course, one could pick a random 64 bit number. *could*.
-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---
--94eb2c0c7b14f176e705528a0a12-- From nobody Thu Jun 22 08:48:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E767C126D05 for ; Thu, 22 Jun 2017 08:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruUfDTLgXUc8 for ; Thu, 22 Jun 2017 08:48:17 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 66A3B129A8D for ; Thu, 22 Jun 2017 08:48:17 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id k67so28679262wrc.2 for ; Thu, 22 Jun 2017 08:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8wNHXfy4XQEHB1A/hfVfudSwtjr+P153gD+EaDSQgK0=; b=mYqJrPQxf7pf+s3M+h/HG7CiyNAfzywb3iS3MJPmzjEMH1ccLd0O9TMZQ7esx6YBU5 l1Ci4a7geYQijcw5gIyvlO8xEx2QOdajdfmPf8xWK/yjGF7Z2Fq4LEOavHu+Il+WW5Qx cjdRCrIT8/xCGwmSIihEGH3KgTrzklmw25KHiA/+IqcuC0heynN9ii1T29IBQQmW2S9v bWAJw19GQQgE0UYB4ChzhXoPCw5J0Xhx7m/3VMXxseK4GqYmbD4cfcko9ujvBEh6qFyM RzzPxdHra2ymVH68Da2Z5HePcz+c3/2AavHxL54ZxK7pT4lMTI3bqad0JGmzIsVocQ+M N6bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8wNHXfy4XQEHB1A/hfVfudSwtjr+P153gD+EaDSQgK0=; b=Gk9mk1gYFV0b2x+oZbyqcBpjzDX7GS4G9nYyS2H+PxZizsngMfG/J3JNlFoE1yQdCt YUTWLRM2o3fcEvYFHYoEH8jeOPpjAPNCfYD+CsCQsqA2ftxLJ/rvmXQ9wQokpTcWFqnx iTx6M4jIelrXFGgaYorz4Y6SIjyYt/pAarZ2frkC1mxkITV3ox7UNgf03k9r4sQ02cnb jFSSYULb5Pf7tN9ilmA0u7VEDZFvHk5rZoaIrwRE3kQ6+BtlrxhU9jD0P5ZdTP807bu5 S9Y5yuVECImSU4S65xvH/bSTWXMuBPt0hJfCloCfBfkSg/y+q9bQaG1aAmCEQPhlVW/b w0aw== X-Gm-Message-State: AKS2vOy+KpwJslA5Tepqlj19pxP4KSzVjL4w09FKn0LxxbX0Df0gqB2m XCtx7n+mSrb9NgRbGlDzoS4yk2WkRedm X-Received: by 10.223.166.196 with SMTP id t62mr2397327wrc.52.1498146495700; Thu, 22 Jun 2017 08:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.2 with HTTP; Thu, 22 Jun 2017 08:48:15 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 22 Jun 2017 08:48:15 -0700 Message-ID: Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: Mark Smith Cc: Nick Hilliard , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 15:48:20 -0000 > Again, this is a specific mitigation against a specific technique that > has been used very successfully against IPv4, including by recent > malware that was so successful at propagation and infection that it > made the world wide main stream press ("WannaCry"), and impacted car > factories, hospitals and other significant organisations. > WannaCry keeps coming up as the example why address randomization is needed, so I'll ask the obvious question. If the world was all IPv6 and all IIDs were randomized, what would the effect had been? Would the attackers have just given up when they saw that scanning wasn't practical? Would they had just implemented an alternate method of discovery (maybe just snoop the network for addresses one they infected one machine)? Would this have completely avoided the attack, slowed propagation by some X%, or have had no material impact on success of the attack? > If large IPv6 IID with random values is "security snake oil", it might > be the first "snake oil" ever that is effective against the threat it > is intended to mitigate. > > "You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet" > https://lab.dsst.io/slides/33c3/8061.html > > "If we cannot scan it, can we observe it?" > https://lab.dsst.io/slides/33c3/slides/8061/10.jpg > > *** Just worked to prevent unsolicited packet scanning *** > > Another example. Shodan.io have made a business out of selling the > ability to scan the IPv4 address space to discover devices. Did they > try that approach with IPv6? No, they instead collected IPv6 addresses > to probe by adding rogue NTP servers into the pool.ntp.org pools. > So in other words, the attackers didn't give up because scanning was too hard, they just found a different way to perform discovery. Tom From nobody Thu Jun 22 09:22:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF68C126579 for ; Thu, 22 Jun 2017 09:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1aCDjLvs7eJ for ; Thu, 22 Jun 2017 09:22:45 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 8EBE7129ACD for ; Thu, 22 Jun 2017 09:22:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5MGMhjK020030 for ; Thu, 22 Jun 2017 18:22:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A02F22016AE for ; Thu, 22 Jun 2017 18:22:43 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 93F64201534 for ; Thu, 22 Jun 2017 18:22:43 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5MGMhjl005436 for ; Thu, 22 Jun 2017 18:22:43 +0200 Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: ipv6@ietf.org References: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: Date: Thu, 22 Jun 2017 18:22:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170622023750.DC8897C0BBE4@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:22:48 -0000 Le 22/06/2017 à 04:37, Mark Andrews a écrit : > > In message , "M > anfredi, Albert E" writes: >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith >> >>> Again, this is a specific mitigation against a specific technique >>> that has been used very successfully against IPv4, including by >>> recent malware that was so successful at propagation and infection >>> that it made the world wide main stream press ("WannaCry"), and >>> impacted car factories, hospitals and other significant >>> organisations. >> >> Yes, and other vulnerabilities would have been and are exploited, if that >> one didn't exist. > > Ones that are less effective at discovering vulnerable hosts. > >> I see the discussion swaying one way, and then the other, and then back >> again, because there's no document that "tells it like it is." By which I >> mean, gives both sides of all of the points - for and against a hard >> 64-bit boundary. Perhaps the current Carpenter et al. draft might be a >> good vehicle for that, via a hopefully brief additional section. >> >> For example, explain that there are security arguments which favor >> maintaining an extremely sparsely populated IID in IPv6 networks. Explain >> how the old criterion of 64-bit IIDs, populated with EUI-64, from RFC >> 2464, has *morphed into this new criterion* of sparse usage of the lower >> 64 bits. Explain too that this is useful for SLAAC, when SLAAC uses >> random IIDs vs EUI-64. Presumably, with EUI-64 IIDs, collisions would be >> even less likely than they might be with randomly selected IIDs. > > Only if you intend to re-write history. From the very beginning > you could take advantage of the sparseness of the /64. It was a > known property. EUI-64 was only ever ONE WAY of selecting addresses > and the limitation of that method against pure random addresses > were discussed at the time. > >> Then, mention how this now impacts the supposed vastness of IPv6 address >> space, reducing it, in essence, from 2^128 to 2^64. > > IPv6 has ALWAYS been 2^128 nodes in 2^64 subnets in 2^48 sites. No. That's classes again. Alex > There is no reducing going on. Only continued misunderstandings > on your part. > > In IPv4 you have ~2^32 public addresses and a site count that is > asymptoting to that value as more sites reduce down to single > addresses with NAT. > >> Explain that while there's no technical reason why SLAAC must use 64-bit >> IIDs, having deprecated EUI-64 as IID, the 64-bit IID requirement for >> SLAAC remains primarily to mitigate a "race to the bottom." Since SLAAC >> is seen as perhaps the most popular of plug and play address assignment >> technique in IPv6, limiting its capability also limits the likelihood of >> other than /64 subnets existing at all. In other words, educate the >> reader as to why such SLAAC limitations are retained. Otherwise, the >> reader might wonder why not allow 48-bit IIDs, or 40-bit IIDs? However, >> manual techniques can be used, to create networks with longer than /64 >> prefixes. > > There is a technical reason for choosing a single value. Hosts > need to choose addresses in the absence of RAs. /64 was choosen > after evaluating a number of different factors. Even with RAs which > could in theory advertise a different value there are still reasons > to not do this. > >> Mention how proponents of having /48s assigned to each device believe >> there is no problem, but then mention how /48s are not common practice >> currently. And how the vast address space would reduce even more, to >> something closer to 2^48. Mention how 2^48 could be still be considered >> vast if applied to people, but perhaps not so vast if applied to >> "things." (There are many more "things" than people, after all.) > > No. It's assign each *site* (or potential site) a /48. The cell > phones in a site border router. /48's *are* common practice other > than for cell phones which haven't moved past the stop gap mechanism > of giving each device a /64. > >> Explain how the current practice of assigning individual /64s, when >> combined with the desire in some quarters to mandating 64-bit IIDs for >> all but very few exceptions, makes it difficult to expand networks at the >> edges. For example, a flat address space becomes mandatory, in any >> user-friendly expansion at the edges, unless more /64s can be obtained. > > Explain how continuing to use stop gap mechanisms (every /64 to a > site has been put in place as stop gap mechanism, this includes > 3GPP) is preventing IPv6 from being used as it was designed to be > used. > >> In short, tell all. I don't think it takes all that much room, and it >> would at least explain to the reader why these decisions were made. >> >> Bert >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Thu Jun 22 09:48:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309AC129AF9 for ; Thu, 22 Jun 2017 09:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx0BFjChXjy7 for ; Thu, 22 Jun 2017 09:48:05 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 25165129AF4 for ; Thu, 22 Jun 2017 09:48:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5MGm3PF029005 for ; Thu, 22 Jun 2017 18:48:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7D675203DC9 for ; Thu, 22 Jun 2017 18:48:03 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7462E2020BC for ; Thu, 22 Jun 2017 18:48:03 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5MGm38b021981 for ; Thu, 22 Jun 2017 18:48:03 +0200 Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Thu, 22 Jun 2017 18:48:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:48:07 -0000 Le 22/06/2017 à 12:25, Ole Troan a écrit : > Bert, > >>> Again, this is a specific mitigation against a specific >>> technique that has been used very successfully against IPv4, >>> including by recent malware that was so successful at propagation >>> and infection that it made the world wide main stream press >>> ("WannaCry"), and impacted car factories, hospitals and other >>> significant organisations. >> >> Yes, and other vulnerabilities would have been and are exploited, >> if that one didn't exist. >> >> I see the discussion swaying one way, and then the other, and then >> back again, because there's no document that "tells it like it is." >> By which I mean, gives both sides of all of the points - for and >> against a hard 64-bit boundary. Perhaps the current Carpenter et >> al. draft might be a good vehicle for that, via a hopefully brief >> additional section. >> >> For example, explain that there are security arguments which favor >> maintaining an extremely sparsely populated IID in IPv6 networks. >> Explain how the old criterion of 64-bit IIDs, populated with >> EUI-64, from RFC 2464, has *morphed into this new criterion* of >> sparse usage of the lower 64 bits. Explain too that this is useful >> for SLAAC, when SLAAC uses random IIDs vs EUI-64. Presumably, with >> EUI-64 IIDs, collisions would be even less likely than they might >> be with randomly selected IIDs. >> >> Then, mention how this now impacts the supposed vastness of IPv6 >> address space, reducing it, in essence, from 2^128 to 2^64. >> >> Explain that while there's no technical reason why SLAAC must use >> 64-bit IIDs, having deprecated EUI-64 as IID, the 64-bit IID >> requirement for SLAAC remains primarily to mitigate a "race to the >> bottom." Since SLAAC is seen as perhaps the most popular of plug >> and play address assignment technique in IPv6, limiting its >> capability also limits the likelihood of other than /64 subnets >> existing at all. In other words, educate the reader as to why such >> SLAAC limitations are retained. Otherwise, the reader might wonder >> why not allow 48-bit IIDs, or 40-bit IIDs? However, manual >> techniques can be used, to create networks with longer than /64 >> prefixes. >> >> Mention how proponents of having /48s assigned to each device >> believe there is no problem, but then mention how /48s are not >> common practice currently. And how the vast address space would >> reduce even more, to something closer to 2^48. Mention how 2^48 >> could be still be considered vast if applied to people, but perhaps >> not so vast if applied to "things." (There are many more "things" >> than people, after all.) >> >> Explain how the current practice of assigning individual /64s, when >> combined with the desire in some quarters to mandating 64-bit IIDs >> for all but very few exceptions, makes it difficult to expand >> networks at the edges. For example, a flat address space becomes >> mandatory, in any user-friendly expansion at the edges, unless more >> /64s can be obtained. >> >> In short, tell all. I don't think it takes all that much room, and >> it would at least explain to the reader why these decisions were >> made. > > I also think writing up the sets of considerations and pros and cons > in a neutral language would be good. How far would that be from > rfc7421 though? I think rfc7421 "why64" does not describe this problem of growth at the edges in the presence of mandatory /64 and SLAAC, whereas it should. I think rfc7421 does not describe that on-link prefixes are practically the same thing as subnet prefixes (otherwise addresses are unreachable, or resolution conflicts may arise). One wouldnt appreciate a /63 prefix for onlink determination and a different /64 to form addresses there. While it talks about shorter IIDs it does not analyze how good it would be it the IIDlen were like 72 or so (more entropy; or good with /56 given by DHCPv6-PD rather than Prefix Exclude option, etc). An analysis of the analysis, performed by an expert neutral, concludes on the necessity of /64; I completely disagree - I myself didnt mean that when participating in that effort. So it would need to be clarified so that analysis analyzers read as intended by the writers. The why64 RFC does not tell that RFC4291 has an issue in fe80::/10 vs fe80::/64. So yes, I think there could be many things to be clarified along the lines of rfc7421. Alex > > Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 22 12:32:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBBD129B5E for ; Thu, 22 Jun 2017 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVCIg0Nlm0ju for ; Thu, 22 Jun 2017 12:32:21 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A990129ABE for ; Thu, 22 Jun 2017 12:32:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id CF12F1BC37 for ; Thu, 22 Jun 2017 19:32:14 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them From: Simon Hobson In-Reply-To: Date: Thu, 22 Jun 2017 20:32:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> References: To: ipv6@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 19:32:24 -0000 Alexandre Petrescu wrote: > I think rfc7421 does not describe that on-link prefixes are = practically > the same thing as subnet prefixes (otherwise addresses are = unreachable, > or resolution conflicts may arise). One wouldnt appreciate a /63 = prefix > for onlink determination and a different /64 to form addresses there. Isn't that mostly wrong - and such "imprecise" use of words part of the = problem ? As mentioned earlier, what is a "subnet prefix" ? Is it some imprecise = combination of IPv4 terminology and thinking with IPv6 ? Yes, it took me a long time to get my head around the concept of = "on-link" being more or less unrelated to "in the same prefix prefix" = (unlike the close coupling between address and subnet in IPv4). In the example you've given, it is actually quite feasible that the /64 = prefix given for forming addresses is not a collection of on-link = addresses - while some different /63 prefix does comprise on-link = addresses. It would be quite a contrived setup and I'm not sure what = technology might arrive at that, but it would be a valid setup from the = IPv6 PoV - perhaps some sort of wireless setup where direct = client-client communications is not possible/permitted, but direct = (on-link) communications between those clients and (say) some backend = stuff is permitted. From nobody Fri Jun 23 03:40:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2FC126BF6 for ; Fri, 23 Jun 2017 03:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHLZa997jv1Y for ; Fri, 23 Jun 2017 03:40:23 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0105.outbound.protection.outlook.com [104.47.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE1D1200ED for ; Fri, 23 Jun 2017 03:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GLTjaexUlHCRuB+VwEFDJUO0RFGnoCqZIC3E84xyj8c=; b=hdMHm8f1ZWUahkFwRsEKU2hvfsTCxdukmVkKca56FUwplf1Pwa1uwWNiGIkTLJe70OPD3n8Q4v9zbBUUdhZUcnhbY+MN50qkiEQPd5BoSjtN/qccX0Fk57pPkT/gLnrSO2rK15f0egcgD7JDsSjuR59W+iaATLHe85aFq2NNvJc= Authentication-Results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Fri, 23 Jun 2017 10:40:19 +0000 Message-ID: <022401d2ec0c$9b633ae0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Tom Herbert" , "Mark Smith" Cc: References: Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them Date: Fri, 23 Jun 2017 11:00:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: VI1PR0101CA0060.eurprd01.prod.exchangelabs.com (2603:10a6:800:1f::28) To DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) X-MS-Office365-Filtering-Correlation-Id: e32ed035-8aef-42af-5e9b-08d4ba243f08 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:DB6PR0701MB3000; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 3:RROFfLw4wyPMEOtwc4mv7PG5U0j46g+UT7JMws2uiNZUexs0HZgzpBcH8JXW0iDA9ac2kz0YX/WXcfgldNgFOm2v9Pe9Q+aZwAZ27Vt9wpYQtJYUtU6DCeE7PhcdxWdm8nG3FXjrZPYGHSG6JhS5abnXO68gXGhukpdpFvhuXI/W01Gi4okccmjTgPIyHPRbbnXjmQ8HDsS5LbkUn0F7fdDcSlZZmE4jtEDVeLSTCyU60F8Kb0TrzDyONIFoCJuWFfm2GKGLeqadWSLzGnDbmu9JpAoCDAMlRe1bbPyHjX278hfhhLOKAJTP8AxKq5FkR4m8ZpcbeFKx4B/blvx95g== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB6PR0701MB3000: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 25:2Gj5avwXTaayzPhob7Bgl8DP0seR+WKSeE1Hp9hyWN2uUzSsV70b9wXIZTwElTo/EVY7hxf8gFdaYmYcIeQjnXv8g+nwx5cKqM/uM98dUbgUU1B2BQv4/6L6IaGTLYPwP8L3UEQwMbNNqsPHadmtMaJQ5M0pwif8xL3+WrL8ShXuDfZRMxOyTe8s6pulQHINGDUmXj8VNN6RNI83hS3ALvBpd+DquXXWpycVod/Am87fqmbEnQ2LUAOe5Ds3VMtdNZlr15PFr57/LtuIAWvedH17r8lJ/T6YTvPv2eOn2NnJoU6qYFbuMwlx63AQ1qfPNn5V5R9s8+OaXdiI0JZoz2HrYPcCUYx4+7cjNVV/ZPm3SbGoEec75nCP+zyaCCBUx/EUvtn/7TVAmPUwrQR69xhO9c2N7pHlcolH6AntTtkKWw+xH2v/WSwyANrI/k7mkQoAOqZn/sdj59MQbCncS3NOuP8+MaF3+O520q/in/Yli/qQHC21HxmC1971W9DV7TlvebZOMTX+ggEXgviXvUJs3YEeNBpNJ1e/jQ2GIpi/HBBGX60W6xc3zPgH7jFYDsip8EvPyLFIcMwJ1xcnkLqbyHoujXLE4WoS2CIP24+mcarDKG7TWek5KA6jMfsQQOhUbVFtXsK9SiHtLtPGs7fvNDYnGBhIQfMfiGIiH5X2bowbOk2Bj1NwGV+9HvyglS74PyI43zWt8mOlUxMDbW2FuFX2bUEsoUScRzEYH/51UwnJgz/FZrLtzCYq3UY16auOS9VHdG1ADeQYoKe8DO5KCQWytvhSZ6QV58HW2NvcllYLvVzmpetHh1L1oJaJRbOVWdNwi2XwwyJdo5eqW11hnKVuKJ80QF+Yx4EDvSzHhZgqsvmIkniCsrOKIuZpMDPB+PjmD/Z7G2XmcVyD3uhSaoL/XVDxGfCDNXLJ0AE= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 31:p4H7VLMVYgPI3eQcDepRkWmpxKcrSPR7fq+G8rhh9L/o5DuyLBFwfT2/5JLa8yxLpi4PRNbAQuK4Dfj4jDl6ZcJ5gTCrm80o2C3dG+oBssiwE6sH1FUNaAerXXTyvYSumhPT8Vp4SVBMuDAl4KAJCrDAbvTp2vxvNQ5MMlanJ0LNLjXZ1hjP6vHrNUyRyed37dfgQ/aVqN+W+dt2qgjSLL+CKIPWpPVkp1LP3qOkyBziPo1oaemBp5OF2GzNBQM3/vz79f1qXCbHPvDc0e++whJHTb+knkr0ccvf/dI7L+MmU0oBEQZrpWVbcw2G7NmEeQXvkpB8Cq0/V4ERL/Mhcq0LwAbaDAwcE/4coGGpTcMJOWha5Qzg6KVoPHSPQMdSwN1gB96BG8k1FG1ahNy8YBllyMq2jMiSvxLqhYz3bAQ64rtc1PJVPR7TKh79QXBGoa43fy4wfzzASqDE8PQU2/iPzzH2DZDvG1S9tF8IhDx/L13t9XOMPkLmvneCdD0lVbO+CDVAbb1S7y6DizoAfodC1onc7WvMRHfPpw31leJH/AyXPH41CYH1pfh+nY4nJV6mJ74nctTuiz8t64LNWswdSFbyjmibaoRDmVJURonjBVmQ13CuI97YkZ+ruZAOHbQaaxWdIkfsEAp0H6WqMJqU+nr0CF54eitv/frj8egOL1FD7FTQy/bInFWq3cfmsA/WngKaxTLGpXF/rj85fw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB3000; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 4:tLPSxNxBJD+q5w6I0PPnm8zy4Q/vveS//IVyxj?= =?iso-8859-1?Q?CvEX/BbpjnawsJLBube5uUotp1jpk5ryw0a0DNy+Qc4XGd3hSbECEExrgD?= =?iso-8859-1?Q?lhA+m8jvUvIg+F8/DS9JHR4ACZBvvqyB0edjjgsUx2p3OAMU6tZ0hinwPp?= =?iso-8859-1?Q?Pp8+noLLOyeshCPRNChKeUIcymUpjdt7It6qcrE1R5YvYzS8esUSDc4fIl?= =?iso-8859-1?Q?guS7dTq5rSr7ugJcrYTNnpPrwTaKJR4Qs+Yz+lFs8dmTGUbGh+/bN8cV6d?= =?iso-8859-1?Q?7wSUKgUlVHKKgnjflibxMbM0d20XDs4zpslbTgc5aYtiMY4aSkmSXNB5iR?= =?iso-8859-1?Q?9JfaNNncPChp7iPQVJWs6n2TYSPlisk+gQPMnhnA+7zO6VZvkBLw/ghrRS?= =?iso-8859-1?Q?1iExQKKqh9zrNOpmvvUf/no+KeEgvfhWZ5QzrSjd/ruMZEVsBa5lhFod2T?= =?iso-8859-1?Q?G9vu+m3TcNubpn0Z6P2WKhCap8BBRsHI1x1Sjf0Gg9BkR6m9KfYEVCGBTq?= =?iso-8859-1?Q?MFmcAho6f0sm/Yym655TRz9/KOhD7j3pqxp7IyzmD2OcH8DkMhfuh4dOtT?= =?iso-8859-1?Q?QI4eHgBkaFvnzmfGBSTjTWlTtY++Icvx/9mL1yKZbOiFD7/fo94Cy3BJ6Q?= =?iso-8859-1?Q?x3GANo3VYc7QExBA61E5IvXpUtvbHIpyXmkrztTyzqy3sFe3vqJoT0WiyT?= =?iso-8859-1?Q?6CCFkez0XHlUO3HIvpqJV+mFfVsjgyHAOwRexKuuwC3KE/KCJinVHKstOq?= =?iso-8859-1?Q?pPZzkH8cvJkdJH4G+Pki8jtfNJGkwRKRrQ3yFjewZwDkSAbUGFr0jVn4RE?= =?iso-8859-1?Q?4wP1tT8qKNIzMEeSNgNV5wnFjW31c7QyPCjvjKErJl1ERHlsFRVzdqGu3J?= =?iso-8859-1?Q?Cd/25Byq5l/2EOaRGLgEyks6VB9Cth78TICAmsOcgxjFPEkYVAdsq+s9vy?= =?iso-8859-1?Q?w1zgS6OCjl+2sFdfSGbknJOB9nAjpY0mkenkB9e9DdWeUO03nTVywxnVcq?= =?iso-8859-1?Q?ZeY3Q5I1wNLrg2zTCnIGC4gjPx5NftPqcW+gwMhHCi11VDDSObEyd0iyvp?= =?iso-8859-1?Q?xVWBSVrudoIlFHqD1uo9E2PdZMT170yerPFsNDz7zh7dXpQ1f3NtEtwQEu?= =?iso-8859-1?Q?f3XXQrXuMwcyNKqOM1ZChklBFqIcFDUcstrCO3/Ku/kxkAwwsVEYjIjdks?= =?iso-8859-1?Q?iQ0KiQVM9xGCRcMgSmAUJdN/KbtNrWMDcVHjZitpuCqNU2AhbCAP7SSzFB?= =?iso-8859-1?Q?91xld6R/aV/GvCVGeZJQqpOscEqlvyBIKZP7WDqA=3D=3D?= X-Forefront-PRVS: 0347410860 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39850400002)(39840400002)(39400400002)(39410400002)(39450400003)(39860400002)(13464003)(377454003)(62236002)(1556002)(116806002)(8676002)(42186005)(6116002)(50226002)(81166006)(4720700003)(61296003)(7736002)(50466002)(6496005)(6486002)(81816999)(44736005)(4326008)(6666003)(86362001)(478600001)(33646002)(305945005)(6306002)(966005)(50986999)(1456003)(229853002)(23756003)(25786009)(14496001)(2906002)(84392002)(53936002)(44716002)(76176999)(81686999)(5660300001)(66066001)(38730400002)(6246003)(47776003)(189998001)(9686003)(3846002)(230700001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 23:6RWsLD7S8MlmHhoTuaHVVM7ExbajCKzsyInQM?= =?iso-8859-1?Q?qFP/1PcSSzUB+D4G/Fmvr7+0ZDlekm92vxXXwIKoDMy93b1RK14KdcP46U?= =?iso-8859-1?Q?UZtYGaSHfxi968B5bqE40G63RDNqXWP4RbACibWMooT9+QWjANBbAECQeV?= =?iso-8859-1?Q?IftfJYlteJM78uHdGMH1AmYyK0LRfD/imJhL5XPesxTS+CBYjcGUwt9uti?= =?iso-8859-1?Q?cI0zzcg4F7bbGdQx8hw3vsi0ayftOtGHfr10hHAa0ICLMAmjnnX0d+f3DX?= =?iso-8859-1?Q?XzqxAXWTmPnaZ2ibxOB6BbMYEVX7Yctzi2qliQ7OqBgoBdzHaFQ3ULv4st?= =?iso-8859-1?Q?rhcLkzCTSslXwlG+xCHSk6TJYClf7ckDUoF0iucJlPaWqIp+YfgVcEvWJF?= =?iso-8859-1?Q?F2uKn+vi359T9EFBkC1WN1/iM+LX2T35EpYc3g4ytDKZ/oYu0z+Lx/4GUn?= =?iso-8859-1?Q?TqEPO5hlmK6pLZKQAcd2JSKCC+lokHPUOOXYdGRlEMpe7Tvaud6xM6DIa6?= =?iso-8859-1?Q?WV1s0tQkAJeY9dFE72buayHFRWuoy9UAD2+d1472efC710K/2lB9+Kss7J?= =?iso-8859-1?Q?0wI5+k71Ge11Xbqc3VCIHevo0dIOSxf2yt4VqLR2gqEOMkcIWJ41cfAr+L?= =?iso-8859-1?Q?Fq2hGbSro6BzrqcQLQzyNAb+xpRH7gHI2hlJlJe0zvgh5alS+F7h2Wzklc?= =?iso-8859-1?Q?Y9NlhqsgxdrsnmWqrzZJNSz9j1td+fDhNJSuznsK4CrgnUjy1Zt45u7AYY?= =?iso-8859-1?Q?fKP+Q9NsHSImuLZIJZuIn1PVkArJOI6wkjelUMxUOigCqDWG63/P14gJq2?= =?iso-8859-1?Q?sMTlytadfBxfE6E7YEQCe7ddrcBXpXOALdm7EyRiuV4vxW6Tly3KOJ0qAm?= =?iso-8859-1?Q?pY8cwMKs0dkHevHr873XF+Y9XqlxxxbKIeuteANdGlNAm3kEyOM1RB5kVU?= =?iso-8859-1?Q?dptRHlfMB8kc5T7I//HGp6544gw2WCzojVE4rtKuGY4Dim3gDLiRcK/Ajp?= =?iso-8859-1?Q?I9tBRIJXSLXyrLgEpqArcGAMe4E/qXGs7JO4mihS5K23Zrp+wvX4D13KsP?= =?iso-8859-1?Q?vUuLqSqPO1JpphyUFUjfA2g3NlhtetbnYpvqw+BV0umiagKMztp4IBeKM8?= =?iso-8859-1?Q?iNaOSo3IWO8n5z5/5h+82yAok47Hy1lOsNdElK/5n+E69BspGo2BXXpxsY?= =?iso-8859-1?Q?/vPWnnGjTNxan3Xf7vmcwiORY4eGolivRKoFGwL9k0DZCAuaxoPocdG+yj?= =?iso-8859-1?Q?jMf8cd9TRmFuAshk1PtfscFpyi0/Dfg+2W4erid2h1WC1qPR0/zooI+5uK?= =?iso-8859-1?Q?0nhocyCwYVIse7644yaODEwdH0XBAtQS0JyslPOh91GuSycicH2AcJpSdv?= =?iso-8859-1?Q?A+ZBVkpk31wdB7vEKbDNFqg+QBh4EDODJrANdzBe+PswFbdFE3UR52xbDM?= =?iso-8859-1?Q?lXmZf+L2u/C1zlac=3D?= X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 6:5ofhRE/9Kd2Mcmyeuwcu8ss2qhMIl/UOVUmJ+v?= =?iso-8859-1?Q?nxew0/GOjjwWNjti+JcnxCnsanI5lzM8pdB36LOGyZ3TuVoOqDD/nNVSNw?= =?iso-8859-1?Q?BLX/10MBKf/kExq23UW3OvNKV/HUSYZNmUgY75cdF2fKVnlOr8T42/Qj4O?= =?iso-8859-1?Q?yq8ut+2k2ip/UeXVHGeFx0sjwBlKH05wgPtESCCdCDNdN1IYfMsFEahZFQ?= =?iso-8859-1?Q?J6FAFawVG5kE1Vqal6tHdPdzDrMo2kUyUtiWftWS4q4WEL5DNfV9dzyaiY?= =?iso-8859-1?Q?ha3KXmOQzsVCAf3AptUpN2wnD88JkW0sqKTxKl8L/SwvpfP30H5GYRwmhB?= =?iso-8859-1?Q?e1+w/pae7UcNLZcSm3kOUVx05fGpgcuRrWy7d5HeeHocSp+dMwIqQdW6l4?= =?iso-8859-1?Q?sM9kEsneY/k3W+MT98XZH4yFCH0d3imJOJNuC/QvvY9iirkWTzY+QqmonU?= =?iso-8859-1?Q?WTETz497ijlqthpvpFJyAgX42CdgwIIq8JUUl9605YPrO3dWM77aTKZxjt?= =?iso-8859-1?Q?JxBJdFDfh6BAhWAUyQL0+38PNgc1nnjhtbO3RY7OjZldKjCl+wsSPVsbK/?= =?iso-8859-1?Q?2IcQZ0Z1mGRrzM9oDRLrKJhRuYzUF5xrIf9iYfUv//DAlJfO5F6F+zdjSD?= =?iso-8859-1?Q?6EL4v9zEnoQrk/kgcFBvFggUu4uk6rEF/oiPgtUXn1RBYNcmVVp1jdX2l6?= =?iso-8859-1?Q?QmjR7jlEVlEaK50MaUVPa7n62J/sRmINj0YrEw24ZPDcQzl+CvlmHQgPEz?= =?iso-8859-1?Q?JDUm/alSGTGjAhpGgLREJJP9HniWZGyE5BIFHZDlnZXebG8gYKGh6835hS?= =?iso-8859-1?Q?lBOUnO9wJ9MoqwPAitB6Y9jHgaeP9du7RSw9LftGQbcWq9osiJfi0tqYZK?= =?iso-8859-1?Q?SyOjx5d3b75Ghnijta7ZVkMvSxsjrfP9p2YczhRhIM6YIYjn60kWRQZQVq?= =?iso-8859-1?Q?NvTv4lh6buvuKUrhO0eHKtvNHpgWf/EJaM6JdwK+FEPWJD/wiKIez//vw+?= =?iso-8859-1?Q?719Im3hofshaV6wcN8Vfzp5uo7cy1bmxDW0sc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 5:0875e4I3KXZAOzpdyHwdvQgARa6L3u6wJpA1epzL7UvGTkwM1AgMhAIaMkFajwTREY+A4IyJr+gMUhsozQ1qvkENok5L8/krbKR5vhzORGVmLKlXCZ2CibxrjthYziVM3jp4B7Pv6KJYZOKdBteY1lrXaegeqUwka1oCPl5Vd4Ohr1tHpjHjcDji7aU000yK2UF1s2Gck59fTnAx8W2dtZsvqzM2wlZIHzcZ+SVRElJSbP9homIRHao4mLJIGQXL99NHN+GpmMWyw4M7ARjjLy35LRGQ9NiGe/b6IIrDIaF6UBJKpVAPAFLbkchDL4uzwQW8DQ/Bfn0ZHDB1BjPCPEuUZ6BEfhR2ZzJAi2dvS5zCU8hxg8O/59IjPa1Aj0qpWYIaiZmAyrR5lug2SZY0QOCtmfbnSY3hB7zcqqVs0A/nrYBKbr05WImKa2ldax3Rpwde293yhARpJzvVVQ88ThvxnlCI4xROtoFJOh/MM8gauFhxXHGAl1DHyBRsYWah; 24:M3Nryj6Or5d8Jo1W0UwkVqpKd2F1L8uZaxa7K1ooULZ87xBpzqv769bxnIzD1crafg0HiQ3/OxbIT2xabu8UqovFdbGcSlPCWKVisNp++os= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 7:Vehg8Q2thiBlUMNIIQ0Zw+568Lx4Q78PsIrR0Jo8Ol0N8tOmSfn2SfpZ3mXv2xwtsHUDVuKpLvYZr7OLFu4odKvuoFcEyKGDvXAuxQNor9V/M6ODYg4kk95WvN342A9icEAFDOd5vXVLfSK6xDiObntjqt2ZywAdhmmbwRZye277QKtKIdSW1KtfdAsQC3ArWtiyo87+94G+EOAWTWblvFSrXBgKH958RXGCy3l4V/mQoa9uq+RkAhcI0u+jeMm00SS2hu4WgPWnkZChV7jMKtC2kiXSq4pZMjK3IFFUDGpRjuwI53CnXEqnE3BP1jGwRCbukRYrPu5UUw/lQ/bY8bPmPaF0Vw5LeIpNZYG6LOKdBrYtQ3bKOTR+ZeQ1ik+6Mzy/GFqogY5qRdNXJbaNtVbF8w27eehvMzNQ8RFM9VnQ3y3jyyOmL6onOIiMWxXTV/6d1mgcyRUHwEqnTOLdAKjBTEc1MOxlALZqldtPcY0KFx+6Nurtp4dP3h+Ksdqfmu8cI7jzNrUr7sz/YkglpLUX2kl2BBHsJrSmNrqTatzm73Oj+fNOcBKkUxZCqfqjOeS6iJYDl1VpiJFuhEQjmO2RDEMKxSTozFT8Mn9Qmz1i4H70VARot7L4Qqv7WyiCLfJkpMJhtGJyjp5+YhwC+vhzdozqwUh6TWXDx7d93OlbA+JqVaU5xQE//qB6sbgSgCXT9LGmHj32Wt3z1cIZlCgj/W2U/1BSVbs/giSeWWJf2Nlse/61+/vfjEFXaWbAifLi1TIB98ongqySBciFzikiKfSkuZcmLi42o+ObpfY= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2017 10:40:19.9872 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:40:26 -0000 ----- Original Message ----- From: "Tom Herbert" Sent: Thursday, June 22, 2017 4:48 PM > > Again, this is a specific mitigation against a specific technique that > > has been used very successfully against IPv4, including by recent > > malware that was so successful at propagation and infection that it > > made the world wide main stream press ("WannaCry"), and impacted car > > factories, hospitals and other significant organisations. > > > WannaCry keeps coming up as the example why address randomization is > needed, so I'll ask the obvious question. If the world was all IPv6 > and all IIDs were randomized, what would the effect had been? Would > the attackers have just given up when they saw that scanning wasn't > practical? Would they had just implemented an alternate method of > discovery (maybe just snoop the network for addresses one they > infected one machine)? Would this have completely avoided the attack, > slowed propagation by some X%, or have had no material impact on > success of the attack? > > > If large IPv6 IID with random values is "security snake oil", it might > > be the first "snake oil" ever that is effective against the threat it > > is intended to mitigate. > > > > "You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet" > > https://lab.dsst.io/slides/33c3/8061.html > > > > "If we cannot scan it, can we observe it?" > > https://lab.dsst.io/slides/33c3/slides/8061/10.jpg > > > > *** Just worked to prevent unsolicited packet scanning *** > > > > Another example. Shodan.io have made a business out of selling the > > ability to scan the IPv4 address space to discover devices. Did they > > try that approach with IPv6? No, they instead collected IPv6 addresses > > to probe by adding rogue NTP servers into the pool.ntp.org pools. > > > So in other words, the attackers didn't give up because scanning was > too hard, they just found a different way to perform discovery. That is my surmise. I don't know what the attackers are doing and, while attackers may well track lists such as these, I doubt that anyone will post a reply based on sound engineering. What I do know is of a parallel field, that of bank robberies, where the history is well understood and it is clear how bank robbers have changed their approach over time as counter measures were developped. So that remains my surmise. Tom Petch > Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jun 23 08:23:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56699126C3D for ; Fri, 23 Jun 2017 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhJUzoRPoi4V for ; Fri, 23 Jun 2017 08:23:11 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B4E3412944F for ; Fri, 23 Jun 2017 08:23:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5NFN8sK009584 for ; Fri, 23 Jun 2017 17:23:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 75CC5204692 for ; Fri, 23 Jun 2017 17:23:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6BFF620458D for ; Fri, 23 Jun 2017 17:23:08 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5NFN8Yn021254 for ; Fri, 23 Jun 2017 17:23:08 +0200 Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: ipv6@ietf.org References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> From: Alexandre Petrescu Message-ID: <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> Date: Fri, 23 Jun 2017 17:23:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 15:23:13 -0000 Le 22/06/2017 à 21:32, Simon Hobson a écrit : > Alexandre Petrescu wrote: > >> I think rfc7421 does not describe that on-link prefixes are >> practically the same thing as subnet prefixes (otherwise addresses >> are unreachable, or resolution conflicts may arise). One wouldnt >> appreciate a /63 prefix for onlink determination and a different >> /64 to form addresses there. > > Isn't that mostly wrong - and such "imprecise" use of words part of > the problem ? As mentioned earlier, what is a "subnet prefix" ? Is > it some imprecise combination of IPv4 terminology and thinking with > IPv6 ? Agreed, imprecise enough. This stems from the fact that we dont have a definition of prefixes that dont involve the word 'subnet'. The definition that is closest for our discussion is in draft-jinmei-6man-prefix-clarify-00. That uses "on-link prefix" and "SLAAC subnet prefix". With these terms at hand, all I can say that the on-link prefix has the same value as the SLAAC subnet prefix, otherwise SLAAC addresses may be unreachable, or ND resolution conflicts may arise. > Yes, it took me a long time to get my head around the concept of > "on-link" being more or less unrelated to "in the same prefix > prefix" (unlike the close coupling between address and subnet in > IPv4). In the example you've given, it is actually quite feasible > that the /64 prefix given for forming addresses is not a collection > of on-link addresses - while some different /63 prefix does comprise > on-link addresses. It would be quite a contrived setup and I'm not > sure what technology might arrive at that, I hope no technology arrives at that. To see why, I would like to propose to think in terms of on-link prefix, SLAAC subnet prefix, _and_ in terms of form of prefix present in the routing table; without this 3rd parameter it's hard to ensure reachability and unique localisation (each address be bidirectionally reachable, and be present at only one place). It's also this 3rd parameter that makes for magic like '64share', connected routes, ND, and others. This 3rd parameter is independent of IP version number; it is a fundamental characteristic. If we take this 3rd parameter into account then we can see that on-link prefix and SLAAC subnet prefix can only be the same. If not, not. Without considering that 3rd parameter we could build networks that dont ensure bidirectional reachability and that allow for ND to break some times. > but it would be a valid setup from the IPv6 PoV It's not a valid setup. It's an error. It may be something useful in small networks like old IPX or other-proprietary that are great inside themselves but hard to connect to Internet. > - perhaps some sort of wireless setup where direct client-client > communications is not possible/permitted, but direct (on-link) > communications between those clients and (say) some backend stuff is > permitted. The details of it are not straightforward to me. But we can discuss and see what would be the on-link prefix, the SLAAC subnet prefix, and the form of the prefixes present in the routing tables. Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jun 23 10:02:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD2129AAA for ; Fri, 23 Jun 2017 10:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQKN0DftDFUd for ; Fri, 23 Jun 2017 10:02:24 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F5C129649 for ; Fri, 23 Jun 2017 10:02:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id CFCCC1BC37 for ; Fri, 23 Jun 2017 17:02:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them From: Simon Hobson In-Reply-To: <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> Date: Fri, 23 Jun 2017 18:02:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> To: "ipv6@ietf.org WG" X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:02:27 -0000 Alexandre Petrescu wrote: >> Isn't that mostly wrong - and such "imprecise" use of words part of = the problem ? As mentioned earlier, what is a "subnet prefix" ? Is >> it some imprecise combination of IPv4 terminology and thinking with >> IPv6 ? >=20 > Agreed, imprecise enough. >=20 > This stems from the fact that we dont have a definition of prefixes = that > dont involve the word 'subnet'. The definition that is closest for = our > discussion is in draft-jinmei-6man-prefix-clarify-00. That uses > "on-link prefix" and "SLAAC subnet prefix". >=20 > With these terms at hand, all I can say that the on-link prefix has = the > same value as the SLAAC subnet prefix, otherwise SLAAC addresses may = be > unreachable, or ND resolution conflicts may arise. >> Yes, it took me a long time to get my head around the concept of = "on-link" being more or less unrelated to "in the same prefix >> prefix" (unlike the close coupling between address and subnet in >> IPv4). In the example you've given, it is actually quite feasible >> that the /64 prefix given for forming addresses is not a collection >> of on-link addresses - while some different /63 prefix does comprise >> on-link addresses. It would be quite a contrived setup and I'm not >> sure what technology might arrive at that, >=20 > I hope no technology arrives at that. >=20 > To see why, I would like to propose to think in terms of on-link = prefix, > SLAAC subnet prefix, _and_ in terms of form of prefix present in the > routing table; without this 3rd parameter it's hard to ensure > reachability and unique localisation (each address be bidirectionally > reachable, and be present at only one place). It's also this 3rd > parameter that makes for magic like '64share', connected routes, ND, = and > others. >=20 > This 3rd parameter is independent of IP version number; it is a > fundamental characteristic. >=20 > If we take this 3rd parameter into account then we can see that = on-link > prefix and SLAAC subnet prefix can only be the same. >=20 > If not, not. Without considering that 3rd parameter we could build > networks that dont ensure bidirectional reachability and that allow = for > ND to break some times. >=20 >> but it would be a valid setup from the IPv6 PoV >=20 > It's not a valid setup. It's an error. >=20 > It may be something useful in small networks like old IPX or > other-proprietary that are great inside themselves but hard to connect > to Internet. >=20 >> - perhaps some sort of wireless setup where direct client-client = communications is not possible/permitted, but direct (on-link) = communications between those clients and (say) some backend stuff is >> permitted. >=20 > The details of it are not straightforward to me. But we can discuss = and > see what would be the on-link prefix, the SLAAC subnet prefix, and the > form of the prefixes present in the routing tables. OK, lets suppose that we have some form of yet to be determined network, = where client-client direct communication is not possible (or not = allowed). That's not uncommon in many public wireless networks where the = APs and/or controller can go to some lengths to block such traffic - for = the security of users. But we could have some devices in the network that we do allow the = clients to communicate with. OK, it's contrived and could (possibly) be = built better with routed segments & prefixes - but lets continue. So the router advertises a /64 for clients to use for SLAAC but does NOT = mark this as on-link. The router also advertises a separate prefix as = on-link - the actual prefix length doesn't matter, it could be a /63, = but it is a different prefix. The router itself has a routing table entry for both prefixes directing = traffic out of the appropriate interface (same interface for both = prefixes). Client A tries to send a packet to Client B, sees that Client B is not = "on-link" and so simply sends the packet to the router - which filters = it according to applied policies before either dropping it or forwarding = it back out the same interface to reach Client B. When Client B replies, = packets again pass via the router. Client wants to send packet to (say) Printer. It sees that Printer is in = a prefix marked as on-link so simply sends the packet and it arrives. = Packets from Printer to Client are simply injected into the network and = delivered. This is all predicated on the network hardware filtering traffic between = clients. So lets say it's done by the AP - it applies rules which are = simply : "If source and destination ports (as determined by reference to = the MAC forwarding table) are both radio then drop the packet, else = forward according to the table". Similar rules would also need to work = back up into the network so as to block traffic between clients on = different APs. Now, lets see what might not work here. ND. What won't work ? Clients can discover Router. Router can discover = Clients. Printer can discover Clients, Clients can discover Printer. = Client A can't discover Client B - but then it doesn't need to and (I = assume) won't even try as it knows that Client B is not in an on-link = prefix. SLAAC. Now, if we go back to addresses based on MAC address then there's = no problem. Each client will form an address in the prefix it's been = given and it will be unique (assuming unique MACs, and it's interesting = when they aren't). So the problem now comes down to duplicate address detection when = devices use random addresses and the prefix isn't on-link. Has there = been any discussion of how this would work when devices are not in an = on-link prefix ? Is there a process for the router to do some sort of = proxy for DAD - eg when Client A does DAD for it's random address, = Router will reply if it knows that the address is in use by Client B ? Taking this last point, it now occurs to me that if there is no such = mechanism, then "public" WiFi has a problem. It either doesn't do client security - so any client can see all other = clients; or it has to run some sort of proxy to make DAD work. At = present, I believe (but haven't personally verified) that one make of AP = that I work with simply blocks IPv6 altogether with bridge rules to = avoid the problem if the admin selects inter-client security. Now, where's the critical bit I've missed that makes the whole argument = fall over ! From nobody Fri Jun 23 10:41:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F921271DF for ; Fri, 23 Jun 2017 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBrmw2rYpwCh for ; Fri, 23 Jun 2017 10:41:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 39A461270A3 for ; Fri, 23 Jun 2017 10:41:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dOSad-0000FEC; Fri, 23 Jun 2017 19:41:51 +0200 Message-Id: To: ipv6@ietf.org Cc: Alexandre Petrescu Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> In-reply-to: Your message of "Fri, 23 Jun 2017 17:23:07 +0200 ." <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> Date: Fri, 23 Jun 2017 19:41:50 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:41:56 -0000 > With these terms at hand, all I can say that the on-link prefix > has the same value as the SLAAC subnet prefix, otherwise SLAAC > addresses may be unreachable, or ND resolution conflicts may arise. You are ignoring the role of the router here. In the extreme case where the route announces no onlink prefix, all traffic (initially) goes through the router. So no problem from a routing point of view. For SLAAC you still need DAD. In this case if multiple hosts share a prefix (which is not a given) the router would have to do some kind of proxy-ND just for DAD. From nobody Fri Jun 23 13:06:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31D41293FF for ; Fri, 23 Jun 2017 13:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRw4QCfr0tuK for ; Fri, 23 Jun 2017 13:06:00 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 2FC26126B7E for ; Fri, 23 Jun 2017 13:06:00 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p66so31028724oia.0 for ; Fri, 23 Jun 2017 13:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ih3LC1PQeTv8aWEqGLcp1eed2AoBWuYJPwPCaH6soS4=; b=SccblgO5gpRZiFa8RZWFruHKE4SHKadd/zYPiJdmmy0JW15nCwqB5ltDmL5Ta+xD1Q mbt6cMjP7p0Iu/9sHjmJwUKJYWpsH6CbcoW1UEc9xd4IHS6KqzGWrQB46NsbKk36YTPd BpecCtQ0c5PmpVc7LszZnzdtG4gw4pKnaW6B1JKVIXh1GVdpUGdL37kBKfgZqQYzqlUe 2cdgt+EbXFbT9MXWvSsSvSvfM8csiteLc2pR2zMH/cDbJ0uofWWF5SFaCbXLuhzJYbba VfesYG73e7dDB7iZkP3xk7GzYWXgyYHqoLUG2x0xQF6O6f7NesBUd4AAL45mz5CEj982 Z2tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ih3LC1PQeTv8aWEqGLcp1eed2AoBWuYJPwPCaH6soS4=; b=I16fneMprqmLFSkraDbZwzCjClPdhSCB25+fyoqAC0hBt+3ryRA6HTOe5SF7DIue7T zofc/PRgIndBKxnFi3fUNrf9xD/CRBN2uz6v7QQoKJ0fVXpPuYWbQ8RgZ7FR2GhnRsLS ihYaYuiG+BdftQj8++22nL4TuipPKoSeCPOGhaQkyGsb75G+5UNh43Ryj7TfNjMtJZDh HRrf/x7lZxSUvGvX4DUtSpiTjcaSjpT9bHwK+fWlz9Oet03PYtHF8ZaqQtcJ2dMd3Uli uxA9WU7ZFL3Oj4kzPJeoeaG3Ak1ct4E48T5GuLMKWigyV8ta9hWodZ2Y9U7mp2Wx9aJm ntKw== X-Gm-Message-State: AKS2vOwtctNfH8urNAiIk1oWXJe+/aTqSkZ2kMB3c52lE1Jst6Of1l2o e0MoAKBH05lbZg== X-Received: by 10.202.75.7 with SMTP id y7mr4879799oia.151.1498248359492; Fri, 23 Jun 2017 13:05:59 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1878? ([2600:8802:5600:1e::1878]) by smtp.gmail.com with ESMTPSA id q19sm1348564otg.7.2017.06.23.13.05.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 13:05:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them From: Fred Baker In-Reply-To: <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> Date: Fri, 23 Jun 2017 13:05:55 -0700 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:06:02 -0000 On Jun 23, 2017, at 8:23 AM, Alexandre Petrescu = wrote: > This stems from the fact that we dont have a definition of prefixes = that > dont involve the word 'subnet'. The definition that is closest for = our > discussion is in draft-jinmei-6man-prefix-clarify-00. That uses > "on-link prefix" and "SLAAC subnet prefix". >=20 > With these terms at hand, all I can say that the on-link prefix has = the > same value as the SLAAC subnet prefix, otherwise SLAAC addresses may = be > unreachable, or ND resolution conflicts may arise. I'd suggest you not ignore routing, or RFC 7608. RFC 7608 says that an = IPv6 prefix is a CIDR prefix, which is to say that it has a length, and = aggregates of them are stacked like Russian Dolls - one prefix contains = another. So when an RIR is given a prefix by the IANA, it is (IIRC), 16 = bits long, and from that the RIR delegates prefixes to ISPs of various = lengths up to 32, which in turn delegate prefixes to their customers, = who in turn deploy them in their networks. BGP, OSPFv3, IS-IS, RIP-II, = and other protocols carry CIDR IPv6 prefixes. They have to be considered = to be IPv6 prefixes if you're defining the term. The only use of the term "subnet" in RFC 7608 refers to a prefix applied = to a LAN, and is not part of the definition. In RFC 5340 (OSPF for = IPv6), section 2.1 is entitled "Protocol Processing Per-Link, Not = Per-Subnet", and guess what it says. In RFC 5308 (IS-IS for IPv6), the = word subnet does not occur. And for BGP, RFC 2545 only refers to cases = in which two routers are interconnected and share a prefix, using = language common in 1999 - they "share a subnet". And in RFC 2080, the = only usage is in the paragraph The distinction between network, subnet and host routes does not need to be made for RIPng because an IPv6 address prefix is unambiguous. From nobody Fri Jun 23 13:41:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636B1129467 for ; Fri, 23 Jun 2017 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S59ca6Dt-PQz for ; Fri, 23 Jun 2017 13:41:40 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DBB129411 for ; Fri, 23 Jun 2017 13:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5NKfdVI020127; Fri, 23 Jun 2017 13:41:40 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5NKfaN5020095 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 23 Jun 2017 13:41:36 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Jun 2017 13:41:36 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 23 Jun 2017 13:41:36 -0700 From: "Manfredi, Albert E" To: Fred Baker CC: "ipv6@ietf.org" Subject: RE: Mixing up threats, expecting a single perfect mitigation to all of them Thread-Topic: Mixing up threats, expecting a single perfect mitigation to all of them Thread-Index: AQHS6u6QXgF54V4SJkGesxzHdEnKtaIwCCQAgAEbGACAAGrggIAALd8AgAFMu4CAAE8DgP//jxbQ Date: Fri, 23 Jun 2017 20:41:36 +0000 Message-ID: References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:41:42 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker > I'd suggest you not ignore routing, or RFC 7608. RFC 7608 says > that an IPv6 prefix is a CIDR prefix, which is to say that it > has a length, and aggregates of them are stacked like Russian > Dolls - one prefix contains another. So when an RIR is given a > prefix by the IANA, it is (IIRC), 16 bits long, and from that > the RIR delegates prefixes to ISPs of various lengths up to 32, > which in turn delegate prefixes to their customers, who in turn > deploy them in their networks. BGP, OSPFv3, IS-IS, RIP-II, and > other protocols carry CIDR IPv6 prefixes. They have to be > considered to be IPv6 prefixes if you're defining the term. Exactly. And really no different from what we do with IPv4, leaving aside t= he length in bits, of course. When a customer is allocated a Class C, for i= nstance, he/she may well proceed to create longer prefixes, for "subnets." = And hosts might conceivably take that even further. With fewer bits to work= with, fewer options than you have with IPv6, perhaps. But same mechanism. > The only use of the term "subnet" in RFC 7608 refers to a prefix > applied to a LAN, and is not part of the definition. In RFC 5340 > (OSPF for IPv6), section 2.1 is entitled "Protocol Processing > Per-Link, Not Per-Subnet", and guess what it says. In RFC 5308 > (IS-IS for IPv6), the word subnet does not occur. "Subnet," in IPv4, seems to me, has always been sloppily applied. I think t= he term "on link" could work just as well in IPv4. I'm either continuing to miss some nuance, or there's really nothing new he= re, other than an unwillingness to continue to use sloppy terms? Bert From nobody Fri Jun 23 17:11:18 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F5B129B41; Fri, 23 Jun 2017 17:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , <6man-chairs@ietf.org> Cc: suresh.krishnan@gmail.com, ipv6@ietf.org Subject: 6man - Requested session has been scheduled for IETF 99 X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282622.7840.12795284847237039246.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:06 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:06 -0000 Dear Ole Troan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. 6man Session 1 (2:30:00) Monday, Morning Session I 0930-1200 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Maintenance Area Name: Internet Area Session Requester: Ole Troan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6lo 6tisch dhc homenet intarea v6ops spring mtgvenue People who must be present: Robert M. Hinden Ole Troan Suresh Krishnan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 03:24:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8291200C1 for ; Sat, 24 Jun 2017 03:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_B4AxvMF3CN for ; Sat, 24 Jun 2017 03:24:23 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DD912009C for ; Sat, 24 Jun 2017 03:24:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 8D5031BC37 for ; Sat, 24 Jun 2017 10:24:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them From: Simon Hobson In-Reply-To: Date: Sat, 24 Jun 2017 11:24:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <477ABC31-B9CA-4098-A4EC-3DF74ED4E8F5@thehobsons.co.uk> References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> To: "ipv6@ietf.org WG" X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 10:24:25 -0000 "Manfredi, Albert E" wrote: > "Subnet," in IPv4, seems to me, has always been sloppily applied. I = think the term "on link" could work just as well in IPv4. >=20 > I'm either continuing to miss some nuance, or there's really nothing = new here, other than an unwillingness to continue to use sloppy terms? I have a feeling that we have become so used to "one 'network' =3D one = subnet (aka prefix)", together with the close binding between "in the = same subnet =3D on-link" with IPv4 - that it's hard to consistently = "unlearn" those associations when dealing with IPv6. It's not as if we = can just forget about IPv4 as (I assume) most (all ?) of us are still = dealing with IPv4 on a daily basis which keeps those associations fresh = in our minds. Thus it needs conscious effort to "think IPv6" - at least it does for = me. From nobody Sat Jun 24 15:12:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35D61200B9; Sat, 24 Jun 2017 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwkD0retCd5u; Sat, 24 Jun 2017 15:12:34 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AAA1279E5; Sat, 24 Jun 2017 15:12:30 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e7so38394228pfk.0; Sat, 24 Jun 2017 15:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q3yvzmT4lb7fFKuge9xcvr011LB8QmZ8sH1RequJ8ns=; b=NTZTrdmgrw7PME9W8ScgbCBL3/CVsK5sikyMysitqMkzQCOz65m0lcdMEEQGPR/VFI rHJ+zow6kAUiuxlVuopcQQdp73qDZ6CuTCax8p6JnKNsGPiSXdiBdFqh6wxeEH0ed9BD ixKRQ3ghmggf3nehy7dn1jNN0/VFNwGaDXWXVEomz/2Z/vjJdNJ7km0JGIN5h1kXTtMh GrSLrTJbNk+Vwdu8Q4HOou+8sLZyW1sUlo0ZEbrB0FxjX4rGLTSOj26V378okVN4Onbv 1cxIPHYO9k0VE7ozcMdxmF+ZhFd7ZwFaaO62o/SpxnrjRhLTl+rlDpf2a6hzVsFZBlRE X36w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Q3yvzmT4lb7fFKuge9xcvr011LB8QmZ8sH1RequJ8ns=; b=Th0NJtAW/KmAX1Gy9SUS8USxdt/7fGsl8hHtIOaLVcPAXzD3Md3ClpBzCXC88tOgnt 7ChmB26jc1mdu0fj1Ejviy5kgI42r8kLvPDlvJ7Hp/jFsyc7PX0hg1xFINdL4ke7qVE3 Ybx2l0AXAMsWzbey8sEb3MdnpcFEpYSJxrIbzUnq6ELELFAM/hAaivSLTpG4axazPcXR k1nXVSAzPcBenl3El6ZuBFNtUxndURZ0LHxoZLA2d5B/8jonUXnlNx6uDOWtd/Z+ZbFX fp04huTsplt1kTf9PJWvxxNU/3ZAYGxTUkIrztDYsq2mK2eZ8Rfc2RuS9CPDxXgaqsJv +MMg== X-Gm-Message-State: AKS2vOxn5bf7epq/RvzjWt3aZRtGyBknSiT+W5UqVifY5adjN4vzpXWu i4InYsGtUKe/Cr97 X-Received: by 10.84.217.137 with SMTP id p9mr16290049pli.80.1498342350170; Sat, 24 Jun 2017 15:12:30 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id c14sm18706596pfk.42.2017.06.24.15.12.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 15:12:29 -0700 (PDT) Subject: Comments on draft-voyer-6man-extension-header-insertion-00 To: 6man , draft-voyer-6man-extension-header-insertion@ietf.org References: <0364b377-7e23-ad4b-136a-86e1dda96cfd@gmail.com> <8F22ADA3-1865-4485-8ACD-56E47BD11CF5@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <48233c99-e983-63f2-a042-96d4821b7676@gmail.com> Date: Sun, 25 Jun 2017 10:12:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <8F22ADA3-1865-4485-8ACD-56E47BD11CF5@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 22:12:36 -0000 Hi, This has been on my to-do list for a long time: 1. The RFC Editor does not allow long lists of authors. Up to 5 authors, some of whom may be tagged as Editors, is OK. Any others should be listed in a separate Contributors section. The difference is that authors must have written a significant part of the text but contributors have made a smaller contribution. (Saying "I agree" isn't a contribution...) 2. The consensus text in rfc2460bis is quite clear: "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. "The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path,..." So the challenge for draft-voyer- is to craft a careful exception to that consensus. The draft will need to be a standards track document that explicitly updates rfc2460bis. 3. The tone of the Abstract is completely wrong. It should be much more neutral and objective, such as: In some circumstances there is value in inserting extension headers into an existing IPv6 packet at any point along its path, as long the entire journey of the packet is certain to remain in its source domain and the extended packet is certain not to exceed the maximum transmission unit (MTU) of its path. This document updates RFCxxxx accordingly. (Also see comment 12 below.) 4. The Introduction needs to introduce the topic: a longer version of the Abstract. 5. As well as defining "domain" the Introduction needs to define and explain the path MTU within the domain. There's some loose wording about this later on, but we need some precision: I suggest formally defining the path MTU assumed by a source node (let's say sPMTU), and the actual path MTU provided by the infrastructure (let's say iPMTU) and then the rule that inserted headers MUST NOT exceed (iPMTU - sPMTU) in length. How all nodes become aware of the domain-wide values of iPMTU and sPMTU needs to be defined. (By the way, TRILL has a solution to a very similar problem.) 6. The Introduction (or possibly section 4) needs to specify more precisely how a domain and its edges are defined and identified. Is a domain a set of address ranges, for example? Is it defined by (manual) configuration? Can its extent change dynamically? 7. "2. Source Domain and Packet Journey" This section is very strange. Is it an example, the main use case, or what? Its presence needs some explanation. 8."Obviously, this FRR service increases the size of the packet during its journey within domain D. This is well-known to operators. Well- known mitigation techniques have been deployed for more than 15 years for the MPLS-based FRR service and the numerous VPN services. The same exact technique can be used which consists of deploying an infrastructure capable of an MTU value higher in the core than at the ingress edge." Again, this has completely the wrong tone. There is no need to shout. By introducing sPMTU and iPMTU as suggested above, you can make this question purely technical. 9. "2.1. Example: 6PE" I don't understand the relevance of this example. Yes, MPLS stacks its headers. That's MPLS. In the context of IPv6 header insertion, this is irrelevant. 10."3. Transit through a Source Domain" I don't understand the relevance of this example. It doesn't discuss header insertion. 11."4. SRH insertion in Source Domain This document reminds that for a packet whose journey is completely contained within its source domain, it does not matter where the IPv6 extension header insertion is done. It could be at the source or at the first-hop router or at any node of the source domain. The source domain owns the packet and decides the location, which suits it best." Again the tone of this text is simply wrong (and defensive). Also, too many words to say something simple: As mentioned above, an IPv6 header may be inserted at any point along a packet's path within its source domain, for example at the first-hop router. 12."During the packet journey in the source domain, any node in the source domain may insert an SRH and the egress node MUST remove both the outer IPv6 header and inserted SRH." That is contradictory with the earlier statement that header insertion applies when "the entire journey of the packet remains in its source domain." So, if that is what you intend, the Abstract and Introduction need to be changed to make it clear that packets MAY leave the domain but if so the inserted headers MUST be removed. And you need to specify how the egress routers know that certain headers are to be removed, but not others. 13."In conclusion, in a context of a controlled/trusted domain, the insertion of SRHs in packets that are sourced within the domain is useful, required and also harmless. Hence, a context-less ban of IPv6 extension header insertion does not make sense." Just delete this. It adds nothing. What you *do* need to say here is something like: SRH insertion and removal as described here update the restriction in Section 4 of [rfc2460bis]. Regards Brian From nobody Mon Jun 26 03:51:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358A5129AEA for ; Mon, 26 Jun 2017 03:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k1xhk7sEnU4 for ; Mon, 26 Jun 2017 03:51:41 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA13F129AE9 for ; Mon, 26 Jun 2017 03:51:41 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 2A9792D4F91; Mon, 26 Jun 2017 10:51:39 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2775FDF659BE; Mon, 26 Jun 2017 12:51:46 +0200 (CEST) From: Ole Troan Message-Id: <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3E47E096-4B33-4052-B306-0D20E96F3DB7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them Date: Mon, 26 Jun 2017 12:51:44 +0200 In-Reply-To: Cc: 6man WG To: Simon Hobson References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 10:51:43 -0000 --Apple-Mail=_3E47E096-4B33-4052-B306-0D20E96F3DB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23 Jun 2017, at 19:02, Simon Hobson wrote: >=20 > SLAAC. Now, if we go back to addresses based on MAC address then = there's no problem. Each client will form an address in the prefix it's = been given and it will be unique (assuming unique MACs, and it's = interesting when they aren't). >=20 > So the problem now comes down to duplicate address detection when = devices use random addresses and the prefix isn't on-link. Has there = been any discussion of how this would work when devices are not in an = on-link prefix ? Is there a process for the router to do some sort of = proxy for DAD - eg when Client A does DAD for it's random address, = Router will reply if it knows that the address is in use by Client B ? DAD as specified in RFC4862 requires that all nodes are on the same = shared media and in the same link-local multicast domain. That is independent of on-link-ness being indicated in the PIO option or = not. Two neighbours at the IP level can discover they are on-link in = several different ways: (from RFC4861): on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: - it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the (target) address, or - any Neighbor Discovery message is received from the address. Much of this is designed for link-types that have gone out of fashion. = See RFC1620. Some of the same problems crop up when people try to emulate isolation = at L3 on shared L2 domains. See also RFC6957. Ole --Apple-Mail=_3E47E096-4B33-4052-B306-0D20E96F3DB7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZUOdBAAoJEL7aWKiYQt92D5IP/03qRkE3Ua9jSAfjMXb+wgqf 53CstyYoZbhiQhvVDbwDDFXtNl7UuXj9krIcMSQqP0URTxCjstdG7GFPockveJBe lSTNd+ZWEIv/tVy6j83GFr40kV/1D7SlCIx57plyuP2KjqJ+1lvcE6o5lHsh/9re 7YVI7uMCAuNHo5APyX7pjTAZyvybYHNvYzovUfjVMcG8mNr3Z2dtxMRiC000fJaZ +S9BKjfNX5LWjmvcTtLpuhV+1WftuUqrqnO8uQve4B+28NA8xv4+9ddn6GM66Ahg P5s6Vccdik3oU5x0e+XvnDyWAySeutxbuxS54v6/2f4096y488Yx7TxxQnB64/K1 33yOtislKsjO4AuT/m+8pY/sG9gXOYTpmbEwrKw08tVkSQ1M6Xd9vKYkLpnmrRDm eCNiJVfLpIfQeyTwtNKBdxSL8B385vC6IgdTUXxADnWY+clfPbtegFvk+Yjzyty5 qY0krSxLJ4udMio7zLFlwKDYulpUQ1IUNXSaeC4H4/6dBD2c/RnWJNb3prKp5TDf dFjKc3roc/CGmqQJXKRCBuC5/8sOlvRpzvi1nZGUfYL+lGodztNWAMv3P9MpcDNU bfnNU+91mb9HEAGkhcufJkuRS4iop6vVmvKZ9HWkJ5UrltJjCMe7LWLYYsoGBVjX ZeZ5fs6JQ4UpF/Y8HrSE =PXma -----END PGP SIGNATURE----- --Apple-Mail=_3E47E096-4B33-4052-B306-0D20E96F3DB7-- From nobody Mon Jun 26 04:29:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1382F1296CF for ; Mon, 26 Jun 2017 04:29:10 -0700 (PDT) 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, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k8ffyRKMVzg for ; Mon, 26 Jun 2017 04:29:08 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 2C81D126579 for ; Mon, 26 Jun 2017 04:29:08 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id z22so65495182uah.1 for ; Mon, 26 Jun 2017 04:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KVV0oLemxurZVFh/HRc1rvjA1jYGxIJjcQCh1DRnE7E=; b=ubeyhzp8VToDoi8QK6BBKygyCtuFKv65BVSRtvXyCVrReppbakGzmSr6A7cQ4Ob6N2 JuTrwBaiLJ4+m1fK8i/Qtv1sRAWYDuXJE8oG3UtEnRg+kFjSsJ/OIBDEdVCVkW5j0p/3 VhZ5W3/dUq/4LtRGczOVG2j57JbgQFrGCAN4zIGiDz8oKAU3S7JaFpF/+FJyHBm+KIVQ 700PZNreXaNzsqe8oM7rNVMpcrqH3zmOqRrtqGOjpQcxcBqmLH9Z9kXvmHpL42BovFjc pqEeOAXOwa2sRZbOKQQczdFymO/9WHKxgQYLJ6E/5PwRYyZKMzCQcJFAzHpU6QvHf6DL 1yNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KVV0oLemxurZVFh/HRc1rvjA1jYGxIJjcQCh1DRnE7E=; b=Btq1r+TTRABhRing7txfcBTKbvwmZtMnoUh4lXuSYClLnEajwm3iCx88OXUUBLIXwR VvPNHZo3ff6aIMGm8wEk1azFwBe09315cxENA70qO4EjGzgEq+24Wimg/j9Bdm3oT1tz dp9FJY+BOqvel8CtcOXKk72S2WlFvOZbXTbBpZ4QI8B0Z/FLIlNPgZzwHChUMIcTiWJS kmyRos/1DiZCkXfQrmufxeKqpTD6OXULqB2vNCkBcRxKuCGZ4rtmQaWYp3mBiTABHBYe Yx5WR56qaj9ozW43V55gvvs2txIuOb4XexK2ml+RC6MBW58fQzmPz2Fy24M+ovGnTIvn JBTg== X-Gm-Message-State: AKS2vOxJqO08282gr5V59LHjhrBb2uanM+q5Qiw23EN9ajZOW+BJ9zOr ga1xK4XNECAFXPipiLHFZtqWK6morgLU X-Received: by 10.176.82.236 with SMTP id w41mr13356912uaw.98.1498476547164; Mon, 26 Jun 2017 04:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Mon, 26 Jun 2017 04:28:36 -0700 (PDT) In-Reply-To: <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> From: Mark Smith Date: Mon, 26 Jun 2017 21:28:36 +1000 Message-ID: Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them To: Ole Troan Cc: Simon Hobson , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 11:29:10 -0000 On 26 June 2017 at 20:51, Ole Troan wrote: > >> On 23 Jun 2017, at 19:02, Simon Hobson wrote: >> >> SLAAC. Now, if we go back to addresses based on MAC address then there's= no problem. Each client will form an address in the prefix it's been given= and it will be unique (assuming unique MACs, and it's interesting when the= y aren't). >> >> So the problem now comes down to duplicate address detection when device= s use random addresses and the prefix isn't on-link. Has there been any dis= cussion of how this would work when devices are not in an on-link prefix ? = Is there a process for the router to do some sort of proxy for DAD - eg whe= n Client A does DAD for it's random address, Router will reply if it knows = that the address is in use by Client B ? > > DAD as specified in RFC4862 requires that all nodes are on the same share= d media and in the same link-local multicast domain. > > That is independent of on-link-ness being indicated in the PIO option or = not. Two neighbours at the IP level can discover they are on-link in severa= l different ways: (from RFC4861): > > on-link - an address that is assigned to an interface on a > specified link. A node considers an address to be on- > link if: > > - it is covered by one of the link's prefixes (e.g., > as indicated by the on-link flag in the Prefix > Information option), or > > - a neighboring router specifies the address as the > target of a Redirect message, or > > - a Neighbor Advertisement message is received for > the (target) address, or > > - any Neighbor Discovery message is received from > the address. > I also haven't seen RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" mentioned in these "on-link" discussions. That RFC may explain what people think is missing. https://www.rfc-editor.org/rfc/rfc5942.txt > > Much of this is designed for link-types that have gone out of fashion. Se= e RFC1620. > Some of the same problems crop up when people try to emulate isolation at= L3 on shared L2 domains. See also RFC6957. > > Ole > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jun 26 18:01:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5E126CC4 for ; Mon, 26 Jun 2017 18:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBy7ClFW7_cD for ; Mon, 26 Jun 2017 18:01:46 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 9C44C12420B for ; Mon, 26 Jun 2017 18:01:46 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id u62so2222930pgb.0 for ; Mon, 26 Jun 2017 18:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xw8S9wwVXiNR9zkgpah5tefIyMF1ZOIFnuQW5U2NG+o=; b=tSyAfyg7Y4Nhd8VAytmhLUIO+qPPuBdywbRhvjfNtQ6P3nkU0VafbT5Ptx8twYr7/j 9tl3RytkoOtBENMuBiSunbbWsBIE208NBIF9wEM5ujV/xlg+rxQWiJnQxsTz6vSeVsEr aDLxKaXQN2eAhYmyw3cBWrt5qjtDzrfXzJO/OIWO90GJ7CUWCDf0sVlEG0eRrw6NfHLl Wrp3kp2YztHo1wsWb4+wV8/3QCQC/E72NDTbA0MvuP84F5kEZ6iu/CUygXEj3fwjAwNT VQTmi296OdnmiOKDDHtkYDyujOJ4KkD+t1W1fvjmsBaJazP4pqkQ+OcDwZbKUpxRlrkL 5zdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xw8S9wwVXiNR9zkgpah5tefIyMF1ZOIFnuQW5U2NG+o=; b=QamoVp2JZV+3LVGvvoGD0u+DW5Gpmehy7005tBSO7k4AQbS75Zq4zFu1Je44nPYEoX 9ERaUYNgqFS5bcCEFf3jf8uxP6TckS5FIXktGLgeQNvczxrd6PJofm/XCBVDYoAdmoXv XnzQlCPHLy0Y8LyhEJ1wAhpD3ZSHA78zEhG1TmUlYYnyH85JC5DVCl3RF5vVh9I4CnS4 TSgwZb7J95v8GcEud7Gocq9PL+2qGIewYYWuFXo+ytX3OIqM/ToqLF1cY/9wR0HcISzm 3ylibp18t48r2w6Qs1cGlWYG9rKqB0t0Kxy7uVLCJ9KXdThEQBMqLDNabKWH/oeNMwxx PZmQ== X-Gm-Message-State: AKS2vOy5t8zXsif1sSWphUr0tw+Wk19lvb1A2+OlzoHRZ4KEDh8uqpFU 8FHZKq5NKkjJiWaEnJ8= X-Received: by 10.99.122.18 with SMTP id v18mr2757514pgc.142.1498525306173; Mon, 26 Jun 2017 18:01:46 -0700 (PDT) Received: from [172.30.1.27] ([121.140.121.133]) by smtp.gmail.com with ESMTPSA id i14sm2457509pgn.14.2017.06.26.18.01.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 18:01:44 -0700 (PDT) From: Dae Young Kim Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_99477F71-01A9-4A68-9419-486232541AA5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them Date: Tue, 27 Jun 2017 10:01:40 +0900 In-Reply-To: <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> Cc: Simon Hobson , 6man WG To: Ole Troan References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 01:01:48 -0000 --Apple-Mail=_99477F71-01A9-4A68-9419-486232541AA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Haven=E2=80=99t been the last two bullets deprecated by RFC 5942? =E2=80=94=E2=80=94 DY > On 26 Jun 2017, at 7:51 PM, Ole Troan wrote: >=20 > That is independent of on-link-ness being indicated in the PIO option = or not. Two neighbours at the IP level can discover they are on-link in = several different ways: (from RFC4861): >=20 > on-link - an address that is assigned to an interface on a > specified link. A node considers an address to be on- > link if: >=20 > - it is covered by one of the link's prefixes = (e.g., > as indicated by the on-link flag in the Prefix > Information option), or >=20 > - a neighboring router specifies the address as the > target of a Redirect message, or >=20 > - a Neighbor Advertisement message is received for > the (target) address, or >=20 > - any Neighbor Discovery message is received from > the address. --Apple-Mail=_99477F71-01A9-4A68-9419-486232541AA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Haven=E2=80=99t been the last two bullets deprecated by RFC = 5942?

=E2=80=94=E2=80=94
DY

On 26 Jun 2017, at 7:51 PM, Ole Troan <otroan@employees.org> wrote:

That is independent = of on-link-ness being indicated in the PIO option or not. Two neighbours = at the IP level can discover they are on-link in several different ways: = (from RFC4861):

on-link     - an address = that is assigned to an interface on a
          &nb= sp;     specified link.  A node considers = an address to be on-
          &nb= sp;     link if:

          &nb= sp;        - it is covered by = one of the link's prefixes (e.g.,
          &nb= sp;          as = indicated by the on-link flag in the Prefix
          &nb= sp;          Information= option), or

          &nb= sp;        - a neighboring = router specifies the address as the
          &nb= sp;          target of = a Redirect message, or

          &nb= sp;        - a Neighbor = Advertisement message is received for
          &nb= sp;          the = (target) address, or

          &nb= sp;        - any Neighbor = Discovery message is received from
          &nb= sp;          the = address.

= --Apple-Mail=_99477F71-01A9-4A68-9419-486232541AA5-- From nobody Tue Jun 27 00:23:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1AC12EBF5 for ; Tue, 27 Jun 2017 00:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1di75kaxRMd7 for ; Tue, 27 Jun 2017 00:23:11 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B0F128C83 for ; Tue, 27 Jun 2017 00:23:11 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 175B82D4F9B; Tue, 27 Jun 2017 07:23:11 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 32828E09518A; Tue, 27 Jun 2017 09:23:09 +0200 (CEST) From: Ole Troan Message-Id: <86260254-02AA-4B39-99AF-D5F4230C9FC8@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_06795520-D0CD-4772-A6DC-83179D3B89DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them Date: Tue, 27 Jun 2017 09:23:08 +0200 In-Reply-To: Cc: Simon Hobson , 6man WG To: Dae Young Kim References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 07:23:13 -0000 --Apple-Mail=_06795520-D0CD-4772-A6DC-83179D3B89DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dae, > Haven=E2=80=99t been the last two bullets deprecated by RFC 5942? Yes, absolutely. Thanks for correcting me! Ole >=20 > =E2=80=94=E2=80=94 > DY >=20 >> On 26 Jun 2017, at 7:51 PM, Ole Troan wrote: >>=20 >> That is independent of on-link-ness being indicated in the PIO option = or not. Two neighbours at the IP level can discover they are on-link in = several different ways: (from RFC4861): >>=20 >> on-link - an address that is assigned to an interface on a >> specified link. A node considers an address to be = on- >> link if: >>=20 >> - it is covered by one of the link's prefixes = (e.g., >> as indicated by the on-link flag in the Prefix >> Information option), or >>=20 >> - a neighboring router specifies the address as = the >> target of a Redirect message, or >>=20 >> - a Neighbor Advertisement message is received for >> the (target) address, or >>=20 >> - any Neighbor Discovery message is received from >> the address. >=20 --Apple-Mail=_06795520-D0CD-4772-A6DC-83179D3B89DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZUgfcAAoJEL7aWKiYQt92K/UP/3WSyOT3i0b9aFIp8SG1iPQi XWhscY9SLjd7XChHdfE5dRRJOZtOwrIgnSFcXdvXXmDqo4TMDvcfDR+mMC/s3awI sL+Rgy7eASYV7M0cAx1ggk5PrVzJ7u1G8wsh/AsGbjyqSv/X1WDSytAFvni6KYBW YSj/+jnePCqvLkWT/rVcz39mApgA5OhWBTepiAnPlKQMeqbrGZhSZYFb6QytQkqK 8mvboMDZtNwspCFI+dT5G6163u8pXny9ga9ZqfteJeBfPYjohlMVIf00k64OzbQw z6jGYS3USLqchFN1A0b9EGTuqOrMvLYd0lueKMGh2F3H9LoHRzkDS5A4qJeqs2dr eSv4fn3lGqbkHZFnOnKFyYGOfHQt+0ztU9OkfnZMHA14KP0A0cOGA+XemLiwbxlj BKAnHOixsRqoi2cdZrsBthJK6cd1ezaW4nexe9UN8xT/ifWXREKyP2aWyq9fAKWE onFCnIW6FUWr3QGUnZmuHymY12YPfgL5mZ2vQnFmZ9JmNVFQ/MgYZvqVt0OnY9Rs qeLQVJJ0YyYRk92VfUWwrUs6ReN2CAk8FVSqAW1PCoziPMDvQRw1e7CCcib/XL7l 6DusXegOIJZ+Q1K8FSh6eYfhtMmC/HXQrZ0JveEw6++vHhibYKSUFZ09a+kyO/v/ Kl/aAofHdYt5tm8hme5M =y+pP -----END PGP SIGNATURE----- --Apple-Mail=_06795520-D0CD-4772-A6DC-83179D3B89DF-- From nobody Tue Jun 27 00:24:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300F812EBF6 for ; Tue, 27 Jun 2017 00:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO2yjP1n_V-y for ; Tue, 27 Jun 2017 00:24:31 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 45077128C83 for ; Tue, 27 Jun 2017 00:24:30 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id u36so3256160pgn.3 for ; Tue, 27 Jun 2017 00:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eL8tai2D6G1D28VRZmsXN+NztY3JDEczS0mtIAChRAA=; b=CkOHlew8/BTFlfHkO1i1pgpWY7DOelE7qe+A7P8Vb/7m3jYi0duiIwhwK6osMc3uL5 AK010gUPK3E8SMTYqghMgICZtTyZki3hS75Kvdz7DQ8tuGdN7uwNVkbCLvKbIbiHjkqU sAEIQMJEmBCDbKv0uRUwI6EekFU08FtT8xmc97b78gY3LiGbaAj5u36s/gRfQ+afFmi9 glrLNp/rHifo0VJ3zL/RkGb/v+cf/7SMHniyfdD+v1OabGv0pKwEJ89ysoxtAIfSNKDF O5HdZm4zGw6QhNUc/EDO7ciDlc0mc/XxFSL2ObbjtwBJBiD7lhI6yS2AqOuHNqwzgHu+ 4hAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eL8tai2D6G1D28VRZmsXN+NztY3JDEczS0mtIAChRAA=; b=a9BvsxWb1Vr+fznNqvyoo6J2KJSrQc3NoiMdVaOVgY7OFwdiJUy44DjbMjmLpIC3JI DnmX5uqvJMqKjMupcixHVgkBfOMFFYozXqbZZS2vDRvXgTyBjdKr7bd1GN6xxJWHOr+Y +wsuve5Rpv5gg3ws60G+sbTcCDAFqrV0jL4LoL2p53R20fG3DVev8v49imxbq3hTLDvN x/qKrEuhXDc5MkE4U1t5w3fvgPPMjZT94GXxbnQwKjZzdimZLY3fNiAPndi4XJ83fjaI +uNZEUJ8URvCokYdVPyMecAbHq3vc0bgJ5e/vzQFE9hqd+BuxxALKSBGrm5MotsU2Ahs G42A== X-Gm-Message-State: AKS2vOywNxgXLPLwnR3HL2kzihqP4UTHD0AQGP5CCt8+tWl1uKmO8RV8 n/xZg4TiAC1VkH04ejo= X-Received: by 10.98.58.209 with SMTP id v78mr3975923pfj.142.1498548269868; Tue, 27 Jun 2017 00:24:29 -0700 (PDT) Received: from [172.30.1.27] ([121.140.121.133]) by smtp.gmail.com with ESMTPSA id d62sm4137144pga.2.2017.06.27.00.24.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 00:24:29 -0700 (PDT) From: Dae Young Kim Message-Id: <3463E867-A995-4E7D-8F65-450E38E4DAB7@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B87245A2-381A-41BD-8101-B6250FDFBDF5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Mixing up threats, expecting a single perfect mitigation to all of them Date: Tue, 27 Jun 2017 16:24:25 +0900 In-Reply-To: <86260254-02AA-4B39-99AF-D5F4230C9FC8@employees.org> Cc: Simon Hobson , 6man WG To: Ole Troan References: <8819DBFA-76CD-4364-A7F9-3FBC13392CF5@thehobsons.co.uk> <9b0580cd-9081-1958-83df-963c65fa3fc0@gmail.com> <778037D8-28E7-47FF-82C9-2C8CB9CB5345@employees.org> <86260254-02AA-4B39-99AF-D5F4230C9FC8@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 07:24:33 -0000 --Apple-Mail=_B87245A2-381A-41BD-8101-B6250FDFBDF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Relax.. I=E2=80=99m not wrong=E2=80=A6 =E2=80=94=E2=80=94 DY > On 27 Jun 2017, at 4:23 PM, Ole Troan wrote: >=20 > Dae, >=20 >> Haven=E2=80=99t been the last two bullets deprecated by RFC 5942? >=20 > Yes, absolutely. Thanks for correcting me! >=20 > Ole >=20 >=20 >>=20 >> =E2=80=94=E2=80=94 >> DY >>=20 >>> On 26 Jun 2017, at 7:51 PM, Ole Troan wrote: >>>=20 >>> That is independent of on-link-ness being indicated in the PIO = option or not. Two neighbours at the IP level can discover they are = on-link in several different ways: (from RFC4861): >>>=20 >>> on-link - an address that is assigned to an interface on a >>> specified link. A node considers an address to be = on- >>> link if: >>>=20 >>> - it is covered by one of the link's prefixes = (e.g., >>> as indicated by the on-link flag in the Prefix >>> Information option), or >>>=20 >>> - a neighboring router specifies the address as = the >>> target of a Redirect message, or >>>=20 >>> - a Neighbor Advertisement message is received for >>> the (target) address, or >>>=20 >>> - any Neighbor Discovery message is received from >>> the address. >>=20 >=20 --Apple-Mail=_B87245A2-381A-41BD-8101-B6250FDFBDF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Relax.. I=E2=80=99m not wrong=E2=80=A6

=E2=80=94=E2=80=94
DY

On 27 Jun 2017, at 4:23 PM, Ole Troan <otroan@employees.org> wrote:

Dae,

Haven=E2=80=99t been the last two bullets deprecated by RFC = 5942?

Yes, absolutely. Thanks = for correcting me!

Ole



=E2=80=94=E2=80=94
DY

On 26 Jun 2017, at 7:51 = PM, Ole Troan <otroan@employees.org> wrote:

That is independent of on-link-ness being indicated in the = PIO option or not. Two neighbours at the IP level can discover they are = on-link in several different ways: (from RFC4861):

on-link     - an address that is assigned = to an interface on a
=             &n= bsp;  specified link.  A node considers an address to be = on-
=             &n= bsp;  link if:

=             &n= bsp;     - it is covered by one of the link's = prefixes (e.g.,
=             &n= bsp;       as indicated by the = on-link flag in the Prefix
=             &n= bsp;       Information option), or

=             &n= bsp;     - a neighboring router specifies the = address as the
=             &n= bsp;       target of a Redirect = message, or

=             &n= bsp;     - a Neighbor Advertisement message is = received for
=             &n= bsp;       the (target) address, = or

=             &n= bsp;     - any Neighbor Discovery message is = received from
=             &n= bsp;       the address.



= --Apple-Mail=_B87245A2-381A-41BD-8101-B6250FDFBDF5-- From nobody Tue Jun 27 14:12:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E808A12EB48 for ; Tue, 27 Jun 2017 14:12:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRACZtcch5Pm for ; Tue, 27 Jun 2017 14:12:28 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 27A3D12EB47 for ; Tue, 27 Jun 2017 14:12:28 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 32so35364965qtv.1 for ; Tue, 27 Jun 2017 14:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=84X/83/NAlwFIJcdWZKJ5k+x3MocOd4v81bBY1McrZc=; b=NbPnAC1c6mAPWaWczrHAkY2a+t7vI6ednrIwjkA21zA8hUogkPYmB5nZ6v16mo/Q48 UOGSAyuLu8pD94OvDTgMdoJci1CSpWFL2StGEgQESVwVswxPvKuEH9Gv5jGL4sfhOXgA GE+fwAsfAzCtYxH9ds+gURrxt0eqgf66V2Rnk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=84X/83/NAlwFIJcdWZKJ5k+x3MocOd4v81bBY1McrZc=; b=PVqYavwviizYYri87GGaQfteUGfkaaN7EPsRATu5pTi3qEChP+ZtXJtV6RmSSFbEiJ gmJxI6BGTulduJnPdpZAK95SrivFNaLJRiIkevIK/nClUc1dYzmzVpiyYTqOZEbkNnrb 1VvGovJXO0EQnAJ2ysQWdbxrh0o7aELPvogTHKyWO2G6IiwkD+M6UryRM0IQ6gt7WSB5 GDM4uPSDNV6Ox9SyVWyOF1Pui/WtWGc9Q4ZfZZQSQuNO37Ld0NO8nFSDwT6gatmtxTPY B4Csic2eFc/nZ21uAMPCqd6I9vatA1DWt1ngrm+pk0qED8b9EmuhM0GozmgjEtflfPBH CQWg== X-Gm-Message-State: AKS2vOwo1yXxnGYWVoNs21rOgpgjOePtVCgxsd8hI62Ya+Q8DJVFgLDw x7V+XPlNcL5WUabgBkFzV03x/lL0a4yS X-Received: by 10.237.55.129 with SMTP id j1mr8700027qtb.152.1498597947296; Tue, 27 Jun 2017 14:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.5.130 with HTTP; Tue, 27 Jun 2017 14:12:06 -0700 (PDT) In-Reply-To: References: <2506bca8-684d-f03f-955f-7c140bc2dca1@gmail.com> <79FBE5B6-41CB-497B-85C0-00714F2FAEAB@jisc.ac.uk> From: Timothy Winters Date: Tue, 27 Jun 2017 17:12:06 -0400 Message-ID: Subject: Re: node requirements text [was: Proposed revised Extension Header text for rfc2460bis] To: Tom Herbert Cc: Tim Chown , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a114145024f74d30552f7864e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 21:12:31 -0000 --001a114145024f74d30552f7864e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, We are working on new revision, do you have some text for 6434-bis for extension header text? Regards, Tim On Tue, May 2, 2017 at 1:53 PM, Tom Herbert wrote: > On Tue, May 2, 2017 at 8:41 AM, Tim Chown wrote: > > Hi, > > > >> On 2 May 2017, at 16:04, Tom Herbert wrote: > >> > >> > >> > >> Btw, this discussion is not just limited to intermediate nodes. As I > >> mentioned in another thread we intend to add configurable limits to > >> the number of options that are accepted at a destination host. When > >> the destination drops the packet because of such limits it is > >> indistinguishable to the source host from an intermediate node > >> dropping the packet, so any attempted mitigations (like sending an > >> ICMP error) should similar. > >> > >> I don't think the wording in RFC2460bis needs to change, but maybe > >> some guidance could be added to node requirements... > > > > I think I saw you mention this before, and it sounds reasonable. Feel > free to propose text for 6434-bis =E2=80=A6 > > > It was Bob Hinden's suggestion to consider modifying node requirements > for host side processing of EH. I will propose some text. > > Tom > > > > Tim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a114145024f74d30552f7864e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

We are working on new revision,= do you have some text for 6434-bis for extension header text?
Regards,
Tim
<= br>
On Tue, May 2, 2017 at 1:53 PM, Tom Herbert <= span dir=3D"ltr"><tom@herbertland.com> wrote:
On Tue, May 2, 2017 at 8:41 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> Hi,
>
>> On 2 May 2017, at 16:04, Tom Herbert <tom@herbertland.com> wrote:
>>
>> <snip>
>>
>> Btw, this discussion is not just limited to intermediate nodes. As= I
>> mentioned in another thread we intend to add configurable limits t= o
>> the number of options that are accepted at a destination host. Whe= n
>> the destination drops the packet because of such limits it is
>> indistinguishable to the source host from an intermediate node
>> dropping the packet, so any attempted mitigations (like sending an=
>> ICMP error) should similar.
>>
>> I don't think the wording in RFC2460bis needs to change, but m= aybe
>> some guidance could be added to node requirements...
>
> I think I saw you mention this before, and it sounds reasonable. Feel = free to propose text for 6434-bis =E2=80=A6
>
It was Bob Hinden's suggestion to consider modifying node requir= ements
for host side processing of EH. I will propose some text.

Tom


> Tim

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



--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a114145024f74d30552f7864e-- From nobody Tue Jun 27 14:39:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFE812EB38 for ; Tue, 27 Jun 2017 14:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUMeCSc031nK for ; Tue, 27 Jun 2017 14:39:27 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 1BE281200C5 for ; Tue, 27 Jun 2017 14:39:26 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id i2so35775618qta.3 for ; Tue, 27 Jun 2017 14:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m+xH7YfulP7MpROp1NiR5r26+UfemFfdgf58ib9PR1o=; b=aZ8NHG/lTB/iuS6QsvEY5VXanY7OnNMlB9WktVSa/3LATE6OBAZ6DijYvkZlqpqg0z CBuVxgBUA3qf3bzXQHPJOMJ4c7E7WKJ2dvZspqTADv4H855wtiCqQJE3RwmpZznHFjW4 KDHjZSQAr5qMeqhqF9H0F7HFdWFUuEFkSmENNUdWOOgaPfl0a04i3vWKBFr8JrvHFWRf pjRNKeCDJjL4/ej+G++VOI7akCSQ+dQpx4HV+CVEKx9UYeZxxDSbiD7zrhXkKIrLJswa lYCkMk/IG0jj+GZF/w/BsRLrgFm8pzUd+EoZ1GxCbUsr7TcSM40PECD7EsjZQGnY6LOq LiEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m+xH7YfulP7MpROp1NiR5r26+UfemFfdgf58ib9PR1o=; b=cNXM+BzBo2phndDV82CUvYNvLDsQtiA/SrUgud/PZ70zBp4Esne3kylZ4naFNv8me1 NlqWE8HpPwR5nAWXsO3Jlr4LJmqCPYoo1Bzh5AXgHhgiMdlMKx32p+aMkmsHKkzc2umC E8536KeK4EXZRd8FffNORtUwC/Od3SrxVdssztuitk2EqKtEAH/fDY0tGHlksxgCQN7H cAItMCwhgYNcr55TjXg4gqZR0KJGVcd2S2mbyCzQtBdLeb+mYxuqpj4q0zu3ZxnTs/Ur 307zTpuxWF6OwSxFxP6s8+IjtVYoPQ6JX9LOCdrf18bDXyOtdh6ILwVyv5Qw6W0w7sPQ UhQA== X-Gm-Message-State: AKS2vOxLDt/2hMMyAwyAqhf8VF0yGgqbOEfz0G4TTAJCcadZNwihjpVV eq9gRTE/cQRzzwtWCToI/Y59aNFQAw== X-Received: by 10.200.49.73 with SMTP id h9mr8899600qtb.13.1498599565114; Tue, 27 Jun 2017 14:39:25 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.43 with HTTP; Tue, 27 Jun 2017 14:39:24 -0700 (PDT) In-Reply-To: <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 27 Jun 2017 14:39:24 -0700 X-Google-Sender-Auth: SDblc4jHKiwTPPBbVCzYPJ1Jmns Message-ID: Subject: Re: To: Brian E Carpenter Cc: IPv6 IPv6 List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 21:39:29 -0000 At Thu, 22 Jun 2017 09:38:04 +1200, Brian E Carpenter wrote: > > I think this is getting really close. However, there still seems to be an > > implication that a subnet must be /64 or 64 bits for both address > > generation and on-link determination. > > Yes, that's what it says, except for documented exceptions. As far as I > understand the motivation of my co-authors on draft-bourbaki, their main > objection to the previous rfc4291bis was that it didn't allow for those > documented exceptions. > > Since SLAAC has always assumed that the two lengths are equal, What do you mean by this? Do you mean "SLAAC has always assumed the prefix length for address generation and the prefix length for on-link determination are equal"? Specifically which text of RFC4862 says that (or are you referring to other RFCs for SLAAC)? -- JINMEI, Tatuya From nobody Tue Jun 27 15:12:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B0129AEB for ; Tue, 27 Jun 2017 15:12:39 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ix9ASbCYAhI for ; Tue, 27 Jun 2017 15:12:38 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45649124D37 for ; Tue, 27 Jun 2017 15:12:38 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c73so23056581pfk.2 for ; Tue, 27 Jun 2017 15:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+hr5tcUFDmqQH9uDqciIq/p9V09mzgUAtgRRF6lAdRE=; b=J+U1q1ejw6f+UYQcFJ4AHsWQ4y1nozyUD9W6J6cVpAaYIc6Tx2g1WT6vRsZa2XYpmo doH+9is92ISAgJTDrjOSk2Hi+YWgk621HYmaqs5+6Wal4MHBipXwyXZXz7M2wJOXDtsy 1wdgur40n1IxCigt3YAX86wanr4pPCLRc6lOfds7I/YxpDcKPXffmLm2LELPuVB7iXdX PES+6NrgfmYna009wVzC/eGRFHeYN6RZIBSf9ZePB7E6QPj1QJ2zr/iJ91XextEFSxGH BCRJvmVCNoTm1TL0ekpy1n/S2k+7Il9Mjq4+T0UpzkUTh4SSZP52lHNFkWQOue7l94+6 ihtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+hr5tcUFDmqQH9uDqciIq/p9V09mzgUAtgRRF6lAdRE=; b=tVlby3SxjFcoPy+W4JWITAlcTSMOyUyHIP2nGH32aQZPWvpVTRvaD8NsBWKQtMusPa egvrDO9QhEIbAArSskdymWJic26gAyMoYI2d7vg/AP3nsKqI8Y2fAEKWn55ByT3NB73x k4oiqjDbByF0K+bmsx7IxArzW1/nXeIDrkXBElEXErmS1dbI261rLwxuH9CJWYaNrPEp LerkvtJPsKSMeC3LJ+1OgjzfWy/WoG6FPfzRtpUpN6Gd2V0PrgBZ8/7uY01oLigLglhH gCg8SDdrsGanxvwWquUmn/zz2yACRH1wQBAKUXnKhdksWBQXdYVFt5S0UGvt5QtPT954 y2MQ== X-Gm-Message-State: AKS2vOxmtxFA13GhxmZGKqVND0JES5EJZmG/q7MD9sCQfwENvGLXk0t+ bLmW9DbeWITrhXaZ X-Received: by 10.99.122.3 with SMTP id v3mr7202888pgc.98.1498601557768; Tue, 27 Jun 2017 15:12:37 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:b57c:d390:f82e:cdb2? ([2620:0:10e7:10:b57c:d390:f82e:cdb2]) by smtp.gmail.com with ESMTPSA id r62sm507951pfb.39.2017.06.27.15.12.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 15:12:37 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CAA3F812-8FFE-4146-A1D7-F41DD21B14E8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Tue, 27 Jun 2017 15:12:29 -0700 In-Reply-To: <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> Cc: ipv6@ietf.org To: Brian E Carpenter References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 22:12:39 -0000 --Apple-Mail=_CAA3F812-8FFE-4146-A1D7-F41DD21B14E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 21, 2017, at 14:38, Brian E Carpenter = wrote: >=20 > Since SLAAC has always assumed that the two lengths are equal, I = don=E2=80=99t see any discrepancy between rfc4291bis-08 and reality, = which is as it should be for an Internet Standard. I=E2=80=99m still further confused now. Are you now saying that LwIP is = correctly interpreting RFC 4291 by assuming the two lengths must be = equal and rejecting advertisements containing a different on-link prefix = length than is the standard address configuration prefix length for the = link type? --james woodyatt > --Apple-Mail=_CAA3F812-8FFE-4146-A1D7-F41DD21B14E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 21, 2017, at 14:38, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Since SLAAC has = always assumed that the two lengths are equal, I = don=E2=80=99t see any discrepancy between rfc4291bis-08 = and reality, which is as it should be for an Internet = Standard.

I=E2=80=99m still = further confused now. Are you now saying that LwIP is correctly = interpreting RFC 4291 by assuming the two lengths must be equal and = rejecting advertisements containing a different on-link prefix length = than is the standard address configuration prefix length for the link = type?

--james woodyatt <jhw@google.com>



= --Apple-Mail=_CAA3F812-8FFE-4146-A1D7-F41DD21B14E8-- From nobody Tue Jun 27 18:02:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF5129B22 for ; Tue, 27 Jun 2017 18:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXKJgdezRL3Z for ; Tue, 27 Jun 2017 18:02:46 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 A11B6127241 for ; Tue, 27 Jun 2017 18:02:46 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id j186so23501426pge.2 for ; Tue, 27 Jun 2017 18:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5EWqXvtkrtCL2/OAsWo9MUqy3OT9Rni2Y/41IuNa0qw=; b=CTvYDdb+9+YR2yi9J79KmxDwr8BStMqCL2GasfAb2ch5evlZW2WIrpfv2TERzGkmQF udR3MBr4UOwzKzSH7RBUzidsd8QpHyltErWy96bEH4d3eH+i0xzHPVQMAOx1U2iUBSVp 7rcO2WrQrvOg24h227x+YwpsVUMO+v2f/zaGiVpkSvvDPfGIgddHvdPk21IKxdoYxRS5 sFbfjxrAFd3CyGGpV2UujKIp/85U6UAwRBxR/NQS3PGveGxvNNI9e1dUUBmrZ7iYx5ys P9xIfGe8xwL4XIb4XjWopyuKZngmOEYS/ldU7WVry0XlHujlh1qKkMY7oNxjAvvUb5ML LljQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5EWqXvtkrtCL2/OAsWo9MUqy3OT9Rni2Y/41IuNa0qw=; b=SADYigN19PUfCf2sWZbR/6F5jjv+xVcZsuGQWABviBoP+/vlF09N2hh5ywXvw8yRpq qyYffm8Not35+EomEgdwoPe/jmuUMj+sIHxa1GHsMDn0vZwVIoJbOn+wZukj/QqNQ/ia oOADsaNcZzsx/fKlfgEsmggin9tk1rU5Gi97zrFUI7D1fAY6K9BaAoRTDk8dUAEVisAT arFWNd0VUKQ3WUQVyHVbUS9iHpsyVoanh0Scen28g4kddb99LabxSS+aRUc5nHqt4hjN JBVdguZohYSFtXklfS8OOnCqLAoW5CSGsUvGL99pO9I0tkqzE4z8l/ESIYDCrQ/6RsyJ qP3g== X-Gm-Message-State: AKS2vOxxPZS1jk+2fJ3roYbBzI6MlN5lhdoDMNAYotm3Swc3C73XOPuq mI0u6LRV9aExA3HZ X-Received: by 10.84.213.8 with SMTP id f8mr8813221pli.22.1498611765881; Tue, 27 Jun 2017 18:02:45 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id 197sm678695pga.58.2017.06.27.18.02.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 18:02:45 -0700 (PDT) Subject: Re: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , james woodyatt Cc: IPv6 IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> Date: Wed, 28 Jun 2017 13:02:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 01:02:48 -0000 On 28/06/2017 09:39, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Thu, 22 Jun 2017 09:38:04 +1200, > Brian E Carpenter wrote: >=20 >>> I think this is getting really close. However, there still seems to = be an >>> implication that a subnet must be /64 or 64 bits for both address >>> generation and on-link determination. >> >> Yes, that's what it says, except for documented exceptions. As far as = I >> understand the motivation of my co-authors on draft-bourbaki, their ma= in >> objection to the previous rfc4291bis was that it didn't allow for thos= e >> documented exceptions. >> >> Since SLAAC has always assumed that the two lengths are equal, >=20 > What do you mean by this? Do you mean "SLAAC has always assumed the > prefix length for address generation and the prefix length for on-link > determination are equal"? =20 Yes. > Specifically which text of RFC4862 says > that (or are you referring to other RFCs for SLAAC)? It doesn't say that. But on a normal broadcast LAN nothing else makes much sense, so I believe that users have always made this assumption, regardless of what implementations might support. On 28/06/2017 10:12, james woodyatt wrote: =2E.. > I=E2=80=99m still further confused now. Are you now saying that LwIP is= correctly interpreting RFC 4291 by assuming the two lengths must be equa= l and rejecting advertisements containing a different on-link prefix leng= th than is the standard address configuration prefix length for the link = type? No, because RFC 4291 doesn't say that: it simply states the IID length. So you're describing an implementation choice, which very possibly doesn'= t conform to RFC 4862. Brian From nobody Wed Jun 28 09:41:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E9A1289B0 for ; Wed, 28 Jun 2017 09:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VvmVn9Ca3Ob for ; Wed, 28 Jun 2017 09:41:48 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 EB9F51200B9 for ; Wed, 28 Jun 2017 09:41:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 33AC61B3 for ; Wed, 28 Jun 2017 16:41:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBWV0kNdbATz for ; Wed, 28 Jun 2017 11:41:47 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id D927CC1C for ; Wed, 28 Jun 2017 11:41:46 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id 82so21587674vki.3 for ; Wed, 28 Jun 2017 09:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CSu/IGUgIFbctcyJtqcFhQR46Fvlus/MphASPrBYYV8=; b=XAMR2mgKTp1YmRcSBRL1MP7mTQOG91Cd/eRIn4cHjZ/NbmUYUE0y0ziKhO437x3b5K 7Wmdhc/8lJw3bQg/UKFyxs1bseu2zuEeu1F2GsUpe4IcGxtTmEkSTCX7ZApt7vincqas l0AGNzzrnr4/2kA9g4VSu0FULpRiyKfNXtfFs0e8gg5S4Pz8kPdYl2waeq4tSc8EM1Wj ZkN1wwHUMH0TgHqajW4jyh5U5CJCGmD+W3u/y45iBlAEcPLXXdSG88EoRb626AOWIg9Y 3cSMvXgK1lEL7yOIQNTSrk3dovt7MuEKVCMU9KNE2xb6rcPTYY4Od9F7h6iKIK0qp7mJ Lg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CSu/IGUgIFbctcyJtqcFhQR46Fvlus/MphASPrBYYV8=; b=PlTLmW5VoGZbBGRQWfNfR0HhK4rExbds0WGeHK4E9FpyaJU0ZG6ET0uXCoe3VIS2XQ vhkisuxmUM03StOLlf0IC8s9nMew15kMaMnojKtSgCXd/o6AzAZXMIqdvGbt+/L1ness PspnyZgxmsa9DgV/KEo/3U5OrdBsxCpGf0NT6EutCrUoKmu1OorTRH4UDo61f/vgJ5Gh 4Wfr4OekNB4t4mTsS8Zkf67tIyGLj/RsIbONq2KiJ2+CPlThjBto51F0u8gRmw4Nnjjd rtcxdQppR097H+POeeYlhWVJL3cK2VqyAMt/CgUo84Q+JckzJizNC6ckyrEQ5kFFLGxu UZUQ== X-Gm-Message-State: AKS2vOwtsZv9OEAgbTgJsVXz6Ud39Rp6lZWqNp3OzEB0TOE4nnyelWsJ 703n51VwIjir0cH7ezmmUOW5S2jnSClMqKVMlHQdTTInETl7BQwDLctMET17fw1WuMO0zSnH1uK OOB7U/UYNfn4N4zk= X-Received: by 10.176.95.69 with SMTP id z5mr6932364uah.113.1498668106009; Wed, 28 Jun 2017 09:41:46 -0700 (PDT) X-Received: by 10.176.95.69 with SMTP id z5mr6932346uah.113.1498668105753; Wed, 28 Jun 2017 09:41:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Wed, 28 Jun 2017 09:41:44 -0700 (PDT) In-Reply-To: <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> From: David Farmer Date: Wed, 28 Jun 2017 11:41:44 -0500 Message-ID: Subject: Re: To: Brian E Carpenter Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , james woodyatt , IPv6 IPv6 List Content-Type: multipart/alternative; boundary="f403045fdfa414940d055307dc73" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 16:41:51 -0000 --f403045fdfa414940d055307dc73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 8:02 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 28/06/2017 09:39, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > At Thu, 22 Jun 2017 09:38:04 +1200, > > Brian E Carpenter wrote: > > > >>> I think this is getting really close. However, there still seems to > be an > >>> implication that a subnet must be /64 or 64 bits for both address > >>> generation and on-link determination. > >> > >> Yes, that's what it says, except for documented exceptions. As far as = I > >> understand the motivation of my co-authors on draft-bourbaki, their ma= in > >> objection to the previous rfc4291bis was that it didn't allow for thos= e > >> documented exceptions. > >> > >> Since SLAAC has always assumed that the two lengths are equal, > > > > What do you mean by this? Do you mean "SLAAC has always assumed the > > prefix length for address generation and the prefix length for on-link > > determination are equal"? > > Yes. > > > Specifically which text of RFC4862 says > > that (or are you referring to other RFCs for SLAAC)? > > It doesn't say that. But on a normal broadcast LAN nothing else > makes much sense, so I believe that users have always made this > assumption, regardless of what implementations might support. > I would agree the normal use of SLAAC is with "64 bits for both address generation and on-link determination." For normal (common, default, etc...) use that is fine, you will have a PIO for /64 with both A and L flags set, and is as it probably should be most of the time. Further, for link-local address generation and on-link determination 64 bits is always the case, all valid link-local address are always on-link by definition. However, the protocol itself doesn't require use of 64 bits for on-link determination for GUA regardless of how the address is generated and I think this is the root of the disagreement here. In reality if it is made clear on-link determination may normally be based on a /64, but is not required to be /64, then manual configuration of an address with an on-link prefix of anything between 0 and 128 isn't actually an exception, it is simply a consequence of how the protocol actually is intended to work, and the same goes of DHCP with an on-link RA other than /64. Now in my option, with the exception of point-to-point links, on-link determination based on /64 prefix is RECOMMENDED. On 28/06/2017 10:12, james woodyatt wrote: > ... > > I=E2=80=99m still further confused now. Are you now saying that LwIP is > correctly interpreting RFC 4291 by assuming the two lengths must be equal > and rejecting advertisements containing a different on-link prefix length > than is the standard address configuration prefix length for the link typ= e? > > No, because RFC 4291 doesn't say that: it simply states the IID length. > So you're describing an implementation choice, which very possibly doesn'= t > conform to RFC 4862. > And subnet prefix is tangled up in the definition of IID and it's length, which without something saying otherwise from the definition and use of subnet in IPv4 it is perfectly reasonable to make such an assumption. Therefore we need to fix this misconception in RFC4291bis. I believe the way to clear this up is to say "a 64 bit IID is REQUIRED for address generation, and /64 prefix is RECOMMENDED for on-link determination." For the sake of discussion, lets say I have pair of nodes connected with an ethernet, I manually configure one with 2001:db8::1:1/112 and the other with 2001:db8::1:2/112. The first node will have an interface will have a link-local address of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 1. The second node will have an interface will have a link-local address of FE80::/64 with a random 64 IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2. Now I add a router, and manually configure the address as 2001:db8::1:3/112, it will generate a link-local address of FE80::/64 probably with an EUI-64 as the IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 3, the router will generate a RA with a PIO of 2001:db8::1/112 with L=3D1 and A=3D0, if A=3D1 this would be an invalid PIO. Further, I co= uld tell the router to set M=3D1 in the RA, and configure a DHCPv6 server on th= e router to respond with addresses 2001:db8::1:4 through 2001:db8::1:ffff. Now, I can attach an additional node and if able it will receive and address via DHCPv6 and for this discussion lets say it receives 2001:db8::1= :4, and from the RA it gets the on-link prefix of 2001:db8::1/112. Lets be clear, this is not a recommended configuration, however it is nevertheless a valid configuration, it doesn't violate protocol. And I believe this is constant with saying "a 64 bit IID is REQUIRED for address generation, and /64 prefix is RECOMMENDED for on-link determination." However, if we simply say "a 64 bit IID is REQUIRED" then I believe it implies "64 bits for both address generation and on-link determination is required," which it is not. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --f403045fdfa414940d055307dc73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 27, 2017 at 8:02 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 28/06/2017 09:39, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote:
> At Thu, 22 Jun 2017 09:38:04 +1200,
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
>>> I think this is getting really close.=C2=A0 However, there sti= ll seems to be an
>>> implication that a subnet must be /64 or 64 bits for both addr= ess
>>> generation and on-link determination.
>>
>> Yes, that's what it says, except for documented exceptions. As= far as I
>> understand the motivation of my co-authors on draft-bourbaki, thei= r main
>> objection to the previous rfc4291bis was that it didn't allow = for those
>> documented exceptions.
>>
>> Since SLAAC has always assumed that the two lengths are equal,
>
> What do you mean by this?=C2=A0 Do you mean "SLAAC has always ass= umed the
> prefix length for address generation and the prefix length for on-link=
> determination are equal"?

Yes.

> Specifically which text of RFC4862 says
> that (or are you referring to other RFCs for SLAAC)?

It doesn't say that. But on a normal broadcast LAN nothing else
makes much sense, so I believe that users have always made this
assumption, regardless of what implementations might support.

I would agree the normal use of SLAAC is with "= 64 bits for both address generation and on-link determination." For no= rmal (common, default, etc...) use that is fine, you will have a PIO for /6= 4 with both A and L flags set, and is as it probably should be most of the = time. Further, for link-local address generation and on-link determination= =C2=A064 bits is always the case, all valid link-local address are always o= n-link by definition.=C2=A0=C2=A0

However, the pro= tocol itself doesn't require use of 64 bits for on-link determination f= or GUA regardless of how the address is generated and I think this is the r= oot of the disagreement here.
=C2=A0
In reality if it i= s made clear on-link determination may normally be based on a /64, but is n= ot required to be /64, then manual configuration of an address with an on-l= ink prefix of anything between 0 and 128 isn't actually an exception, i= t is simply a consequence of how the protocol actually is intended to work,= and the same goes of DHCP with an on-link RA other than /64.
Now in my option, with the exception of point-to-point links, o= n-link determination based on /64 prefix is RECOMMENDED.

On 28/06/2017 10:12, james woodyatt wrote:
...
> I=E2=80=99m still further confused now. Are you now saying that LwIP i= s correctly interpreting RFC 4291 by assuming the two lengths must be equal= and rejecting advertisements containing a different on-link prefix length = than is the standard address configuration prefix length for the link type?=

No, because RFC 4291 doesn't say that: it simply states the IID length.=
So you're describing an implementation choice, which very possibly does= n't
conform to RFC 4862.

And subnet prefix = is tangled up in the definition of IID and it's length, which without s= omething saying otherwise from the definition and use of subnet in IPv4 it = is perfectly reasonable to make such an assumption.=C2=A0 Therefore we need= to fix this misconception in RFC4291bis.

I b= elieve the way to clear this up is to say "a 64 bit IID is REQUIRED fo= r address generation, and /64 prefix is RECOMMENDED for on-link determinati= on."

For the sake of discussion, l= ets say I have pair of nodes connected with an ethernet, I manually configu= re one with 2001:db8::1:1/112 and the other with 2001:db8::1:2/112.=C2=A0

The first node will have an interface will have a l= ink-local address of=C2=A0FE80::/64 wit= h a random 64 bit IID, and a GUA with a subnet prefix of 2001:db8::1/112 an= d a 16bit IID of 1.=C2=A0 The second node=C2=A0will have an interfac= e will have a link-local address of=C2=A0FE80::/64 = with a random 64 IID, and a GUA=C2=A0with a subnet prefix of=C2=A02001:db8::= 1/112 and a 16bit IID of 2.=C2=A0=C2=A0

Now I add a router, and= manually=C2=A0configure the address as=C2=A02001:db8::1:3/112,=C2= =A0it will generate a link-local=C2=A0<= /span>address of=C2=A0FE80::/64 probably=C2=A0with = an EUI-64 as the IID, and a GUA=C2=A0with a subnet prefix of=C2=A02001:db8::= 1/112 and a 16bit IID of 3, the router will generate a RA with a PIO of=C2= =A02001:db8::1/112 with L=3D1 an= d A=3D0, if A=3D1 this would be an invalid PIO.=C2=A0 Further, I could tell= the router to set M=3D1 in the RA, and configure a DHCPv6 server on the ro= uter to respond with addresses=C2=A0=C2=A02001:db8::1:4 through=C2=A0= =C2=A020= 01:db8::1:ffff.
=
Now, I can attach an addition= al node and if able it will=C2=A0receive and address via DHCPv6 and for thi= s discussion lets say it receives=C2=A02001:db8::1:4, and from the RA it gets the on-link prefix of=C2=A02001:db8::1/112.
=
Lets be clear, this is n= ot a recommended configuration, however it is nevertheless a valid configur= ation, it doesn't violate protocol. And I believe this is constant with= saying "a 64 bit IID is REQUIRED for address generation, and /64 pref= ix is RECOMMENDED for on-link determination."

However, if we simply say "a 64 bit IID is REQUIRED" then = I believe it implies "64 bits for both address generation and on-link = determination is required," which it is not.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &am= p; Telecommunication Services
Office of Information Technology
Univer= sity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--f403045fdfa414940d055307dc73-- From nobody Wed Jun 28 10:52:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E27129B9C for ; Wed, 28 Jun 2017 10:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ady_u3I-t4RD for ; Wed, 28 Jun 2017 10:52:27 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71AF127078 for ; Wed, 28 Jun 2017 10:52:27 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id s66so37048773pfs.1 for ; Wed, 28 Jun 2017 10:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=J2nfI2eFIvYJa01jRJGkAfAgt/NkUnrYjSPu6k7clsY=; b=dgr5zVX10eC36xbEK4JDcIh+zR3TijI+D54w1shz5kvAzZxSissGbxc6qU0pyeAtUG 8gyuX/X/nCM4qTq9bO54jjoTXKy0BfPCfuJ+Sx9Kwm05c9OHVWMfb38uaydS2FGwcutK 1ddSVDmLZ5f6niucbRliXhLj8IdbGebrxMaZxGZUzd37O05ymfuNZRVuLtYbJBGPedh4 jFEV9ow0t+GSiaUbCXLmealevacn32YxyqOOqFGWCTMNR0D7YCv4IxzZm0GnPWT7vcIx V1zDgHJwZHgLdqZwtFlxgAsoMQFeMQmhsNv7WrAX7js0EXdnVl8FrL6vmFxr4QkNJiVL VwAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=J2nfI2eFIvYJa01jRJGkAfAgt/NkUnrYjSPu6k7clsY=; b=srzNaFF52gcKNSDGpHUDkVcpbRParuAZyKZLONNEzQ9ZiyL0AFrl+8bFg5YOoABauk VKztFXc0tiQBomPtr7PmvXEEG4FzaOCeZuQXgqP6kQwQkOXb8R0jvEqd/AAFaX6epGN1 fH8EeywE71qtW9+XWaxz8CQQ+z0a3Iv92ktjT1W8DzBWQqyfUfq6OOJbI4Np/OAs2iTq JhgfECk6QuZ9ifhYMlJ/qUuCAdKSwr55X1rn3DDVzFkbm94AmtJvshSmx/Zyagcvv7ix xMEbmXW7XFZr7bURhfQCe5/dfqb+5KfaxI/7AXLXNLotL9WVgEpvSWblslrD59boyW5k yGuQ== X-Gm-Message-State: AKS2vOyCXtQo9QG7WGzEC7ko3+u6Npt46RGolEw0Z63dXPe1xywyGWbM 8vL3d9dYH4xxwakHFYasiA== X-Received: by 10.98.207.2 with SMTP id b2mr8154502pfg.16.1498672347056; Wed, 28 Jun 2017 10:52:27 -0700 (PDT) Received: from [100.107.37.169] ([100.107.37.169]) by smtp.gmail.com with ESMTPSA id k18sm4977506pgf.5.2017.06.28.10.52.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 10:52:26 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 28 Jun 2017 10:52:25 -0700 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> To: IPv6 IPv6 List In-Reply-To: Message-Id: <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 17:52:30 -0000 On Jun 28, 2017, at 09:41, David Farmer wrote: >=20 > The first node will have an interface will have a link-local address = of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of = 2001:db8::1/112 and a 16bit IID of 1. The second node will have an = interface will have a link-local address of FE80::/64 with a random 64 = IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID = of 2. > [=E2=80=A6] To define a /112 subnet prefix means the IID must be only 16 bits long. = That=E2=80=99s not valid under RFC 4291. Specifically, when the DHCPv6 server generates the IID for the addresses = that it provides to hosts in IA_NA or IA_TA configuration options, those = addresses do not have /112 subnet prefixes and 16 bit IIDs. They have = /64 subnet prefixes and 64 bit IIDS. The first two paragraphs of RFC = 4291 =C2=A72.5.1 are clear about the requirements for the uniqueness = properties of IIDs, and these must be respected by SLAAC, DHCPv6 and any = other address configuration mechanism. >> Interface identifiers in IPv6 unicast addresses are used to = identify >> interfaces on a link. They are required to be unique within a = subnet >> prefix. It is recommended that the same interface identifier not = be >> assigned to different nodes on a link. They may also be unique = over >> a broader scope. In some cases, an interface's identifier will be >> derived directly from that interface's link-layer address. The = same >> interface identifier may be used on multiple interfaces on a = single >> node, as long as they are attached to different subnets. >>=20 >> Note that the uniqueness of interface identifiers is independent = of >> the uniqueness of IPv6 addresses. For example, a Global Unicast >> address may be created with a local scope interface identifier and = a >> Link-Local address may be created with a universal scope interface >> identifier. To highlight the [@RFC2119] keywords in the above above=E2=80=A6. "They are REQUIRED to be unique within a subnet prefix.=E2=80=9D "It is RECOMMENDED that the same interface identifier not be assigned to = different nodes on a link." "They MAY also be unique over a broader scope." And just to drive the point home: "Note that the uniqueness of interface identifiers is independent of the = uniqueness of IPv6 addresses." "Note that the uniqueness of interface identifiers is independent of the = uniqueness of IPv6 addresses." "Note that the uniqueness of interface identifiers is independent of the = uniqueness of IPv6 addresses.=E2=80=9D There is no easy and straightforward way to break the /64 subnet prefix = boundary declared by [@RFC4291] without making a major forklift upgrade = to the language defining the uniqueness properties of interface = identifiers independent of the uniqueness properties of IPv6 addresses. = We should not be entertaining any discussion of doing that in the = context of [@I-D.ietf-6man-rfc4291bis]. My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that it = tries to admit more variability in the length of interface identifiers = without clarifying how the uniqueness properties of interface = identifiers declared in [@RFC4291] are to be properly respected on links = where varying interface identifier lengths are in use. Shorter james: don=E2=80=99t try to do this in = [@I-D.ietf-6man-rfc4291bis], and if you insist on trying to do this in = another draft, then provide sufficient clarity about the uniqueness = properties of interface identifiers on links where their length is = variable and subject to dynamic operational configuration. --james woodyatt From nobody Wed Jun 28 12:41:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642B212EAC2 for ; Wed, 28 Jun 2017 12:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRfWWeD_16-U for ; Wed, 28 Jun 2017 12:41:18 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B13512EAC1 for ; Wed, 28 Jun 2017 12:41:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5SJfHjV029124; Wed, 28 Jun 2017 12:41:17 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5SJfFiZ029104 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 28 Jun 2017 12:41:15 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 12:41:15 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 12:41:15 -0700 From: "Manfredi, Albert E" To: james woodyatt , IPv6 IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS8C198zNl709EfUWKnaYWTqVEwaI7A5eA//+iT1A= Date: Wed, 28 Jun 2017 19:41:15 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> In-Reply-To: <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 19:41:20 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBqYW1lcyB3b29keWF0dA0KU2VudDogV2VkbmVzZGF5 LCBKdW5lIDI4LCAyMDE3IDEzOjUyDQoNCj4gVG8gZGVmaW5lIGEgLzExMiBzdWJuZXQgcHJlZml4 IG1lYW5zIHRoZSBJSUQgbXVzdCBiZSBvbmx5IDE2IGJpdHMgbG9uZy4NCj4gVGhhdOKAmXMgbm90 IHZhbGlkIHVuZGVyIFJGQyA0MjkxLg0KDQpJIGRvbuKAmXQgc2VlIHdoeSBub3QuIFRoZSBJSUQg aGFzIHRvIGJlICJ1bmlxdWUgd2l0aGluIGEgc3VibmV0IHByZWZpeCwiIHF1b3RlZCBkaXJlY3Rs eSBmcm9tIHNlY3Rpb24gMi41LjEuIChTYW1lIGFzIGZvciBJUHY0LikNCg0KPiBTcGVjaWZpY2Fs bHksIHdoZW4gdGhlIERIQ1B2NiBzZXJ2ZXIgZ2VuZXJhdGVzIHRoZSBJSUQgZm9yIHRoZQ0KPiBh ZGRyZXNzZXMgdGhhdCBpdCBwcm92aWRlcyB0byBob3N0cyBpbiBJQV9OQSBvciBJQV9UQSBjb25m aWd1cmF0aW9uDQo+IG9wdGlvbnMsIHRob3NlIGFkZHJlc3NlcyBkbyBub3QgaGF2ZSAvMTEyIHN1 Ym5ldCBwcmVmaXhlcyBhbmQgMTYgYml0DQo+IElJRHMuIFRoZXkgaGF2ZSAvNjQgc3VibmV0IHBy ZWZpeGVzIGFuZCA2NCBiaXQgSUlEUy4gVGhlIGZpcnN0IHR3bw0KPiBwYXJhZ3JhcGhzIG9mIFJG QyA0MjkxIMKnMi41LjEgYXJlIGNsZWFyIGFib3V0IHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0K PiB1bmlxdWVuZXNzIHByb3BlcnRpZXMgb2YgSUlEcywgYW5kIHRoZXNlIG11c3QgYmUgcmVzcGVj dGVkIGJ5IFNMQUFDLA0KPiBESENQdjYgYW5kIGFueSBvdGhlciBhZGRyZXNzIGNvbmZpZ3VyYXRp b24gbWVjaGFuaXNtLg0KDQpESENQIGNhbiBndWFyYW50ZWUgdW5pcXVlbmVzcyB3aXRoIHNob3J0 IElJRHMsIHdpdGhvdXQgYW55IHByb2JsZW0uIEkgdGhpbmsgdGhhdCB3ZSdyZSBiYWNrIHRvIHRo aXMgcHJvYmxlbSBhZ2Fpbi4gUXVvdGluZyBmcm9tIDIuNS4xOg0KDQogICBGb3IgYWxsIHVuaWNh c3QgYWRkcmVzc2VzLCBleGNlcHQgdGhvc2UgdGhhdCBzdGFydCB3aXRoIHRoZSBiaW5hcnkNCiAg IHZhbHVlIDAwMCwgSW50ZXJmYWNlIElEcyBhcmUgcmVxdWlyZWQgdG8gYmUgNjQgYml0cyBsb25n IGFuZCB0byBiZQ0KICAgY29uc3RydWN0ZWQgaW4gTW9kaWZpZWQgRVVJLTY0IGZvcm1hdC4NCg0K Tm90ZSB0aGF0ICJhbmQiIGNsYXVzZS4gVGhlIGFzc3VtcHRpb24sIGluIHRoZXNlIG9sZGVyIFJG Q3MsIGlzIHRoYXQgRVVJLTY0IGZvcm1hdCB3YXMgdXNlZCwgYW5kICp0aGVyZWZvcmUqIHRoZSBJ SUQgd2FzIGdvaW5nIHRvIGJlIDY0IGJpdHMgbG9uZy4gT25jZSB0aGF0IEVVSS02NCBhc3N1bXB0 aW9uIGJlY29tZXMgaW52YWxpZCwgc28gZG9lcyB0aGUgcmF0aW9uYWxlIGZvciA2NC1iaXQgSUlE cy4NCg0KTm93LCBmb3IgU0xBQUMsIHRvIG1pbmltaXplIHRoZSBjaGFuY2VzIG9mIElJRCBjb2xs aXNpb25zLCBtb3JlIGJpdHMgaXMgYmV0dGVyIHRoYW4gZmV3ZXIgYml0cy4gQW5kIHNvbWUgd2ls bCBhcmd1ZSB0aGF0IHRoZXJlIGFyZSBhbHNvIHNlY3VyaXR5IGJlbmVmaXRzIHdpdGggYSBzcGFy c2VseSBwb3B1bGF0ZWQgSUlEIGZpZWxkLiBCdXQgSSBkbyBub3QgdGhpbmsgaXQgaXMgdmFsaWQg dG8gcXVvdGUgUkZDcyB0aGF0IGFzc3VtZWQgRVVJLTY0IGFzIGEgcmVhc29uIHdoeSA2NC1iaXQg SUlEcyBhcmUgbWFuZGF0b3J5Lg0KDQoiTm90ZSB0aGF0IHRoZSB1bmlxdWVuZXNzIG9mIGludGVy ZmFjZSBpZGVudGlmaWVycyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgdW5pcXVlbmVzcyBvZiBJUHY2 IGFkZHJlc3Nlcy4iDQoNCkRvZXNuJ3QgbWF0dGVyLiBUaGF0IHdhcyBpbiBhIGRpZmZlcmVudCBj b250ZXh0LiBJZiB5b3UgZ28gb24gdGhlIG5vdGlvbiB0aGF0IEVVSS02NCBlbWJlZHMgYSBNQUMg YWRkcmVzcywgcHJlc3VtYWJseSBpdCBiZWNvbWVzIGEgdW5pcXVlIElJRCwgYW5kIHByZXN1bWFi bHksIHdpdGggU0xBQUMsIHlvdSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IGNvbGxpc2lvbnMu IFRoZXJlIGlzIG5vIG90aGVyIHJhdGlvbmFsZSBmb3IgZ2xvYmFsIHVuaXF1ZW5lc3Mgb2YgSUlE cy4NCg0KU28sIGFsbCBvZiB0aGF0IGlzIG5vdyBvdXQgdGhlIHdpbmRvdy4gU0xBQUMgKndpbGwq IHJlcXVpcmUgREFELCBpZiB0aGUgSUlEIGlzIGNob3NlbiBhdCByYW5kb20sIGV2ZW4gY29sbGlz aW9uIGNoYW5jZXMgYXJlIHNsaW0uIFNvIHRoZSBnbG9iYWwgdW5pcXVlbmVzcyBvZiBJSURzIGlz IGEgbW9vdCBwb2ludC4gVGhleSBjYW7igJl0IGJlIGFzc3VtZWQgdG8gYmUgZ2xvYmFsbHkgdW5p cXVlLCBub3IgYXJlIHRoZXkgcmVxdWlyZWQgdG8gYmUsIGZvciBTTEFBQy4NCg0KPiBNeSBwcmlu Y2lwbGUgY3JpdGljaXNtIG9mIFtASS1ELmJvdXJiYWtpLTZtYW4tY2xhc3NsZXNzLWlwdjZdIGlz DQo+IHRoYXQgaXQgdHJpZXMgdG8gYWRtaXQgbW9yZSB2YXJpYWJpbGl0eSBpbiB0aGUgbGVuZ3Ro IG9mIGludGVyZmFjZQ0KPiBpZGVudGlmaWVycyB3aXRob3V0IGNsYXJpZnlpbmcgaG93IHRoZSB1 bmlxdWVuZXNzIHByb3BlcnRpZXMgb2YNCj4gaW50ZXJmYWNlIGlkZW50aWZpZXJzIGRlY2xhcmVk IGluIFtAUkZDNDI5MV0gYXJlIHRvIGJlIHByb3Blcmx5DQo+IHJlc3BlY3RlZCBvbiBsaW5rcyB3 aGVyZSB2YXJ5aW5nIGludGVyZmFjZSBpZGVudGlmaWVyIGxlbmd0aHMgYXJlIGluDQo+IHVzZS4N Cg0KVGhlIGRyYWZ0IGF0dGVtcHRzIHRvIHJlc3RvcmUgYSBzZW5zZSBvZiBsb2dpYywgYmVjYXVz ZSB0aGVyZSdzIHRvbyBtdWNoIGNvbnRpbnVlZCBlbXBoYXNpcyBvZiBhIG1hbmRhdG9yeSA2NC1i aXQgSUlELCB3aGVuIHRoZSBtYWluIHJhdGlvbmFsZSBmb3IgaXQgaGFzIGJlZW4gZGVwcmVjYXRl ZC4gSWYgYW55dGhpbmcsIHRoZSBkcmFmdCBjb250aW51ZXMgdG8gYmUgdG9vIGNvbnNlcnZhdGl2 ZSwgZS5nLiwgaW4gYXNzdW1pbmcgdGhhdCBTTEFBQyBjYW4gb25seSB3b3JrIHdpdGggNjQtYml0 IElJRHMuDQoNCkJlcnQNCg0K From nobody Wed Jun 28 13:41:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99BD12EC6E for ; Wed, 28 Jun 2017 13:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd60EUE2vfw4 for ; Wed, 28 Jun 2017 13:41:44 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F2D1270AC for ; Wed, 28 Jun 2017 13:41:44 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id E3B25B53 for ; Wed, 28 Jun 2017 20:41:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH2YB9Ud6St6 for ; Wed, 28 Jun 2017 15:41:43 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id A2AF46BB for ; Wed, 28 Jun 2017 15:41:43 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id 40so23903658uav.14 for ; Wed, 28 Jun 2017 13:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4xX1LI6lwFoSACrBTfscIZjcbTjSnkvkfbMztWW+Zb4=; b=ZDMUBhXzG7b2uFcOzWN0flcs0PZalLcpj3E6lOPnVFtiJsRvG6IS0nEe9Q8ZAdL9Ox Fa/KK8PBzRGpiNWo7FW5qHqgpdu8Gn1B62ImqEwG1MmRJpe2YeXy8RtuqFa0o+j5OXoh oWv6+dwHrcTVgR/+zI6NMUB1jHulftXZcPHDv3ZoiYyWa+k1vdxkt1eTt7Pn4syyfeLr wvXgY5o3gsvmSJht+VqK19my/kJr39AIn5ypq1QLsPopr9gKwg56LPhDnQ0jra64ERdP QERNqGIYDYoHIvWU2UWB9mUDm9HngV41/OLr9mcFPdUfXQP5by4LY7n6XwkO0vFIP9px PDJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4xX1LI6lwFoSACrBTfscIZjcbTjSnkvkfbMztWW+Zb4=; b=jMtqtoYNoS9nX1IVhbXukP3kikAylvFCkOmHK7d/1pZKMSFoeCXNUVc4KNOdnRIobF eDlqBHhSupcXjfknK0dV0F2jQ0MkdH5uCYZVfJZuJzZwG1YzQj5nvUmBr5wGvsgZsmWa OwT//tt2cChx0HEsnPp93B0o3Adp7xuN4mjWEpkt5pcsriklbRuSEk0+nI2U8Ye9SKni cQkvSWkCa/onTDH+/f/2grZR0TCz725imopi4R/AN2LxO3mEgZENPqzQdIa8b3VU8sPF U/IOq1r8WTesZ5idopHli+qWnGhLAhC/hDS84NTo0yInLMSg/9e4lzu6a8zsh/shoi6s 8rlA== X-Gm-Message-State: AKS2vOwrvypJ9X98A2epMcvJvcJuJtj+AikimgYKuxQ4navK2Fr5E7tU D5Wf93Y8ehYMufr3vLrGLzDx7aGB1kG4jvaLjqxllHHkPQGvfETSF++ndffdZR8bELMDJ7PxzFN poEjVpKl7alDlBKg= X-Received: by 10.159.62.220 with SMTP id n28mr7618270uaj.142.1498682502853; Wed, 28 Jun 2017 13:41:42 -0700 (PDT) X-Received: by 10.159.62.220 with SMTP id n28mr7618262uaj.142.1498682502686; Wed, 28 Jun 2017 13:41:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Wed, 28 Jun 2017 13:41:42 -0700 (PDT) In-Reply-To: <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> From: David Farmer Date: Wed, 28 Jun 2017 15:41:42 -0500 Message-ID: Subject: Re: To: james woodyatt Cc: IPv6 IPv6 List Content-Type: multipart/alternative; boundary="089e0820758c34404705530b3670" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 20:41:47 -0000 --089e0820758c34404705530b3670 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2017 at 12:52 PM, james woodyatt wrote: > On Jun 28, 2017, at 09:41, David Farmer wrote: > > > > The first node will have an interface will have a link-local address of > FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of > 2001:db8::1/112 and a 16bit IID of 1. The second node will have an > interface will have a link-local address of FE80::/64 with a random 64 II= D, > and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2. > > [=E2=80=A6] > > To define a /112 subnet prefix means the IID must be only 16 bits long. > That=E2=80=99s not valid under RFC 4291. > > Specifically, when the DHCPv6 server generates the IID for the addresses > that it provides to hosts in IA_NA or IA_TA configuration options, those > addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 > subnet prefixes and 64 bit IIDS. DHCPv6 only provides a 128bit address it doesn't provide any subnet or IID information at all. S must > The first two paragraphs of RFC 4291 =C2=A72.5.1 are clear about the > requirements for the uniqueness properties of IIDs, and these must be > respected by SLAAC, DHCPv6 and any other address configuration mechanism. > > >> Interface identifiers in IPv6 unicast addresses are used to identif= y > >> interfaces on a link. They are required to be unique within a subn= et > >> prefix. It is recommended that the same interface identifier not b= e > >> assigned to different nodes on a link. They may also be unique ove= r > >> a broader scope. In some cases, an interface's identifier will be > >> derived directly from that interface's link-layer address. The sam= e > >> interface identifier may be used on multiple interfaces on a single > >> node, as long as they are attached to different subnets. > >> > >> Note that the uniqueness of interface identifiers is independent of > >> the uniqueness of IPv6 addresses. For example, a Global Unicast > >> address may be created with a local scope interface identifier and = a > >> Link-Local address may be created with a universal scope interface > >> identifier. > > To highlight the [@RFC2119] keywords in the above above=E2=80=A6. > > "They are REQUIRED to be unique within a subnet prefix.=E2=80=9D > > "It is RECOMMENDED that the same interface identifier not be assigned to > different nodes on a link." > > "They MAY also be unique over a broader scope." > > And just to drive the point home: > > "Note that the uniqueness of interface identifiers is independent of the > uniqueness of IPv6 addresses." > "Note that the uniqueness of interface identifiers is independent of the > uniqueness of IPv6 addresses." > "Note that the uniqueness of interface identifiers is independent of the > uniqueness of IPv6 addresses.=E2=80=9D > Please explain how those uniqueness requirements are not met in this situation I described? And if they are not meet for DHCPv6 in the situation I described they are not meet for manual configuration either. > There is no easy and straightforward way to break the /64 subnet prefix > boundary declared by [@RFC4291] without making a major forklift upgrade t= o > the language defining the uniqueness properties of interface identifiers > independent of the uniqueness properties of IPv6 addresses. We should not > be entertaining any discussion of doing that in the context of > [@I-D.ietf-6man-rfc4291bis]. > > My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that it > tries to admit more variability in the length of interface identifiers > without clarifying how the uniqueness properties of interface identifiers > declared in [@RFC4291] are to be properly respected on links where varyin= g > interface identifier lengths are in use. > > Shorter james: don=E2=80=99t try to do this in [@I-D.ietf-6man-rfc4291bis= ], and if > you insist on trying to do this in another draft, then provide sufficient > clarity about the uniqueness properties of interface identifiers on links > where their length is variable and subject to dynamic operational > configuration. > You seem to be calming the uniqueness properties are not met, could I ask where you see a problem, because I don't see one. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --089e0820758c34404705530b3670 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 28, 2017 at 12:52 PM, james woodyatt <= jhw@google.com><= /span> wrote:
On Jun 2= 8, 2017, at 09:41, David Farmer <farme= r@umn.edu> wrote:
>
> The first node will have an interface will have a link-local address o= f FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of 200= 1:db8::1/112 and a 16bit IID of 1.=C2=A0 The second node will have an inter= face will have a link-local address of FE80::/64 with a random 64 IID, and = a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2.
> [=E2=80=A6]

To define a /112 subnet prefix means the IID must be only 16 bits long. Tha= t=E2=80=99s not valid under RFC 4291.

Specifically, when the DHCPv6 server generates the IID for the addresses th= at it provides to hosts in IA_NA or IA_TA configuration options, those addr= esses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subne= t prefixes and 64 bit IIDS.

DHCPv6 only pr= ovides a 128bit address it doesn't provide any subnet or IID informatio= n at all. S must =C2=A0
=C2=A0
The first two paragraphs of RFC 4291 =C2=A72.5.1 are c= lear about the requirements for the uniqueness properties of IIDs, and thes= e must be respected by SLAAC, DHCPv6 and any other address configuration me= chanism.

>>=C2=A0 =C2=A0 Interface identifiers in IPv6 unicast addresses are u= sed to identify
>>=C2=A0 =C2=A0 interfaces on a link.=C2=A0 They are required to be u= nique within a subnet
>>=C2=A0 =C2=A0 prefix.=C2=A0 It is recommended that the same interfa= ce identifier not be
>>=C2=A0 =C2=A0 assigned to different nodes on a link.=C2=A0 They may= also be unique over
>>=C2=A0 =C2=A0 a broader scope.=C2=A0 In some cases, an interface= 9;s identifier will be
>>=C2=A0 =C2=A0 derived directly from that interface's link-layer= address.=C2=A0 The same
>>=C2=A0 =C2=A0 interface identifier may be used on multiple interfac= es on a single
>>=C2=A0 =C2=A0 node, as long as they are attached to different subne= ts.
>>
>>=C2=A0 =C2=A0 Note that the uniqueness of interface identifiers is = independent of
>>=C2=A0 =C2=A0 the uniqueness of IPv6 addresses.=C2=A0 For example, = a Global Unicast
>>=C2=A0 =C2=A0 address may be created with a local scope interface i= dentifier and a
>>=C2=A0 =C2=A0 Link-Local address may be created with a universal sc= ope interface
>>=C2=A0 =C2=A0 identifier.

To highlight the [@RFC2119] keywords in the above above=E2=80=A6.

"They are REQUIRED to be unique within a subnet prefix.=E2=80=9D

"It is RECOMMENDED that the same interface identifier not be assigned = to different nodes on a link."

"They MAY also be unique over a broader scope."

And just to drive the point home:

"Note that the uniqueness of interface identifiers is independent of t= he uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of t= he uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of t= he uniqueness of IPv6 addresses.=E2=80=9D

Please explain how those uniqueness requirements are not met in thi= s situation I described?=C2=A0 And if they are not meet for DHCPv6 in the s= ituation I described they are not meet for manual configuration either.=C2= =A0
=C2=A0
There is no easy and straightforward way to break the /64 subnet prefix bou= ndary declared by [@RFC4291] without making a major forklift upgrade to the= language defining the uniqueness properties of interface identifiers indep= endent of the uniqueness properties of IPv6 addresses. We should not be ent= ertaining any discussion of doing that in the context of [@I-D.ietf-6man-rf= c4291bis].

My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that = it tries to admit more variability in the length of interface identifiers w= ithout clarifying how the uniqueness properties of interface identifiers de= clared in [@RFC4291] are to be properly respected on links where varying in= terface identifier lengths are in use.

Shorter james: don=E2=80=99t try to do this in [@I-D.ietf-6man-rfc4291bis],= and if you insist on trying to do this in another draft, then provide suff= icient clarity about the uniqueness properties of interface identifiers on = links where their length is variable and subject to dynamic operational con= figuration.

You seem to be calming the = uniqueness properties are not met, could I ask where you see a problem, bec= ause I don't see one.=C2=A0
=C2=A0
Thanks.


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David= Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
= Networking & Telecommunication Services
Office of Information Techno= logy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e0820758c34404705530b3670-- From nobody Wed Jun 28 14:04:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5971129B7A for ; Wed, 28 Jun 2017 14:04:20 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHMTly_0-SG3 for ; Wed, 28 Jun 2017 14:04:18 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 554301270AC for ; Wed, 28 Jun 2017 14:04:18 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id j186so37320089pge.2 for ; Wed, 28 Jun 2017 14:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=tVRUwFdhZbhHfuc1zxRvUlbfd8LW1FXaUKKJiYyGqZU=; b=e780P7RKFTY6CYJLB6Lu/h6wqgg3vxJu90rIVOH8xHPPupRjPFX7BpxyBZq5dvAa7x 8QqAjWAJD/v4YfkwtEcuov0eLkWma43ij0hwGH8YOaxDcMkfG8aYpgR985TfQ7UmuJMR PMOegkbjK01mBisdA/NzTMqfb3wMTfnVd8V5XEnFG8A+bBjGPsNOSgXppTBuY92FToz0 TPY9b6qDnBGYg5BiRr3vRMpBdxjSS98ITDJOqgzw/wuXsRlE475fdDeLQQl13cGgKWGl rX8jIqqAVHJPuKQ9nLsdhl3b8SiDDWX+XReGU7lSAJJqn2URFXiaGKq/Q93ss3UGTgXC 9GcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=tVRUwFdhZbhHfuc1zxRvUlbfd8LW1FXaUKKJiYyGqZU=; b=rgev92+kNjqW3HTUsysGEGJguf0lq50pt/3qlgXAJZHmEbXHFBZBCjtK0kG/5huw1q +EdZJUETRvZ+ztnOHSCClcLizqQjAapsgKuPQn7t/VRsxB3fcw8oMpOVmFksumrU0LqQ Zj1/OBiHZ2zK188gizh7xcscFrTSRgaP2VOaeR/PUZzZRU7KjbvQST7Nu6+udFTrbk8U fL2yfUrVPYJOPFKuJQhVfd4Et039Onf/W+F7fSpUNwZROQehvhWFnkD9RTXg9NaFCZaZ Hf+SJrEwekElnXLwj6WhEbPz9EqzACB7lUdxL6Fe8UsMk7lv8sO78aMWMkm1X3Jlj27q Z/+A== X-Gm-Message-State: AKS2vOwQPc3YNOGlhlVd1tG17TZe7GvocrelaVNm1Dy1m6vRFctqUwfY FFhiswprhZaBjWezZ08TwA== X-Received: by 10.84.213.8 with SMTP id f8mr14086533pli.22.1498683857625; Wed, 28 Jun 2017 14:04:17 -0700 (PDT) Received: from [100.107.37.169] ([100.107.37.169]) by smtp.gmail.com with ESMTPSA id c63sm7862593pfk.79.2017.06.28.14.04.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 14:04:17 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_B1D30338-DB18-4F6A-A693-C47D17FBC19C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 28 Jun 2017 14:04:16 -0700 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> To: IPv6 IPv6 List In-Reply-To: Message-Id: <17D20A33-C574-42F1-8905-39907388745D@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:04:21 -0000 --Apple-Mail=_B1D30338-DB18-4F6A-A693-C47D17FBC19C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 28, 2017, at 12:41, Manfredi, Albert E = wrote: >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of james woodyatt > Sent: Wednesday, June 28, 2017 13:52 >=20 >> To define a /112 subnet prefix means the IID must be only 16 bits = long. >> That=E2=80=99s not valid under RFC 4291. >=20 > I don=E2=80=99t see why not. The IID has to be "unique within a subnet = prefix," quoted directly from section 2.5.1. (Same as for IPv4.) Because [@RFC4291] clearly says that interface identifiers in the = 2001:db8:/32 prefix are 64 bits long. That=E2=80=99s why it=E2=80=99s = not valid under [@RFC4291]. I get that you want = [@I-D.ietf-6man-rfc4291bis] to change that, but the current revision = does not change that. I don=E2=80=99t agree that changing it is = appropriate in this draft. I=E2=80=99m willing to consider it = appropriate to change in another draft, but not in = [@I-D.ietf-6man-rfc4291bis]. Is that clear? > "Note that the uniqueness of interface identifiers is independent of = the uniqueness of IPv6 addresses." >=20 > Doesn't matter. That was in a different context. If you go on the = notion that EUI-64 embeds a MAC address, presumably it becomes a unique = IID, and presumably, with SLAAC, you don't have to worry about = collisions. There is no other rationale for global uniqueness of IIDs. The context is NOT different. It is exactly the sane context. We are revising [@RFC4291] to promote it to Internet Standard. Yes, we = have moved the =E2=80=9CModified EUI-64=E2=80=9D format for interface = identifiers into the historical appendix, but changing the uniqueness = properties of interface identifiers is a completely different thing, and = it is neither necessary nor warranted. It would be a significant = technical change to the addressing architecture, and quite a significant = departure from the earlier architecture compared with the change to stop = using modified EUI-64 format. >> My principal criticism of [@I-D.bourbaki-6man-classless-ipv6] is >> that it tries to admit more variability in the length of interface >> identifiers without clarifying how the uniqueness properties of >> interface identifiers declared in [@RFC4291] are to be properly >> respected on links where varying interface identifier lengths are in >> use. >=20 > The draft attempts to restore a sense of logic, because there's too = much continued emphasis of a mandatory 64-bit IID, when the main = rationale for it has been deprecated. If anything, the draft continues = to be too conservative, e.g., in assuming that SLAAC can only work with = 64-bit IIDs. You are not addressing my criticism here, and the draft does not succeed = in its attempt to =E2=80=9Crestore=E2=80=9D any sense of logic. It does = the opposite. The current language in [@I-D.ietf-6man-rfc4291bis] =C2=A72.4.1, which = maintains the uniqueness properties of interface identifiers from = [@RFC4291] even when the Modified EUI-64 Format has been moved to the = historical appendix, is currently standard in the IPv6 addressing = architecture and it=E2=80=99s apparently non-controversial to retain it = in the revision we will promote to Internet Standard. The current draft of [@I-D.bourbaki-6man-classless-ipv6] does not = explain how these properties can be respected on links where interface = identifier lengths are variable and subject to dynamic operational = configuration. Neither does it update [@RFC4291] to relax the uniqueness = properties of interface identifiers to those that the existing draft can = accommodate. You need to do one or the other of those, and I=E2=80=99m = objecting because you haven=E2=80=99t done either one. --james woodyatt > --Apple-Mail=_B1D30338-DB18-4F6A-A693-C47D17FBC19C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 28, 2017, at 12:41, Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote:

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of james = woodyatt
Sent: Wednesday, June 28, 2017 13:52

To define = a /112 subnet prefix means the IID must be only 16 bits long.
That=E2=80=99s not valid under RFC 4291.

I don=E2=80=99t see why not. The = IID has to be "unique within a subnet prefix," quoted directly from = section 2.5.1. (Same as for IPv4.)

Because= [@RFC4291] clearly says that interface identifiers in the 2001:db8:/32 = prefix are 64 bits long. That=E2=80=99s why it=E2=80=99s not valid under = [@RFC4291]. I get that you want [@I-D.ietf-6man-rfc4291bis] to change = that, but the current revision does not change that. I don=E2=80=99t = agree that changing it is appropriate in this draft. I=E2=80=99m willing = to consider it appropriate to change in another draft, but not in = [@I-D.ietf-6man-rfc4291bis]. Is that clear?

"Note that the uniqueness of interface identifiers is = independent of the uniqueness of IPv6 addresses."

Doesn't matter. That was in a different context. If you go on = the notion that EUI-64 embeds a MAC address, presumably it becomes a = unique IID, and presumably, with SLAAC, you don't have to worry about = collisions. There is no other rationale for global uniqueness of = IIDs.

The context is NOT different. It is exactly the = sane context.

We are revising = [@RFC4291] to promote it to Internet Standard. Yes, we have moved the = =E2=80=9CModified EUI-64=E2=80=9D format for interface identifiers into = the historical appendix, but changing the uniqueness properties of = interface identifiers is a completely different thing, and it is neither = necessary nor warranted. It would be a significant technical change to = the addressing architecture, and quite a significant departure from the = earlier architecture compared with the change to stop using modified = EUI-64 format.

My principal criticism of [@I-D.bourbaki-6man-classless-ipv6] = is
that it tries to admit more variability in the length = of interface
identifiers without clarifying how the = uniqueness properties of
interface identifiers declared in = [@RFC4291] are to be properly
respected on links where = varying interface identifier lengths are in
use.

The draft attempts to restore a = sense of logic, because there's too much continued emphasis of a = mandatory 64-bit IID, when the main rationale for it has been = deprecated. If anything, the draft continues to be too conservative, = e.g., in assuming that SLAAC can only work with 64-bit = IIDs.

You are not = addressing my criticism here, and the draft does not succeed in its = attempt to =E2=80=9Crestore=E2=80=9D any sense of logic. It does the = opposite.

The current language in = [@I-D.ietf-6man-rfc4291bis] =C2=A72.4.1, which maintains the uniqueness = properties of interface identifiers from [@RFC4291] even when the = Modified EUI-64 Format has been moved to the historical appendix, is = currently standard in the IPv6 addressing architecture and it=E2=80=99s = apparently non-controversial to retain it in the revision we will = promote to Internet Standard.

The = current draft of [@I-D.bourbaki-6man-classless-ipv6] does not explain = how these properties can be respected on links where interface = identifier lengths are variable and subject to dynamic operational = configuration. Neither does it update [@RFC4291] to relax the uniqueness = properties of interface identifiers to those that the existing draft can = accommodate. You need to do one or the other of those, and I=E2=80=99m = objecting because you haven=E2=80=99t done either one.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_B1D30338-DB18-4F6A-A693-C47D17FBC19C-- From nobody Wed Jun 28 14:19:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460DF12EC58 for ; Wed, 28 Jun 2017 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF9QMmYHjrDM for ; Wed, 28 Jun 2017 14:19:13 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 6DC1912EA6A for ; Wed, 28 Jun 2017 14:19:13 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p21so61875421qke.3 for ; Wed, 28 Jun 2017 14:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AftLk+Dr29cR9evnAMHbdYL3D7Sbq7TGU3aKozW/HxM=; b=HSn2SDVQyw8hbnHurtPjVntjMJDO5NYCpFeNphtSM2fZw8124tVRn5PUQpnKUqqEMc urAPcVyCwTGLFX0GS4whCtzKS44mUrwrjqQaukkkZ2plWp85734PpawR+fGE6lMxFMkz DLoGiBBHIGCIPnWem8zFAGTKYoGd+DqPq5SYEeLwENlnlFLogHoP7F0nQiassxTvIeik hKimde1a42iL15lZnqV6hnNhHqYhpsLOLZsI967Vc7a5uPTeif712k4h2ddnYw1kyy4P nXAESq9Ve/XEx8fm1PJr5Vm6UBsxpEEDiRPS2tmOLQEprBJWu3FK5Jq2Nna2SIUAeSEV oL6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AftLk+Dr29cR9evnAMHbdYL3D7Sbq7TGU3aKozW/HxM=; b=F1o4g0UAn+IZKrks0hTsdxMQqcH6RURXFNMCxseitQr7cVjen4vVB+12unHtvzqz/W xhlrhDAGQAPjClX91ChVC/zQsJ8auUW+kb+intVzVFIoRdWVNlLH0lJfS/cgMdUMSZkR jPbogMBIMdUEoCoZ+rQ8dR482NRGghCiqfZJhcezQo/qPaEtvcJ4npKUWYZpobUYZ+gx VDHKAnUClB+2Shvm+siZqD9d1cvU0OdqhftayYx1yjodz/wGKx4afaXOQLeyr3DlcmFh R1ed0G7x029UTsly79b/BDRW1N8Oh8RtzII4oZXmJP+ux2LUIP+JHYz9oAmDE3Ysg19I LGMg== X-Gm-Message-State: AKS2vOzWAEkujq+Dnuu5TSFb4pUt6ttIaRgXeC/5/yju+BWKTwmr4epZ qnGZsPdrv71ZUnCLFVNpzIE90wzhnw== X-Received: by 10.55.74.13 with SMTP id x13mr14407861qka.254.1498684752481; Wed, 28 Jun 2017 14:19:12 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Wed, 28 Jun 2017 14:19:11 -0700 (PDT) In-Reply-To: <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 28 Jun 2017 14:19:11 -0700 X-Google-Sender-Auth: 9u3GEhSKH57rFg7Mv8lOAcwcI4k Message-ID: Subject: Re: To: Brian E Carpenter Cc: james woodyatt , IPv6 IPv6 List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:19:15 -0000 At Wed, 28 Jun 2017 13:02:48 +1200, Brian E Carpenter wrote: > >> Since SLAAC has always assumed that the two lengths are equal, > > > > What do you mean by this? Do you mean "SLAAC has always assumed the > > prefix length for address generation and the prefix length for on-link > > determination are equal"? > > Yes. > > > Specifically which text of RFC4862 says > > that (or are you referring to other RFCs for SLAAC)? > > It doesn't say that. But on a normal broadcast LAN nothing else > makes much sense, so I believe that users have always made this > assumption, regardless of what implementations might support. Ah, okay, I don't necessarily disagree on that observation, but I'm afraid it's quite difficult to interpret your original sentence that way: the original sentence seemed to talk about assumptions of protocol specification in the general case, while the actual intent is based on what users would assume for a "normal broadcast LAN". Anyway, I'm just trying to clarify a thread comment I happened to notice. I have no problem with draft-ietf-6man-rfc4291bis-08.txt moving forward. -- JINMEI, Tatuya From nobody Wed Jun 28 14:37:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041B126B71 for ; Wed, 28 Jun 2017 14:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-gmKigkmuoZ for ; Wed, 28 Jun 2017 14:37:05 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEA512773A for ; Wed, 28 Jun 2017 14:37:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id C5776BA7 for ; Wed, 28 Jun 2017 21:37:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_BOYhpLmq3v for ; Wed, 28 Jun 2017 16:37:04 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 7FB41BA3 for ; Wed, 28 Jun 2017 16:37:04 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id 191so23789153vko.1 for ; Wed, 28 Jun 2017 14:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mPM6vbtJq5ooVzUqSjbszOIcC933pETL75xmUcWj2HM=; b=EhYaWcPW8v9PbDu/NZCSP0qmSl43iN+i1PU8dFSQ8/vbbyDugZ7MW5Eiyk4r3+xSso FFOlWVzapPt5uBWL/TAuJVLdx9I6e1YxUY/hOFFBaHVrlmw/jd1W/sJ/qmYvj/tjseUN ckGJIy96HOiVvrJMq1Z06fT13+piqkB/kyPgM6ltgy/l+wQF3AVpFNKrVY2ua8tTLBP9 U8pu4KLiqbCk74mvp84rntzlM0iFbsimZQRwnH8eo3aqPLgwyMlCafw8Lkb/UeJ6sxoA 72oi9SSMQzi5vbKe9cv/ZrOrQnWM3HqqSdg74pZVlQBK5bZZSeNp7yMVC6chqCOAxW8j I99g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mPM6vbtJq5ooVzUqSjbszOIcC933pETL75xmUcWj2HM=; b=Ntv8T5xSPt0KM3fzcCb0OIeiV4CVlmR0NuAI7vxWFCwEXrIoKmcKBckOaNlyDXDYQ5 WOKEZj/XJenJdp63NWTvNvA5xJDS04kq60u0L4awV+d8bJQPgvBrCGUwqDj9uGo1NnFx cAOdLQHPuBlNFBot3swjMDILWYqSYG5NgoCMsYjD40BjsK3783H0W+MYMHNOjp2OGIOF lJc2vwkLtXQfyoCY+M9sixFOWL+6TehQ4f9mBDtPGFQLVXwADsWigX0IWBdOqT+UB+8i u7AL+qUm5zpryBZSoPZvVbgvCeMhBX0K5xVGQ7U51cDjZPfrMc9g5MIuBkOwp/ezbHD4 IHiw== X-Gm-Message-State: AKS2vOy4ugXde4L7Gnq0GahkS4RB+Z7zWjmInX/evOnNuKDzA6hOjoB9 Qz8ciNCE9QjJAbcT8MHa2waOh5OfLLsI8NiYiD61btw8Jqx3eFHbHymyNxttlMxGj0C455o5AMF 12f+eGqKIorC/LS4= X-Received: by 10.31.114.75 with SMTP id n72mr6832162vkc.24.1498685823518; Wed, 28 Jun 2017 14:37:03 -0700 (PDT) X-Received: by 10.31.114.75 with SMTP id n72mr6832155vkc.24.1498685823324; Wed, 28 Jun 2017 14:37:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Wed, 28 Jun 2017 14:37:02 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> From: David Farmer Date: Wed, 28 Jun 2017 16:37:02 -0500 Message-ID: Subject: Re: To: james woodyatt Cc: IPv6 IPv6 List Content-Type: multipart/alternative; boundary="94eb2c14949a212dfd05530bfcde" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:37:08 -0000 --94eb2c14949a212dfd05530bfcde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2017 at 3:41 PM, David Farmer wrote: > > > On Wed, Jun 28, 2017 at 12:52 PM, james woodyatt wrote: > >> On Jun 28, 2017, at 09:41, David Farmer wrote: >> > >> > The first node will have an interface will have a link-local address o= f >> FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of >> 2001:db8::1/112 and a 16bit IID of 1. The second node will have an >> interface will have a link-local address of FE80::/64 with a random 64 I= ID, >> and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2. >> > [=E2=80=A6] >> >> To define a /112 subnet prefix means the IID must be only 16 bits long. >> That=E2=80=99s not valid under RFC 4291. >> >> Specifically, when the DHCPv6 server generates the IID for the addresses >> that it provides to hosts in IA_NA or IA_TA configuration options, those >> addresses do not have /112 subnet prefixes and 16 bit IIDs. They have /6= 4 >> subnet prefixes and 64 bit IIDS. > > > DHCPv6 only provides a 128bit address it doesn't provide any subnet or II= D > information at all. S must > Some how the last sentence got mangled. it was suppose to read; This information must be provided by the RA. > The first two paragraphs of RFC 4291 =C2=A72.5.1 are clear about the >> requirements for the uniqueness properties of IIDs, and these must be >> respected by SLAAC, DHCPv6 and any other address configuration mechanism= . >> >> >> Interface identifiers in IPv6 unicast addresses are used to identi= fy >> >> interfaces on a link. They are required to be unique within a >> subnet >> >> prefix. It is recommended that the same interface identifier not = be >> >> assigned to different nodes on a link. They may also be unique ov= er >> >> a broader scope. In some cases, an interface's identifier will be >> >> derived directly from that interface's link-layer address. The sa= me >> >> interface identifier may be used on multiple interfaces on a singl= e >> >> node, as long as they are attached to different subnets. >> >> >> >> Note that the uniqueness of interface identifiers is independent o= f >> >> the uniqueness of IPv6 addresses. For example, a Global Unicast >> >> address may be created with a local scope interface identifier and= a >> >> Link-Local address may be created with a universal scope interface >> >> identifier. >> >> To highlight the [@RFC2119] keywords in the above above=E2=80=A6. >> >> "They are REQUIRED to be unique within a subnet prefix.=E2=80=9D >> >> "It is RECOMMENDED that the same interface identifier not be assigned to >> different nodes on a link." >> >> "They MAY also be unique over a broader scope." >> >> And just to drive the point home: >> >> "Note that the uniqueness of interface identifiers is independent of the >> uniqueness of IPv6 addresses." >> "Note that the uniqueness of interface identifiers is independent of the >> uniqueness of IPv6 addresses." >> "Note that the uniqueness of interface identifiers is independent of the >> uniqueness of IPv6 addresses.=E2=80=9D >> > > Please explain how those uniqueness requirements are not met in this > situation I described? And if they are not meet for DHCPv6 in the > situation I described they are not meet for manual configuration either. > > >> There is no easy and straightforward way to break the /64 subnet prefix >> boundary declared by [@RFC4291] without making a major forklift upgrade = to >> the language defining the uniqueness properties of interface identifiers >> independent of the uniqueness properties of IPv6 addresses. We should no= t >> be entertaining any discussion of doing that in the context of >> [@I-D.ietf-6man-rfc4291bis]. >> >> My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that it >> tries to admit more variability in the length of interface identifiers >> without clarifying how the uniqueness properties of interface identifier= s >> declared in [@RFC4291] are to be properly respected on links where varyi= ng >> interface identifier lengths are in use. >> >> Shorter james: don=E2=80=99t try to do this in [@I-D.ietf-6man-rfc4291bi= s], and >> if you insist on trying to do this in another draft, then provide >> sufficient clarity about the uniqueness properties of interface identifi= ers >> on links where their length is variable and subject to dynamic operation= al >> configuration. >> > > You seem to be calming the uniqueness properties are not met, could I ask > where you see a problem, because I don't see one. > > Thanks. > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --94eb2c14949a212dfd05530bfcde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 28, 2017 at 3:41 PM, David Farmer <farmer@umn.edu> wrote:


On Wed, Jun 28, 2017 at 12= :52 PM, james woodyatt <jhw@google.com> wrote:
On Jun 28, 2017, at 09:41, David Farme= r <farmer@umn.edu> wrote:
>
> The first node will have an interface will have a link-local address o= f FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of 200= 1:db8::1/112 and a 16bit IID of 1.=C2=A0 The second node will have an inter= face will have a link-local address of FE80::/64 with a random 64 IID, and = a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID of 2.
> [=E2=80=A6]

To define a /112 subnet prefix means the IID must be only 16 bits long. Tha= t=E2=80=99s not valid under RFC 4291.

Specifically, when the DHCPv6 server generates the IID for the addresses th= at it provides to hosts in IA_NA or IA_TA configuration options, those addr= esses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subne= t prefixes and 64 bit IIDS.


=
Some how the last sentence got mangled. it was suppose to read;
<= div>
The first two paragraphs of RFC 4291 =C2=A72.5.1 are clear ab= out the requirements for the uniqueness properties of IIDs, and these must = be respected by SLAAC, DHCPv6 and any other address configuration mechanism= .

>>=C2=A0 =C2=A0 Interface identifiers in IPv6 unicast addresses are u= sed to identify
>>=C2=A0 =C2=A0 interfaces on a link.=C2=A0 They are required to be u= nique within a subnet
>>=C2=A0 =C2=A0 prefix.=C2=A0 It is recommended that the same interfa= ce identifier not be
>>=C2=A0 =C2=A0 assigned to different nodes on a link.=C2=A0 They may= also be unique over
>>=C2=A0 =C2=A0 a broader scope.=C2=A0 In some cases, an interface= 9;s identifier will be
>>=C2=A0 =C2=A0 derived directly from that interface's link-layer= address.=C2=A0 The same
>>=C2=A0 =C2=A0 interface identifier may be used on multiple interfac= es on a single
>>=C2=A0 =C2=A0 node, as long as they are attached to different subne= ts.
>>
>>=C2=A0 =C2=A0 Note that the uniqueness of interface identifiers is = independent of
>>=C2=A0 =C2=A0 the uniqueness of IPv6 addresses.=C2=A0 For example, = a Global Unicast
>>=C2=A0 =C2=A0 address may be created with a local scope interface i= dentifier and a
>>=C2=A0 =C2=A0 Link-Local address may be created with a universal sc= ope interface
>>=C2=A0 =C2=A0 identifier.

To highlight the [@RFC2119] keywords in the above above=E2=80=A6.

"They are REQUIRED to be unique within a subnet prefix.=E2=80=9D

"It is RECOMMENDED that the same interface identifier not be assigned = to different nodes on a link."

"They MAY also be unique over a broader scope."

And just to drive the point home:

"Note that the uniqueness of interface identifiers is independent of t= he uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of t= he uniqueness of IPv6 addresses."
"Note that the uniqueness of interface identifiers is independent of t= he uniqueness of IPv6 addresses.=E2=80=9D

Please explain how those uniqueness requirements are not met in thi= s situation I described?=C2=A0 And if they are not meet for DHCPv6 in the s= ituation I described they are not meet for manual configuration either.=C2= =A0
There is no easy and straightforward way to break the /64 subnet prefix bou= ndary declared by [@RFC4291] without making a major forklift upgrade to the= language defining the uniqueness properties of interface identifiers indep= endent of the uniqueness properties of IPv6 addresses. We should not be ent= ertaining any discussion of doing that in the context of [@I-D.ietf-6man-rf= c4291bis].

My principle criticism of [@I-D.bourbaki-6man-classless-ipv6] is that = it tries to admit more variability in the length of interface identifiers w= ithout clarifying how the uniqueness properties of interface identifiers de= clared in [@RFC4291] are to be properly respected on links where varying in= terface identifier lengths are in use.

Shorter james: don=E2=80=99t try to do this in [@I-D.ietf-6man-rfc4291bis],= and if you insist on trying to do this in another draft, then provide suff= icient clarity about the uniqueness properties of interface identifiers on = links where their length is variable and subject to dynamic operational con= figuration.


--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David = Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
N= etworking & Telecommunication Services
Office of Information Technol= ogy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0= =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--94eb2c14949a212dfd05530bfcde-- From nobody Wed Jun 28 14:38:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD00129B4C for ; Wed, 28 Jun 2017 14:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwMnjZNBzxDI for ; Wed, 28 Jun 2017 14:38:32 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83387126B71 for ; Wed, 28 Jun 2017 14:38:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5SLcW7q019315; Wed, 28 Jun 2017 14:38:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5SLcShF019284 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 28 Jun 2017 14:38:28 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 14:38:27 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 14:38:27 -0700 From: "Manfredi, Albert E" To: james woodyatt , IPv6 IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS8C198zNl709EfUWKnaYWTqVEwaI7A5eA//+iT1CAAJNLAP//kIxw Date: Wed, 28 Jun 2017 21:38:27 +0000 Message-ID: <1fdf185c3c884b45949ed40d611fc1f8@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <17D20A33-C574-42F1-8905-39907388745D@google.com> In-Reply-To: <17D20A33-C574-42F1-8905-39907388745D@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:38:34 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGph bWVzIHdvb2R5YXR0DQoNCj4gV2UgYXJlIHJldmlzaW5nIFtAUkZDNDI5MV0gdG8gcHJvbW90ZSBp dCB0byBJbnRlcm5ldCBTdGFuZGFyZC4gWWVzLA0KPiB3ZSBoYXZlIG1vdmVkIHRoZSDigJxNb2Rp ZmllZCBFVUktNjTigJ0gZm9ybWF0IGZvciBpbnRlcmZhY2UgaWRlbnRpZmllcnMNCj4gaW50byB0 aGUgaGlzdG9yaWNhbCBhcHBlbmRpeCwgYnV0IGNoYW5naW5nIHRoZSB1bmlxdWVuZXNzIHByb3Bl cnRpZXMNCj4gb2YgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGlzIGEgY29tcGxldGVseSBkaWZmZXJl bnQgdGhpbmcsIGFuZCBpdCBpcw0KPiBuZWl0aGVyIG5lY2Vzc2FyeSBub3Igd2FycmFudGVkLg0K DQpEYXZpZCByZXNwb25kZWQgc3VjY2luY3RseSB0byB0aGlzIHBvaW50LiBJbiBzaG9ydCwgd2hh dCBpcyBuZWl0aGVyIG5lY2Vzc2FyeSwgbm9yIHdhcnJhbnRlZCwgbm9yIG1hbmRhdG9yeSBldmVu IGluIFJGQyA0MjkxLCBpcyB0byByZXF1aXJlIHRoZSBJSUQgdG8gYmUgYW55dGhpbmcgbW9yZSB0 aGFuIHVuaXF1ZSB3aXRoaW4gdGhhdCBzdWJuZXQgcHJlZml4LiBUaGlzIGlzIHdoYXQgSSBtZWFu IGJ5ICJyZXN0b3JpbmcgbG9naWMuIiBUaGVyZSBpcyBubyBsb2dpY2FsIHJhdGlvbmFsZSBmb3Ig aW5zaXN0aW5nIHRoYXQgdGhlIElJRCBiZSBhbnl0aGluZyBtb3JlIHRoYW4gbG9jYWxseSB1bmlx dWUuIFRoZSBmYWN0IHRoYXQgaW4gdGhlIHBhc3QsIG9uZSBmb3JtIG9mIElJVSAoaS5lLiBFVUkt NjQpIHdhcyAqcHJlc3VtZWQqIHRvIGJlIGdsb2JhbGx5IHVuaXF1ZSBjcmVhdGVkIHRoaXMgb2Rk IGNvbmNlcHQsIG9mIG11bHRpcGxlIGRpZmZlcmVudCB1bmlxdWVuZXNzIHJlcXVpcm1lbnRzIGZv ciB0aGUgSUlELiBJdCB3YXMgYSBtZXJlIGFydGlmYWN0IG9mIEVVSS02NC4NCg0KPiBJdCB3b3Vs ZCBiZSBhIHNpZ25pZmljYW50IHRlY2huaWNhbCBjaGFuZ2UgdG8gdGhlIGFkZHJlc3NpbmcNCj4g YXJjaGl0ZWN0dXJlLCBhbmQgcXVpdGUgYSBzaWduaWZpY2FudCBkZXBhcnR1cmUgZnJvbSB0aGUg ZWFybGllcg0KPiBhcmNoaXRlY3R1cmUgY29tcGFyZWQgd2l0aCB0aGUgY2hhbmdlIHRvIHN0b3Ag dXNpbmcgbW9kaWZpZWQgRVVJLTY0DQo+IGZvcm1hdC4NCg0KSSBtYXkgYmUgd3JvbmcsIGJ1dCB3 ZSBzZWVtIHRvIGhhdmUgZ29uZSBhcm91bmQgYW5kIGFyb3VuZCBvbiB0aGlzLiBBbmQgdGhlIHJl c3VsdCBhbHdheXMgc2VlbXMgdG8gYmUgdGhlIHNhbWUuIEV2ZW4gaWYgd2UgY29udGludWUgdG8g bWFuZGF0ZSB0aGF0IFNMQUFDIG11c3Qgb25seSBiZSBjb21wdXRlZCB3aXRoIDY0LWJpdCBJSURz LCB3ZSBhbHNvIGFja25vd2xlZGdlIHRoYXQgbWFudWFsIG9yIERIQ1AgbWV0aG9kcyBjYW4gcmVh ZGlseSBhY2NvbW1vZGF0ZSBhbnkgbGVuZ3RoIG9mIElJRC4gU28gSSBoYXZlIG5ldmVyIHVuZGVy c3Rvb2Qgd2h5IHNvbWUgc2VlbSB0byBtYWtlIHRoaXMgc3VjaCBhIGh1cmRsZS4gDQoNCj4gTXkg cHJpbmNpcGFsIGNyaXRpY2lzbSBvZiBbQEktRC5ib3VyYmFraS02bWFuLWNsYXNzbGVzcy1pcHY2 XSBpcw0KPiB0aGF0IGl0IHRyaWVzIHRvIGFkbWl0IG1vcmUgdmFyaWFiaWxpdHkgaW4gdGhlIGxl bmd0aCBvZiBpbnRlcmZhY2UNCj4gaWRlbnRpZmllcnMgd2l0aG91dCBjbGFyaWZ5aW5nIGhvdyB0 aGUgdW5pcXVlbmVzcyBwcm9wZXJ0aWVzIG9mDQo+IGludGVyZmFjZSBpZGVudGlmaWVycyBkZWNs YXJlZCBpbiBbQFJGQzQyOTFdIGFyZSB0byBiZSBwcm9wZXJseQ0KPiByZXNwZWN0ZWQNCg0KQW5k IEkgY2xhaW0gdGhhdCB0aGlzIGlzIG5vIGRpZmZpY3VsdCB0YXNrLiBUaGUgb25seSB1bmlxdWVu ZXNzIHByb3BlcnR5IHRoYXQgc3Vydml2ZXMgYW5kIHRoYXQgaXMgbWFuZGF0ZWQsIGV2ZW4gaW4g UkZDIDQyOTEsIGlzIHRoZSB1bmlxdWVuZXNzIHdpdGhpbiB0aGUgc3VibmV0IHByZWZpeCwgYXMg SSBxdW90ZWQgcHJldmlvdXNseS4gQW55dGhpbmcgbW9yZSBpcyBubyBsb25nZXIgZGVmZW5zaWJs ZSwgYXMgZmFyIGFzIEkgY2FuIGRldGVybWluZS4gV2UncmUganVzdCBvdmVyZW1waGFzaXppbmcg dGV4dCB0aGF0IGhhcyBiZWVuIHN1cGVyc2VkZWQgYnkgZXZlbnRzLg0KDQpQZXJoYXBzLCBpZiBh bnl0aGluZywgdGhlIGRyYWZ0IGNhbiBlbXBoYXNpemUgdGhhdCBhbnkgb3RoZXIgdW5pcXVlbmVz cyBwcm9wZXJ0aWVzIGFyZSBub3Qgd2FycmFudGVkPw0KDQpCZXJ0DQoNCg== From nobody Wed Jun 28 15:25:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF812EB44 for ; Wed, 28 Jun 2017 15:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6hB-pmhErwc for ; Wed, 28 Jun 2017 15:25:20 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 A024712EC7B for ; Wed, 28 Jun 2017 15:25:13 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u62so38133263pgb.3 for ; Wed, 28 Jun 2017 15:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NY8Bpot34adFRimD2lf7EyUveqiC5niUymX5s2eF4sc=; b=fz7tDjXzPeh7v0dRWY0CKmaEREwo+qwwe6fh3M+0Nme7K7sMwTUoF1+TR6uqpfR4By GPmNmfCNNsN++MCYmtrP7SdsF2TpamChdj9lb4YPBTkJndcdYeaK69zPSrUsbcAhpdtO ZsADcotn+a1bTLmMl+YjlntDuw6DEX1kLjP0ZFK7KIKE8Sj8d0kGh82QlV6J6wEIg2oE 7Z74fPIcskCifJevEby+xwWYW3sID6enmSBE0evwvMcxgg3cbYDOr14VpXqbMSWGc9Bq 3dGGY2WV0wnjT1Hlex6Yy6c4ZmOdErqcfxZqbvud2vYboweRGifqxgkDBwZQbDJMQu4e pplw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=NY8Bpot34adFRimD2lf7EyUveqiC5niUymX5s2eF4sc=; b=sOmE692PI7aw/ZHkH3CnEdEEqdbfJiDrxXdKaLO5ztqG3d1LKPDMChettVZWXdY4zE /iPB8YgSlh+/zXLE32TKLmYK7/rjNGYK245K2hhXDms5wb4RwBJVCXITD/M7e1Uf+BB4 v4Wp20GXBvs+XCa/Jj5xW1zDNNUAdt0gD9dkbZ4fn4QuByQ6NIlkeYWc7WRyAILAQwU/ AIk0OTFXt0BvFyk40DRsuwIDt6trEMPCkoXfLlegUjeFBCF2uQkcG5Zm+Fg2wOMK1BDX LHr0bzMhmorBBkMPB3gLc5xIojhqlqK5ZU/5t2xqydiix/Jvgm8d8x5nyigVWiVtZurj gMWg== X-Gm-Message-State: AKS2vOwVHZrAbkRdXSc+ZLGmmP9tF5HFTeTF+IqkSI2RG25pyBMGVO07 LZtHLyv/3rLGnOhagCkczQ== X-Received: by 10.84.232.207 with SMTP id x15mr14637815plm.173.1498688712782; Wed, 28 Jun 2017 15:25:12 -0700 (PDT) Received: from [100.107.37.169] ([100.107.37.169]) by smtp.gmail.com with ESMTPSA id l63sm7710959pfc.132.2017.06.28.15.25.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 15:25:12 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 28 Jun 2017 15:25:11 -0700 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> To: IPv6 IPv6 List In-Reply-To: Message-Id: <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:25:25 -0000 On Jun 28, 2017, at 13:41, David Farmer wrote: > On Wed, Jun 28, 2017 at 12:52 PM, james woodyatt = wrote: > On Jun 28, 2017, at 09:41, David Farmer wrote: > > > > The first node will have an interface will have a link-local address = of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix of = 2001:db8::1/112 and a 16bit IID of 1. The second node will have an = interface will have a link-local address of FE80::/64 with a random 64 = IID, and a GUA with a subnet prefix of 2001:db8::1/112 and a 16bit IID = of 2. > > [=E2=80=A6] >=20 > To define a /112 subnet prefix means the IID must be only 16 bits = long. That=E2=80=99s not valid under RFC 4291. >=20 > Specifically, when the DHCPv6 server generates the IID for the = addresses that it provides to hosts in IA_NA or IA_TA configuration = options, those addresses do not have /112 subnet prefixes and 16 bit = IIDs. They have /64 subnet prefixes and 64 bit IIDS.=20 >=20 > DHCPv6 only provides a 128bit address it doesn't provide any subnet or = IID information at all. Of course it doesn=E2=80=99t. The subnet prefix of 2001:db8::1:1 is = 2001:db8::/64. The length of the IID is set by [@RFC4291] and DHCPv6 is = not empowered to override that.=20 > Please explain how those uniqueness requirements are not met in this = situation I described? And if they are not meet for DHCPv6 in the = situation I described they are not meet for manual configuration either.=20= Firstly to address your second point, as I=E2=80=99ve written = repeatedly, the uniqueness requirements are set by [@RFC4291] completely = independent of the method used for address configuration. It doesn=E2=80=99= t matter whether the address is manually or automatically configured, = with SLAAC or DHCPv6 or any bespoke protocol you can dream up. The interface identifier uniqueness properties are separate from the = uniqueness properties of IPv6 addresses that include them, and there are = no drafts anywhere under discussion that will change that. Now to address your first point=E2=80=94 with apologies up front to the = rest of the list for taking up so much space with an explanation of = something so basic=E2=80=94 the problem with allowing interface = identifiers to have variable length subject to dynamic operational = configuration, as [@I-D.bourbaki-6man-classless-ipv6] tries to do, = hinges on how to interpret the various instances of the [@RFC2119] = keyword phrases in =C2=A72.5.1 [@RFC4291] (and its forthcoming = successor). In the first case, "They are REQUIRED to be unique within a subnet = prefix.=E2=80=9D Here, the problem is that variable length subnet = prefixes allow for overlapping subnet prefixes. Consider the case of two = overlapping variable length subnet prefixes on the same link, e.g. = 2001:db8::/64 and 2001:db8::100/112. It=E2=80=99s only possible to = assign an address that respects the standard IID uniqueness properties = in the former prefix as long as it does not also have the latter prefix. One way (not the only way) that [@I-D.bourbaki-6man-classless-ipv6] = could try to deal with that problem is to forbid overlapping subnet = prefixes, but it doesn=E2=80=99t even recognize the problem, much less = present a solution. It=E2=80=99s far from clear how to go about = forbidding overlapping subnet prefixes in practice, and a more workable = solution to the problem might be even more problematic. In the second case, "It is RECOMMENDED that the same interface = identifier not be assigned to different nodes on a link." A brief = digression, for which I will explain the purpose below: strictly = speaking, to comply with this recommendation entails choosing between = one of two alternatives: a) ensuring that the same interface identifier = is not assigned to different nodes on the same link, and b) providing a = reasoned explanation for why special considerations require diverging = from the recommendation. What isn=E2=80=99t, strictly speaking, = permitted: simply ignoring the recommendation without providing any = explanation for it. So, let=E2=80=99s consider your example above. Two hosts, Alfa and = Bravo. Alfa: Link-local fe80::$ALFA subnet=3D/64 Global 2001:db8:$SUBNET1::$IID subnet=3D/112 Bravo: Link-local fe80::$BRAVO subnet=3D/64 Global 2001:db8:$SUBNET2::$IID subnet=3D/112 In this example, if $IID =3D $ALFA or $BRAVO, then it matters whether = $SUBNET1 or $SUBNET2 are more than 32 bits long. Here is a concrete = example of that case, which I will assume you accept as a valid manual = configuration under [@I-D.bourbaki-6man-classless-ipv6]: Alfa: Link-local fe80::1 subnet=3D/64 Global 2001:db8::1:1 subnet=3D/112 Bravo: Link-local fe80::2 subnet=3D/64 Global 2001:db8::2:1 subnet=3D/112 Here, Alfa has two addresses with the same IID: IID(address=3Dfe80::1 length=3D64) -> 1 IID(address=3D2001:db8::1:1 length=3D112) -> 1 And that=E2=80=99s okay, because [@RFC4291] says "The same interface = identifier may be used on multiple interfaces on a single node, as long = as they are attached to different subnets." However, Bravo has the same IID as Alfa on one of its addresses: IID(address=3Dfe80::2 length=3D64) -> 2 IID(address=3D2001:db8::2:1 length=3D112) -> 1 In the concrete case, above, both Alfa and Bravo have the same IID=3D1 = in their global IPv6 addresses if the subnet prefix is /112 in both = cases, and therefore the recommended uniqueness property in = [@I-D.ietf-6man-rfc4291bis] is not respected. Whereas, if the subnet = prefix is /64 as [@RFC4291] requires, then both Alfa and Bravo have = different IID as shown below: IID(address=3D2001:db8::1:1 length=3D64) -> 0x10001 IID(address=3D2001:db8::2:1 length=3D64) -> 0x20001 Following up on my promise to explain the digression about = recommendations above, the problem is that = [@I-D.bourbaki-6man-classless-ipv6] doesn=E2=80=99t even recognize that = this issue can arise, much less provide any guidance on how to ensure = that the recommended uniqueness property is respected or what = considerations might lead an operator to diverge intentionally from the = recommendation. Picture the above scenario except using a mixture of = configuration methods, SLAAC, DHCPv6, manual configuration, etc. = Respecting the REQUIRED uniqueness properties for IPv6 addresses is = handled by DAD, but respecting the RECOMMENDED uniqueness properties for = interface identifiers cannot be done with DAD. Something else must do = it, and nothing is defined, much less RECOMMENDED by = [@I-D.bourbaki-6man-classless-ipv6]. Which would be okay PROVIDED that = [@I-D.bourbaki-6man-classless-ipv6] simply updated [@RFC4291] to remove = the recommendation to ensure that the same IID is not assigned to more = than one node on the same link. But it does not do that. Finally in the third case, "They MAY also be unique over a broader = scope.=E2=80=9D Now, you can argue over whether =E2=80=9Cunique=E2=80=9D = and =E2=80=9Cstatistically unique=E2=80=9D is a relevant distinction = here, but with /112 subnet prefixes there isn=E2=80=99t much of a case = for statistical uniqueness. To achieve broader uniqueness than just the = subnet prefix for the address entails using some kind of interface = identifier registration system completely apart from the address = registration system that DHCPv6 provides. Again, = [@I-D.bourbaki-6man-classless-ipv6] doesn=E2=80=99t even consider this = problem. With very short IID lengths, it=E2=80=99s simply not true at = all to say that they MAY also be unique over a broader scope, absent = some unspecified registration system. An additional complication with allowing subnet prefix lengths to vary = dynamically according to operator configuration is the practical problem = of ensuring that uniqueness properties, which applied when the address = was assigned and configured, still apply after subnet prefix lengths are = changed. Once again, [@I-D.bourbaki-6man-classless-ipv6] implies that = this is possible, yet nothing is explicitly discussed about the = complications for the address architecture by introducing such a change. --james woodyatt From nobody Wed Jun 28 16:26:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC17A12EB0B for ; Wed, 28 Jun 2017 16:26:17 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJiKDKQrdRN2 for ; Wed, 28 Jun 2017 16:26:16 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7586D129B45 for ; Wed, 28 Jun 2017 16:26:16 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s66so40699612pfs.1 for ; Wed, 28 Jun 2017 16:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lmt1EdMfJkMkVTYgeUyXNSu0boYR9QrO+cjvbV4zNNc=; b=OzgdJWK+37Dro/eXqEuX/gDqmJaVXTibarcAHxqjqRGhaNeo9ZeKH43MgMv/II057S yYjBOQm2PJq+SjIuujT90MhdopfpTlnqpPYHpoc5WMO57OSm/UbHSdZWXo/mLzm+L8vH OcHN+fnkZaoRGppKLteXxCreodwQyRvSc/+Njqr9v82Hr4BiqZAQmWw+w7JbXkO0DQbP X+BIWkwswKgUrNPcNDbQfi1Oyt7sVHFSohV9+OqNhcOI2+Vmz9TsravGFtIv+WaVxbta SC9M2e8/kgpEXSAW225SwpyQR8KTflGvjDniCtnw7IuQ9UKsfXEegwDdHDC+0NA4BH6d ZEwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lmt1EdMfJkMkVTYgeUyXNSu0boYR9QrO+cjvbV4zNNc=; b=WXKV2p9rWs/2pP0gnldMgUW6M3KNUE1j9LZ5xOSwEauGXsDBWIWAZyiU+AvyG30B+r NCt6LH6wxd7Gmj5JwAki6XJ7fSUIqqsL+WtHJnQxBNsqb0xTXgsxpB1Dkeb3Seq7K/hh UxXn1mTpTOaYNxjXksN4U1DQrD46MEsJl1hE0YaEg8xX9hoNVInRm4wd7HQlcwgXEU5e io0sPyj30bf3Y/UaWHCGMIyU7FZgRiVbZ7RIjjf7NtwmvUQOKpsYHJph4GDy7TCDdgGe bmAl+Z7phROAhvjGSh56gGt9ruBYch9UwG/DTIo0doyW/n3CFl8Qlp4sevGpwEDXfKmr +9mw== X-Gm-Message-State: AKS2vOwaqEZHMPPYmc6ES/zEeA1K1MCwFv91mYoBQgLAiQoo8zidMkmA kl2odOdQyn1qYg== X-Received: by 10.84.224.134 with SMTP id s6mr14445417plj.263.1498692376060; Wed, 28 Jun 2017 16:26:16 -0700 (PDT) Received: from [59.29.43.118] ([59.29.43.118]) by smtp.gmail.com with ESMTPSA id u9sm7768019pfg.127.2017.06.28.16.26.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 16:26:14 -0700 (PDT) From: DY Kim Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8020D1DF-5464-49C9-BC39-E3B4B489A390" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Thu, 29 Jun 2017 08:26:10 +0900 In-Reply-To: <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> Cc: IPv6 IPv6 List To: james woodyatt References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:26:18 -0000 --Apple-Mail=_8020D1DF-5464-49C9-BC39-E3B4B489A390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi James, > On 29 Jun 2017, at 07:25, james woodyatt wrote: >=20 > In the concrete case, above, both Alfa and Bravo have the same IID=3D1 = in their global IPv6 addresses if the subnet prefix is /112 in both = cases, and therefore the recommended uniqueness property in = [@I-D.ietf-6man-rfc4291bis] is not respected. The two IDs (1) are within different /112 subnet prefixes (2001:db8::1 = vs 2001:db8::2).So each is unique within each subnet prefix. I=E2=80=99d = think this configuration is in conformance with the recommendation in = rfc4291bis: "They are required to be unique within a subnet prefix." --Apple-Mail=_8020D1DF-5464-49C9-BC39-E3B4B489A390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi James,

On 29 Jun 2017, at 07:25, james woodyatt <jhw@google.com> = wrote:

In the concrete = case, above, both Alfa and Bravo have the same IID=3D1 in their global = IPv6 addresses if the subnet prefix is /112 in both cases, and therefore = the recommended uniqueness property in [@I-D.ietf-6man-rfc4291bis] is = not respected.

The = two IDs (1) are within different /112 subnet prefixes (2001:db8::1 = vs 2001:db8::2).So = each is unique within each subnet prefix. I=E2=80=99d think this = configuration is in conformance with the recommendation in = rfc4291bis:

   "They are required = to be unique within a subnet prefix."

= --Apple-Mail=_8020D1DF-5464-49C9-BC39-E3B4B489A390-- From nobody Wed Jun 28 16:44:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDA3129B39 for ; Wed, 28 Jun 2017 16:44:35 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5gl7_s4XHSi for ; Wed, 28 Jun 2017 16:44:34 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 2336D126BF0 for ; Wed, 28 Jun 2017 16:44:34 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u62so38864911pgb.3 for ; Wed, 28 Jun 2017 16:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=97zc63nu5CZ2IeOdFn7DZlP8YKJECYWU8eCS6FWVtK4=; b=SLJmuROyQonLmUunIOHSaXp5OMxEZKu0XenGnRT8EUMa0K05aACnkOX7z6aIvy6x5C t+jNT+OB3jg6sgwTdeEBzIKf1ur1kUxnD0cffWT6e5mxtAofAowsEgLBszNFZt9sjMnm z82EWwMy087jFnlQCNIqslViYEEn7bS0ejGbWrXTIDh4kMIobh2aCnIcN/TPbAVL9+A6 XvXEBlsqc/uY350ZegLLjIXcXcijFfYx6PDdmpFGN7nZ8wS4sgWFQVi3OELhuCvrhJjj i4LtHGEwx8AUXqSJZnklbjzpOuu1Mqh6kRBpYAaq3LLFO0ZUJa2Zjh2fmuv7U/dzgSLb EXhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=97zc63nu5CZ2IeOdFn7DZlP8YKJECYWU8eCS6FWVtK4=; b=Pzx1oHVkWk5bOGSJ2JAk7ImyNm9IMeoyEfwiAfbt+BTVIWwnZgbc7X0tyL+7HObTAR 3KQ5yZxADCbVuS/4AOL3gxi+SaDzHWywGC+5zK7+Bwqce6OP+gfeyD4BXHEdkPz9d28c 1E4rb64/PtTLeDrRFbf+lfXZ7esh7ZJ2sJtrqIHTIB3ERR6Yoi9YLEj1teps4ZD0ViCu DDVf8zqBFHKfr4OOo3BEUS76WuGefXZja93c/DrZay/jCqwuptxoXZ65bAsieoOmaiwI ERg33LLfbNDGMmXYjT3nA8nhkdTNXOsDvIEFsfWqMLPC0hVuHECP+TWsHthYIR6hB9sT QuRQ== X-Gm-Message-State: AKS2vOzUfrGL0kBPIAj3lnn5fiiz9plWTwR5WyQQTtWaNJYZc2uRxJ+H +7jdSKGJT9pOIGPm X-Received: by 10.84.224.199 with SMTP id k7mr14265541pln.207.1498693473591; Wed, 28 Jun 2017 16:44:33 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:f84e:29fc:7232:2f86? ([2620:0:10e7:10:f84e:29fc:7232:2f86]) by smtp.gmail.com with ESMTPSA id x85sm7510681pff.92.2017.06.28.16.44.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 16:44:33 -0700 (PDT) From: james woodyatt Message-Id: <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E05E5693-1372-4A75-9A5A-B1E638DFC8D4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 28 Jun 2017 16:44:32 -0700 In-Reply-To: Cc: IPv6 IPv6 List To: DY Kim References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:44:36 -0000 --Apple-Mail=_E05E5693-1372-4A75-9A5A-B1E638DFC8D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 28, 2017, at 16:26, DY Kim wrote: >> On 29 Jun 2017, at 07:25, james woodyatt > wrote: >>=20 >> In the concrete case, above, both Alfa and Bravo have the same IID=3D1 = in their global IPv6 addresses if the subnet prefix is /112 in both = cases, and therefore the recommended uniqueness property in = [@I-D.ietf-6man-rfc4291bis] is not respected. >=20 > The two IDs (1) are within different /112 subnet prefixes (2001:db8::1 = vs 2001:db8::2).So each is unique within each subnet prefix. I=E2=80=99d = think this configuration is in conformance with the recommendation in = rfc4291bis: >=20 > "They are required to be unique within a subnet prefix.=E2=80=9D But they do not meet the recommendation that the same IID not be = assigned to different nodes on the same link. With long interface = identifiers generated by pseudo-random or random number generators, the = recommended uniqueness property is achieved by statistical uniqueness. = If short interface identifiers are admissible, then some other mechanism = must be recommended for achieving uniqueness. There is neither any such = recommended method nor a relaxation of the uniqueness property declared = by [@RFC4291]. That=E2=80=99s my point. Fix that, and you=E2=80=99ve addressed my concern. Not sure how you can = address it though... --james woodyatt > --Apple-Mail=_E05E5693-1372-4A75-9A5A-B1E638DFC8D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 28, 2017, at 16:26, DY Kim <dykim6@gmail.com> = wrote:
On 29 = Jun 2017, at 07:25, james woodyatt <jhw@google.com> wrote:

In the concrete = case, above, both Alfa and Bravo have the same IID=3D1 in their global = IPv6 addresses if the subnet prefix is /112 in both cases, and therefore = the recommended uniqueness property in [@I-D.ietf-6man-rfc4291bis] is = not respected.

The two IDs (1) are within different /112 subnet prefixes = (2001:db8::1 = vs 2001:db8::2).So = each is unique within each subnet prefix. I=E2=80=99d think this = configuration is in conformance with the recommendation in = rfc4291bis:

   "They are required to be unique within = a subnet prefix.=E2=80=9D

But they do not meet the recommendation that the = same IID not be assigned to different nodes on the same link. With long = interface identifiers generated by pseudo-random or random number = generators, the recommended uniqueness property is achieved by = statistical uniqueness. If short interface identifiers are admissible, = then some other mechanism must be recommended for achieving uniqueness. = There is neither any such recommended method nor a relaxation of the = uniqueness property declared by [@RFC4291]. That=E2=80=99s my = point.

Fix that, and you=E2=80=99ve = addressed my concern. Not sure how you can address it = though...


--james woodyatt <jhw@google.com>



= --Apple-Mail=_E05E5693-1372-4A75-9A5A-B1E638DFC8D4-- From nobody Wed Jun 28 16:53:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FC1126C23 for ; Wed, 28 Jun 2017 16:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsysbXttpsFh for ; Wed, 28 Jun 2017 16:53:06 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603A6124D85 for ; Wed, 28 Jun 2017 16:53:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5SNr59o003017; Wed, 28 Jun 2017 16:53:05 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5SNr2UD003001 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 28 Jun 2017 16:53:02 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 16:53:01 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 16:53:02 -0700 From: "Manfredi, Albert E" To: james woodyatt , IPv6 IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS8C198zNl709EfUWKnaYWTqVEwaI7A5eAgAAvTACAABzqgP//nPOA Date: Wed, 28 Jun 2017 23:53:01 +0000 Message-ID: <5d7fb19e3af846a8984ca3f3320715e6@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> In-Reply-To: <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:53:08 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBqYW1lcyB3b29keWF0dA0KDQo+IEhlcmUsIEFsZmEg aGFzIHR3byBhZGRyZXNzZXMgd2l0aCB0aGUgc2FtZSBJSUQ6DQo+DQo+CUlJRChhZGRyZXNzPWZl ODA6OjEgbGVuZ3RoPTY0KSAtPiAxDQo+CUlJRChhZGRyZXNzPTIwMDE6ZGI4OjoxOjEgbGVuZ3Ro PTExMikgLT4gMQ0KPg0KPiBBbmQgdGhhdOKAmXMgb2theSwgYmVjYXVzZSBbQFJGQzQyOTFdIHNh eXMgIlRoZSBzYW1lIGludGVyZmFjZQ0KPiBpZGVudGlmaWVyIG1heSBiZSB1c2VkIG9uIG11bHRp cGxlIGludGVyZmFjZXMgb24gYSBzaW5nbGUgbm9kZSwNCj4gYXMgbG9uZyBhcyB0aGV5IGFyZSBh dHRhY2hlZCB0byBkaWZmZXJlbnQgc3VibmV0cy4iDQoNCk9rYXkuIEp1c3QgbGlrZSBJUHY0Lg0K DQo+IEhvd2V2ZXIsIEJyYXZvIGhhcyB0aGUgc2FtZSBJSUQgYXMgQWxmYSBvbiBvbmUgb2YgaXRz IGFkZHJlc3NlczoNCj4NCj4JSUlEKGFkZHJlc3M9ZmU4MDo6MiBsZW5ndGg9NjQpIC0+IDINCj4J SUlEKGFkZHJlc3M9MjAwMTpkYjg6OjI6MSBsZW5ndGg9MTEyKSAtPiAxDQoNCkJ1dCB0aGUgc3Vi bmV0IHByZWZpeCBpcyBkaWZmZXJlbnQuIEFsZmEncyBJSUQgb2YgMSBpcyB1c2VkIGluIGFuIGFk ZHJlc3Mgd2l0aCBhIGRpZmZlcmVudCBzdWJuZXQgcHJlZml4IHRoYW4gQnJhdm8ncywgc28gdGhl IGFkZHJlc3NlcyBkb27igJl0IGNvbmZsaWN0LiBXaGF0IG1hdHRlcnMgaXMgb25seSB0aGF0IGhv c3RzIGluIHN1Ym5ldCBwcmVmaXggMjAwMTpkYjg6OjI6MCBsZW5ndGggMTEyIG11c3QgaGF2ZSB1 bmlxdWUgSUlEcy4gKFJlYXNvbiBpcyBvYnZpb3VzLikNCg0KPiBJbiB0aGUgY29uY3JldGUgY2Fz ZSwgYWJvdmUsIGJvdGggQWxmYSBhbmQgQnJhdm8gaGF2ZSB0aGUgc2FtZQ0KPiBJSUQ9MSBpbiB0 aGVpciBnbG9iYWwgSVB2NiBhZGRyZXNzZXMgaWYgdGhlIHN1Ym5ldCBwcmVmaXggaXMgLzExMg0K PiBpbiBib3RoIGNhc2VzLCBhbmQgdGhlcmVmb3JlIHRoZSByZWNvbW1lbmRlZCB1bmlxdWVuZXNz IHByb3BlcnR5IGluDQo+IFtASS1ELmlldGYtNm1hbi1yZmM0MjkxYmlzXSBpcyBub3QgcmVzcGVj dGVkLg0KDQpUaGlzIGlzIHRoZSBxdW90ZToNCg0KICAgVGhleSBhcmUgcmVxdWlyZWQgdG8gYmUg dW5pcXVlIHdpdGhpbiBhIHN1Ym5ldA0KICAgcHJlZml4LiAgSXQgaXMgcmVjb21tZW5kZWQgdGhh dCB0aGUgc2FtZSBpbnRlcmZhY2UgaWRlbnRpZmllciBub3QgYmUNCiAgIGFzc2lnbmVkIHRvIGRp ZmZlcmVudCBub2RlcyBvbiBhIGxpbmsuDQoNCkJ1dCBhZ2FpbiwgaXQncyBjbGVhciB3aHkgdGhh dCBpcyBub3QgbWFuZGF0ZWQuIEl0IGRvZXNuJ3QgbWF0dGVyLiBUaGUgYWRkcmVzcyBpcyB1bmlx dWUgYW55d2F5LiBJdCBtaWdodCBoYXZlIGJlZW4gY29uZnVzaW5nIGJhY2sgd2hlbiBFVUktNjQg d2FzIG1hbmRhdG9yeSAodHdvIGhvc3RzLCBzYW1lIEVVSS02ND8/KS4gRXZlbiBpZiB0aGUgZHJh ZnQgd2VyZSB0byBicmluZyBpdCB1cCwgdGhlIG9ubHkgcmVhc29uIHdvdWxkIGJlIHRvIG1lbnRp b24gdGhhdCByZWNvbW1lbmRhdGlvbiB0ZXh0IGZyb20gdGhlIHBhc3QuDQoNCkJlcnQNCg0K From nobody Wed Jun 28 17:03:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018401201FA for ; Wed, 28 Jun 2017 17:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-fXcb0UWTr8 for ; Wed, 28 Jun 2017 17:03:06 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D20124D85 for ; Wed, 28 Jun 2017 17:03:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5T035T4053200; Wed, 28 Jun 2017 17:03:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5T02wJZ053161 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 28 Jun 2017 17:02:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 17:02:57 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 17:02:58 -0700 From: "Manfredi, Albert E" To: IPv6 IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS8C198zNl709EfUWKnaYWTqVEwaI7A5eAgAAvTACAABzqgP//nPOAgAAH5AA= Date: Thu, 29 Jun 2017 00:02:58 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:03:08 -0000 VGhpcyBpcyB0aGUgcXVvdGUgZnJvbSBSRkMgNDI5MToNCg0KICAgVGhleSBhcmUgcmVxdWlyZWQg dG8gYmUgdW5pcXVlIHdpdGhpbiBhIHN1Ym5ldA0KICAgcHJlZml4LiAgSXQgaXMgcmVjb21tZW5k ZWQgdGhhdCB0aGUgc2FtZSBpbnRlcmZhY2UgaWRlbnRpZmllciBub3QgYmUNCiAgIGFzc2lnbmVk IHRvIGRpZmZlcmVudCBub2RlcyBvbiBhIGxpbmsuDQoNCkhlcmUncyBhbm90aGVyIGNvbnNpZGVy YXRpb24sIHdpdGggcmVzcGVjdCB0byB3aGV0aGVyIHRoYXQgcmVjb21tZW5kYXRpb24gZXZlbiBt YWtlcyBzZW5zZSBhbnltb3JlLg0KDQpXaXRoIFNMQUFDLCB0aGUgd2F5IGl0J3MgaW1wbGVtZW50 ZWQgdG9kYXksIHRoYXQgcmVjb21tZW5kYXRpb24gY2Fubm90IGJlIGd1YXJhbnRlZWQuIFRoZXJl IGlzIG5vIGNoZWNrIGZvciBpdC4gSWYgdGhlcmUgYXJlIHR3byBzdWJuZXQgcHJlZml4ZXMgYXZh aWxhYmxlIG9uIGEgbGluaywgcGVyaGFwcyBvbmUgbWVhbnQgZm9yIG9ubHkgc3RhdGljYWxseSBh c3NpZ25lZCBhZGRyZXNzZXMgYW5kIHRoZSBvdGhlciBmb3IgU0xBQUMsIHRoZXJlIGlzIG5vdGhp bmcgdG8gY2hlY2sgZm9yIHRoYXQgdHlwZSBvZiBJSUQgdW5pcXVlbmVzcy4NCg0KQmVydA0KDQo= From nobody Wed Jun 28 17:14:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC630126C83 for ; Wed, 28 Jun 2017 17:14:32 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMDMZ_NUIIib for ; Wed, 28 Jun 2017 17:14:31 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 B0C2E126C23 for ; Wed, 28 Jun 2017 17:14:31 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u62so39140292pgb.3 for ; Wed, 28 Jun 2017 17:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aj9ZthGjtm4JXwo+VgDw7nLB71dE53rc9HuC5C8aGy8=; b=ID+tgkpP7u6qiBBc/7HbbFKSj4HXKG4cN/5GOs9LSTQSOZx7mhEjN7SE9Li38CPNLT oEciD6jnH8OgUKMm9WUnaNfHcSCOllgm52GjA06Z/8hkapuYZNcoOJDcLgbW18MnCmxc L+hMUPhqwiicpMJDyjvXWNPmZzJfbm8HST/UzhACHRq2R/V0kdrKbYTEJg0SeKnwf+ED 053sTXl7s0ghF+4N78r1lEB/9xFILHniwIUkMadEWfdCRoMqWG79xgZa3s7f7qhCrXb2 l4nv5R3edQg1K/OAJyV42fQi0WOHUgouAM3w7sjUa2upIb1X6hTHtOF2Q9UBf7LZCHcx wcOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aj9ZthGjtm4JXwo+VgDw7nLB71dE53rc9HuC5C8aGy8=; b=YXO60UyqYAQ34u3Mh7dzKyaUXwutdp5Gbb/kXZkaf5v5s8YklX/hkAa8/XyK8eyq6s 1P974OrG8SO+ghNKtO2lGqFrrtS2zfaY+RxcisTdqB65NyfJEXdMUZURZ2PMgQJ/Lwbo /UZV5qK5Fn1yNIOBEFxCGM4epIpv+4c99rvd+U990x7+AR0hDpEGuVlnDpRrq14RncbN OQo60Ujxdi3LjmOftfvS+DOOpdHaM7QYRBd0h/GaW3S3SHY/lQBuVNqASNOD+2V7STav nHQs0bgEiIs+OFPdlSqB5zrVeJ0dQoR84DHPuEqbmPpl0CVHHpqiDphBEoaAWdowOIaZ ZVIw== X-Gm-Message-State: AKS2vOxTjMI3k1kW3D8mA/ELgmyh5JvysnbqMUeuV+TNxuTCUCSl8dnL MWYXxdXDLIUM+Tpf5YU= X-Received: by 10.98.152.208 with SMTP id d77mr10598516pfk.210.1498695271152; Wed, 28 Jun 2017 17:14:31 -0700 (PDT) Received: from [59.29.43.118] ([59.29.43.118]) by smtp.gmail.com with ESMTPSA id f70sm7054398pfk.27.2017.06.28.17.14.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 17:14:30 -0700 (PDT) From: DY Kim Message-Id: <1969B60F-EF92-46AD-BAAC-99D70C2B6321@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9915F6F4-1717-4D55-9897-C8F1BDA0EADF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Thu, 29 Jun 2017 09:14:27 +0900 In-Reply-To: <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> Cc: IPv6 IPv6 List To: james woodyatt References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:14:33 -0000 --Apple-Mail=_9915F6F4-1717-4D55-9897-C8F1BDA0EADF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi James, [Quote] o They are required to be unique within a subnet prefix. o It is recommended that the same interface identifier not be assigned = to different nodes on a link. [QED} Rather than reading the two sentences =E2=80=98literally, I=E2=80=99d = think we might better read the two in the context. To me, the two are = meant to say the same thing. For example, the 2nd sentence could be read (or rewritten to avoid = confusion): o It is recommended that the same interface identifier not be = assigned to different nodes on the same subnet (or link) prefix. --Apple-Mail=_9915F6F4-1717-4D55-9897-C8F1BDA0EADF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi James,

[Quote]

  o They are required to be = unique within a subnet prefix.
  o It = is recommended that the same interface identifier not = be assigned to different nodes on a = link.

[QED}

Rather than reading the two sentences =E2=80=98literally, = I=E2=80=99d think we might better read the two in the context. To me, = the two are meant to say the same thing.

For example, the 2nd sentence could be = read (or rewritten to avoid confusion):

   o It is recommended that the same interface identifier not = be assigned to different nodes on the = same subnet (or link) prefix.


= --Apple-Mail=_9915F6F4-1717-4D55-9897-C8F1BDA0EADF-- From nobody Wed Jun 28 22:27:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF89129B13 for ; Wed, 28 Jun 2017 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-yc93qMYFy8 for ; Wed, 28 Jun 2017 22:26:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED2912025C for ; Wed, 28 Jun 2017 22:26:45 -0700 (PDT) Received: from [192.168.0.168] (unknown [91.105.20.29]) (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 4D1E580EC2; Thu, 29 Jun 2017 07:27:46 +0200 (CEST) Subject: Re: Tussles in IPv6 Land To: Brian E Carpenter , 6man References: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> From: Fernando Gont Message-ID: Date: Thu, 29 Jun 2017 08:13:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <13c1417b-36ab-b608-599e-8293c0a87402@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:26:48 -0000 On 06/10/2017 04:33 AM, Brian E Carpenter wrote: > > I wrote the text below a couple of months ago, but then got distracted. > However, I do think it's important that as we argue about (for example) > /64, to remember what's going on behind the apparent argument. > [...] > > Tussles in IPv6 Land > > Today (April 2017) we seem to have three very active tussles in the IPv6 technical > community. > > 1. Is header insertion on the fly OK, or is it the work of the devil? Quite a bit of the discussion about EH insertion wasn't even at this level, but rather at how the proposal was made: rather than proposing it as a change to RFC2460, it was trie to be sold as something that could be done while remaining compliant with RFC2460... eventually getting to a point in which we were supposed to stall progression of rfc2460bis to standard until the whole EH insertion thing was cooked. There were certainly sensible technical objections at some point, but most of the recent discussion had to do with trying to push this idea/proposal the wrong way. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jun 28 22:27:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6FD129B13; Wed, 28 Jun 2017 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNHldy9Qf8aP; Wed, 28 Jun 2017 22:26:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C76F128854; Wed, 28 Jun 2017 22:26:47 -0700 (PDT) Received: from [192.168.0.168] (unknown [91.105.20.29]) (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 3208082544; Thu, 29 Jun 2017 07:27:48 +0200 (CEST) Subject: Re: Comments on draft-voyer-6man-extension-header-insertion-00 To: Brian E Carpenter , 6man , draft-voyer-6man-extension-header-insertion@ietf.org References: <0364b377-7e23-ad4b-136a-86e1dda96cfd@gmail.com> <8F22ADA3-1865-4485-8ACD-56E47BD11CF5@cisco.com> <48233c99-e983-63f2-a042-96d4821b7676@gmail.com> From: Fernando Gont Message-ID: <0541fdce-0737-5372-0a0c-defff30bbae4@si6networks.com> Date: Thu, 29 Jun 2017 08:26:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <48233c99-e983-63f2-a042-96d4821b7676@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:26:49 -0000 On 06/25/2017 01:12 AM, Brian E Carpenter wrote: > Hi, > > This has been on my to-do list for a long time: > > 1. The RFC Editor does not allow long lists of authors. > Up to 5 authors, some of whom may be tagged as Editors, > is OK. Any others should be listed in a separate Contributors > section. The difference is that authors must have written a > significant part of the text but contributors have made > a smaller contribution. (Saying "I agree" isn't a contribution...) > > 2. The consensus text in rfc2460bis is quite clear: > > "Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node (or each of the set of nodes, > in the case of multicast) identified in the Destination Address field > of the IPv6 header. > > "The Hop-by-Hop Options header is not inserted or deleted, but may be > examined or processed by any node along a packet's delivery path,..." > > So the challenge for draft-voyer- is to craft a careful exception > to that consensus. The draft will need to be a standards track > document that explicitly updates rfc2460bis. Procedurally-speaking, it would seem to me that the I-D would need to do two things: 1) Change the is_to/must to "should" 2) Explain why an exception should be made for this particular case Rationale: the current text in rfc2460bi is a "must", hence there's not much room for exceptions with the current text -- without the text being relaxed first (possibly in the same I-D). > > 3. The tone of the Abstract is completely wrong. It should be much more > neutral and objective, such as: > > In some circumstances there is value in inserting extension > headers into an existing IPv6 packet at any point along its path, > as long the entire journey of the packet is certain to remain in > its source domain and the extended packet is certain not to exceed > the maximum transmission unit (MTU) of its path. This document > updates RFCxxxx accordingly. In which case, I'd expect that the proposal explains why they don't do tunneling -- which, by definition, would guarantee that such packets don't escape the intended domain. 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 Wed Jun 28 23:40:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4753129ACC for ; Wed, 28 Jun 2017 23:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eomwEaZkacJb for ; Wed, 28 Jun 2017 23:40:23 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 8D1C5129417 for ; Wed, 28 Jun 2017 23:40:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5T6eLDs047583 for ; Thu, 29 Jun 2017 08:40:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BB7D1200EF3 for ; Thu, 29 Jun 2017 08:40:21 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B5F132007F9 for ; Thu, 29 Jun 2017 08:40:21 +0200 (CEST) Received: from [132.166.84.31] ([132.166.84.31]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5T6eLN1020278 for ; Thu, 29 Jun 2017 08:40:21 +0200 Subject: Re: To: ipv6@ietf.org References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> From: Alexandre Petrescu Message-ID: <5e602478-c91d-6e21-cc0d-f7fb4f7d9131@gmail.com> Date: Thu, 29 Jun 2017 08:40:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 06:40:26 -0000 Le 28/06/2017 à 18:41, David Farmer a écrit : > > > On Tue, Jun 27, 2017 at 8:02 PM, Brian E Carpenter > > > wrote: > > On 28/06/2017 09:39, 神明é”哉 wrote: >> At Thu, 22 Jun 2017 09:38:04 +1200, Brian E Carpenter >> > wrote: >> >>>> I think this is getting really close. However, there still > seems to be an >>>> implication that a subnet must be /64 or 64 bits for both >>>> address generation and on-link determination. >>> >>> Yes, that's what it says, except for documented exceptions. As > far as I >>> understand the motivation of my co-authors on draft-bourbaki, > their main >>> objection to the previous rfc4291bis was that it didn't allow > for those >>> documented exceptions. >>> >>> Since SLAAC has always assumed that the two lengths are equal, >> >> What do you mean by this? Do you mean "SLAAC has always assumed >> the prefix length for address generation and the prefix length for > on-link >> determination are equal"? > > Yes. > >> Specifically which text of RFC4862 says that (or are you referring >> to other RFCs for SLAAC)? > > It doesn't say that. But on a normal broadcast LAN nothing else makes > much sense, so I believe that users have always made this assumption, > regardless of what implementations might support. > > > I would agree the normal use of SLAAC is with "64 bits for both > address generation and on-link determination." For normal (common, > default, etc...) use that is fine, you will have a PIO for /64 with > both A and L flags set, and is as it probably should be most of the > time. Further, for link-local address generation and on-link > determination 64 bits is always the case, all valid link-local > address are always on-link by definition. > > However, the protocol itself doesn't require use of 64 bits for > on-link determination for GUA regardless of how the address is > generated and I think this is the root of the disagreement here. In > reality if it is made clear on-link determination may normally be > based on a /64, but is not required to be /64, then manual > configuration of an address with an on-link prefix of anything > between 0 and 128 isn't actually an exception, it is simply a > consequence of how the protocol actually is intended to work, and the > same goes of DHCP with an on-link RA other than /64. > > Now in my option, with the exception of point-to-point links, on-link > determination based on /64 prefix is RECOMMENDED. > > On 28/06/2017 10:12, james woodyatt wrote: ... >> I’m still further confused now. Are you now saying that LwIP is > correctly interpreting RFC 4291 by assuming the two lengths must be > equal and rejecting advertisements containing a different on-link > prefix length than is the standard address configuration prefix > length for the link type? > > No, because RFC 4291 doesn't say that: it simply states the IID > length. So you're describing an implementation choice, which very > possibly doesn't conform to RFC 4862. > > > And subnet prefix is tangled up in the definition of IID and it's > length, which without something saying otherwise from the definition > and use of subnet in IPv4 it is perfectly reasonable to make such an > assumption. Therefore we need to fix this misconception in > RFC4291bis. > > I believe the way to clear this up is to say "a 64 bit IID is > REQUIRED for address generation, and /64 prefix is RECOMMENDED for > on-link determination." > > For the sake of discussion, lets say I have pair of nodes connected > with an ethernet, I manually configure one with 2001:db8::1:1/112 and > the other with 2001:db8::1:2/112. > > The first node will have an interface will have a link-local address > of FE80::/64 with a random 64 bit IID, and a GUA with a subnet prefix > of 2001:db8::1/112 and a 16bit IID of 1. The second node will have > an interface will have a link-local address of FE80::/64 with a > random 64 IID, and a GUA with a subnet prefix of 2001:db8::1/112 and > a 16bit IID of 2. > > Now I add a router, and manually configure the address as > 2001:db8::1:3/112, it will generate a link-local address of FE80::/64 > probably with an EUI-64 as the IID, and a GUA with a subnet prefix > of 2001:db8::1/112 and a 16bit IID of 3, the router will generate a > RA with a PIO of 2001:db8::1/112 with L=1 and A=0, if A=1 this would > be an invalid PIO. Further, I could tell the router to set M=1 in > the RA, and configure a DHCPv6 server on the router to respond with > addresses 2001:db8::1:4 through 2001:db8::1:ffff. > > Now, I can attach an additional node and if able it will receive and > address via DHCPv6 and for this discussion lets say it receives > 2001:db8::1:4, and from the RA it gets the on-link prefix of > 2001:db8::1/112. > > Lets be clear, this is not a recommended configuration, however it is > nevertheless a valid configuration, it doesn't violate protocol. And > I believe this is constant with saying "a 64 bit IID is REQUIRED for > address generation, and /64 prefix is RECOMMENDED for on-link > determination." ... sounds as if on-link determination happens better if the prefix len were 64. But it happens equally well if nodes used e.g. 112, as long as all use the same value, and as long as the forwarding is set up towards them. > However, if we simply say "a 64 bit IID is REQUIRED" then I believe > it implies "64 bits for both address generation and on-link > determination is required," which it is not. Hmm... Alex > > Thanks. > > -- =============================================== David Farmer > Email:farmer@umn.edu Networking & > Telecommunication Services Office of Information Technology > University of Minnesota 2218 University Ave SE Phone: > 612-626-0815 Minneapolis, MN 55414-3029 > Cell: 612-812-9952 > =============================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 29 00:02:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D014129417 for ; Thu, 29 Jun 2017 00:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mscC7mU7Agqk for ; Thu, 29 Jun 2017 00:02:40 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FD9127775 for ; Thu, 29 Jun 2017 00:02:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 1119CBA4 for ; Thu, 29 Jun 2017 07:02:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGhobEn61R-o for ; Thu, 29 Jun 2017 02:02:39 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id CFC8DBA3 for ; Thu, 29 Jun 2017 02:02:39 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id l38so27818876uaf.1 for ; Thu, 29 Jun 2017 00:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9HXhIgt+ZgmqBQ59DQ1R0TFJYiPiBI4f9nHJnuvxN1w=; b=Z2aEku+VOanHxe+MESrusWnF0+5gZfzL2wnYy0EuAvg7OL5ZhnUOkcv2TVQuObkZMG SsMkzD6LbJruxXnimdF/FCaWFxiXL2tEAC25t4W0Mt1RAcE3Rl0S8XPxGMIY9lH6miSq dHIoeoDKVIRV9RwjxTsEBHQfvgmlNLeuHNxZ1BKFPAUxrM+WIEumZe2SuyeFd0YMRsoK 9BWqY1x3R+zQsu+IFQpkXt8mjXgs3xmFM3Yx+p0grx6VetaGky08crdWM4WLT9SSMBfn F+dUYhp+QrGQtNqwn9Bh/zZ4zCW2eTPNZBhea45YbhT+F2ciHIGLdYJRn18B7TU/zzSG J9Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9HXhIgt+ZgmqBQ59DQ1R0TFJYiPiBI4f9nHJnuvxN1w=; b=HwqnGL04pn5y3ChfriNskK16zBO101IvygjeqrScLe7X4RZhbCEA9T7GEtDQ2+xQxA lKoExTOmaQFORbtgdE3/dcWgWg4kMBk5dT2vBsxMudAmkok0+9OfNbrXzCPUjVMZAxjn yJjbSDQhtTMXbLOLovR/xeCs1zY5Fz4fJA30EIzV9RnadoJPiGT/OLZBBX2JaH17OYMj 4uCpwTID1BGrOpw8E8+KkqY7UB4gu79tqXUAGNch3nkSg6ySDeyISyZF2lMHZiBhkMfE FBeTdLwmaGfbCwycm7qniz9Y0/USLQiqOAZdWuxUy1vL5HJDrcee0p7HgQtTPQcoEFqa DtBQ== X-Gm-Message-State: AKS2vOxcnRRZnoaB8VkYlEDO8Na30RV2wMzBE1wPSGnweasvEc0MxmZp noycO2BWXK67oHNlJNV8KnIQFBDQP2VRtWDIXBhIjNt02gSCbXf5AXl8R64aEtmpkQGRdYBaElE P/bvj5cQaC3SPo9Q= X-Received: by 10.176.90.148 with SMTP id w20mr8696828uae.92.1498719758211; Thu, 29 Jun 2017 00:02:38 -0700 (PDT) X-Received: by 10.176.90.148 with SMTP id w20mr8696817uae.92.1498719758007; Thu, 29 Jun 2017 00:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Thu, 29 Jun 2017 00:02:36 -0700 (PDT) In-Reply-To: <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> From: David Farmer Date: Thu, 29 Jun 2017 02:02:36 -0500 Message-ID: Subject: Re: To: james woodyatt Cc: DY Kim , IPv6 IPv6 List Content-Type: multipart/alternative; boundary="f403045f8efecb56ea055313e2ad" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:02:42 -0000 --f403045f8efecb56ea055313e2ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2017 at 6:44 PM, james woodyatt wrote: > On Jun 28, 2017, at 16:26, DY Kim wrote: > > On 29 Jun 2017, at 07:25, james woodyatt wrote: > > In the concrete case, above, both Alfa and Bravo have the same IID=3D1 in > their global IPv6 addresses if the subnet prefix is /112 in both cases, a= nd > therefore the recommended uniqueness property in > [@I-D.ietf-6man-rfc4291bis] is not respected. > > > The two IDs (1) are within different /112 subnet prefixes (2001:db8::1 vs= 2001:db8::2).So > each is unique within each subnet prefix. I=E2=80=99d think this configur= ation is > in conformance with the recommendation in rfc4291bis: > > "They are required to be unique within a subnet prefix.=E2=80=9D > > > But they do not meet the recommendation that the same IID not be assigned > to different nodes on the same link. With long interface identifiers > generated by pseudo-random or random number generators, the recommended > uniqueness property is achieved by statistical uniqueness. If short > interface identifiers are admissible, then some other mechanism must be > recommended for achieving uniqueness. There is neither any such recommend= ed > method nor a relaxation of the uniqueness property declared by [@RFC4291]= . > That=E2=80=99s my point. > > Fix that, and you=E2=80=99ve addressed my concern. Not sure how you can a= ddress it > though... > Yes, you can derive situations with /112 prefixes that don't meet that recommendation, but I can derive ones that do meet the recommendation. That simply means ones set of situation are recommended and the others are not. This would only truly be a problem if it were impossible to meet the recommendation with a /112 prefix. I can also derive a situation where the recommendation isn't meet even with a /64 prefix. Manually assign 2001:db8:0:1::1 and 2001:db8:0:2::1 to two different nodes. Does this mean /64 prefixes are invalid? No, that is why this is a recommendation and it is not a requirement. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --f403045f8efecb56ea055313e2ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 28, 2017 at 6:44 PM, james woodyatt <<= a href=3D"mailto:jhw@google.com" target=3D"_blank">jhw@google.com> wrote:
On Jun 28, 2017, at 16:26, DY Kim <dykim6@gmail.com> wrote:=
On 29 Jun 2017, at 07:25, james woodyatt &= lt;jhw@google.com&g= t; wrote:

In the concrete case, above, bo= th Alfa and Bravo have the same IID=3D1 in their global IPv6 addresses if t= he subnet prefix is /112 in both cases, and therefore the recommended uniqu= eness property in [@I-D.ietf-6man-rfc4291bis] is not respected.

The two IDs (1) are within different /112 subn= et prefixes (2001:db8::1 vs=C2=A0= 2001:db8::2).So each is unique within e= ach subnet prefix. I=E2=80=99d think this configuration is in=C2=A0c= onformance with the recommendation in rfc4291bis:

= =C2=A0 =C2=A0"They are required to= be unique within a subnet=C2=A0= prefix.=E2=80=9D

But th= ey do not meet the recommendation that the same IID not be assigned to diff= erent nodes on the same link. With long interface identifiers generated by = pseudo-random or random number generators, the recommended uniqueness prope= rty is achieved by statistical uniqueness. If short interface identifiers a= re admissible, then some other mechanism must be recommended for achieving = uniqueness. There is neither any such recommended method nor a relaxation o= f the uniqueness property declared by [@RFC4291]. That=E2=80=99s my point.<= /div>

Fix that, and you=E2=80=99ve addressed my concern.= Not sure how you can address it though...

Yes, you can derive situations with /112= prefixes that don't meet that recommendation, but I can derive ones th= at do meet the recommendation. That simply means ones set of situation are = recommended and the others are not. This would only truly be a problem if i= t were impossible to meet the recommendation with a /112 prefix.

I can also derive a situation where the recommend= ation isn't meet even with a /64 prefix. Manually assign 2001:db8:0:1::= 1 and 2001:db8:0:2::1 to two different nodes. Does this mean /64 prefixes a= re invalid? No, that is why this is a recommendation and it is not a requir= ement.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication = Services
Office of Information Technology
University of Minnesota=C2= =A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-= 626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045f8efecb56ea055313e2ad-- From nobody Thu Jun 29 02:27:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9112EC05 for ; Thu, 29 Jun 2017 02:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODz1kEi26RYK for ; Thu, 29 Jun 2017 02:27:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E470A12EBF6 for ; Thu, 29 Jun 2017 02:27:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dQVjb-0000GeC; Thu, 29 Jun 2017 11:27:35 +0200 Message-Id: To: ipv6@ietf.org Cc: james woodyatt Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> In-reply-to: Your message of "Wed, 28 Jun 2017 15:25:11 -0700 ." <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> Date: Thu, 29 Jun 2017 11:27:33 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 09:27:41 -0000 > > To define a /112 subnet prefix means the IID must be only 16 bits long. Tha > ts not valid under RFC 4291. > > > > Specifically, when the DHCPv6 server generates the IID for the addresses th > at it provides to hosts in IA_NA or IA_TA configuration options, those addres > ses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet pr > efixes and 64 bit IIDS. There is nothing that operationally links IA_NA to /64. An address is just an address. A host can not derive any meaningfull semantics from the statement that IIDs are 64 bits when dealing with IA_NA. In theory a DHCPv6 server could refuse to operate on prefixes that are not /64, but that's an implementation detail. So I'd like to propose that we kill any connection between IA_NA and /64 from all relevant documents. Keeping this will only create confusion and lead to implementations that mistakenly derive (or restrict) prefix lengths related to addresses configured this way. The same applies to manually configured addresses. From nobody Thu Jun 29 02:35:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5571C12ECCB for ; Thu, 29 Jun 2017 02:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIkSiHGwxs7j for ; Thu, 29 Jun 2017 02:35:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6642812ECBC for ; Thu, 29 Jun 2017 02:35:21 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dQVr2-0000GIC; Thu, 29 Jun 2017 11:35:16 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <17D20A33-C574-42F1-8905-39907388745D@google.com> <1fdf185c3c884b45949ed40d611fc1f8@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Wed, 28 Jun 2017 21:38:27 +0000 ." <1fdf185c3c884b45949ed40d611fc1f8@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 29 Jun 2017 11:35:12 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 09:35:23 -0000 In your letter dated Wed, 28 Jun 2017 21:38:27 +0000 you wrote: > There is no > logical rationale for insisting that the IID be anything more than > locally unique. The fact that in the past, one form of IIU (i.e. > EUI-64) was *presumed* to be globally unique created this odd > concept, of multiple different uniqueness requirments for the IID. > It was a mere artifact of EUI-64. Historically, EUI-64 IIDs were not assumed to be globally unique. When EUI-64 was introduced as IID, manufacturing defects in ethernet cards were common enough that any attempt to use them as world wide unique identifiers was assumed to fail. Note that DAD was required from early on because it was assumed that ethernet addresses are not always unique. Beyond that, it is possible to interprate the IEEE standard such that a device as a whole needs a unique ethernet address but can use that address on multiple ports. As far as I know, Sun was one of the first companies to do this. Which caused all kinds of interesting issues in switches that assumed ethernet address would be unique. From nobody Thu Jun 29 10:41:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA4F128BA2 for ; Thu, 29 Jun 2017 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RbUtuYsYJm9 for ; Thu, 29 Jun 2017 10:41:53 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 459701289B0 for ; Thu, 29 Jun 2017 10:41:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5THfpA2195600 for ; Thu, 29 Jun 2017 19:41:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A8E12086AF for ; Thu, 29 Jun 2017 19:41:51 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 20D71205A3A for ; Thu, 29 Jun 2017 19:41:51 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5THfoca024252 for ; Thu, 29 Jun 2017 19:41:51 +0200 Subject: Re: To: ipv6@ietf.org References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> From: Alexandre Petrescu Message-ID: Date: Thu, 29 Jun 2017 19:41:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:41:55 -0000 Le 29/06/2017 à 11:27, Philip Homburg a écrit : >>> To define a /112 subnet prefix means the IID must be only 16 bits long. Tha >> ts not valid under RFC 4291. >>> >>> Specifically, when the DHCPv6 server generates the IID for the addresses th >> at it provides to hosts in IA_NA or IA_TA configuration options, those addres >> ses do not have /112 subnet prefixes and 16 bit IIDs. They have /64 subnet pr >> efixes and 64 bit IIDS. > > There is nothing that operationally links IA_NA to /64. An address is just > an address. A host can not derive any meaningfull semantics from the statement > that IIDs are 64 bits when dealing with IA_NA. In theory a DHCPv6 server > could refuse to operate on prefixes that are not /64, but that's an > implementation detail. It's common that DHCPv6 Clients set 64 as prefix len without anybody telling them do so, except, err... RFC4291. > So I'd like to propose that we kill any connection between IA_NA and /64 from > all relevant documents. I agree. Alex > Keeping this will only create confusion and lead to > implementations that mistakenly derive (or restrict) prefix lengths related > to addresses configured this way. The same applies to manually configured > addresses. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jun 29 10:45:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EFB129B23 for ; Thu, 29 Jun 2017 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvA7N_AtMA-u for ; Thu, 29 Jun 2017 10:45:45 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3575B1289B0 for ; Thu, 29 Jun 2017 10:45:45 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s66so53945448pfs.1 for ; Thu, 29 Jun 2017 10:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=2LPG2oDifYoHr4Mbm2RuYoj4C0mV+9L4bfI0bae8+pw=; b=YtwDmcJ2GxZIMsiSoyFJoAmnrBHBxq9PKYikHy0vRwkdYfBQKLJytHG+Ue5JmyBwjQ VjXGUGx/TxYNGBf8hzNMz7Df428+nVGPZ+F4cfS2UCv4v64JX9fxbgbo6xJKum5YJHlL ruODICgzsvWmXoeDQ7LZ/Kpr8TCNN8gzA6DiozA1vx4pTbfbQkVVEom2XeGQU0ykqnmh X6ynmeuUqaC3YTbgmcjO5RyW2YB0F9zPLT2F7Z3p1axFKBlzzibcaiDEduXJx+NQcRGZ KZxGjPI4pC8K0P3ty5W62RVkAjLXCUT+2dUF7k7zv8oZgoN+nAxj7ugVz9/zB+qKLQ3Z r97g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=2LPG2oDifYoHr4Mbm2RuYoj4C0mV+9L4bfI0bae8+pw=; b=WuA8kCx1B5UyZVV0bxw1G0tt9ONJmMdie5UrNlkvpCVohpzqEejjvIeH270GSz6mYk KcJjUsy0AL1BCNXqjEprsO8TBIkpnXsr9z6qPiIOjYZ8vzKYsX5XNm2gkYgde2rggJx/ t+amdIqq0cN9rGVcVOaU0yuRn1qh1xBlv4+xWu62MpOUD1BioJY+nh+Mewj9DWkaiaSk dDo1yobe0/ZBCiGqA2/ONwgd6vda33FRvG4AACJsDxVDpxtgdfhgguFZLuY6dvnVZSY3 Mfr15n9Vuozc7DYzPWPjj9a99Y7ksM9Ypb4sUgXaE+2JzOfuTP5YPlDLWb3KdSlAvJ5O PgOg== X-Gm-Message-State: AKS2vOylwBxD9T2v6AjtxQiZpGRg2cYYCbnhQTpJtxaO+Q0OIPZkEgkt e5p/vEpRvJSECyTul/Ks9Q== X-Received: by 10.84.224.206 with SMTP id k14mr19292169pln.72.1498758344450; Thu, 29 Jun 2017 10:45:44 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:c0aa:9e13:f4a1:253a? ([2620:0:10e7:10:c0aa:9e13:f4a1:253a]) by smtp.gmail.com with ESMTPSA id m68sm14485273pfi.12.2017.06.29.10.45.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 10:45:43 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_FCF91038-5929-49BD-ABBA-AD5B6544905E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Thu, 29 Jun 2017 10:45:42 -0700 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> To: IPv6 IPv6 List In-Reply-To: Message-Id: <10D232D4-FBE1-4EAF-B4BC-F65E8EE923B9@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:45:47 -0000 --Apple-Mail=_FCF91038-5929-49BD-ABBA-AD5B6544905E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 29, 2017, at 00:02, David Farmer wrote: >=20 > Yes, you can derive situations with /112 prefixes that don't meet that = recommendation, but I can derive ones that do meet the recommendation. = That simply means ones set of situation are recommended and the others = are not. This would only truly be a problem if it were impossible to = meet the recommendation with a /112 prefix. I disagree. There is a serious problem. All the currently standard and best current practice methods of = generating IPv6 interface addresses meet the recommendation provided you = accept that statistical uniqueness is a adequate for the purpose. = Changing the /64 subnet prefix length from a constant to a dynamic = operational configuration parameter removes that condition, and that=E2=80= =99s what makes this change inappropriate for an update intended for = simply promoting [@RFC4291] to Internet Standard. Either drop the = recommendation in another draft that updates the successor to = [@RFC4291], or keep the recommendation and specify a method of meeting = it with short interface identifiers that doesn=E2=80=99t rely on = statistical uniqueness. I think I have now restated this argument in sufficiently different = terms that it should be clear to anyone legitimately confused about my = reasoning, and any further repetition would be combative in my view. So, = I=E2=80=99m done. --james woodyatt > --Apple-Mail=_FCF91038-5929-49BD-ABBA-AD5B6544905E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 29, 2017, at 00:02, David Farmer <farmer@umn.edu> = wrote:

Yes, you can derive situations with = /112 prefixes that don't meet that recommendation, but I can derive ones = that do meet the recommendation. That simply means ones set of situation = are recommended and the others are not. This would only truly be a = problem if it were impossible to meet the recommendation with a /112 = prefix.

I disagree. = There is a serious problem.

All the = currently standard and best current practice methods of generating IPv6 = interface addresses meet the recommendation provided you accept that = statistical uniqueness is a adequate for the purpose. Changing the /64 = subnet prefix length from a constant to a dynamic operational = configuration parameter removes that condition, and that=E2=80=99s what = makes this change inappropriate for an update intended for simply = promoting [@RFC4291] to Internet Standard. Either drop the = recommendation in another draft that updates the successor to = [@RFC4291], or keep the recommendation and specify a method of meeting = it with short interface identifiers that doesn=E2=80=99t rely on = statistical uniqueness.

I think I = have now restated this argument in sufficiently different terms that it = should be clear to anyone legitimately confused about my reasoning, and = any further repetition would be combative in my view. So, I=E2=80=99m = done.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_FCF91038-5929-49BD-ABBA-AD5B6544905E-- From nobody Thu Jun 29 11:59:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E0129B94 for ; Thu, 29 Jun 2017 11:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-2HJA-vh54S for ; Thu, 29 Jun 2017 11:59:38 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 A86D4126D05 for ; Thu, 29 Jun 2017 11:59:38 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 2FF65C2C for ; Thu, 29 Jun 2017 18:59:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK42nwtBJI9l for ; Thu, 29 Jun 2017 13:59:38 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id E373712B for ; Thu, 29 Jun 2017 13:59:37 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id f197so30043425vka.15 for ; Thu, 29 Jun 2017 11:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ASxFxc0Qf+GjNu9tlaEjxpfcUTr3JpZMNt2nzY8jJq4=; b=aaHa5gWfIFL1WdINKBO5J1/o9RNBcoeNdtc415Z4xcLprDyttjoyhy+9WCqBcm/cro 3WEYlSI9GuqL3Li8SpvaeQJDoZ0drnCQahjLeCrELkKJeyYLiIUUXQ+NZxQDtKKOHgPb LP1fsV5krNWB+6oyiMoIGXWrkNWbvvFpFjrUpbShXf3xC07OBlq4AiH0xANnXjzcJicx 7mRva3w9S3BB3rO//8rwzWjZYM38MKa2jOqUikuFpMh6TlQk6gfmYAeAmwvM9bCkJnks plghiC3SD0TxH2JhQA23ElIdd1i6NsRv5Hb3ORvbeqSaNotQclIpM8WUZgZa7A21lKtb RxPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ASxFxc0Qf+GjNu9tlaEjxpfcUTr3JpZMNt2nzY8jJq4=; b=HFCjbT6ynJ6qy75rQjcWe6Xi95v48jfThw75QnxD1WLPo9R7syTK1w3Qy3IKYhzF7f 3KbrRlrUTykGYdt/4eguyX0CwoXu8bDGaJ/+uANHdvnLtRD0UI9xZe25EOMs3XHFlLWG UFT3ZxAwm6mIjH/4t4NJFz7v+RxOrtYbFcG7GW56ceh0Z4VM+YivH5hJPTFUvdsi9H4L +1YBARx6IUOM/V55xerrcHykYmps+uWXy/710RhraxWi4OBYajZeCokF+OPJlQTmBSoz TfhJwEsDigTpU9i8Q1dXPh0K+cAQHhENGqXjR9OWnDW6vjO/kAK9CMrtNbIw8tYGKbXN siQQ== X-Gm-Message-State: AKS2vOzp1Swukp1/PQjZiROW1YOuzYObhfdFnFnGuU2YOiwBbZoLuCc4 IIdbfpBjfJ6jHU/RyBRXntY7WnFqeQJ8pugrXN+L2MnAFDtG1oZ+rl6vfSYmnbzov7kV3JBwpqs ojSYKQgZudnYwocc= X-Received: by 10.31.114.75 with SMTP id n72mr9464024vkc.24.1498762776621; Thu, 29 Jun 2017 11:59:36 -0700 (PDT) X-Received: by 10.31.114.75 with SMTP id n72mr9464017vkc.24.1498762776434; Thu, 29 Jun 2017 11:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Thu, 29 Jun 2017 11:59:35 -0700 (PDT) In-Reply-To: <10D232D4-FBE1-4EAF-B4BC-F65E8EE923B9@google.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> <10D232D4-FBE1-4EAF-B4BC-F65E8EE923B9@google.com> From: David Farmer Date: Thu, 29 Jun 2017 13:59:35 -0500 Message-ID: Subject: Re: To: james woodyatt Cc: IPv6 IPv6 List Content-Type: multipart/alternative; boundary="94eb2c14949ae4708605531de606" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 18:59:41 -0000 --94eb2c14949ae4708605531de606 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 29, 2017 at 12:45 PM, james woodyatt wrote: > On Jun 29, 2017, at 00:02, David Farmer wrote: > > > Yes, you can derive situations with /112 prefixes that don't meet that > recommendation, but I can derive ones that do meet the recommendation. Th= at > simply means ones set of situation are recommended and the others are not= . > This would only truly be a problem if it were impossible to meet the > recommendation with a /112 prefix. > > > I disagree. There is a serious problem. > > All the currently standard and best current practice methods of generatin= g > IPv6 interface addresses meet the recommendation provided you accept that > statistical uniqueness is a adequate for the purpose. Changing the /64 > subnet prefix length from a constant to a dynamic operational configurati= on > parameter removes that condition, and that=E2=80=99s what makes this chan= ge > inappropriate for an update intended for simply promoting [@RFC4291] to > Internet Standard. Either drop the recommendation in another draft that > updates the successor to [@RFC4291], or keep the recommendation and speci= fy > a method of meeting it with short interface identifiers that doesn=E2=80= =99t rely > on statistical uniqueness. > > I think I have now restated this argument in sufficiently different terms > that it should be clear to anyone legitimately confused about my reasonin= g, > and any further repetition would be combative in my view. So, I=E2=80=99m= done. > OK then, please explain to me how you resolve the apparent conflicts between the following; RFC4291 basically states subnet prefixes and IIDs MUST be 64 bit, and since the term subnet prefix is used this seems to imply this is true both for address generation and on-link determination. However, RFC4861 seems quite specific that prefixes for on-link determination can be any length 0-128, and regardless if the prefix is invalid for SLAAC, it is still valid for on-link determination. This is discussed in detail in draft-jinmei-6man-prefix-clarify-00. Furthermore, the fact that on-link determination can be any length 0-128, seems to be reinforced by RFC7608. In my mind I resolve this by qualifying the MUST statement of RFC4291 to be about address generation and go to a RECOMMENDED statement for on-link determination. Which to me means /64 prefixes are normal for both address generation and on-link determination, However any length prefix is valid but NOT RECOMMENDED for on-link determination. But if you have another resolution to this conflict, I'm happy to listen. Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --94eb2c14949ae4708605531de606 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 29, 2017 at 12:45 PM, james woodyatt <= jhw@google.com><= /span> wrote:
On Jun 29, 2017, at 00:02, David Farmer <farmer@umn.edu> wro= te:

Yes, you can derive situations with /112 prefixes that don'= t meet that recommendation, but I can derive ones that do meet the recommen= dation. That simply means ones set of situation are recommended and the oth= ers are not. This would only truly be a problem if it were impossible to me= et the recommendation with a /112 prefix.

I disagree. There is a serious problem.

All = the currently standard and best current practice methods of generating IPv6= interface addresses meet the recommendation provided you accept that stati= stical uniqueness is a adequate for the purpose. Changing the /64 subnet pr= efix length from a constant to a dynamic operational configuration paramete= r removes that condition, and that=E2=80=99s what makes this change inappro= priate for an update intended for simply promoting [@RFC4291] to Internet S= tandard. Either drop the recommendation in another draft that updates the s= uccessor to [@RFC4291], or keep the recommendation and specify a method of = meeting it with short interface identifiers that doesn=E2=80=99t rely on st= atistical uniqueness.

I think I have now restated = this argument in sufficiently different terms that it should be clear to an= yone legitimately confused about my reasoning, and any further repetition w= ould be combative in my view. So, I=E2=80=99m done.
<= /blockquote>
=C2=A0
OK then, please explain to me how you res= olve the apparent conflicts between the following;

RFC4291 basically states subnet prefixes and IIDs MUST be 64 bit, and sinc= e the term subnet prefix is used this seems to imply this is true both for = address generation and on-link determination.=C2=A0

However, RFC4861 seems quite specific that prefixes for on-link determina= tion can be any length 0-128, and regardless if the prefix is invalid for S= LAAC, it is still valid for on-link determination.=C2=A0 This is discussed = in detail in draft-jinmei-6man-prefix-clarify-00. Furthermore, the fac= t that on-link determination can be any length 0-128, seems to be reinforce= d by RFC7608.

In my mind I resolve this by qualify= ing the MUST statement of RFC4291 to be about address generation and go to = a RECOMMENDED statement for on-link determination.=C2=A0 Which to me means = /64 prefixes are normal for both address generation and on-link determinati= on, However any length prefix is valid but NOT RECOMMENDED for on-link dete= rmination.

But if you have another resolution to t= his conflict, I'm happy to listen.

Thank= s

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c14949ae4708605531de606-- From nobody Thu Jun 29 12:23:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419E612EAB6 for ; Thu, 29 Jun 2017 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbZwvPOq0nZq for ; Thu, 29 Jun 2017 12:23:24 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD6912EBF6 for ; Thu, 29 Jun 2017 12:23:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v5TJNM25026387; Thu, 29 Jun 2017 12:23:22 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5TJNKRJ026367 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 29 Jun 2017 12:23:20 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Jun 2017 12:23:19 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 29 Jun 2017 12:23:19 -0700 From: "Manfredi, Albert E" To: james woodyatt , IPv6 IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS8C198zNl709EfUWKnaYWTqVEwaI7A5eAgAAvTACAABzqgIAAEQoAgAAFIQCAAHplAIAAs64A//+kyKA= Date: Thu, 29 Jun 2017 19:23:19 +0000 Message-ID: <58030254d08c4c43b2379b620903a62d@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <595E02BA-439D-41ED-B166-A4E854ACA6F2@gmail.com> <23764a2f-3c47-ae86-d6d3-441fc6a9ef84@gmail.com> <62fae350-26c5-ecee-973b-d51bdf11ad35@gmail.com> <36229DA7-7BDA-48D8-A959-31E562FC33E5@google.com> <73BCB83E-9484-4472-BA1E-44ABE9B38084@google.com> <91041AA2-185B-4C5D-87EB-A93DC69D432E@google.com> <10D232D4-FBE1-4EAF-B4BC-F65E8EE923B9@google.com> In-Reply-To: <10D232D4-FBE1-4EAF-B4BC-F65E8EE923B9@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:23:26 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGph bWVzIHdvb2R5YXR0DQoNCj4gSSBkaXNhZ3JlZS4gVGhlcmUgaXMgYSBzZXJpb3VzIHByb2JsZW0u DQo+DQo+IEFsbCB0aGUgY3VycmVudGx5IHN0YW5kYXJkIGFuZCBiZXN0IGN1cnJlbnQgcHJhY3Rp Y2UgbWV0aG9kcyBvZiBnZW5lcmF0aW5nDQo+IElQdjYgaW50ZXJmYWNlIGFkZHJlc3NlcyBtZWV0 IHRoZSByZWNvbW1lbmRhdGlvbiBwcm92aWRlZCB5b3UgYWNjZXB0IHRoYXQNCj4gc3RhdGlzdGlj YWwgdW5pcXVlbmVzcyBpcyBhIGFkZXF1YXRlIGZvciB0aGUgcHVycG9zZS4NCg0KVGhlbiBteSBy ZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSwgYXQgbW9zdCwgZm9yIHRoZSBkcmFmdCB0byBtZW50aW9u IHRoaXMgInJlY29tbWVuZGF0aW9uIiBpbiBSRkMgNDI5MSwgdG8gZXhwbGFpbiB3aHkgaXQgd2Fz IG1hZGUgKGR1cGxpY2F0ZSBFVUktNjRzIG1heSBjcmVhdGUgY29uZnVzaW9uKSwgYW5kIGNvbnNl cXVlbnRseSwgZGlzbWlzcyB0aGUgcmVjb21tZW5kYXRpb24gYXMgbm8gbG9uZ2VyIGJlaW5nIGEg Y29uY2Vybj8NCg0KSWYgaXQncyB0cnVseSBzZXJpb3VzLCBpdCB3b3VsZCBoYXZlIGJlZW4gYSBN VVNULCBvbmUgd291bGQgaGF2ZSB0byBiZWxpZXZlLg0KDQpCZXJ0DQoNCg== From nobody Fri Jun 30 20:25:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E793E12EB27 for ; Fri, 30 Jun 2017 20:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NofkVqg_ic8 for ; Fri, 30 Jun 2017 20:25:27 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 10E25127241 for ; Fri, 30 Jun 2017 20:25:27 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id z22so85568108uah.1 for ; Fri, 30 Jun 2017 20:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=iOaiDPfhoMD7mwy029CfKmY1nrx6rrnaCIvACmtGtOc=; b=OiaQDz44lw3hO2UtgmbHtVqv0VY9kd6PZUYdxSjIqad5ZH6Pwam9zPJiKinlHipW5y 1qETkWZGM3d2Ab47p0ebZ3yj2wL27ZX9WoHkcBhAxxgeRiVFVyVdnkBLOmfZ3WZ0ZP0Y 1/FJ88oMN+RBbwM4Xt5/RodH5it3H9OVwUuftTYVgPsrHSeE4vWWZgT/inrIxpcU/vVQ UDzxy86HDXNRDXhFbiB0ceKp/R9nnFlumo3ODVntjFUMoNRkZ8eZh1xe5OY9t0/YxEA5 jC4UvJBa6EibSfd10rU9TcN0d2t5qMWQy04NrCiKoF1cvGBSWWY8O9ENmczq6Ql8E8p/ q3iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=iOaiDPfhoMD7mwy029CfKmY1nrx6rrnaCIvACmtGtOc=; b=XdCIhdAmzzWCXpl5fQf7sfK5Fl1HeSz9KlVXZGX+lDIlOKrIeRmu2zH3G0fwRSDnRB 6tsnmH//3p5bPkF2Aep03GGeCoIVMesczY4ag2v9HeeEbrFb102a0qw3O2eW829yA4sM BdE4p5mI4pgFccRMJtSr5GosE/QXNXQ02QrR0K4XM8CFkUkOqP2FCh8Quj0L5qd+vXDU OKxPX4gJ6kBdboixHDzWWJm1PmekChbugbMMf1HiUVxaxVSH0MRg0FQYmpwJgkmJHrd6 AENciPizy3OCiRfA4Fti0HckGexnwr9ldc3tLnF4KysNmILRMtlFdkKDOQKlrV96EJHN y70A== X-Gm-Message-State: AKS2vOwjnUuJye1yeRQ1yKAIjVoJ7lRtk1cK7uwCXLwbBiEt7NTuEQSH OR7b64Uv/volw5/gH4SnDAiKcAWZiw== X-Received: by 10.176.1.212 with SMTP id 78mr15427161ual.32.1498879526023; Fri, 30 Jun 2017 20:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Fri, 30 Jun 2017 20:24:55 -0700 (PDT) From: Mark Smith Date: Sat, 1 Jul 2017 13:24:55 +1000 Message-ID: Subject: EUI-64s and DAD (Re: ) To: Philip Homburg Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 03:25:29 -0000 On 29 June 2017 at 19:35, Philip Homburg wrote: > In your letter dated Wed, 28 Jun 2017 21:38:27 +0000 you wrote: >> There is no >> logical rationale for insisting that the IID be anything more than >> locally unique. The fact that in the past, one form of IIU (i.e. >> EUI-64) was *presumed* to be globally unique created this odd >> concept, of multiple different uniqueness requirments for the IID. >> It was a mere artifact of EUI-64. > > Historically, EUI-64 IIDs were not assumed to be globally unique. > I think they probably were assumed to be or globally unique enough at the time. > When EUI-64 was introduced as IID, manufacturing defects in ethernet cards > were common enough that any attempt to use them as world wide unique identifiers > was assumed to fail. Note that DAD was required from early on because it was > assumed that ethernet addresses are not always unique. > I think DAD was introduced because IPv6 supported more than using EUI-64s for IIDs e.g., static addresses. Having had a Novell IPX background, I found the use of EUI-64s in combination with Neighbor Discovery a bit confusing for a while. The reason is that if you use link-layer addresses for layer 3 addresses, you don't need any form of layer 3 to layer 2 mapping protocol such as ARP or ND - the layer 2 address is directly available in the layer 3 address, so you can literally copy the layer 3 address into the layer 2 destination address field. This is how IPX (and I think XNS work) and why IPX doesn't have an ARP or ND equivalent. So in the case of IPv6, the use of EUI-64s for IIDs was a convenience rather than a requirement, and used to get a likely link unique IID to start with. DAD could have probably been made optional for EUI-64 derived addresses, however I think there is still value in performing it for all addresses. I'd much rather a device check and then refuse to work because there is a detectable problem rather than have to troubleshoot an intermittent and partial failure. (A link-layer DAD protocol would be great ...) I'm not sure DAD would be actually that useful for detecting duplicate IIDs due to duplicate MAC addresses, as it is likely that the duplicate MAC addresses would be causing frame transmission failures at layer 2 before DAD gets a chance to work effectively. Fortunately it was easy to abandon EUI-64s (per RFC8064) for IIDs after realising their security and privacy problems because a layer 3 to layer 2 mapping discovery protocol had already been developed and deployed. > Beyond that, it is possible to interprate the IEEE standard such that a > device as a whole needs a unique ethernet address but can use that address > on multiple ports. > > As far as I know, Sun was one of the first companies to do this. Which caused > all kinds of interesting issues in switches that assumed ethernet address would > be unique. > "48-bit Absolute Internet and Ethernet Host Numbers" explains that addresses were intended to be per-device rather than per interface, and if a device had multiple interfaces, the same address was to be used on all of them. That precludes multiple interfaces being attached to the same segment. Early Sun hosts were conforming with this design. I expect it evolved into per-interface MAC addresses because when NICs were added to a host that didn't understand Ethernet, the address came on the NIC, and then it was simpler to burn addresses onto each individual NIC rather than trying to have them check to see if there was already a NIC and therefore an existing MAC address to use. It also explains that 48 bit globally unique addresses were chosen for operational convenience of not having to set them, even though an Ethernet segment was limited to 1024 nodes. It might be the first time that address size was chosen based on providing benefits beyond the direct protocol operational requirement. It's an excellent paper and well worth the read. "48-bit Absolute Internet and Ethernet Host Numbers", Yogen K. Dalal, Robert Printis, July 1981. http://ethernethistory.typepad.com/papers/HostNumbers.pdf Regards, Mark. From nobody Fri Jun 30 21:10:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B706D13152E for ; Fri, 30 Jun 2017 21:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmMkg-ySX5Zd for ; Fri, 30 Jun 2017 21:10:03 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC44127F0E for ; Fri, 30 Jun 2017 21:10:03 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id y70so75014268vky.3 for ; Fri, 30 Jun 2017 21:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cM1WsC5dv67X+JJwSbykvEHaJHzEQcUhQT7dUelWrcU=; b=PQkPtZ0PGHJnRbShgDheIbEmgqnemdX8wj1TYjEw6ET2/2qJ4t5UoziS1hQbyg24Zy boihpJK0kUFIJMrxsMeel/MwXaLpttxg2TopzWWXdCvbw0HaFCvYbrFe5qsz7YSqosPR TncdYR4PWDDoEZjy7pdggBD3mSJs7E29CeTBAtwPprpoFE24SywwKtIPfeHO3stBUh1D wPDj9h7yM0OHEfoOAyNj/JjdVulf0otVn2co8CBQAgqKlr0zDTejSUxZyQzhtcrFhRIe VvVh6VglnrcP2kz06yxm/15oOd5fyEf+NrnCYtAH8a4zX92jev0yM9A2WTFsL2AHk95f 4O0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cM1WsC5dv67X+JJwSbykvEHaJHzEQcUhQT7dUelWrcU=; b=crN24BVBwnqLZ5hHbaYgxhhIlrp7Qx5BNw5O1ojvA7v8HZTrt+olwsu+DcfBenvO7A lCPzfkt82SPb20qFj9VzKZ6SnU2orsUnOt1eE+UBYaHgUbiQF3OwkvesufExW+BbpG/2 IwsD9r55PCy5z0ppN0PXtGfKqXo7gSyi3WVM/5dK/v3m9Kd7LHrzDwmR26sN88XO8RZa whMSDvyV31RsInzUOJ5t44tLb2z8wIzbehcCtEytYuF1eFZeSlGaXgvnJAaaw4uRx3Nz 4LeM0YZbnXO/SJ/P/942lxnYp3SJGapa1I3hg5YzN+go8u1/7ZVXqp9nb5foyDYLKUZw K1jQ== X-Gm-Message-State: AKS2vOw7eOfhg4UIhgMOx7kpCye34WO3y4YfJOeaKZOZvYFXk3eARreu NdtK0wPuDUUyoc+t/2ZksUgNMxNzLQ== X-Received: by 10.31.10.198 with SMTP id 189mr13785980vkk.36.1498882202449; Fri, 30 Jun 2017 21:10:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Fri, 30 Jun 2017 21:09:32 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Sat, 1 Jul 2017 14:09:32 +1000 Message-ID: Subject: Re: EUI-64s and DAD (Re: ) To: Philip Homburg Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 04:10:06 -0000 On 1 July 2017 at 13:24, Mark Smith wrote: > On 29 June 2017 at 19:35, Philip Homburg wrote: >> In your letter dated Wed, 28 Jun 2017 21:38:27 +0000 you wrote: > Having had a Novell IPX background, I found the use of EUI-64s in > combination with Neighbor Discovery a bit confusing for a while. The > reason is that if you use link-layer addresses for layer 3 addresses, > you don't need any form of layer 3 to layer 2 mapping protocol such as > ARP or ND - the layer 2 address is directly available in the layer 3 > address, so you can literally copy the layer 3 address into the layer > 2 destination address field. This is how IPX (and I think XNS work) > and why IPX doesn't have an ARP or ND equivalent. > And as a bit of Internet Protocol trivia, this is how IP originally worked - link-layer addresses were embedded in the lower 24 bits of the IP address, while the upper 8 bits identified the network. This was before classes and subnets were introduced and Ethernet with its addresses that were larger than IP addresses came along. "ADDRESS MAPPINGS", August 1979. https://www.rfc-editor.org/ien/ien115.txt " An internet address is a 32 bit quantity, divided into an 8 bit network number and a 24 bit local address as shown below. +--------+--------+--------+--------+ | Net | Local Address | +--------+--------+--------+--------+ The local address carries information to address a host in the network identified by the network number. Since each network has a particular address format and length, the following section describes the mapping between internet local addresses and the actual address format used in the particular network." RFC796 (September 1981) replaced IEN115. Address classes had been introduced by then, however the above mappings still applied because all of the former networks became Class A networks. https://tools.ietf.org/rfc/rfc796.txt ARP was then developed to support 48 bit Ethernet addresses (RFC826, November 1982) that could not be embedded in the lower IP address Local Address bits. Regards, Mark.