From nobody Sun Jul 2 12:38:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C5D124E15 for ; Sun, 2 Jul 2017 12:38: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] 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 14UDSLR6TgC0 for ; Sun, 2 Jul 2017 12:38:33 -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 2DBE81200C1 for ; Sun, 2 Jul 2017 12:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499024311; x=1499629111; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=fPcIS40lz9Mm9DrDgT7xPMrnnKHCf/XQ0+os8jgeaV4=; b=ONgoHwIaHWiPv R8KD/hV/84gef5HcWDQagI6b2GN4Oq+8SYG+Q7djGckwkSYG0OGj+DKWJeN+SL88 zGIOfxFW1E8Gt/Cc2H2/Dtif8GAiK0R7B7XtYQE054NNqT8Ru4Y+Ov82rj86rqzy VzfSBwKDnH1ChverhNJDszZnfW4UU8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=pCECcenJ1aNg/rGcVQIJ8sRuEz2imHIPNOIhkNE+9U51stmp1fJ4oLeZKwWm Bf2dGLvyLnLUOhiOo0RefsNOuYqOn8fJjl2fW2a8EyUXkEkfjcdfbsPSS 6fBQpvSNQoAHmLPrkQJUhmeziWgX06MtD5S08hG2rak4npY0eb/zYw=; X-MDAV-Processed: mail.consulintel.es, Sun, 02 Jul 2017 21:38:31 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 02 Jul 2017 21:38:30 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005463711.msg for ; Sun, 02 Jul 2017 21:38:29 +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:170702:md50005463711::Ngwiyb6b3E9wdzIx:00000no+ X-Return-Path: prvs=13567b6fc3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 02 Jul 2017 21:38:28 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> Thread-Topic: question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 19:38:35 -0000 Hi John, Gunter, While writing an article where I=E2=80=99ve included a reference to this wo= rk, I realized something that despite having read many times this document,= I didn=E2=80=99t cached before. The title of the document is =E2=80=9CUnique IPv6 Prefix Per Host=E2=80=9D = but actually I think the overall idea of this work is more on the direction= of =E2=80=9CUnique IPv6 Prefix Per Link=E2=80=9D. I mean the document is talking always about =E2=80=9Clink=E2=80=9D, whereas= sometimes uses =E2=80=9Chost=E2=80=9D, but I believe the intend is more on= =E2=80=9Chost-links=E2=80=9D, as everything is applicable to each link in = case a host has several. Right? Or I=E2=80=99m missing anything? I may require a very quick tidy-up of all the document (and I=E2=80=99m hap= py to review it or help, if you need that) to make sure that everything is = consistent if you decide to change the title and make all the text coherent= with that. Regards, Jordi =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 Sun Jul 2 12:42:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E49127137 for ; Sun, 2 Jul 2017 12:42:55 -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 EjU_yG1Po2WN for ; Sun, 2 Jul 2017 12:42:53 -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 57D9B1243F3 for ; Sun, 2 Jul 2017 12:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499024571; x=1499629371; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=ZLz/D4v6aE8n4q/HQx8zOYO++Yp6fEdFbpZ6sn57EBs=; b=TQ4cKE5ujDgc/ oJlrELq/RXKKH8RPw7U6DDyp8FR7v2ivWmqTHcwxDXPEn95MNmheXc/Ftso0Owqn mHST7C3fCtS6xUFV6n0q69eyPNciMphBRaLnHyyDfk536J3OytsMB4jPX13hGexQ Ez/TaQbOy5RY7CJZElf8nRvMaW7IkU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=QWdDBUu2B/y0oya4OdTcvm7OW36016Kl+/f9aoJW7bsxKOQdQWClD98DhQ5L EJtKOSu1bzV556fpc0qi18+HOrChAD2GooaePmDiuo6tLcD/6dk6yW5D4 ziSic/pps9wiaqM4y9wo6OU6BC4/y08+C5mAK7NCVdAAzpudg0C+Yo=; X-MDAV-Processed: mail.consulintel.es, Sun, 02 Jul 2017 21:42:51 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 02 Jul 2017 21:42:51 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005463714.msg for ; Sun, 02 Jul 2017 21:42:49 +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:170702:md50005463714::2rpQrjXIJ75BlqJi:00001YB7 X-Return-Path: prvs=13567b6fc3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 02 Jul 2017 21:42:46 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <1EE0D678-630D-4288-9133-1C6171491CF6@consulintel.es> Thread-Topic: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 19:42:55 -0000 Quick idea =E2=80=A6 May be instead of using host/link in some of the text = maybe clearer using the combination =E2=80=9Chost/link=E2=80=9D or =E2=80= =9Chost/interface=E2=80=9D even in the title =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Responder a: Fecha: domingo, 2 de julio de 2017, 21:38 Para: Asunto: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host Hi John, Gunter, =20 While writing an article where I=E2=80=99ve included a reference to thi= s work, I realized something that despite having read many times this docum= ent, I didn=E2=80=99t cached before. =20 The title of the document is =E2=80=9CUnique IPv6 Prefix Per Host=E2=80= =9D but actually I think the overall idea of this work is more on the direc= tion of =E2=80=9CUnique IPv6 Prefix Per Link=E2=80=9D. =20 I mean the document is talking always about =E2=80=9Clink=E2=80=9D, whe= reas sometimes uses =E2=80=9Chost=E2=80=9D, but I believe the intend is mor= e on =E2=80=9Chost-links=E2=80=9D, as everything is applicable to each link= in case a host has several. Right? Or I=E2=80=99m missing anything? =20 I may require a very quick tidy-up of all the document (and I=E2=80=99m= happy to review it or help, if you need that) to make sure that everything= is consistent if you decide to change the title and make all the text cohe= rent with that. =20 Regards, Jordi =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =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 Sun Jul 2 14:58:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756F129AF3 for ; Sun, 2 Jul 2017 14:58: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 oyrrkHloy-QH for ; Sun, 2 Jul 2017 14:58:32 -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 5CF80127076 for ; Sun, 2 Jul 2017 14:58:32 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id b40so22929281qtb.2 for ; Sun, 02 Jul 2017 14:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=pw4WolbXVfjat6CwPHK/xXb1UFMXvzNY2vFhuKM59bk=; b=PZFJyc0wvIdVehbdaVHwUCUVE41KRH2HMIqwsujyywmxmgev3W7x48hy+/m59IvZwQ NYrNI287LzU2Pp2xKjsPQFZPdgj7Y+mUDkYSoU4ByeoudeeOI+m+WdaYOblI2f1fPeVy jqBVx4YE24RRoE30FrTnX8mh0orZykbI22GCJxAGjfRFx5dCMPFf/U1BEUABTJFrNlco 8dlLIQp/suRBkftoV3t6x8wd/qffCzYzu/CyH5d8pmbSNYC9QE85wF/KxlTTyEOtCJFb 1MAh0mKD0HaIbfiEGtraXudvPnZT+hWWelSav7JlCslwGoaylf8nkSE5UVDz3ui4WspJ 3M+g== 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:message-id:date:to; bh=pw4WolbXVfjat6CwPHK/xXb1UFMXvzNY2vFhuKM59bk=; b=Uq7ug81qID6k1O+h/5muuZjAW0bF451W6qctZzRNw2zrRj/o0vZpYJKZpcTqNbzuDE bAe2DWp7t9EHZSoL9Atz4oMoPs2kna3hiSVfnvweh+Ea6GVVk1EM/d+J4prDq5kBeVyj 9IJjW6cjxsYzazGXEzrp5r64xHSD+CDdQ8JFhAuJY5JRZh+PxBciwAk0zyDnW5B4ShZV WIX/28ytB2+VcQ8+aRp1glbzsXJmXSGRkXyVO+6vLk+Ysr7PLO6t75BluN0JU52NG7J3 Fb18oIzWSaECrus7m50RhuevpQ9zHJ7eTV9rI/aQxLVKYeWdfuTYWuL46g1KknVrUfiO wPHg== X-Gm-Message-State: AKS2vOw5ZYf3Djea3lk46L2pUTAR8PMJCdg4xC/vli/pen8Ky0gb6RIc WPpJxZRMF4FiIvB9zR0= X-Received: by 10.200.34.2 with SMTP id o2mr20881757qto.67.1499032711356; Sun, 02 Jul 2017 14:58:31 -0700 (PDT) Received: from [192.168.216.217] ([64.125.109.186]) by smtp.gmail.com with ESMTPSA id z43sm11267582qtg.59.2017.07.02.14.58.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jul 2017 14:58:30 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3436.2\)) Message-Id: <289257BA-A8A3-43A8-BC87-2E399109C9A7@gmail.com> Date: Sun, 2 Jul 2017 16:58:30 -0500 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3436.2) Archived-At: Subject: [v6ops] IETF 99 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 21:58:34 -0000 I have uploaded an updated agenda for v6ops at IETF 99. https://datatracker.ietf.org/meeting/99/agenda/v6ops/ From nobody Sun Jul 2 18:18:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2C1129AD5 for ; Sun, 2 Jul 2017 18:18: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, 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 6p-Bol51bpC8 for ; Sun, 2 Jul 2017 18:18:48 -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 1D1B1129AD2 for ; Sun, 2 Jul 2017 18:18:48 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id z22so101097801uah.1 for ; Sun, 02 Jul 2017 18:18:48 -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=Z551AQPGLx4+0RVqLz6TEHAbxgYizpvknvdjGDrbfl4=; b=eoarbqWnKjVbj/WiYn82J8m5kxObx4HMpLYq+89BqUZMFK9guVFJayzi3T8gzUYtmG kKd1GYtBjCvLOj+Hy8bv8ZUqvFQ1gFQdmrpB+2yslD4/kE/J7ssgW3BHgZR0K7NPEIY6 yPTQx24dSBceUuvAhfCrIByDpG9jzq4VDvNwyF/9NPzPb6CMy72O/g780SQzPsUTIOYl uCQSs4Q3q7vOcnlkbQGESbW8g/2miCZdigVPEBod80OBrzRQwZNv2rg6ec1kQnb3KXN8 ONkgU+Ug5A72uZIDQ9QYzsxLt+3LC9x5keLQ9fmVcoTQeUvLsYepZfQ53qG/jZsmVGYy l3uQ== 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=Z551AQPGLx4+0RVqLz6TEHAbxgYizpvknvdjGDrbfl4=; b=WzGM2KPq571I2oU4uy9D0DBtxgQb3t65pAzTsyaytIDOllyXUh52CxCEsbaNW8/JG8 ognagpkeCz+J72stcylc0mVG3fY0vh4/j0r0f3rB8o+JA+PfIDnf/vrxGmJ21ZMzU8SW 70EcBNVXr6iKBlCVIYYMj/DQpJ9zIv/YIh6UlRADnSYcT+QqWrUIX1airZz84PT9Lit7 q4uPB7kBc3OeYJXjhaMWcsmlkfBlzAUw3dCE7MAVLgqTN29ixK9j55Og3axbE4GYTOtD 6uR50ia/PLnjygI0eCeU0W4QJQ5zrD14TbO4nIIdw1Tt3LX/FtFGNIMW0nz+bUvaGC3e Xmzw== X-Gm-Message-State: AKS2vOyKoS8psaBC8cwrbF/zKFw008HkdF2clRiuIx95dzLB/1UC8D4/ 27bZqA7YxrDtZ58022qvuJoQUFA4iOxQ X-Received: by 10.176.95.220 with SMTP id g28mr16527594uaj.71.1499044726910; Sun, 02 Jul 2017 18:18:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Sun, 2 Jul 2017 18:18:26 -0700 (PDT) In-Reply-To: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> From: Lorenzo Colitti Date: Mon, 3 Jul 2017 10:18:26 +0900 Message-ID: To: Jordi Palet Martinez Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="089e08208e9873be8b05535f8c52" Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 01:18:50 -0000 --089e08208e9873be8b05535f8c52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -1 I think "per host" is the best title. It clearly explains that the network provides a unique prefix for every host. Of course, a host may be connected to other networks at the same time, but that is true whether this draft is in use or not. "Per link" is not a good title, because a link almost always has a unique prefix, even though in general there may be many hosts on it. On Mon, Jul 3, 2017 at 4:38 AM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi John, Gunter, > > While writing an article where I=E2=80=99ve included a reference to this = work, I > realized something that despite having read many times this document, I > didn=E2=80=99t cached before. > > The title of the document is =E2=80=9CUnique IPv6 Prefix Per Host=E2=80= =9D but actually I > think the overall idea of this work is more on the direction of =E2=80=9C= Unique > IPv6 Prefix Per Link=E2=80=9D. > > I mean the document is talking always about =E2=80=9Clink=E2=80=9D, where= as sometimes uses > =E2=80=9Chost=E2=80=9D, but I believe the intend is more on =E2=80=9Chost= -links=E2=80=9D, as everything is > applicable to each link in case a host has several. Right? Or I=E2=80=99m= missing > anything? > > I may require a very quick tidy-up of all the document (and I=E2=80=99m h= appy to > review it or help, if you need that) to make sure that everything is > consistent if you decide to change the title and make all the text cohere= nt > with that. > > Regards, > Jordi > > > > > ********************************************** > 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 > confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e08208e9873be8b05535f8c52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-1

I think "per host" is the = best title. It clearly explains that the network provides a unique prefix f= or every host. Of course, a host may be connected to other networks at the = same time, but that is true whether this draft is in use or not.

"Per link" is not a good title, because a link almost al= ways has a unique prefix, even though in general there may be many hosts on= it.

On Mon, Jul 3, 2017 at 4:38 AM, JORDI PALET MARTINEZ <jordi.= palet@consulintel.es> wrote:
= 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.



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

--089e08208e9873be8b05535f8c52-- From nobody Mon Jul 3 00:23:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D3129AE3 for ; Mon, 3 Jul 2017 00:23:30 -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 Dc2O_m9UhA9r for ; Mon, 3 Jul 2017 00:23:29 -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 F0393127735 for ; Mon, 3 Jul 2017 00:23:28 -0700 (PDT) Received: from h.hanazo.no (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 5B4CF2D502A; Mon, 3 Jul 2017 07:23:25 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3A639E535725; Mon, 3 Jul 2017 09:23:24 +0200 (CEST) From: Ole Troan Message-Id: <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_75C16191-4A81-474B-A447-3C9CCC6D30B4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 09:23:23 +0200 In-Reply-To: Cc: Jordi Palet Martinez , "v6ops@ietf.org WG" To: Lorenzo Colitti References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 07:23:30 -0000 --Apple-Mail=_75C16191-4A81-474B-A447-3C9CCC6D30B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > -1 >=20 > I think "per host" is the best title. It clearly explains that the = network provides a unique prefix for every host. Of course, a host may = be connected to other networks at the same time, but that is true = whether this draft is in use or not. >=20 > "Per link" is not a good title, because a link almost always has a = unique prefix, even though in general there may be many hosts on it. in my implementation I have a unique link per host. Ole --Apple-Mail=_75C16191-4A81-474B-A447-3C9CCC6D30B4 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 iQIcBAEBCgAGBQJZWfDrAAoJEL7aWKiYQt92BH8QAM4p17Bnf2o6kX5fe2qJtcOf TulmGtw/qWCKPNF2pmnCZr0fBnKwo/2a9eGmGXXqvSYWPFQp9K45iJzPb59xjNJJ Fh7aKecGIIw0ZnOpkCy+fSo02k5ZZCj6eKtr4JK47wIAQxZJGSTj3IM+TYDisvi4 +fvHMSgsz56jQhm+G4aaI4q5b53mBq6uDWoYpeTsdrZhBALgSKPHdLxQllpY4zBp yf4UncKFDCmGw+ShJHP/VIuiV23lC2FiLjocGfnEgQ9nEiPfCU++RSo1pAF2WEkZ GCb0Xh9wLb5x5gU5fV+2grtb06sQLQ0XopLfXN0ExzMWHdxGUuBmst6XV4wXIQFc MhOPzt5VW7jWudtK6yCf8BOXfTx2BgdSHm3w+bJvNJMZdSlTZZyJbqe88XWA2mxZ osMUikhdI9cpBHQ/PgjKA77pKgNw1fyV+LWYjVKeXjlVA+hmwT0bK5a+DAtZTeRj WkkgAuQPRLGAIH5B+6Lz5kup+psYJdmoVeqwlCEzdkw376aVEzAv8l9uvNNu2RFJ fKvksPROFE8xPHQ1UA+2vtY96M2ur5Rph976urbaM3ElcAYXa7WzhDQc2Ts3eay3 /MCOMuR6g/SIMho2du1ANxtqnpL3HatdxPEw8MSA8Xj/Vk4O30NKfMEOEnQ7PN89 e3EFRazwe4T5zf7BMy8j =Hn0g -----END PGP SIGNATURE----- --Apple-Mail=_75C16191-4A81-474B-A447-3C9CCC6D30B4-- From nobody Mon Jul 3 00:56:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9477312EB2B for ; Mon, 3 Jul 2017 00:56: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, 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 pFnaWY5IuDdd for ; Mon, 3 Jul 2017 00:56:38 -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 F1B4A12EAA5 for ; Mon, 3 Jul 2017 00:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499068596; x=1499673396; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=eLp/pxiAZdJ24idmPWsfO/0Gcgi9zJc4nHNFaflSGCI=; b=HP3CxLaHJoKMk C9I4KFIpkCJDXcBDhqfvH4twWG2SsjdoToeHPwiqNI0aiQ7v1X9tXIzd0grpdak8 qcXQUQfwGa0+P4ZHQmo3r/HxsdB9fqlgrnz0etgLiMRiSED8+Lcv2Q/lTKzR5dJd pBAxg/3CNYFyouRbGZOsat607BrzOM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=kdqtcAqOyGFjI6m37iMpTQM1l1nqg4mRVWbRGwOgVTOKeIIezS8zDjH3iZT0 bUZEOqENHlTcIyVDigkYWAxJL/U2aDSFe7usG8erAh0+SLfczSZyFhWAw 7azaP24eger2Lc7zxwGVuqHR5nQUDIqayjtWiEHeJnJErCLDfkPVsk=; X-MDAV-Processed: mail.consulintel.es, Mon, 03 Jul 2017 09:56:36 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 03 Jul 2017 09:56:35 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005464030.msg for ; Mon, 03 Jul 2017 09:56:34 +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:170703:md50005464030::56seLRKsyuwH6Qdt:00001Zj7 X-Return-Path: prvs=1357fe33c6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 03 Jul 2017 09:56:31 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] question about draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 (was draft-jjmb-v6ops-unique-ipv6-prefix-per-host) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] question about draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 (was draft-jjmb-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 07:56:41 -0000 Note: Of course, I was referring to the latest version draft-ietf-v6ops-uni= que-ipv6-prefix-per-host-06, not sure how I miscopied the wrong one in the = subject. I=E2=80=99m not sure my question was understood. You need to =E2=80=9Cread= =E2=80=9D the document as if you never followed the discussion in the list = and is the first time you read the document. What I mean is that, reading the document a =E2=80=9Cnew=E2=80=9D reader ma= y understand that only hosts with a single link may use this, and I think t= he original goal is that a unique IPv6 prefix can be used by a host and not= just in one interface, but in any of the interfaces. One possible solution for that is to look for a better title, for example: - Unique IPv6 Prefix Per Host/Link - Unique IPv6 Prefix Per Host/Interface Another possible solution is to clarify it in the text, or both choices tog= ether. I know the document don=E2=80=99t say something such as =E2=80=9Cthis can o= nly be applied to a single interface=E2=80=9D, but is not either clarifying= that it works as well for multiple interfaces/link in the same host. Some possible text improvements for that: New p., at the end of the abstract: This approach may be used also in several interfaces of a single host. Actual: This document will focus upon the process for UEs to obtain a unique IPv6 prefix. New: This document will focus upon the process for UEs to obtain a unique IPv6 prefix and it may also happen in several interfaces. Actual: The Best Current Practice documented in this note is to provide a unique IPv6 prefix to hosts/subscribers devices New: The Best Current Practice documented in this note is to provide a unique IPv6 prefix to hosts/subscribers devices (and if needed to severa= l of their interfaces) Actual: The architected result of designing the RA as documented above is that each UE/subscriber gets its own unique IPv6 prefix for which it New: The architected result of designing the RA as documented above is that each UE/subscriber gets its own unique IPv6 prefix (and if needed a= t multiple interfaces) for which it Regards, Jordi =20 -----Mensaje original----- De: Ole Troan Responder a: Fecha: lunes, 3 de julio de 2017, 9:23 Para: Lorenzo Colitti CC: Jordi Palet Martinez , "v6ops@ietf.org WG" = Asunto: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-= host > -1 >=20 > I think "per host" is the best title. It clearly explains that the ne= twork provides a unique prefix for every host. Of course, a host may be con= nected to other networks at the same time, but that is true whether this dr= aft is in use or not. >=20 > "Per link" is not a good title, because a link almost always has a un= ique prefix, even though in general there may be many hosts on it. =20 in my implementation I have a unique link per host. =20 Ole =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 Mon Jul 3 01:04:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0515612EB2B for ; Mon, 3 Jul 2017 01:04:09 -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 QYt6BWaxYRSt for ; Mon, 3 Jul 2017 01:04:07 -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 4B07D129B7F for ; Mon, 3 Jul 2017 01:04:07 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id 191so91308395vko.2 for ; Mon, 03 Jul 2017 01:04: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=z3btzQxSmdKXMR6tRn2/uGntb2mcJucgGjnF6l4Nvcg=; b=tizN3nNt7Kx1f1S3mZg6+fIj32z7PDVI/Dt61vi0AYqLBP+aYHDUzPVpvOi0x9eJHn 7Ug1CwLJnDzkyVtVpU7ut++phBMjYOKwhOTzXDyf/xjD4rJuAR1babbcMPYqxpdB8VlR kULBgrNhDgo5pCQ2Swz+FoWaXKDQZ3bOby/Qyy6ch7S3ps9M4rkxIqDa7BdGd2x5bG/q o+bzIlhnmL30i7YPUcFr7dS+YG4yyqru/jSB1wfHaMhYsovgftbznnVpEyQrKwivbtwr kHTZ4SGkVjRo868v/DKYmDKBuUBQC/gT05CZEXZiapHAZtx+nd4zbgzV4tAWumzg45FO 0zpQ== 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=z3btzQxSmdKXMR6tRn2/uGntb2mcJucgGjnF6l4Nvcg=; b=H0W1hE4FqJYRWAQYtZNke6ILUDBQxrx8hARsbvYc57Ke9KyJzb+kCmit0elM5yuLjh P7VxE9MpG6Jx4Oee8boU0hURNrQkTWTMF2eXo4mWnZVtYjPYcQoA7b67bt30hOahwUHA TzNZouuys7v63Qr25LBQwJdQ5pL6MUMaEruE2KO2jCSLpZ6o/U/Wh6yp0QWT/guIpszx VKnMXAuvaTMAQL8YZV83ppv/BLxth+FbAVJaQB/L2Is4oIyQfPKJBTUlS1o+s3H0EOYa rDoKkKZ1QLyDbNwjOXE9bqWmpNtRxVGAEof7wAnJuyTZtcC/SJRaLjCt/xOdedFuMYzh iNug== X-Gm-Message-State: AKS2vOxwfvuYu/zE+G/cBVZsKw/tqp+4uMPCk91OyPWpk7p8cmd9I8j+ 1ukXKCigvvjC2hGhFVBdfMzphjFhhHLP X-Received: by 10.31.218.196 with SMTP id r187mr18022625vkg.96.1499069046230; Mon, 03 Jul 2017 01:04:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Mon, 3 Jul 2017 01:03:45 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 3 Jul 2017 17:03:45 +0900 Message-ID: To: Jordi Palet Martinez Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c07c562ff07bb0553653559" Archived-At: Subject: Re: [v6ops] question about draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 (was draft-jjmb-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 08:04:09 -0000 --94eb2c07c562ff07bb0553653559 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 3, 2017 at 4:56 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > What I mean is that, reading the document a =E2=80=9Cnew=E2=80=9D reader = may understand > that only hosts with a single link may use this, and I think the original > goal is that a unique IPv6 prefix can be used by a host and not just in o= ne > interface, but in any of the interfaces. > I don't think using the same prefix on multiple interfaces is necessarily a goal The goal is to route an entire prefix to a host, such that different hosts are guaranteed to have different prefixes. > Some possible text improvements for that: > New p., at the end of the abstract: > This approach may be used also in several interfaces of a single host. > That is true of *any* IP addressing mechanism. All existing mechanisms for IP address assignment (SLAAC, manual configuration, DHCPv6, ...) can be used on multiple interfaces simultaneously. --94eb2c07c562ff07bb0553653559 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 3, 2017 at 4:56 PM, JORDI PALET MARTINEZ <jordi.palet@con= sulintel.es> wrote:
What I = mean is that, reading the document a =E2=80=9Cnew=E2=80=9D reader may under= stand that only hosts with a single link may use this, and I think the orig= inal goal is that a unique IPv6 prefix can be used by a host and not just i= n one interface, but in any of the interfaces.

I don't think using the same prefix on multiple interfaces is n= ecessarily a goal The goal is to route an entire prefix to a host, such tha= t different hosts are guaranteed to have different prefixes.
=C2= =A0
Some possible text improvements for= that:
New p., at the end of the abstract:
This approach may be used also in several interfaces of a single host.
<= /blockquote>

That is true of *any* IP addressing mechani= sm. All existing mechanisms for IP address assignment (SLAAC, manual config= uration, DHCPv6, ...) can be used on multiple interfaces simultaneously.
--94eb2c07c562ff07bb0553653559-- From nobody Mon Jul 3 01:06:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79DF12EB4A for ; Mon, 3 Jul 2017 01:06:54 -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 lMKli-x3M16v for ; Mon, 3 Jul 2017 01:06:53 -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 02CFB126B7F for ; Mon, 3 Jul 2017 01:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499069211; x=1499674011; 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=C9+wqPMVsQ8X4ld0zts8zPRWW m286TVTpH4ZNXgLpZI=; b=YKWZ7yP3tZYbwRDJeGwaMecKwWunLzR11Cejf2qjg vxwWe9dXnmiFrtxulxIn55PcQYavRdr55BrZV7/AqI1qU8GviwJzbchjIqisigs+ Zn9AARNrA5GlVWqbz5upu78Cpr4TVucyRx7bvacJwUC9CCcWhZB9+b1SuYxs/KSH X8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gI3gXHIHfuYx2MsyISlK1NYq2GfOIjtPD6NZj7NDOCbuMJh0cJUWsIqH7Gr5 FBq9ZHArWVzEHkb9vIH/unADwUFrvmDD/ltBkKP2EHMpc95vJwpBA/gtz Tx1+bbZ+JKD77C3SjD9uVx0877EYKVYKZmqe5mhfCUsUDUuOwwI8lk=; X-MDAV-Processed: mail.consulintel.es, Mon, 03 Jul 2017 10:06:51 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 03 Jul 2017 10:06:50 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005464041.msg for ; Mon, 03 Jul 2017 10:06:50 +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:170703:md50005464041::ObW98kxpAInGtibf:00000MNJ X-Return-Path: prvs=1357fe33c6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 03 Jul 2017 10:06:47 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] question about draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 (was draft-jjmb-v6ops-unique-ipv6-prefix-per-host) 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: Subject: Re: [v6ops] question about draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 (was draft-jjmb-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 08:06:55 -0000 I guess I=E2=80=99m not good describing what I want to say =E2=80=A6 What I mean is that a host can be connected to multiple networks, and it ma= y need to use a single prefix (from each network, not the same prefix in di= fferent ones). Regards, Jordi =20 -----Mensaje original----- De: Lorenzo Colitti Responder a: Fecha: lunes, 3 de julio de 2017, 10:03 Para: Jordi Palet Martinez CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] question about draft-ietf-v6ops-unique-ipv6-prefix-per-= host-06 (was draft-jjmb-v6ops-unique-ipv6-prefix-per-host) On Mon, Jul 3, 2017 at 4:56 PM, JORDI PALET MARTINEZ wrote: =20 What I mean is that, reading the document a =E2=80=9Cnew=E2=80=9D reade= r may understand that only hosts with a single link may use this, and I thi= nk the original goal is that a unique IPv6 prefix can be used by a host and= not just in one interface, but in any of the interfaces. =20 =20 =20 I don't think using the same prefix on multiple interfaces is necessari= ly a goal The goal is to route an entire prefix to a host, such that differ= ent hosts are guaranteed to have different prefixes. =20 =20 Some possible text improvements for that: =20 New p., at the end of the abstract: This approach may be used also in several interfaces of a single host. =20 =20 =20 That is true of *any* IP addressing mechanism. All existing mechanisms = for IP address assignment (SLAAC, manual configuration, DHCPv6, ...) can be= used on multiple interfaces simultaneously. =20 =20 =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 Mon Jul 3 01:31:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C9412704A for ; Mon, 3 Jul 2017 01:31:57 -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 zkyFHzpEU3se for ; Mon, 3 Jul 2017 01:31:55 -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 515E212441E for ; Mon, 3 Jul 2017 01:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499070712; x=1499675512; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=ba7TVGzW36SMVE3M1AkBCr//0Zn7W5CQn1S3bVzpJ4E=; b=GixnbRi4tJFJc WzdWQnBx43DJalVR/12eGlmVJw6K8VYtbdjKko1LY6LL+9FZ1VoW90bpKG6vM8VR 9fBbIvAxCNW4c8Fg+nXOkGNwT5HNGh8VXmmWgTowIpllHRvY/2DydBL8G2GS1TG0 Fi7ptHP0KCvempkf5oajKtSibkqNUM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=HDy28OsvmwKJsYDxWKAkFxBFrn88XN86YUq0h4vsGVoAtuoLyy5eTGGxFg66 DN+ed7bOFuXKqYty3btTGA4qoZW/sklKDPGQqgcyFYJ7Qu1AnuXDctGjA i2hEG8WIwjw+G3ScSdg/t6cBBexTEA6RMoUx7H27wmSt3K5jib+aJQ=; X-MDAV-Processed: mail.consulintel.es, Mon, 03 Jul 2017 10:31:52 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 03 Jul 2017 10:31:52 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005464053.msg for ; Mon, 03 Jul 2017 10:31:51 +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:170703:md50005464053::popj5L3+OrFYs43Q:0000A71c X-Return-Path: prvs=1357fe33c6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 03 Jul 2017 10:31:45 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <8BFE0CCE-4345-40D5-A8D1-B77E1E5B0B88@consulintel.es> Thread-Topic: draft-jjmb-v6ops-ietf-ipv6-only-incremental-00 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] draft-jjmb-v6ops-ietf-ipv6-only-incremental-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 08:31:57 -0000 I like this document, however I think we should also provide some guidance = about possible alternatives to allow at least some of the major problems de= scribed in section 9. Known Client-side Issues. We like it or not, we live in a world were app developers, even some time O= S developers, and device developers, may not have any IPv6 support (for exa= mple vendors that no longer exist but we still need to use their devices), = and STILL users need to be able (both in the IETF network and the real worl= d). Follows some proposed text: New p. at the end of the actual abstract. The document also provides a possible solution for clients/apps/devices whi= ch may not have IPv6 support, so they keep running. New p. at the end of the actual Intro. Support for non-IPv6 clients/apps/devices is also provided either in the ma= in network or alternative ones (such as additional SSIDs). New section x. Support of transition for non-IPv6 capable clients/devices/apps As an alternative to the legacy dual-stack infrastructure as a fallback des= cribed in section 2.1, either in the main network or an alternative one (su= ch as a fallback SSID), the network infrastructure can provide private IPv4= addresses by means of a CLAT client (it can be run in hardware by one of t= he existing infrastructure devices or as a VM). The usage of the CLAT shoul= d be logged in order to understand what traffic, destinations, etc., are st= ill not working with only NAT64/DNS64. If you don=E2=80=99t like a new section, this text can be used as an altern= ative after the existing text in section 2.1 related to the dual-stack fall= back.=20 One alternative is also considering this text as one more point within the = 3. Network Services (IPv4 as a service). In any case, if we use CLAT, then the text recommending the suppression of = DHCPv4 should be clean up. I think a real =E2=80=9Ceating our own dog-food=E2=80=9D is better done wit= h CLAT than with dual-stack, as we all know that dual-stack has been runnin= g in our networks for ages, right? Regards, Jordi =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 Mon Jul 3 04:38:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3321315E1 for ; Mon, 3 Jul 2017 04:38: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, 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 nboWd4H-caMP for ; Mon, 3 Jul 2017 04:38:49 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 4A8311315D7 for ; Mon, 3 Jul 2017 04:38:44 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id v202so86089492itb.0 for ; Mon, 03 Jul 2017 04:38:44 -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=V0BMVzTY9WUTByfvTCJzM/ROPhGbZ20EnytXHWvSzOM=; b=UvFtEEB51Ln2J8cFN5PFVK44iYJe0ep4bsppnSpm/NMzbhdMrmEU4mTmdEtgJk9D97 jg7Ez6lTpRIDU8CdJwOmktkNXMd2Zv04UW6OE1YYwDkLUkxnGNv7+sbbIfM0B31ikZmG XCJQH7X549SP0HBnsyUVxYlKZCE3n9J26JWdJbMR5Y/e4oInpNK+jVWhRoNrsSX2dD9p 2tWv8zloBRQwIw02BtdRQiuA1gWgS4BqHDs7j+JRHWzIQXrh+kvuTgrAQ1wxq/+8OXuf 0kwHmV9+yC3k9/lff/QubDopa8/Flp7DF2JrHkBpKCqZ4sevGU27ydq6f9kTaWpAzus6 oB6g== 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=V0BMVzTY9WUTByfvTCJzM/ROPhGbZ20EnytXHWvSzOM=; b=Z/eQD3UA0NZB1+vygnLhdYQtMUfE5snTjieTcQqQL/+O7tjALuIMiALRrT14LoXSXx EIALBs3Go+Muo1mmyj0Ob5OQH0otWfn277sXwroCpJ+JqlmjI8QKq6QAy18BmG7gBmWv 0KRTpExpLGQ88BsfxedPpjzoHHGNRX4EZg/g02uRJvAJR0a4RBg9W79J9yJE4jB0q6Yo kibXpZ0yIOZuVBWfbMdL/nxUSvXon2QHd+41Dh1Id9e9hqJkuWfkE0wSQ1bBQMojqVal DYp23WZNvjBHlKFw08QDbGZ6MKaeVQPZb9ebNQgIFHpIL57L/efcOQDUrOMvMRmILnyQ 0ukA== X-Gm-Message-State: AIVw113Iy0N8ukiuMWBkMMwGnVqlFjjn+HyH9Cssa5sNOuYBsKaPCRrG RJeIfaKA7mTsUu3tL0mjzaj3bJgQnBXv3tU= X-Received: by 10.36.228.142 with SMTP id o136mr7748285ith.71.1499081923507; Mon, 03 Jul 2017 04:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Mon, 3 Jul 2017 04:38:23 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Mon, 3 Jul 2017 21:38:23 +1000 Message-ID: To: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 11:38:51 -0000 I received some comments off-list, so -01 version has been submitted: https://datatracker.ietf.org/doc/draft-linkova-v6ops-conditional-ras/ - a co-author added; - some clarification added to the "Topologies with Dedicated Border Routers" section; - a lot of typos, missing articles and commas fixed ;) On Thu, Jun 15, 2017 at 4:14 PM, Jen Linkova wrote: > Well, better late than never, right? So following the discussion on > https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00 > and the sad fact that default address selection rule 5.5 is not widely > implemented (yet), I've finally managed to write down how multihoming > on PA address space could be done now in *some* cases: > > https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-00 > > Comments are highly appreciated. > > P.S. It's '00' version, far from being perfect, I'll keep polish it > and -01 will be submitted before the IETF99 deadline. > -- > SY, Jen Linkova aka Furry -- SY, Jen Linkova aka Furry From nobody Mon Jul 3 05:40:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989BF12762F for ; Mon, 3 Jul 2017 05:40:27 -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, 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=fugue-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 CioiH_0hKVzY for ; Mon, 3 Jul 2017 05:40:25 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 EBF821315FD for ; Mon, 3 Jul 2017 05:40:14 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id b40so33577182qtb.2 for ; Mon, 03 Jul 2017 05:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BP+VdkNH61im3yQC/uP9I77jBoFcYFPHuelezj1uqoA=; b=h/uz8WMf3cCXBVI1PdZynEG4DgqIi0TLPGPHiXc9aSljiKxXNRpQabMP1UCen7p7a3 IDRSmAUirwUfdajoNeQcM0xRfGG/oOr4yiUmdHDLHso0XoqL/aV1yzSyzfKJ2yAno3zm F5Y3JQaLMwh370R6w3gtySGUXUVG0A0G3zF10oDLralfaHdMT3Zx+m/HMEQj9VOsGZvQ 8mBbSZlWCrBp+o+nHOBC4DgZnzhxvLWbWWGHcEjln5W4xbPCN85p1gznOteBj3SZuzjG KNoV1zdhlW0o3/DylsrPFzME6+jipkz6J3d3NKvAjS4yKGyQhxNCgIu3ZvGND5m/oUX+ Wl4A== 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=BP+VdkNH61im3yQC/uP9I77jBoFcYFPHuelezj1uqoA=; b=rglM8ql7WalkqgE9RgwnfkQbJP7+ol9ctWlfirQ4VE/tYOAef2+5zxH99q3JSMoOCf zco031YDKYMo+/U/y6aDSIj7KOqD1jhZ80k1g+jMyn8FSYeL4emXGGvaeg+zZHVqpYAy zZfqvpqWfNKHVUC5pyD8YLKQgo1XyzjcV3Yj06ieFPwtQhOnj/Tb75gKexx9LP3/7nYL a1QsrFWRvOr1YjFtCAzicw4XIGdMqVteRdQQAlb5nI90ZeUtRPoilasF2MWfJYA6Hsqc s//aCOJFOjabbe4Jtezl33LmcqRmAu5qgLOpy5jIhKlCNAMHVxjv8sp7GNjut3Kc9KuB Sqrg== X-Gm-Message-State: AIVw112TMg0xVyFhaQ7o3h5fsBxogSwGg+4isoofiQDejuIlUseWrB7h GDvRXYqbe/zOKnCphwU0NQ== X-Received: by 10.237.58.167 with SMTP id o36mr5569105qte.128.1499085613941; Mon, 03 Jul 2017 05:40:13 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id o39sm13519995qto.10.2017.07.03.05.40.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 05:40:13 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0564C15E-3CCD-4A37-BC0C-9E846BA56563" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 08:40:10 -0400 In-Reply-To: <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> Cc: Lorenzo Colitti , "v6ops@ietf.org WG" To: Ole Troan References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:40:28 -0000 --Apple-Mail=_0564C15E-3CCD-4A37-BC0C-9E846BA56563 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 3:23 AM, Ole Troan wrote: > in my implementation I have a unique link per host. So you create vlans somehow...? --Apple-Mail=_0564C15E-3CCD-4A37-BC0C-9E846BA56563 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 3:23 AM, Ole Troan <otroan@employees.org> wrote:
in my implementation I have a unique link = per host.

So you create vlans somehow...?

= --Apple-Mail=_0564C15E-3CCD-4A37-BC0C-9E846BA56563-- From nobody Mon Jul 3 06:07:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7F3131619 for ; Mon, 3 Jul 2017 06:07:47 -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 SCKtF9ow3HgJ for ; Mon, 3 Jul 2017 06:07:38 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A482C129B4B for ; Mon, 3 Jul 2017 06:07:38 -0700 (PDT) Received: from h.hanazo.no (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id C33862D502B; Mon, 3 Jul 2017 13:07:36 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A7D8BE542931; Mon, 3 Jul 2017 15:07:32 +0200 (CEST) From: Ole Troan Message-Id: <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_47315078-1A5C-4E1C-BADD-80972AAD2A56"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 15:07:31 +0200 In-Reply-To: Cc: Lorenzo Colitti , "v6ops@ietf.org WG" To: Ted Lemon References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 13:07:47 -0000 --Apple-Mail=_47315078-1A5C-4E1C-BADD-80972AAD2A56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Ted, >> in my implementation I have a unique link per host. > > So you create vlans somehow...? something that looks like a point to point interface on the router side. e.g.: interface Ethernet0.X point-to-point https://gerrit.fd.io/r/#/c/7224/ Ole --Apple-Mail=_47315078-1A5C-4E1C-BADD-80972AAD2A56 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 iQIcBAEBCgAGBQJZWkGUAAoJEL7aWKiYQt92IXMQAM2iXOg3HZJ5QWzdc+NDdulf fFjVD7CnxHuF8I8qc/6SRo1kxwsDRkIOdLBVaZcugCoEGzsFNxAYLkg+o1XtQYqu tMn+OmF4itfMH+C1GGFZqHADJIAZadm7zvwNZ4xeMSkSA9AFicjASlU7pZSSGlJV UfUwk0FBFJco9rmgj6mo7gV+yZra3KxwaDwBwQAk47saonAG4VFlBAvznTBiCpbk yTwk2u0L/9k3Lie78npOJDB35T0SdZb3UY7e2ELEaxOTQCQxIMoCa8/zFaaDlWIm uWYAT0XoqAwlyJzXb5KKrxLEovVujpTGCwTZ44aEwBhc0DpAnSF6DduYbzl2nBnH Hz/NeBXeEAzpQrLk/OBUNyz1SrMQ65NtDcVWFQHtyNLxUYl3We4FxveAS/PEHSH4 4LF/WaPMnYP+Yaj9R6Kzt5I/O/T8ZtdOh85UrblYiimFj1l01L56PiZLbYpxsApQ HD9zpPOba9lG/89AHkSz0UXsJxCJ6if92vvtWcjscZH2rLg2GJK2ibWFMrAxUMQS ZNsxK5g3tfCLRWlZ+GbG5aB1co1vuouQ8aoonbB/PawhE+0uKJJYjLWgJXiCiLi7 ItZquXhvvO83Q+pbzO8dJh5oc0/BWOCwr+MuJM8wsZJeIqHLC3oxqXTizKs1KqXn HieZfqASpKeVIfiduTIY =MMqv -----END PGP SIGNATURE----- --Apple-Mail=_47315078-1A5C-4E1C-BADD-80972AAD2A56-- From nobody Mon Jul 3 06:16:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2303B131624 for ; Mon, 3 Jul 2017 06:16:30 -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, 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=fugue-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 IIoFYaDWtBXw for ; Mon, 3 Jul 2017 06:16:28 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 122F51300CE for ; Mon, 3 Jul 2017 06:16:20 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v143so61324708qkb.0 for ; Mon, 03 Jul 2017 06:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5BswuptWewy6Zb9VyzUB8oKoxhVGBx1TvtVa1mMzcNg=; b=0qC3e4dt9cHM8nUDaFjMWZb5s4coSP2HUnmGNlO6nHMlP1UuhwOSPx65nhP1XuAnC6 NjNgpNyS92RA9CBXSqUMlJYcshEGwh7fcqQGTfKCOGZByJKBMLxgMya6hq2bJkr2f9w+ lJc2CHrwwQmUZdwF/7Uhfz5Nt0WwlemkV+znVl1w1MvNYn3glkJxr+mHzBzmFaP47ubK qkJ3pH9bgwDN3250C4sPSWCe/yas9N+dNmoZuHJq+aKlASSUcmf/Hnfka5XjFnJzfzZ2 5ExN4yNOMx1osidkcBiBJlxxA5GXVanXAWKa1j+3QiUj8cHbi9+2vZ8Bxn9k1kpr8ip7 OHAg== 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=5BswuptWewy6Zb9VyzUB8oKoxhVGBx1TvtVa1mMzcNg=; b=Sk5PPmnku1+UqU6Z+o/uNhSCdtVjI0Eg7tDZotoiGpKVPZjwa4TlYmn33q5uLVrS/O domMU1sA1l+AeB0nDamzvwCe6Z7Nxvti2zGIlHpz6A0OlvNWaaevb0rjIaFdQ8B0Yvdq /OSjBc9Ue8rKjYr2svK/u93B9MD36znoKS91opynQc4qvgzwrPDWi7tlVxUUDG/B9RMN fOLrhmEetzEWgbLYPyTH0xum2lbAPaCzyoJJjQgW3P8Gt9kcKFi+rCeoYpl5igiVQYOw GQlbupyaaOY/UGQGap70NHXI45hwHi7wJUAXXqkcT+9xnjyPEUn8PpzXcSBKQQeCQEly evCQ== X-Gm-Message-State: AKS2vOwOgbiZKGEIbvwhh20TnMK1OZxbi27r8YHWAzgrcmBC72rz/Zi8 DM/3J7hweUX3YZ7Z X-Received: by 10.55.104.195 with SMTP id d186mr38708519qkc.176.1499087779142; Mon, 03 Jul 2017 06:16:19 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j7sm4687747qtb.60.2017.07.03.06.16.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 06:16:18 -0700 (PDT) From: Ted Lemon Message-Id: <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2CCF4CD7-C5FE-4E5B-B678-28722FE30657" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 09:16:16 -0400 In-Reply-To: <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> Cc: Lorenzo Colitti , "v6ops@ietf.org WG" To: Ole Troan References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 13:16:30 -0000 --Apple-Mail=_2CCF4CD7-C5FE-4E5B-B678-28722FE30657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 9:07 AM, Ole Troan wrote: > something that looks like a point to point interface on the router = side. So hosts on the link communicate through the router. The reason I ask = is that while this is certainly a valid way of doing it, it isn't clear = to me that it's necessary. --Apple-Mail=_2CCF4CD7-C5FE-4E5B-B678-28722FE30657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 9:07 AM, Ole Troan <otroan@employees.org> wrote:
something that looks like a point to = point interface on the router side.

So = hosts on the link communicate through the router.   The reason I = ask is that while this is certainly a valid way of doing it, it isn't = clear to me that it's necessary.

= --Apple-Mail=_2CCF4CD7-C5FE-4E5B-B678-28722FE30657-- From nobody Mon Jul 3 08:41:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FED1316A7 for ; Mon, 3 Jul 2017 08:41:44 -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 Y7ZCXj5TlFaI for ; Mon, 3 Jul 2017 08:41:39 -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 581F31316B1 for ; Mon, 3 Jul 2017 08:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499096473; x=1499701273; 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=ck4Myo43ROKkhrnz6U1/q9/ad rEfxJczGZbpupU9AeU=; b=qaq2Xg2Cx6NUfWPufspdbuudG09AAOUG0a6Doixx4 pTrJhcQvVSscZxbjeiTV+dqdDApYpXQFnzUVAsr7YseB9Wb9mlZ/oz5jy7eYdQQm 7cUG8BzJNTbRAevwl/ArGOSXUic8cUUhRYXaSZUxzhNnGMsttngj4A2zddnLS9wb q8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=efhb0htL7SlM8V9GFgHY0jC5hg5BvT8qx3uNLZ4axXwWlHmYBqGmXCIj8+7M RWd9tYMiTDJJV868deJygxrq7zGezaFkrBNY7fLkjk1qJp2YhDt9OGN8i BoFdc4BjL7Nc0WJs/SvV14hfOoUVZoU6A4ucjW0B0RUe+15zYWyCrE=; X-MDAV-Processed: mail.consulintel.es, Mon, 03 Jul 2017 17:41:13 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 03 Jul 2017 17:41:13 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005464375.msg for ; Mon, 03 Jul 2017 17:41:13 +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:170703:md50005464375::rITnlcpJYm5TXfEE:0000175Y X-Return-Path: prvs=1357fe33c6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 03 Jul 2017 17:41:10 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> Thread-Topic: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> In-Reply-To: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.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: Subject: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:41:45 -0000 Following my inputs to the update of HE, I=E2=80=99ve summited a new draft: Reporting of Happy Eyeballs v2 Failures I think this could be part of the main document, but just in case, to avoid= missing the cut-off today =E2=80=A6 Hopefully I can get a few minutes in the next meeting agenda to discuss abo= ut it, and as usual happy to get inputs, alternative suggestions, etc. Note that even if the title mentions v2, I think it can work the same with = the existing HE, but to me it makes sense to move on with the new version a= nd include this reporting procedure. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: lunes, 3 de julio de 2017, 17:36 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00= .txt =20 A new version of I-D, draft-palet-ietf-v6ops-he-reporting-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-ietf-v6ops-he-reporting Revision: 00 Title: Reporting of Happy Eyeballs v2 Failures Document date: 2017-07-03 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-palet-ietf-v= 6ops-he-reporting-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops= -he-reporting/ Htmlized: https://tools.ietf.org/html/draft-palet-ietf-v6ops-he-r= eporting-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-ietf-= v6ops-he-reporting-00 =20 =20 Abstract: This document describes an extension to Happy Eyeballs in order to report IPv6 failures that force the fall-back to IPv4. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =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 Mon Jul 3 12:36:57 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45D13175F; Mon, 3 Jul 2017 12:36:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911060034.22794.11047254310877550899@ietfa.amsl.com> Date: Mon, 03 Jul 2017 12:36:40 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 19:36:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Happy Eyeballs Version 2: Better Connectivity Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-02.txt Pages : 14 Date : 2017-07-03 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 12:54:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D541286CA for ; Mon, 3 Jul 2017 12:54:30 -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 DweqxDsuE6VI for ; Mon, 3 Jul 2017 12:54:28 -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 B610F126BFD for ; Mon, 3 Jul 2017 12:54:28 -0700 (PDT) Received: from h.hanazo.no (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id EAC482D502A; Mon, 3 Jul 2017 19:54:27 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6C47AE54AF94; Mon, 3 Jul 2017 21:54:24 +0200 (CEST) From: Ole Troan Message-Id: <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_FDE26423-325C-401F-9126-8645AB450DD0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 21:54:23 +0200 In-Reply-To: <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> Cc: Lorenzo Colitti , "v6ops@ietf.org WG" To: Ted Lemon References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 19:54:30 -0000 --Apple-Mail=_FDE26423-325C-401F-9126-8645AB450DD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3 Jul 2017, at 15:16, Ted Lemon wrote: >=20 > On Jul 3, 2017, at 9:07 AM, Ole Troan wrote: >> something that looks like a point to point interface on the router = side. >=20 > So hosts on the link communicate through the router. The reason I = ask is that while this is certainly a valid way of doing it, it isn't = clear to me that it's necessary. >=20 correct. almost all commonly used network topologies are point to point = anyway. just stop emulating a shared media with bridges and do routing at those = points instead. long time since anyone has seen a thick yellow cable. Ole --Apple-Mail=_FDE26423-325C-401F-9126-8645AB450DD0 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 iQIcBAEBCgAGBQJZWqDwAAoJEL7aWKiYQt92Gx8QAJshN9zVuAHOoGbP3uVSOQOr NhtBckOieq+AAOlWfRXKZzUzDigAvj/dUr4pNLHcA6QGjSMIsA2vBmBewnyv8WNi AarSVn3ZypTJAsxivB+M4HCSgwQ4PcXBdBvO+RGs5MjgQqauseAuwUXMBipui9Yc 5KvFegGmZsgerXfNSwI+POmH9HPGovGdWP8r/++m5pxigsqwgHEsv8f80FO83hEp /pwjxeA1u/zp92+xE09crPEOH91pJY+bWdC4pD9zdFX5bL8dy2URJPAxmfnOOSS9 r0aTlUu6LTT7/eiCm93+xLayYoRfZzkRMLwg3cpNCAwS7QWplYLWnvHQhjNC0lYt Jcw0WpjMyRif2S3rc3XwmhTnxnT+et6ezvAAWbVXq7VDY1DLh+fAM1HR9Txi1lwY 8g06r4aeRG+6WXrop2n2mjcKyl91sFgZiKuzePvKHwrXzxbDvWYSSAE9glE4ZoKh gAYn82viCVks7WnUWx2Aw3nlHtSzGu0SucqSi1cLHgSoYQi8UD/Cl/+ESq2M8Sf8 y0VQgY/QGByuS9KcgeMqdhEX3KZ1lmNxGaoqsYZ8VEk59z9hG2RDlTmV8BEYQtBD kcvt5SZ6jEwXNZt2+ZujamI8bMTYrgr0WyvJ1drPwQ+dNLnl6vb8ns7Kyh+uMR/M T2e1t4fJaSCLDmf2+LR2 =LaGk -----END PGP SIGNATURE----- --Apple-Mail=_FDE26423-325C-401F-9126-8645AB450DD0-- From nobody Mon Jul 3 13:38:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31692120724 for ; Mon, 3 Jul 2017 13:38:06 -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 F7AoLMDzuAoY for ; Mon, 3 Jul 2017 13:38:04 -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 EB91E1201F8 for ; Mon, 3 Jul 2017 13:38:03 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id q86so104807123pfl.3 for ; Mon, 03 Jul 2017 13:38:03 -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=1hdKEwuOF+VD0p51u2frKnoD4zqQsQXcvFp8PtQtUkU=; b=a3gosK9dqdKDLYVEMVgyjaaDIeYyE9cf+qdqxAAuVoN7OS1bbzEC07dm0SRbojKVbk yQV6rk1nnPsa7U/6cWQOHXhSTwPr3En3qyrA9Kg3+q++IA4wWIJB3wpcvLL7zGbltjE0 69YM+gLdhZi6h9scY1Fgol+cwPzIChXxXsOfB46ursCEbhPaLlV/mvD8BFDoghHJqHr/ HFVA4Nur365UopOKjyBoWGjFKKbfOy+3ruU3vYdJ+rjoGRdmTTLoxUJs66AlR0CuI0Wu 8WePAWh1oK+j5fNxSUoj7wklJPzjWRolWJWKc1AJU8/QlCmMGV3lttrfmD4D2yKw0669 2Tlg== 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=1hdKEwuOF+VD0p51u2frKnoD4zqQsQXcvFp8PtQtUkU=; b=gzcHeOLwJn0wM2isyIdKp9+TRltjW/FfBi5XTzPmFcOlyP3S+W9OUhzb/WnKUlTgU9 W2fRLUCoEZ7THI55QFAzmvCrH89lFF2f1i/33RqwOLueItuihSnHRxIYfci4lSwGtlLI 9FMaeb3cez4KS3aaQ83jMLVKldCmMrgk0ZOYkHtLwkX/K+x40F/mIxFii7ZfcvHf4q/f YsBMPyik3HkMs1yak+l+fD1d7bvQ2xCEV2EXWeo2NtQHjrtn/2pEEUtxPPPOy7aAQhw0 9Qov6ZogRUEZVigzdRElxJBTTFyGb1JJN8JabAq5u0HU0K5UY3hUfp9kaBLZd7Yh6Sse wJ/g== X-Gm-Message-State: AIVw111d82BmdbschpvIDMY0wPM+eON7nL5tIobzlNNypHcH35RbyjOC baFHMljJtOyhrWIr810= X-Received: by 10.99.101.135 with SMTP id z129mr11926275pgb.66.1499114283330; Mon, 03 Jul 2017 13:38:03 -0700 (PDT) Received: from ?IPv6:2406:e007:4f03:1:28cc:dc4c:9703:6781? ([2406:e007:4f03:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 75sm7316408pfk.84.2017.07.03.13.38.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 13:38:02 -0700 (PDT) To: v6ops@ietf.org References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> Date: Tue, 4 Jul 2017 08:38:00 +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: <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:38:06 -0000 On 04/07/2017 07:54, Ole Troan wrote: > >> On 3 Jul 2017, at 15:16, Ted Lemon wrote: >> >> On Jul 3, 2017, at 9:07 AM, Ole Troan wrote: >>> something that looks like a point to point interface on the router side. >> >> So hosts on the link communicate through the router. The reason I ask is that while this is certainly a valid way of doing it, it isn't clear to me that it's necessary. >> > > correct. almost all commonly used network topologies are point to point anyway. > just stop emulating a shared media with bridges and do routing at those points instead. > long time since anyone has seen a thick yellow cable. But, as the saying goes, "just say multicast". Brian From nobody Mon Jul 3 14:14:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A886313147F for ; Mon, 3 Jul 2017 14:14:32 -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 tfOTfYOMnhNB for ; Mon, 3 Jul 2017 14:14:31 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D853130A93 for ; Mon, 3 Jul 2017 14:14:24 -0700 (PDT) Received: from h.hanazo.no (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 946B22D502A; Mon, 3 Jul 2017 21:14:21 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 69E64E55F580; Mon, 3 Jul 2017 23:14:16 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A36F04E2-DB30-43D2-A2A1-6AF33F14C22E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 23:14:15 +0200 In-Reply-To: <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> Cc: v6ops@ietf.org To: Brian E Carpenter References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:14:33 -0000 --Apple-Mail=_A36F04E2-DB30-43D2-A2A1-6AF33F14C22E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> On 3 Jul 2017, at 15:16, Ted Lemon wrote: >>>=20 >>> On Jul 3, 2017, at 9:07 AM, Ole Troan wrote: >>>> something that looks like a point to point interface on the router = side. >>>=20 >>> So hosts on the link communicate through the router. The reason I = ask is that while this is certainly a valid way of doing it, it isn't = clear to me that it's necessary. >>>=20 >>=20 >> correct. almost all commonly used network topologies are point to = point anyway. >> just stop emulating a shared media with bridges and do routing at = those points instead. >> long time since anyone has seen a thick yellow cable. >=20 > But, as the saying goes, "just say multicast". what about multicast? no change in location of replication point, and the commonly used = multicast scopes are of course much smaller. Ole --Apple-Mail=_A36F04E2-DB30-43D2-A2A1-6AF33F14C22E 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 iQIcBAEBCgAGBQJZWrOoAAoJEL7aWKiYQt92mqMP/jglUGZ3XMIJB6vO6p0dsOy0 PyqLiueY7oOchYltAorukicaypJNXoWSpOfxq4UJGtuEXKumsAzx+aAno8NKXTE2 k0TekrCDQuqC2WdpAg3B7KvJiB+Lt1N/lHcb9/ma0Navo6tcixZeqg6me1FJq1Wx 11j7CNu2RX+z1CF3bXi2Hz6RZlOfIFyiZ9aw7c8WV93QCbm3Y2SD1VBWQeRW8YEO qmDIqbvfIQZBOFaZQVFVswbuoIIbfeAMApPsRcAZ/c2I8YpJIWu1tQSF1t3xaW81 oQBMRGWkFfnfoiTNJ3RPG7XI2W3nsGph9SSa4lApIHaZP85Z9nuD2lmCl7OFK/QE Q/XLuDyhBCu1NJHtr+AQgpSaqafvGplK+3o0ciP61EXCka9lXeMvABaG77UDMQVa EYkw2nbOMH/srDqouf1AwhjLZSu1yQ3KpjUUler1pzcmrqZHhN8ai/XhRcmYyveJ EJGIZdqouqv6u/qGbqOT/6sIXAWXtLGwCsW8FfP83aYt9Txafaqm8PqZsOmoJMs8 3gwWgBbIhENkStbBnSg0Nudk79ezH1gCNa322HX2K/icnO9U2PGBj/JPrfqrQQn8 lvU+xiE//H8v0PmgH+V1d6gwNuYi+CrXSnBvMueaZkq+hgIzBGdzcCqyv8QVGaK6 Dl2ciLu2KoJSEVMShJl5 =vqt2 -----END PGP SIGNATURE----- --Apple-Mail=_A36F04E2-DB30-43D2-A2A1-6AF33F14C22E-- From nobody Mon Jul 3 14:37:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF54129AC4 for ; Mon, 3 Jul 2017 14:37:53 -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, 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=fugue-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 xrWSpO8U1OLJ for ; Mon, 3 Jul 2017 14:37:51 -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 6E801128B8F for ; Mon, 3 Jul 2017 14:37:51 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id r30so152712180qtc.0 for ; Mon, 03 Jul 2017 14:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=STZ+46Srxe8D3rpKDLkru5Kl7+DWxSrgnUGGQY3imuQ=; b=dmwHWcs8k4mSUQWXT0CdrjjPfdAH1cqaZbTWKrWnL6PhUUX4ugvO2Z9SIW9ohwfUgr io5lcc2ZqSDsd9ynIB/5sC4b5XC4hARXI/4pN65x2nBsFZar6CEsTFG1T1unh6S8kG8Q CF9/XEoPwyaUZboLE6xIFzvWwf32FEw2bwCpE/jP2XHk3F3CuVhp1b1AKrLxKmjEzWgD wttssX0sZ8dcKR3s8rV9l9y7liCDNMmeFlRn9GNmcTc3yajdBj4UYu+KdOelN9QNkDd8 X7Uj8ecpxzfPTKCiNw2IjXroqqPWezDgg0Wj6nyIXnfVjGQya3n5di3lwcEkzi+b0DLI OuTQ== 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=STZ+46Srxe8D3rpKDLkru5Kl7+DWxSrgnUGGQY3imuQ=; b=eyyh5rS5EmvF2/JTwoSphr7pjyWq9pXQ8asX9hr+CQadmukcOOiz/6gXz5T3GzXPmG ZeO1OqVTE6/cs64vexJS8GmFxcvJ6PyZ68UPBkF53o8XGdkWCKXyYZy29ejD+jE4wZGv Ze4hcRbxJhwn8DPIRtpI+d4XYM2SEbUHEmxhEPQF6a3r3iqez6v6U6zkxc7C1lXxpJws bIrnTq25unGbuhkeO48I8dMRy+pWnjhhj1iEK7F36FtLorj8nQTY73K1cqxK8myX66YG 8nuI38W6t6uNdFur8YyMW7rHEjtiv1PpCjxGEXnOF0fx09QsSUPktosgR91WKKoZ4g3s HPxA== X-Gm-Message-State: AKS2vOyXU6ERdWrEb+xTBGIAANvuBazkH620lWPpWDdtsxl6Oo6B/8PV /BWwjL2WjUSxXkvmHzxeXg== X-Received: by 10.200.36.70 with SMTP id d6mr37840588qtd.42.1499117870388; Mon, 03 Jul 2017 14:37:50 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t11sm14308762qtt.47.2017.07.03.14.37.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 14:37:49 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E91F4640-0572-4ABA-ADA2-A188C9B8B258" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 17:37:48 -0400 In-Reply-To: Cc: Brian E Carpenter , v6ops@ietf.org To: Ole Troan References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:37:53 -0000 --Apple-Mail=_E91F4640-0572-4ABA-ADA2-A188C9B8B258 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 5:14 PM, Ole Troan wrote: > no change in location of replication point, and the commonly used = multicast scopes are of course much smaller. This breaks service discovery. --Apple-Mail=_E91F4640-0572-4ABA-ADA2-A188C9B8B258 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 5:14 PM, Ole Troan <otroan@employees.org> wrote:
no change in location of replication = point, and the commonly used multicast scopes are of course much = smaller.

This breaks service discovery.

= --Apple-Mail=_E91F4640-0572-4ABA-ADA2-A188C9B8B258-- From nobody Mon Jul 3 14:41:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8023312EBFA for ; Mon, 3 Jul 2017 14:41:44 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 viLUenx7flPc for ; Mon, 3 Jul 2017 14:41:43 -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 45C6D129B62 for ; Mon, 3 Jul 2017 14:41:43 -0700 (PDT) Received: from [192.168.10.6] (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D3A912D502B; Mon, 3 Jul 2017 21:41:42 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-49D234CF-B664-413A-B841-BFE6E7684FC9 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (14G5057a) In-Reply-To: Date: Mon, 3 Jul 2017 23:41:39 +0200 Cc: Brian E Carpenter , v6ops@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> To: Ted Lemon Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:41:44 -0000 --Apple-Mail-49D234CF-B664-413A-B841-BFE6E7684FC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 3 Jul 2017, at 23:37, Ted Lemon wrote: >=20 >> On Jul 3, 2017, at 5:14 PM, Ole Troan wrote: >> no change in location of replication point, and the commonly used multica= st scopes are of course much smaller. >=20 > This breaks service discovery. It breaks the assumption that everything you want discovered is within the s= ame broadcast domain. Many think that assumption was broken anyway.=20 Ole= --Apple-Mail-49D234CF-B664-413A-B841-BFE6E7684FC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 3 Jul= 2017, at 23:37, Ted Lemon <mellon@fu= gue.com> wrote:

On Jul 3, 2= 017, at 5:14 PM, Ole Troan <otroan@employees.org> wrote:
no change in location o= f replication point, and the commonly used multicast scopes are of course mu= ch smaller.

This breaks se= rvice discovery.

It breaks the assumption t= hat everything you want discovered is within the same broadcast domain. Many= think that assumption was broken anyway. 

Ole=
= --Apple-Mail-49D234CF-B664-413A-B841-BFE6E7684FC9-- From nobody Mon Jul 3 14:50:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4112EBFA for ; Mon, 3 Jul 2017 14:50:29 -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, 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=fugue-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 sW0qn1jNmFw4 for ; Mon, 3 Jul 2017 14:50:27 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 EF30113166B for ; Mon, 3 Jul 2017 14:49:39 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p21so155792069qke.3 for ; Mon, 03 Jul 2017 14:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Cd3Q7yzC1m5PySO6CBtReSH8X1WntmGdSMcb0a+dI/c=; b=CcqW7TxyaR12RYUvVj6nrwdVqjdnVw+XbSDDMAZTVDAZUUHIH5gNJcg1LQkWeXZFyK FOtFV1HIlYhqgcVmJ7eMRP++8K1wvyvS6MSHgesly9JSM605/zwb5I9DL+hAqdgjGeDk Vrf4XQm+LTIZl4bm9qZ0X3t25cdR7bBE4zvHx09MCkfdyz6JWaBA+vufZHkXH12nSbC5 V235/AGfMPP3iW1mx1uDZP/OCKqudJsIm3zgpasPcnIH2aUW/lLxUr7Ff+2MycW8orQM 5FDmXHXWeX1+DG6CB+Ne0XVM1ACKnOf/1/k2C80UV9s0Or87LQybuKxEZSujxVwgFsBe amXA== 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=Cd3Q7yzC1m5PySO6CBtReSH8X1WntmGdSMcb0a+dI/c=; b=O5iYPFqgsSdDryeyDeiiu5seC48p/uQJgdxNpmAL2Ca9VUwXp5v0Z/5t9yYNifRw70 shmrXEMuciXdB+1S4MZMz8c9fc2E/w9VTryOC8yYNjSIByTXlvsGI3N5B6ocOY//nw2L Zdo3pO2DaxbOhinSwf03HD0wK+0ZkehgSKoBXEMSAZ9kGlXLWxP0MJCGl1VWSbLRy5Xe pFxLBSZpHo6sDmyKPVKKuVDAA5geEC8mn0xVqT24KolmsF/TVjiSD3NirZBh8mJ7KFgT 03yUe92kXFpcAp/masOMbRKgQHCPpco1KYlooYlyyrolWAUa1+dQ44tnQbIoqhMSOPWa icMA== X-Gm-Message-State: AKS2vOyVkbSjOaAVXPYiG3dUL3UfgrhrUXu/TgbTCIoxFQUWq9YFx5Ow oUO1D+yamBfWgagw X-Received: by 10.55.137.6 with SMTP id l6mr45075511qkd.83.1499118579156; Mon, 03 Jul 2017 14:49:39 -0700 (PDT) Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u30sm13323624qtc.68.2017.07.03.14.49.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 14:49:38 -0700 (PDT) From: Ted Lemon Message-Id: <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5D096F74-0629-45E1-A7E5-E2A2FF0393CB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 17:49:37 -0400 In-Reply-To: <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> Cc: Brian E Carpenter , v6ops@ietf.org To: Ole Troan References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:50:29 -0000 --Apple-Mail=_5D096F74-0629-45E1-A7E5-E2A2FF0393CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2017, at 5:41 PM, Ole Troan wrote: > It breaks the assumption that everything you want discovered is within = the same broadcast domain. Many think that assumption was broken anyway.=20= Given the document I'm presently working on, I wouldn't really argue = with that, except to say that it's still the default assumption in most = environments. --Apple-Mail=_5D096F74-0629-45E1-A7E5-E2A2FF0393CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 3, 2017, at 5:41 PM, Ole Troan <otroan@employees.org> wrote:
It breaks = the assumption that everything you want discovered is within the same = broadcast domain. Many think that assumption was broken = anyway. 

Given = the document I'm presently working on, I wouldn't really argue with = that, except to say that it's still the default assumption in most = environments.


= --Apple-Mail=_5D096F74-0629-45E1-A7E5-E2A2FF0393CB-- From nobody Mon Jul 3 16:31:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C321317E0 for ; Mon, 3 Jul 2017 16:31: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, 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 JQhLxYJZju3U for ; Mon, 3 Jul 2017 16:31:43 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 D00641317D6 for ; Mon, 3 Jul 2017 16:31:16 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u62so101141961pgb.3 for ; Mon, 03 Jul 2017 16:31:16 -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=yEdQU6CFJIpC0KV7soHioeO6cBb1nBbP3q54uM5P9iM=; b=T39p0hy/fQ8TimOVgfiAaRwatdPWXkhOe2/H4/Q5BkKpLPHpVbz36axeeOE7sSB27P Pu6AHskOT0saEn/M29zeuntx/mkDxz6WST1FVnURI6mA9lBxgf4nps5yCL4b6KaqINr6 qevKWeD+waPSAVx7tcPg2YI2IcBsiLn0e6h5gsn7dp57YKRhVqE3Ga6XbXqVujL4Etki EN2fQnzs17KgEFWmFkG5yZdnkswkwdVPvSdDkMbkp2TVhEpytNTv7gAQrQCCbwLJkq+q CqaI+myP9uKZjUOJGTkkheNggyorp+0fnq8leZaHXaWT58/Rn7DQG/EgAHdpBuozORFO 9z9Q== 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=yEdQU6CFJIpC0KV7soHioeO6cBb1nBbP3q54uM5P9iM=; b=hBxRw0AIAL9JTjlJiclIFrOfjdP6Iwp52m7ulMVsAudIKyI+uOuizcXC1ODIZcjTFM 4Fz30G9UYqBhWaqF55dtufDv2TDYEyZFUz1EDPASGHyYcz1Kw+IiQZXCfXdZCplb+ZyJ qTt+XTFLjY7H9NLVt7ezNrqVPcLrhWTDApfQCnAF4TxhCcijc2yS/v97C4KFTJ87EnFS kVYdAGFayLFvouDKtCgczi1MUUJ7EkLRNRx+qjhf6N0urFJT0sUuwjSFnmFrpfXENd87 Ypy50ZJYB5VL/dB/WTAcetdtkcMAYap3KXNwefydty4Vfj3fceTFbrN0yTTwLJI6gcNy hv9A== X-Gm-Message-State: AIVw113HFzyPXVZnLaTlhZ3EBfCrAoaC9/6OwbXVTp4GAfWUkHvGCJUW r8PIkQkQoYEypxfr X-Received: by 10.84.229.136 with SMTP id c8mr13288180plk.27.1499124676150; Mon, 03 Jul 2017 16:31:16 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id i27sm28381554pfi.82.2017.07.03.16.31.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 16:31:15 -0700 (PDT) To: Ted Lemon , Ole Troan Cc: v6ops@ietf.org References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com> Date: Tue, 4 Jul 2017 11:31:14 +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: <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:31:45 -0000 On 04/07/2017 09:49, Ted Lemon wrote: > On Jul 3, 2017, at 5:41 PM, Ole Troan wrote: >> It breaks the assumption that everything you want discovered is within the same broadcast domain. Many think that assumption was broken anyway. > > Given the document I'm presently working on, I wouldn't really argue with that, except to say that it's still the default assumption in most environments. Yes, and that has deeply impacted both a document I'm working on (draft-ietf-anima-grasp) and a demo implementation thereof (https://github.com/becarpenter/graspy/blob/master/grasp.py). The cost of *not* having link-local multicast is considerable, because it means that every node, however dumb, must replicate and relay discovery in one way or another. Brian From nobody Mon Jul 3 17:25:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72871131817 for ; Mon, 3 Jul 2017 17:25: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, 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=fugue-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 bP-OBRW2NtK4 for ; Mon, 3 Jul 2017 17:25: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 87858131815 for ; Mon, 3 Jul 2017 17:25:00 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id c73so106727858pfk.2 for ; Mon, 03 Jul 2017 17:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FuiosneTG/aN0LkWws0wYePs0lQxTMo90cxSpUqhDLg=; b=u0STMjsvHf4kSZyuco+4YF1BPmxF7A9TWcdp+XoF42Lv1evUUecC6MNDPt+bKeAdAc X4NeDwdVPgFpbetp9pE4uC83aNoaJfToeuR/GlEitLK43UV4icMADXM/7mhWuMN1BjXN q/157ntcyLgsZ+fgKgRHI7vUGADZ9LkN0GxNzz5V9lmSYF5L8MH9jxNNayE3ynkZTyYV JDkHILA562Sbo49VUztVfNtk9dBpqsmaghK1XUS6i8ozeetJjyxKFGgY7ifq915f6huc 9i/zDABqYiaILa76tL9vsVQijwD8UbkHtO/lZLuRdUf+LeVVEUL6a0M2l857n74ol/04 m/2g== 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=FuiosneTG/aN0LkWws0wYePs0lQxTMo90cxSpUqhDLg=; b=mP/EZ+s11hov1Z/AaDY80bgrZsebNF/Ol3JfdOQitGw4JaCAnwqPc0Pd/XCvyh4XCc obfpz8h2JgNpA1IUXhbJh7FaGk8UHL9BuFowWCGs89SMAOSEG9q1+2pc+iP8LUOdjlLh 9FLS9wbHnMDlI53oKEELXWDNt1G3mvdeltNEiiV1M3/WumV450Fw5gc9J6zn/DcVzMmR IhDUE2e1ENymmIPH6TKNSxGTneEg2qKgQuDvBC9eYO+NwIipEfqNBtzF9NqZwg9/rOjv zXMKja/utcS98XNiaQQtTPHnjNocBYw+y+mb5fxN2C4urCWGR45kfV0+uVtUkMEvGWWN 6Kiw== X-Gm-Message-State: AIVw111B2ZQezlDzE2BNdvdCIsITgKwgqIfe0PFnxspr8FSML8cWuFpY ta9gpf9xehMrZo3J9MFyZ6yDDm6Zc5oe X-Received: by 10.99.145.67 with SMTP id l64mr12911577pge.184.1499127900101; Mon, 03 Jul 2017 17:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.2 with HTTP; Mon, 3 Jul 2017 17:24:59 -0700 (PDT) Received: by 10.100.170.2 with HTTP; Mon, 3 Jul 2017 17:24:59 -0700 (PDT) In-Reply-To: <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com> References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org> <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com> <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com> From: Ted Lemon Date: Mon, 3 Jul 2017 20:24:59 -0400 Message-ID: To: Brian E Carpenter Cc: IPv6 Ops WG , otroan@employees.org Content-Type: multipart/alternative; boundary="94eb2c0374aef57157055372e9fe" Archived-At: Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 00:25:08 -0000 --94eb2c0374aef57157055372e9fe Content-Type: text/plain; charset="UTF-8" Dnssd hybrid.proxy addresses this. On Jul 3, 2017 7:31 PM, "Brian E Carpenter" wrote: > On 04/07/2017 09:49, Ted Lemon wrote: > > On Jul 3, 2017, at 5:41 PM, Ole Troan wrote: > >> It breaks the assumption that everything you want discovered is within > the same broadcast domain. Many think that assumption was broken anyway. > > > > Given the document I'm presently working on, I wouldn't really argue > with that, except to say that it's still the default assumption in most > environments. > > Yes, and that has deeply impacted both a document I'm working on > (draft-ietf-anima-grasp) and a demo implementation thereof > (https://github.com/becarpenter/graspy/blob/master/grasp.py). > > The cost of *not* having link-local multicast is considerable, > because it means that every node, however dumb, must replicate > and relay discovery in one way or another. > > Brian > --94eb2c0374aef57157055372e9fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dnssd hybrid.proxy addresses this.=C2=A0

On Jul 3, 2017 7:31 PM, &qu= ot;Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
On 04/07/2017 09:49, Ted Lemon wrote:
> On Jul 3, 2017, at 5:41 PM, Ole Troan <otroan@employees.org> wrote:
>> It breaks the assumption that everything you want discovered is wi= thin the same broadcast domain. Many think that assumption was broken anywa= y.
>
> Given the document I'm presently working on, I wouldn't really= argue with that, except to say that it's still the default assumption = in most environments.

Yes, and that has deeply impacted both a document I'm working on
(draft-ietf-anima-grasp) and a demo implementation thereof
(https://github.com/becarpenter/grasp= y/blob/master/grasp.py).

The cost of *not* having link-local multicast is considerable,
because it means that every node, however dumb, must replicate
and relay discovery in one way or another.

=C2=A0 =C2=A0 Brian
--94eb2c0374aef57157055372e9fe-- From nobody Mon Jul 3 18:20:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456AD12FEAA for ; Mon, 3 Jul 2017 18:20:39 -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 hdyfNBnW4opu for ; Mon, 3 Jul 2017 18:20:37 -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 965CC12F9A8 for ; Mon, 3 Jul 2017 18:20:37 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id f194so500732yba.3 for ; Mon, 03 Jul 2017 18:20:37 -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; bh=f/Y0g66pTZxez+Yazs5hirP4BjdYmnK5tVnWt/7Bsho=; b=p4K6kKHJTW7pog2/Xp7TKCHP8kHDqxDpsYYfS/8NYELI8Mg1zEAiCcXa8MNXBADEjj iuz96vVb8MiXQ5u9zPB8M8p6Gmwb+orlWwa5O4Xw1qCfvTif/wwITWVFHSEyAAclyuE7 o10weRMZUoIjdT7bUdtOuD2aJeGPQr+rwFrniErB0zgdQ15mAVswsx6uOrevoG+XJuma +IXGirgG0KST3stmh0KUgr2YdgCi7gSNUMjSPqWvunq65mSIRb52fB/9eQNk6ziTEtxe SIJ/coqzdLJ2GfihGS+3z9NGSS9CAzn33ilvoULGb75IoPUM4jG+NEnEXWWAakqB9Y/f uMHA== 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=f/Y0g66pTZxez+Yazs5hirP4BjdYmnK5tVnWt/7Bsho=; b=Gu+3cAEastwz3AuZx0USzc8SSCDItjDWZKzrvyHiju4jnAbfzhbPe3P3FXfYHzvnMP 20YsvG/1MenO7Do63OrErhe2yNDp/i3ijAUZMH1z7a1+36vaztziIYunvxWKbizNqiGP DowKHTlGRcUb3JXLfoAItDza4fICNu1PUgqPVM7RGPd5D91ef9Z/JG7afLWyVfSke+qI AxTYghwV0PSvrxqmEDv0BP5JqnzKhYSqg9Xp4Wfzne0Cwj4nv8Rwla7ZvLcHiMMbSePQ O6b+HP3MJRtcrQLrokvX9NTu1jS9EzDju85Ui+OZZ4BLCI5GkCFgf1vz5jJtpDZUM6pT /Ohw== X-Gm-Message-State: AKS2vOwbmo3u6MEHtyIshtN+QV+wS94WFQNPDAxRILGdTXuteNgl8uhk pGKj79Gew5oFtIz44WmfGpYdCvZNnTmt X-Received: by 10.37.180.18 with SMTP id n18mr30299691ybj.258.1499131236690; Mon, 03 Jul 2017 18:20:36 -0700 (PDT) MIME-Version: 1.0 From: Ca By Date: Tue, 04 Jul 2017 01:20:26 +0000 Message-ID: To: IPv6 Ops WG Content-Type: multipart/alternative; boundary="f403045e6aa2d5b715055373b025" Archived-At: Subject: [v6ops] draft-jjmb-v6ops-ietf-ipv6-only-incremental-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 01:20:39 -0000 --f403045e6aa2d5b715055373b025 Content-Type: text/plain; charset="UTF-8" I read draft-jjmb-v6ops-ietf-ipv6-only-incremental-00 Looks good to me. It may be wise to note this is not a novel approach, the ietf is not on the bleeding edge here. https://archive.fosdem.org/2015/news/2015-01-31-ipv6-only-again/ The purpose of the document should also inlclude scope for not only being a bcp for the ietf but SDO conferences in general, maybe? 1 nit, i think s/AAAA/A "Applications that explicitly require IPv4 by only performing AAAA queries or restricting the type of underlying socket they use." Also, could we include support for Unique IPv6 Prefix Per Host draft-ietf-v6ops-unique-ipv6-prefix-per-host-06? Finally, dnssec. I am sure at least 1 person would like to see a discussion of this. In anticipation, it may we wise to discuss this specifically by referencing where this discussion concluded in BEHAVE. https://tools.ietf.org/html/rfc6147#section-6.2 --f403045e6aa2d5b715055373b025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
I read 
draft-jjmb-v6ops-ietf-ipv6-only-incremental-00


Looks good to me. It may be wise to note this is no=
t a novel approach, the ietf is not on the bleeding edge here. https://ar=
chive.fosdem.org/2015/news/2015-01-31-ipv6-only-again/

The purpose of the document should also =
inlclude scope for not only being a bcp for the ietf but SDO conferences in=
 general, maybe?



1 nit, i think s/AAAA/A


"Applications that explicitly require IPv4 by only performin=
g AAAA
      queries or restricting the type of underlying socket they use."


Also, could we include =
support for                       =

Unique IPv6 Pref=
ix Per Host
            
draft-ietf-v6ops-unique-ipv6-prefix-per-host-06? 

<=
/span>
<=
span class=3D"h1" style=3D"line-height:0pt;display:inline;font-size:1em;fon=
t-weight:bold">
<=
br>
Finally, dnssec.  I am sure at least=
 1 person would like to see a discussion of this. In anticipation, it may w=
e wise to discuss this specifically by referencing where this discussion co=
ncluded in BEHAVE. https://tools.ietf.org/html/rfc6147#section-6.2






--f403045e6aa2d5b715055373b025--


From nobody Mon Jul  3 23:59:53 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E10F13188C for ; Mon,  3 Jul 2017 23:59: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 FWH4CriShPBP for ; Mon,  3 Jul 2017 23:59:50 -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 C661A129B64 for ; Mon,  3 Jul 2017 23:59:50 -0700 (PDT)
Received: from h.hanazo.no (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A5BA72D502A; Tue,  4 Jul 2017 06:59:47 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 58040E565EEE; Tue,  4 Jul 2017 08:59:45 +0200 (CEST)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_B758F154-B67D-4FA1-927D-5FAE86E8143E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 4 Jul 2017 08:59:44 +0200
In-Reply-To: <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com>
Cc: Ted Lemon , v6ops@ietf.org
To: Brian E Carpenter 
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>  <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org>  <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com>   <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 06:59:52 -0000

--Apple-Mail=_B758F154-B67D-4FA1-927D-5FAE86E8143E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

>> On Jul 3, 2017, at 5:41 PM, Ole Troan  wrote:
>>> It breaks the assumption that everything you want discovered is =
within the same broadcast domain. Many think that assumption was broken =
anyway.
>>=20
>> Given the document I'm presently working on, I wouldn't really argue =
with that, except to say that it's still the default assumption in most =
environments.
>=20
> Yes, and that has deeply impacted both a document I'm working on
> (draft-ietf-anima-grasp) and a demo implementation thereof
> (https://github.com/becarpenter/graspy/blob/master/grasp.py).
>=20
> The cost of *not* having link-local multicast is considerable,
> because it means that every node, however dumb, must replicate
> and relay discovery in one way or another.

The solution I briefly described previously of course supports =
link-local multicast.

If your answer to the discovery problem is that we must put all nodes on =
the network in the same broadcast domain, we know that doesn't scale =
well. Apart from Taht showing that bridging links with very different =
properties doesn't work well either (wired and wireless). This was the =
premise for homenet.

For the current mDNS based discovery, that is already heavily filtered =
by the network in large L2 domains. It is just too noisy.

Since we have to solve the problem for multiple links anyway, does it =
then make a difference that logical topology follows physical topology =
and each host is on its own link?

Fingers crossed for hybrid dns-sd... the IETF glorious past in service =
discovery hasn't given me much confidence though. ;-)

Ole

--Apple-Mail=_B758F154-B67D-4FA1-927D-5FAE86E8143E
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

iQIcBAEBCgAGBQJZWzzhAAoJEL7aWKiYQt929gkP/RQXYL+gX1hOjxqlND3ThKz1
0D4yAt05p0UbuMIX2hbQSNlW+y8nLPK0JZA4EpnY7ZNgWTj8y21yxTrSJKb6MpZu
dxlvWBDfBB+rS4PMj4ETEcxODlgNLbflAvZEySa1kYfkqBqX8Ao4GLwJP6GetFNW
rdFtj5pkTsL4ZhUwtjm4b8oHkio6SgHwfbB316N2R3E5pKLPncLxTIJ8D+DmRjrS
kotueBWxmaNS3MtZ7vGUirYjtlnJuf3yB/tOsIosJnXBbaFx2xAEzxj5N47AItB7
Ar/nBOffZfaLMV39NHmc5NVAUm819EiY3SUp49Gy8A+zB+bHAG/9EEcwgPv7yVoK
bFcPPF13AP5aHO3VV4ES9ERvTq0M7ijnlD3jmil9Kad2Anwp6eIikJEa6Ol7gftJ
im5M19MsVV/nYyondVyMHv9/FU9Ibzvl8t5F5aJqBILlivM9faaHOUC/ks4/dGqa
RNLcl8aWAg0W5ywbS0GuxVKkUbYpR92ItZCX7YTPFDy9HCRFsEP7XTjpgKZ66pa5
OlNd4AyXkZE43LI46NjRT5jHqQK9YJUjYIcD/yn1iUuO/Gf7cCMBLAald9OSDwVv
RHipOkqM+ZhEPPyUgZLqUsDf7GsFe0CVAP9XBaovUeHF8s52pAuQAZ80n9dNHwNi
XOIEFeVPoInW32R73bdq
=jznr
-----END PGP SIGNATURE-----

--Apple-Mail=_B758F154-B67D-4FA1-927D-5FAE86E8143E--


From nobody Tue Jul  4 04:17:48 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216AF131F09 for ; Tue,  4 Jul 2017 04:17:47 -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 1T6kom2R2Eqj for ; Tue,  4 Jul 2017 04:17:44 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8AD131574 for ; Tue,  4 Jul 2017 04:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1499167061; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=YLL9PvSdy8/LzrTNX0CTK/yXHkWhvVSDuTmeIEY8uZY=; b=Pz2SXE/UEQuxuHAe2EmtLLqNUlODx7y+oia0tX8Jadb4vrBdTIFRN1n9izF2zsYfsREJjw67t1Zd6v358zc4IatVJ6vRKkk/xry3PIc9u/OuhD2dvy0A0p7LvcO2q1qG9GnvrrtU/5/W66eXoodeGeo00RyUe28rNeSuH6AWDRg=
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-71-JAvQQ_HnOLSR2OHrxj8lpw-1; Tue, 04 Jul 2017 12:17:39 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0502.eurprd07.prod.outlook.com (10.141.47.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 11:17:38 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa%14]) with mapi id 15.01.1240.013; Tue, 4 Jul 2017 11:17:38 +0000
From: Tim Chown 
To: Ole Troan 
CC: Brian E Carpenter , "v6ops@ietf.org" 
Thread-Topic: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
Thread-Index: AQHS9DY/r1sjPdW8D0mWBg5mgRcJoaJCkBgAgAAKIYCAAAaUAIAAARSAgAACOoCAABxkAIAAfU8AgABIDYA=
Date: Tue, 4 Jul 2017 11:17:38 +0000
Message-ID: <085365CA-D138-4C0F-868F-EA42637F4F38@jisc.ac.uk>
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>  <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org>  <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com>   <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-originating-ip: [2001:a88:d510:1101:c818:2a2a:c7e5:da35]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB0502; 20:kJLpNapBCSSR6VWKkOGyJvcCzV6lTUHi+BQmYLmS9R9oUsKd31OG6Z3lx+R+HOc7vYpjp7/igxT8WnlHi5s9xG5XDea0DDpicc9OFFaC4GFdLb9mONkMGKMhWKgmcF6fJ2qord9m/hgzvReROBb2rzkxk/guTife+8hwe4KKomE=
x-ms-office365-filtering-correlation-id: 499cd72f-6e8d-4dd9-e662-08d4c2ce4788
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0502; 
x-ms-traffictypediagnostic: AM3PR07MB0502:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278178393323532)(158342451672863)(166708455590820)(236129657087228)(48057245064654)(148574349560750)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0502; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0502; 
x-forefront-prvs: 0358535363
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(24454002)(52314003)(377454003)(6486002)(5250100002)(230783001)(93886004)(305945005)(81166006)(8676002)(81156014)(8936002)(6116002)(2950100002)(6916009)(42882006)(102836003)(5660300001)(82746002)(76176999)(50986999)(86362001)(83716003)(74482002)(3280700002)(2906002)(2900100001)(229853002)(3660700001)(97736004)(189998001)(57306001)(36756003)(478600001)(6436002)(6512007)(7736002)(6506006)(6306002)(99286003)(50226002)(14454004)(53546010)(966005)(54906002)(4326008)(72206003)(53936002)(33656002)(25786009)(110136004)(6246003)(39060400002)(38730400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0502; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <7D5F3357CCEB37459D1CD07F67E2F615@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 11:17:38.4663 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0502
X-MC-Unique: JAvQQ_HnOLSR2OHrxj8lpw-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 11:17:47 -0000

> On 4 Jul 2017, at 07:59, Ole Troan  wrote:
>=20
> Brian,
>=20
>>> On Jul 3, 2017, at 5:41 PM, Ole Troan  wrote:
>>>> It breaks the assumption that everything you want discovered is within=
 the same broadcast domain. Many think that assumption was broken anyway.
>>>=20
>>> Given the document I'm presently working on, I wouldn't really argue wi=
th that, except to say that it's still the default assumption in most envir=
onments.
>>=20
>> Yes, and that has deeply impacted both a document I'm working on
>> (draft-ietf-anima-grasp) and a demo implementation thereof
>> (https://github.com/becarpenter/graspy/blob/master/grasp.py).
>>=20
>> The cost of *not* having link-local multicast is considerable,
>> because it means that every node, however dumb, must replicate
>> and relay discovery in one way or another.
>=20
> The solution I briefly described previously of course supports link-local=
 multicast.
>=20
> If your answer to the discovery problem is that we must put all nodes on =
the network in the same broadcast domain, we know that doesn't scale well. =
Apart from Taht showing that bridging links with very different properties =
doesn't work well either (wired and wireless). This was the premise for hom=
enet.
>=20
> For the current mDNS based discovery, that is already heavily filtered by=
 the network in large L2 domains. It is just too noisy.
>=20
> Since we have to solve the problem for multiple links anyway, does it the=
n make a difference that logical topology follows physical topology and eac=
h host is on its own link?
>=20
> Fingers crossed for hybrid dns-sd... the IETF glorious past in service di=
scovery hasn't given me much confidence though. ;-)

The hybrid proxy work was split at IETF97 into a discovery and an advertisi=
ng proxy. The discovery proxy is about to be sent to the IESG (though it ca=
rries a reference to .home that needs fixing); see https://tools.ietf.org/h=
tml/draft-ietf-dnssd-hybrid-06

The general approach is that unicast queries from a DNS-SD client for a spe=
cific subdomain allocated to a link, e.g. Building1.example.com, are forwar=
ded until they reach the discovery proxy (as the delegated authoritative na=
me server for that subdomain), and the unicast response is then synthesised=
 from responses to a local multicast DNS query on the link. The new DNS Pus=
h work allows client hosts to subscribe to receive updates; DNS Push is als=
o about to be sent to the IESG.

Tim


From nobody Tue Jul  4 08:42:46 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF67131967 for ; Tue,  4 Jul 2017 08:42:45 -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=neo-co-tz.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 WebIDOMNMCvN for ; Tue,  4 Jul 2017 08:42:43 -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 6DD58131964 for ; Tue,  4 Jul 2017 08:42:43 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id w126so199427696wme.0 for ; Tue, 04 Jul 2017 08:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uB7KIuPWHxjGpT0x58X4brPqAQodO7jtmbJz6kVjPoQ=; b=SZMKbTaiXbL4UPyduWrxfNRzWukIbTZmnFcp8+t9aqXFCa8tBHprfQQMXa1Pgw0Gwo cTfx0zDcyxScHZQTp6g1cPssVk7IZP0WNHU6hEqst8RAHhhkj84kB0fX4aWPZ24t5bpM UqJF0wLcbVsd12IeFEeh7HMbQ3o+RtfXJ5ql/n9hicM1JnKf4hbUCBaR0uaeOiop1Viv 8Si7PdJIyhKXcUCibXM0X21jnYe3NwbpvfV0xBrfOImLGn1fhAhHXxbjahncsWdNSHgl r96KToq8J5UGYmVcZwjackDEREhBWQ5xK/E9J2e+Kj+CAMLu5ETEKcaI19b8LgOLy02h vYNg==
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=uB7KIuPWHxjGpT0x58X4brPqAQodO7jtmbJz6kVjPoQ=; b=En1n4J5KdxAjkQfjn6hbQBxG9JdAo07149QLb5fx6ZVjt96hY0Qbzr+bnobfxE6bA0 wJe1MWNTm5cI1snKt3LQ5Pm36MQbrYlxU8NFPodRgPFwGhslo19YVruYB942e6KrRNO+ qt43aXB1ySoEEDiX7zoP+e7I81V4ChrGB3DybBaL7zqLcTEQvW3B6+8PWG+Y+rkzjDT5 pmsXKBgEugcy3hsoEK/z/TSKqXkTH7Qf07BQf0PHK21FTRcaVLJCNXpAM/C0KfuPZUSF Zt0/08Rc/I/FjXsqr+71myaDIvpjNXXy4PCpXiDfm+cFhC1M4FvXiE05zcnqtkj6dbfV Zr8A==
X-Gm-Message-State: AKS2vOwatPzhkFwZ0CeaejFEzQBscAFxbkr4qXt/NYmNYAvRJisvPgh5 FiubBPwQAywMKfwKEpjMnE2CcyYb0q6s
X-Received: by 10.28.212.145 with SMTP id l139mr24258616wmg.110.1499182961661;  Tue, 04 Jul 2017 08:42:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.206.4 with HTTP; Tue, 4 Jul 2017 08:42:40 -0700 (PDT)
X-Originating-IP: [196.41.63.138]
In-Reply-To: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>
From: Noah 
Date: Tue, 4 Jul 2017 18:42:40 +0300
Message-ID: 
To: Jordi Palet Martinez 
Cc: IPv6 Operations 
Content-Type: multipart/alternative; boundary="001a11469e72e265bc05537fbb1b"
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 15:42:45 -0000

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

On Sun, Jul 2, 2017 at 10:38 PM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> Hi John, Gunter,
>
> The title of the document is =E2=80=9CUnique IPv6 Prefix Per Host=E2=80=
=9D but actually I
> think the overall idea of this work is more on the direction of =E2=80=9C=
Unique
> IPv6 Prefix Per Link=E2=80=9D.
>
>
How about  "Unique IPv6 Prefix Per /End System",   Since a host could have
different interfaces each with a unique Identifier address.

Cheers,
Noah

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




On Sun, Jul 2, 2017 at 10:38 PM, JORDI PALET MARTINEZ <jordi.=
palet@consulintel.es> wrote:
Hi John, Gunter,



The title of the document is =E2=80=9CUnique IPv6 Prefix Per Host=E2=80=9D =
but actually I think the overall idea of this work is more on the direction=
 of =E2=80=9CUnique IPv6 Prefix Per Link=E2=80=9D.



How about =C2=A0"Unique IPv6 Pref=
ix Per=C2=A0/End System", =C2=A0 Since a host could have different int=
erfaces each with a unique Identifier address.

Che=
ers,
Noah




--001a11469e72e265bc05537fbb1b--


From nobody Tue Jul  4 10:12:04 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77570126CD8 for ; Tue,  4 Jul 2017 10:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level: 
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 lOHinki_Er5Y for ; Tue,  4 Jul 2017 10:12:00 -0700 (PDT)
Received: from mta03.svc.cra.dublin.eircom.net (mta03.svc.cra.dublin.eircom.net [159.134.118.145]) by ietfa.amsl.com (Postfix) with SMTP id C2FEF132461 for ; Tue,  4 Jul 2017 10:11:59 -0700 (PDT)
Received: (qmail 44176 messnum 4592362 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 4 Jul 2017 17:11:57 -0000
Received: from avas00.vendorsvc.cra.dublin.eircom.net (HELO avas00) (213.94.190.11) by mta03.svc.cra.dublin.eircom.net (qp 44176) with SMTP; 4 Jul 2017 17:11:57 -0000
Received: from [192.168.1.4] ([86.40.118.133]) by Cloudmark Gateway with SMTP id SRMjd8icCUNZBSRMjdRlhc; Tue, 04 Jul 2017 18:11:57 +0100
X-CNFS-Analysis: v=2.2 cv=GcZnpUfL c=1 sm=1 tr=0 a=GiPPpUk0tzTpajBNWewD7A==:117 a=GiPPpUk0tzTpajBNWewD7A==:17 a=IkcTkHD0fZMA:10 a=XgkYmhZldMK02zkb5kIA:9 a=QEXdDO2ut3YA:10
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3436.2\))
From: Ross Chandler 
In-Reply-To: 
Date: Tue, 4 Jul 2017 18:09:47 +0100
Cc: Jordi Palet Martinez , IPv6 Operations 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F04571D-77E4-42FC-A958-AC68C2B6953E@eircom.net>
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es> 
To: Noah 
X-Mailer: Apple Mail (2.3436.2)
X-CMAE-Envelope: MS4wfGcNESI1p9qjQXCa6VX5HOsb/eq+6tdLwekQm5eFw+o7wCD6HDSLYrrVJDSQK18KjS0sgEnSc+kA7FCfwShqfMUEXa9SvNXHnipruKS3lqVWVSwE/uF5 DpKRB+fptegzPz9ZNgrY+HQWeUBKhw5MTiApq4wY1AGD+GIasp13D1OXUtzde5qQVX4wF2h0TAdgorf5Io8zOGomeL2AYttO/wQCVmI1HkBVPHYvyBqR8mOj
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 17:12:02 -0000

> On 4 Jul 2017, at 16:42, Noah  wrote:
>=20
>=20
> How about  =E2=80=9CUnique IPv6 Prefix Per /End System",   Since a =
host could have different interfaces each with a unique Identifier =
address.

Sticking with the current per-host title is more understandable. I =
don=E2=80=99t think the draft seeks to preclude more than one unique =
prefix per end system anyway.=20
E.g.  the host may have  multiple network interface types such as WiFi & =
3GPP, each connecting to different upstream networks. =20

Ross


From nobody Tue Jul  4 12:58:51 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440A21328AB for ; Tue,  4 Jul 2017 12:58:47 -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=neo-co-tz.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 vJWyqTkrlezs for ; Tue,  4 Jul 2017 12:58:45 -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 70498131A21 for ; Tue,  4 Jul 2017 12:58:45 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id 62so204688430wmw.1 for ; Tue, 04 Jul 2017 12:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p6TjaHshuS+AMJDlfxBAuMcXPm3WOtaOtxY0GQn5R1E=; b=B7u5RHDv4VJKjWopc6L+MLjUSgFdhQC6wBdDtJtQzC6kSSWv4gDjj4LKRuCFIAQP/w yDqXtaOKtYjQBxWgHKFfTu2nCFCvQeIbabqfiOBmBar9WegFw2yuQXJps1Ux0qA5rSxS f861ekRroylYcRdwU2VNXxNEfF3EcURff6fwD43tAC9tCzH4gtzYHxyG2mJUhqb/Ofmh VA7pMypHR2Fr3CV1GKq5rwGLxkXR8WvSvFZR4T/uHxM6ky2tzgXg6oBNYeIX2yo5eguC Yu4hrWjWIkJnG7wa25iG2Iw4trFsP4KXQxV/0zkDxxWW9j/tNPrL03Fr6HXmAbzBhnaB 3HQg==
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=p6TjaHshuS+AMJDlfxBAuMcXPm3WOtaOtxY0GQn5R1E=; b=Ryt/edhbNYSBJjtLtr/mf9oYLMNFa8vHQaS/62iBAaGTgDw8OnA6ZZdGobx6ejfFNr NiPajnc4TFtixDmeV41oytP1RhviQdZncK4XHGa9sUypSLrZ22Iyok5vABJQXKibQpn5 nCOaXn13lUdgbAV6HWUmK67YDG5YFhMQaoSYHtPsgWiW/4tcC7bRvi+Kms3V3x+xA6KC pjVybEaBQkN5YpgVTYKb7ccC5SwmUGxTjndJdR60ujiYwszNo2XNrZZN2CgwI2WGBzS7 YPQa58R16fxQ9hZ7V1V5zm5C3geAohYRVWOBOD2unx/FhXRrWJlXeBuL1Fat4lFz5mL7 Olbw==
X-Gm-Message-State: AIVw110IkGltYKQZqmVWRVR5NXVnSbqg/iEkJlKOJJpITzmmxQ/7KXqu secKvSnThFD9c/ypKARTlEhaFcbXeLDL
X-Received: by 10.28.144.6 with SMTP id s6mr14660083wmd.16.1499198323520; Tue, 04 Jul 2017 12:58:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.206.4 with HTTP; Tue, 4 Jul 2017 12:58:42 -0700 (PDT)
X-Originating-IP: [197.250.98.241]
Received: by 10.28.206.4 with HTTP; Tue, 4 Jul 2017 12:58:42 -0700 (PDT)
In-Reply-To: <8F04571D-77E4-42FC-A958-AC68C2B6953E@eircom.net>
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>  <8F04571D-77E4-42FC-A958-AC68C2B6953E@eircom.net>
From: Noah 
Date: Tue, 4 Jul 2017 22:58:42 +0300
Message-ID: 
To: Ross Chandler 
Cc: Jordi Palet Martinez , IPv6 Operations 
Content-Type: multipart/alternative; boundary="001a1145b55c85a87f0553834f2f"
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 19:58:47 -0000

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

On 4 Jul 2017 8:11 p.m., "Ross Chandler"  wrote:



> On 4 Jul 2017, at 16:42, Noah  wrote:
>
>
> How about  =E2=80=9CUnique IPv6 Prefix Per /End System",   Since a host c=
ould
have different interfaces each with a unique Identifier address.

Sticking with the current per-host title is more understandable. I don=E2=
=80=99t
think the draft seeks to preclude more than one unique prefix per end
system anyway.


Ok then

E.g.  the host may have  multiple network interface types such as WiFi &
3GPP, each connecting to different upstream networks.


Make sense.


Ross

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




On 4 Jul 2017 8:11 p.m., "Ross Chandler" <ross@eircom.net> wrote:




> On 4 Jul 2017, at 16:42, Noah <no=
ah@neo.co.tz> wrote:

>

>

> How about=C2=A0 =E2=80=9CUnique IPv6 Prefix Per /End System",=C2=
=A0 =C2=A0Since a host could have different interfaces each with a unique I=
dentifier address.




Sticking with the current per-host title is more understandable. I do=
n=E2=80=99t think the draft seeks to preclude more than one unique prefix p=
er end system anyway.
<=
br>
Ok then


E.g.=C2=A0 the host may have=C2=A0 multiple network interface types such as=
 WiFi & 3GPP, each connecting to different upstream networks.

Make=
 sense.




Ross







--001a1145b55c85a87f0553834f2f--


From nobody Tue Jul  4 13:17:38 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45295131775 for ; Tue,  4 Jul 2017 13:17: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, 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 xdKPTYpoTFqJ for ; Tue,  4 Jul 2017 13:17:34 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 B2C0B12F26D for ; Tue,  4 Jul 2017 13:17:34 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id t186so114499494pgb.1 for ; Tue, 04 Jul 2017 13:17:34 -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=DyzN/P1S23PhJYErxknfi3rBX1I496AXlPS7/rvV+kc=; b=akAS4hiqFDbePfYEoRm0z2IGYAF8m7HiSKjC6Fuywbq9UqdGVYqFMg0iEuwpzGoeya yPftb+NZjN/T+Qx4Te3Zq3P9z7kgiJntnJJXHOIqVk9xOYVFIvdcME+ORR2i3BLvKs35 70/sYYcwGHt8FkrYz5ektQfxN2HQXIHbXbdgPnUxd8CDKMQWauFB/3QKYqZ0x2xLzB83 Srnw1dlIBKn73XhPRN9xAOEyiWeagN2amfyNOCupF5lX0gfJeFZAMzLEUq+FLzzyNtKd /3UIVXiIoKOmRkfbhtGT5Q0rxz2BmILcd46uOuXhLriMu7ruzAyVbUf+TxvTDgdQY7gW WBIQ==
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=DyzN/P1S23PhJYErxknfi3rBX1I496AXlPS7/rvV+kc=; b=KhOtDZqEavNpiSsaw8cBp0TKoEzqre+tVdXBBm1uwAOBpNra6cZqp6Ajv0X/fSCec/ hTSJ5baLqle8bZGUYt9Y91/M20nsJnOTbtl7bxck15fH9tOETw9tCSqkn85nvJmnXA47 +35PX0g6W/A/syStZDBwLGTXlbhJfGHQobNYgHBHOi+W+y4KslV+8GylTy3vWw7PJPav PAVjrwTDrIP0k7Af9FHFKntLrlBRLq7S9yEeq8VIqUGS9kRJTTz4JkLyAo5fZPLnomAn co9ftPCGlgz0C6qcjYf5GPdA/78vxrnJmccd1oHq/PAyI2tLj5898A1krC5IF9q+OJnb oTnA==
X-Gm-Message-State: AIVw113SCi+M8oRJKfUImh7itFz4y1EnVDsSckNUtabfVWSi/pWUizn/ 4li6yOJICYYLzDN7
X-Received: by 10.84.198.67 with SMTP id o61mr18218113pld.98.1499199454001; Tue, 04 Jul 2017 13:17:34 -0700 (PDT)
Received: from ?IPv6:2406:e007:4f03:1:28cc:dc4c:9703:6781? ([2406:e007:4f03:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l85sm18455766pfi.53.2017.07.04.13.17.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 13:17:33 -0700 (PDT)
To: Ole Troan 
Cc: Ted Lemon , v6ops@ietf.org
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>  <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org>  <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com>   <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 5 Jul 2017 08:17:32 +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: 7bit
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 20:17:36 -0000

On 04/07/2017 18:59, Ole Troan wrote:
> Brian,
> 
>>> On Jul 3, 2017, at 5:41 PM, Ole Troan  wrote:
>>>> It breaks the assumption that everything you want discovered is within the same broadcast domain. Many think that assumption was broken anyway.
>>>
>>> Given the document I'm presently working on, I wouldn't really argue with that, except to say that it's still the default assumption in most environments.
>>
>> Yes, and that has deeply impacted both a document I'm working on
>> (draft-ietf-anima-grasp) and a demo implementation thereof
>> (https://github.com/becarpenter/graspy/blob/master/grasp.py).
>>
>> The cost of *not* having link-local multicast is considerable,
>> because it means that every node, however dumb, must replicate
>> and relay discovery in one way or another.
> 
> The solution I briefly described previously of course supports link-local multicast.
> 
> If your answer to the discovery problem is that we must put all nodes on the network in the same broadcast domain, we know that doesn't scale well. 

Of course not. I think both DNSSD and ANIMA have got beyond that point.

...
> Since we have to solve the problem for multiple links anyway, does it then make a difference that logical topology follows physical topology and each host is on its own link?

If the discovery traffic is a very small proportion of total traffic, it probably doesn't matter exactly which solution you adopt. But (as Tim implies for DNSSD), I think you should use link-local multicast when it's available. Are we disagreeing?

    Brian


From nobody Tue Jul  4 13:36:08 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF9131754 for ; Tue,  4 Jul 2017 13:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWTpwRrwM1Yw for ; Tue,  4 Jul 2017 13:36:04 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DB613171C for ; Tue,  4 Jul 2017 13:36:04 -0700 (PDT)
Received: from [10.221.197.128] (77.16.69.128.tmi.telenormobil.no [77.16.69.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id F23952D502B; Tue,  4 Jul 2017 20:36:01 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Ole Troan 
X-Mailer: iPhone Mail (14G5057a)
In-Reply-To: 
Date: Tue, 4 Jul 2017 22:35:56 +0200
Cc: Ted Lemon , v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A1B0327-CAA2-40B6-8BC2-30586A64E8AD@employees.org>
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>  <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org>  <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com>   <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com>  
To: Brian E Carpenter 
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 20:36:06 -0000

Brian,

>> Since we have to solve the problem for multiple links anyway, does it the=
n make a difference that logical topology follows physical topology and each=
 host is on its own link?
>=20
> If the discovery traffic is a very small proportion of total traffic, it p=
robably doesn't matter exactly which solution you adopt. But (as Tim implies=
 for DNSSD), I think you should use link-local multicast when it's available=
. Are we disagreeing?

Are you implying there are links where link-local multicast aren't available=
?
If course on the link type I describe there is ever only two nodes connected=
.=20

If we can't do better than require every link to have a service discovery "h=
elper" then sure link-local multicast is fine ( benefit is well known addres=
ses).

Ole=


From nobody Tue Jul  4 13:46:35 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90452131782 for ; Tue,  4 Jul 2017 13:46:33 -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 9kxTMAuDtyAb for ; Tue,  4 Jul 2017 13:46:32 -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 EB0E013174E for ; Tue,  4 Jul 2017 13:46:31 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id q85so5970362pfq.1 for ; Tue, 04 Jul 2017 13:46:31 -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=DUtXr0ExVcSTi/3IbpE6WBsIg8m2+DfrwVrrUo3zXeY=; b=OOj5nSAcaNpOK1V/DsUG4q+bduCbThCnCcUNERDcRWZMmoGWjo/ejEex7OgqGzZNrU PU1hOszd9uhQrCqKXbJevFXzWWmcn1X/AhYqiq0sjDJaewjSg0ZQQ3C60mRMQp7tXyWL yhDWtMiINlKPVTITRW3KHZ8BqkfCfuaIEuPexn1JM2LH8Jy5Q4teiOZOw5ypzBLruZhE mnBNAiebYBiggaO7v6wAoeaQS77zIKXSC9QOcncUjS3tQGd2VeM/CMv487zqsbalpS1R iX42mx1IcAvSHrlquDOLfos81P0osITebB0IckggNHihyYaXfbTTLZ6RY3HU240NYkyu nTdA==
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=DUtXr0ExVcSTi/3IbpE6WBsIg8m2+DfrwVrrUo3zXeY=; b=QnVvwELSlVQfcZBAeIwErlTEAh7+IE+TS1mpo8KPE1pvYd0Zhel6sJKgdic+GBF27Y kLuttbj5oaRE/VKHs+8SR6bSTp4xJWtvPFsjCCivI6k+OIo0m6ZQ07iaB5ImdMaxrfi+ kxjKdOcqUmaxeHsMZXOWPwJYYCq8i/LUVLimiJwJSectZqxw+I+eF1So6P5KAqbvnlAp E0rV2jXh+fGFrYwHBkA6bIqs8f5x9swZ4R7o9yZoaxxdxmlxO24ZF3WK/Ko4555lYl08 qmM2nl5Nz21j11CWfEi7XRTn+RIGJDs+m2XbCfuAALs5G5ZpC4qvI70esXFhuMuBE5sh Gstg==
X-Gm-Message-State: AIVw1106AuJd8egtB5MfNq4owhjWG3M/m2UOEH0ChC540Hc3FEnr0XRU z+zu4mrHqcL1fJvT
X-Received: by 10.98.14.130 with SMTP id 2mr17265401pfo.218.1499201191332; Tue, 04 Jul 2017 13:46:31 -0700 (PDT)
Received: from ?IPv6:2406:e007:4f03:1:28cc:dc4c:9703:6781? ([2406:e007:4f03:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n74sm46627657pfh.118.2017.07.04.13.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 13:46:30 -0700 (PDT)
To: Ole Troan 
Cc: Ted Lemon , v6ops@ietf.org
References: <5348A2C7-D762-470B-9BC9-86B8A09E6369@consulintel.es>  <645EA227-F9E8-4B15-878B-83BC8FD9809A@employees.org>  <07EE34C2-A479-41EB-B983-D8F2D585E306@employees.org> <071E625C-7B68-4E9F-98C6-262A1052CBF1@fugue.com> <310527F9-C27E-4EA0-B655-9B20878DC459@employees.org> <3cc51f51-139d-940d-bf05-6e449528f8b1@gmail.com>   <1E8426B8-1622-42EF-97E2-D81F70A78493@employees.org> <958452FD-2F9F-4057-BCB9-D62F2DC2127A@fugue.com> <2254408d-0382-fda6-aabf-2fefe033c4cc@gmail.com>   <2A1B0327-CAA2-40B6-8BC2-30586A64E8AD@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5a5db7d9-61ab-c8a9-ec9b-6bf45fd56aa8@gmail.com>
Date: Wed, 5 Jul 2017 08:46:30 +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: <2A1B0327-CAA2-40B6-8BC2-30586A64E8AD@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jul 2017 20:46:34 -0000

On 05/07/2017 08:35, Ole Troan wrote:
> Brian,
> 
>>> Since we have to solve the problem for multiple links anyway, does it then make a difference that logical topology follows physical topology and each host is on its own link?
>>
>> If the discovery traffic is a very small proportion of total traffic, it probably doesn't matter exactly which solution you adopt. But (as Tim implies for DNSSD), I think you should use link-local multicast when it's available. Are we disagreeing?
> 
> Are you implying there are links where link-local multicast aren't available?

I'm not aware of any, but do we actually have a standard that makes it mandatory?

> If course on the link type I describe there is ever only two nodes connected. 

Sure, I understood that.
 
> If we can't do better than require every link to have a service discovery "helper" then sure link-local multicast is fine ( benefit is well known addresses).

Yes. I think it's unavoidable. Certainly our intention in ANIMA is that discovery must work on any topology without prior configuration, and that requires every node that has more than one interface to automatically deploy a discovery relay between its interfaces. (And yes, that in turn requires loop prevention.)

  Brian


From nobody Wed Jul  5 09:11:06 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A221E131BBF for ; Wed,  5 Jul 2017 09:11:04 -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 sSmPJMAZDwY9 for ; Wed,  5 Jul 2017 09:11:02 -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 2C71E13153B for ; Wed,  5 Jul 2017 09:11:02 -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 v65GAvaA015137; Wed, 5 Jul 2017 18:10:57 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B3C13207D71; Wed,  5 Jul 2017 18:10:57 +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 A607A207D0F; Wed,  5 Jul 2017 18:10:57 +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 v65GAvNl022929; Wed, 5 Jul 2017 18:10:57 +0200
To: "Templin, Fred L" , "v6ops@ietf.org" 
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <1e7de6487fef4959b9177993c7581e3e@XCH15-06-08.nw.nos.boeing.com>
From: Alexandre Petrescu 
Message-ID: <5e60eb73-33a9-9c38-70f6-794583034a7f@gmail.com>
Date: Wed, 5 Jul 2017 18:10:57 +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: <1e7de6487fef4959b9177993c7581e3e@XCH15-06-08.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Jul 2017 16:11:05 -0000

Hi Fred,

But what we want is DHCPv6 PD on a real cellular interface (not tunnel).

Alex


Le 24/05/2017 à 23:21, Templin, Fred L a écrit :
> Hi Alex,
> 
> We have been doing DHCPv6 PD on Androids for a long time. DHCPv6 messaging
> is via a tunnel over the cellular and WiFi links. The DHCPv6 client app was easy to
> implement and requires just a small amount of code and a few DHCPv6 messages.
> The DHCPv6 server we are using is from ISC.
> 
> Thanks - Fred
> 
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
>> Sent: Wednesday, May 24, 2017 10:06 AM
>> To: v6ops@ietf.org
>> Subject: [v6ops] DHCPv6 PD client on cellular on some IoT platform
>>
>> Hello,
>>
>> We discussed extensively about the potential use of DHCPv6 Prefix
>> Delegation on cellular links.
>>
>> The chicken issue is the lack of DHCPv6 PD software on typical User
>> Equipment.  For example, there is no DHCPv6-PD app on Android.  The egg
>> issue is the lack of operator support of DHCPv6-PD towards the User
>> Terminal.  For example, there is no cellular operator answering to
>> DHCPv6-PD requests issued by the User Terminal.
>>
>> To address the chicken issue, we started with an ISC DHCP open software
>> client, which does implement Prefix Delegation.  It can be
>> (cross)compiled on various platforms; then type "./dhclient -6 -P"; this
>> sends an DHCPv6 Solicit Identity Associtaion for Prefix Delegation
>> message on the interface.
>>
>> However, whereas this software runs ok on interfaces such as Ethernet,
>> USBnet and WiFi interfaces, it breaks if run on the cellular interface
>> of some IoT cellular platform.  The error can be corrected by the
>> quick-and-dirty solution below.
>>
>> Alex
>>
>> ------------------------------------------------------------------------
>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
>> dhcp-4.3.5
>> ./common/lpf.c
>> line number: 551
>>
>> //default:
>> //      log_fatal("Unsupported device type %ld for \"%s\"",
>> //                (long int)sa->sa_family, name);
>>     default:
>>           hw->hlen = 7;
>>           hw->hbuf[0] = HTYPE_ETHER;
>>           memcpy(&hw->hbuf[1], sa->sa_data, 6);
>>     break;
>>
>> (two programmers worked this out).
>>
>> Alex
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 


From nobody Wed Jul  5 11:08:26 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF5F13184D for ; Wed,  5 Jul 2017 11:08: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, 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 a_DWWuEEPpsY for ; Wed,  5 Jul 2017 11:08:23 -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 65F791317D4 for ; Wed,  5 Jul 2017 11:08:23 -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 v65I8Ma5037609; Wed, 5 Jul 2017 11:08:22 -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 v65I8FIC037579 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 5 Jul 2017 11:08:15 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Jul 2017 11:08:14 -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; Wed, 5 Jul 2017 11:08:13 -0700
From: "Templin, Fred L" 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] DHCPv6 PD client on cellular on some IoT platform
Thread-Index: AQHS1LAKWsHR+akJJEGy3XAfHLYfKKID+7lQgEIi0YD//6sK4A==
Date: Wed, 5 Jul 2017 18:08:13 +0000
Message-ID: 
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <1e7de6487fef4959b9177993c7581e3e@XCH15-06-08.nw.nos.boeing.com> <5e60eb73-33a9-9c38-70f6-794583034a7f@gmail.com>
In-Reply-To: <5e60eb73-33a9-9c38-70f6-794583034a7f@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: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Jul 2017 18:08:25 -0000

SGkgQWxleCwNCg0KT0ssIGJ1dCBoZW4gaG93IHdvdWxkIHlvdSBleHBlY3QgdG8gaGFuZGxlIG11
bHRpcGxlIGludGVyZmFjZXMgKGNlbGx1bGFyICsgV2lGaSkgPw0KDQpUaGFua3MgLSBGcmVkDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZHJlIFBldHJlc2N1
IFttYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5
LCBKdWx5IDA1LCAyMDE3IDk6MTEgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl
bXBsaW5AYm9laW5nLmNvbT47IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNd
IERIQ1B2NiBQRCBjbGllbnQgb24gY2VsbHVsYXIgb24gc29tZSBJb1QgcGxhdGZvcm0NCj4gDQo+
IEhpIEZyZWQsDQo+IA0KPiBCdXQgd2hhdCB3ZSB3YW50IGlzIERIQ1B2NiBQRCBvbiBhIHJlYWwg
Y2VsbHVsYXIgaW50ZXJmYWNlIChub3QgdHVubmVsKS4NCj4gDQo+IEFsZXgNCj4gDQo+IA0KPiBM
ZSAyNC8wNS8yMDE3IMOgIDIzOjIxLCBUZW1wbGluLCBGcmVkIEwgYSDDqWNyaXQgOg0KPiA+IEhp
IEFsZXgsDQo+ID4NCj4gPiBXZSBoYXZlIGJlZW4gZG9pbmcgREhDUHY2IFBEIG9uIEFuZHJvaWRz
IGZvciBhIGxvbmcgdGltZS4gREhDUHY2IG1lc3NhZ2luZw0KPiA+IGlzIHZpYSBhIHR1bm5lbCBv
dmVyIHRoZSBjZWxsdWxhciBhbmQgV2lGaSBsaW5rcy4gVGhlIERIQ1B2NiBjbGllbnQgYXBwIHdh
cyBlYXN5IHRvDQo+ID4gaW1wbGVtZW50IGFuZCByZXF1aXJlcyBqdXN0IGEgc21hbGwgYW1vdW50
IG9mIGNvZGUgYW5kIGEgZmV3IERIQ1B2NiBtZXNzYWdlcy4NCj4gPiBUaGUgREhDUHY2IHNlcnZl
ciB3ZSBhcmUgdXNpbmcgaXMgZnJvbSBJU0MuDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4N
Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdjZvcHMgW21haWx0
bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJlc2N1
DQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI0LCAyMDE3IDEwOjA2IEFNDQo+ID4+IFRvOiB2
Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbdjZvcHNdIERIQ1B2NiBQRCBjbGllbnQgb24g
Y2VsbHVsYXIgb24gc29tZSBJb1QgcGxhdGZvcm0NCj4gPj4NCj4gPj4gSGVsbG8sDQo+ID4+DQo+
ID4+IFdlIGRpc2N1c3NlZCBleHRlbnNpdmVseSBhYm91dCB0aGUgcG90ZW50aWFsIHVzZSBvZiBE
SENQdjYgUHJlZml4DQo+ID4+IERlbGVnYXRpb24gb24gY2VsbHVsYXIgbGlua3MuDQo+ID4+DQo+
ID4+IFRoZSBjaGlja2VuIGlzc3VlIGlzIHRoZSBsYWNrIG9mIERIQ1B2NiBQRCBzb2Z0d2FyZSBv
biB0eXBpY2FsIFVzZXINCj4gPj4gRXF1aXBtZW50LiAgRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG5v
IERIQ1B2Ni1QRCBhcHAgb24gQW5kcm9pZC4gIFRoZSBlZ2cNCj4gPj4gaXNzdWUgaXMgdGhlIGxh
Y2sgb2Ygb3BlcmF0b3Igc3VwcG9ydCBvZiBESENQdjYtUEQgdG93YXJkcyB0aGUgVXNlcg0KPiA+
PiBUZXJtaW5hbC4gIEZvciBleGFtcGxlLCB0aGVyZSBpcyBubyBjZWxsdWxhciBvcGVyYXRvciBh
bnN3ZXJpbmcgdG8NCj4gPj4gREhDUHY2LVBEIHJlcXVlc3RzIGlzc3VlZCBieSB0aGUgVXNlciBU
ZXJtaW5hbC4NCj4gPj4NCj4gPj4gVG8gYWRkcmVzcyB0aGUgY2hpY2tlbiBpc3N1ZSwgd2Ugc3Rh
cnRlZCB3aXRoIGFuIElTQyBESENQIG9wZW4gc29mdHdhcmUNCj4gPj4gY2xpZW50LCB3aGljaCBk
b2VzIGltcGxlbWVudCBQcmVmaXggRGVsZWdhdGlvbi4gIEl0IGNhbiBiZQ0KPiA+PiAoY3Jvc3Mp
Y29tcGlsZWQgb24gdmFyaW91cyBwbGF0Zm9ybXM7IHRoZW4gdHlwZSAiLi9kaGNsaWVudCAtNiAt
UCI7IHRoaXMNCj4gPj4gc2VuZHMgYW4gREhDUHY2IFNvbGljaXQgSWRlbnRpdHkgQXNzb2NpdGFp
b24gZm9yIFByZWZpeCBEZWxlZ2F0aW9uDQo+ID4+IG1lc3NhZ2Ugb24gdGhlIGludGVyZmFjZS4N
Cj4gPj4NCj4gPj4gSG93ZXZlciwgd2hlcmVhcyB0aGlzIHNvZnR3YXJlIHJ1bnMgb2sgb24gaW50
ZXJmYWNlcyBzdWNoIGFzIEV0aGVybmV0LA0KPiA+PiBVU0JuZXQgYW5kIFdpRmkgaW50ZXJmYWNl
cywgaXQgYnJlYWtzIGlmIHJ1biBvbiB0aGUgY2VsbHVsYXIgaW50ZXJmYWNlDQo+ID4+IG9mIHNv
bWUgSW9UIGNlbGx1bGFyIHBsYXRmb3JtLiAgVGhlIGVycm9yIGNhbiBiZSBjb3JyZWN0ZWQgYnkg
dGhlDQo+ID4+IHF1aWNrLWFuZC1kaXJ0eSBzb2x1dGlvbiBiZWxvdy4NCj4gPj4NCj4gPj4gQWxl
eA0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gVGhlIGVycm9yIHNheXMgIi8vVU5T
VVBQT1JURUQgREVWSUNFIFRZUEUgNTAzIEZPUiBSTU5FVDAuIg0KPiA+PiBkaGNwLTQuMy41DQo+
ID4+IC4vY29tbW9uL2xwZi5jDQo+ID4+IGxpbmUgbnVtYmVyOiA1NTENCj4gPj4NCj4gPj4gLy9k
ZWZhdWx0Og0KPiA+PiAvLyAgICAgIGxvZ19mYXRhbCgiVW5zdXBwb3J0ZWQgZGV2aWNlIHR5cGUg
JWxkIGZvciBcIiVzXCIiLA0KPiA+PiAvLyAgICAgICAgICAgICAgICAobG9uZyBpbnQpc2EtPnNh
X2ZhbWlseSwgbmFtZSk7DQo+ID4+ICAgICBkZWZhdWx0Og0KPiA+PiAgICAgICAgICAgaHctPmhs
ZW4gPSA3Ow0KPiA+PiAgICAgICAgICAgaHctPmhidWZbMF0gPSBIVFlQRV9FVEhFUjsNCj4gPj4g
ICAgICAgICAgIG1lbWNweSgmaHctPmhidWZbMV0sIHNhLT5zYV9kYXRhLCA2KTsNCj4gPj4gICAg
IGJyZWFrOw0KPiA+Pg0KPiA+PiAodHdvIHByb2dyYW1tZXJzIHdvcmtlZCB0aGlzIG91dCkuDQo+
ID4+DQo+ID4+IEFsZXgNCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+IHY2b3BzQGll
dGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN
Cj4gPg0KPiA+DQo+ID4NCg0K


From nobody Wed Jul  5 16:54:43 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D39B131545 for ; Wed,  5 Jul 2017 16:54:42 -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 9-2746r5G4rb for ; Wed,  5 Jul 2017 16:54:40 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 831DA131469 for ; Wed,  5 Jul 2017 16:54:40 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id g40so2560073uaa.3 for ; Wed, 05 Jul 2017 16:54:40 -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=OydNbxsrt/GLgrix93I4XKx4QhGO+jGnHnVlk5aZWqg=; b=vU5LU+s3QuQWvVlHKLWMB2UEiLUdH6qUV0e/nnWtA662t961LYqi/Z1Vl8P0HU7Ewd p1I2XfNsOPLNvsPkHOMBVE3B0s0WoV7HoiJ7W+KesndJbS181pkcC8AjHGpMG2LUjqYe SZKeT7vUazYn835Z/WHIxi2qtzPV9I3jc6HzwFUP6E7SF1avlNbnJuVFmrE6xl5bad1d 2cQGMfyWgWqpKOBU5QIbOnNddYu8MD/386y2Exm+qN1Wdo6JAqF+xLQ0RRb6wmTP8M6V BSqBCa2BhNQw7QkdOvjqLG/4B+7l7osjhbTRFZgI8BXoDgaC283PJTQawAU8NCqB9e4G m3gw==
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=OydNbxsrt/GLgrix93I4XKx4QhGO+jGnHnVlk5aZWqg=; b=W7dSBf0lnoRj0StXd4H0jMUX1TdhXJ/JWG+zADyUMOysq88IItoJw9yGIYVf6K1XKE m7+YTJdZDmtYoqtIH6t6b4Lvnep0vpub/4DSDGlbWe4zkxIxb+kdeSEfIAEFluiEKhwE Wn1bPVtWw7GDXVHe8Hq/8rFcjbL2b/HUirNnhGvGdfzEymEzVGiOyul4gOY6iKsp2thb wzR6zjOGqH/yTwfdhU1BOPZ0pU+wJXpQE+HYuhlgz4koFSD7Wyvaq1BJPaHi4mKnbXzM nCjQ03VasjKZ7TYDm8qqJx6UQdykiRcpRM3O+x8lBrEP4ha988EhKEfkSxmwW5g0Hv9/ +v+Q==
X-Gm-Message-State: AKS2vOwRHBHzK1tA8Vg0v2bdbhOMqsvJH/6is0hrenwFeWzPOtd8knPL IyFJQVSyjJ3hXA==
X-Received: by 10.176.64.229 with SMTP id i92mr22800102uad.55.1499298879680; Wed, 05 Jul 2017 16:54:39 -0700 (PDT)
Received: from [172.20.13.236] ([186.177.98.146]) by smtp.gmail.com with ESMTPSA id d1sm144495uag.39.2017.07.05.16.54.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 16:54:38 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3436.2\))
From: Fred Baker 
In-Reply-To: <1e7de6487fef4959b9177993c7581e3e@XCH15-06-08.nw.nos.boeing.com>
Date: Wed, 5 Jul 2017 17:54:36 -0600
Cc: Alexandre Petrescu , "v6ops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2103CDFB-9718-4656-A147-1D12F7521DE1@gmail.com>
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <1e7de6487fef4959b9177993c7581e3e@XCH15-06-08.nw.nos.boeing.com>
To: Fred Templin 
X-Mailer: Apple Mail (2.3436.2)
Archived-At: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Jul 2017 23:54:42 -0000

On May 24, 2017, at 3:21 PM, Templin, Fred L  =
wrote:
> The DHCPv6 server we are using is from ISC.

Point of Clarification:

In that, you aren't going across the backbone to a server in ISC, are =
you? I would expect you are running one of ISC's open source packages  =
(ISC-DHCP or KEA) on a server inside Boeing. Hence, not across a tunnel.

Correct?=


From nobody Wed Jul  5 18:17:33 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A819129AC1 for ; Wed,  5 Jul 2017 18:17:31 -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 0n6VB4uWKVGh for ; Wed,  5 Jul 2017 18:17:29 -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 2EB4212F251 for ; Wed,  5 Jul 2017 18:17:28 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 460D424AE09; Thu,  6 Jul 2017 01:16:04 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1BB1E16005B; Thu,  6 Jul 2017 01:16:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DBCCC16007B; Thu,  6 Jul 2017 01:16:07 +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 WHsAixKH2CjQ; Thu,  6 Jul 2017 01:16:07 +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 9359A16005B; Thu,  6 Jul 2017 01:16:07 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1BEDB7D9F1D6; Thu,  6 Jul 2017 11:16:05 +1000 (AEST)
To: Alexandre Petrescu 
Cc: "v6ops@ietf.org" 
From: Mark Andrews 
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>
In-reply-to: Your message of "Wed, 24 May 2017 19:05:49 +0200." <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>
Date: Thu, 06 Jul 2017 11:16:05 +1000
Message-Id: <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org>
Archived-At: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jul 2017 01:17:31 -0000

In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, Alexandre Petrescu writes:
> Hello,
> 
> We discussed extensively about the potential use of DHCPv6 Prefix 
> Delegation on cellular links.
> 
> The chicken issue is the lack of DHCPv6 PD software on typical User 
> Equipment.  For example, there is no DHCPv6-PD app on Android.  The egg 
> issue is the lack of operator support of DHCPv6-PD towards the User 
> Terminal.  For example, there is no cellular operator answering to 
> DHCPv6-PD requests issued by the User Terminal.
> 
> To address the chicken issue, we started with an ISC DHCP open software 
> client, which does implement Prefix Delegation.  It can be 
> (cross)compiled on various platforms; then type "./dhclient -6 -P"; this 
> sends an DHCPv6 Solicit Identity Associtaion for Prefix Delegation 
> message on the interface.
> 
> However, whereas this software runs ok on interfaces such as Ethernet, 
> USBnet and WiFi interfaces, it breaks if run on the cellular interface 
> of some IoT cellular platform.  The error can be corrected by the 
> quick-and-dirty solution below.

The hack would be better as

#ifdef ARPHRD_XXXX
	case ARPHRD_XXXX:
		hw->hlen = 7;
		hw->hbuf[0] = HTYPE_ETHER;
		memcpy(&hw->hbuf[1], sa->sa_data, 6);
		break;
#endif
	default:
		log_fatal("Unsupported device type %ld for \"%s\"",
			  (long int)sa->sa_family, name);
		break;

with ARPHRD_XXXX being replaced by the correct macro for 503
from .  Something like that is at least portable.

As for the rest of it I have no idea about the presented hardware
address of this type so I don't know it the rest of it make sense.

> Alex
> 
> ------------------------------------------------------------------------
> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
> dhcp-4.3.5
> ./common/lpf.c
> line number: 551
> 
> //default:
> //      log_fatal("Unsupported device type %ld for \"%s\"",
> //                (long int)sa->sa_family, name);
>    default:
>          hw->hlen = 7;
>          hw->hbuf[0] = HTYPE_ETHER;
>          memcpy(&hw->hbuf[1], sa->sa_data, 6);
>    break;
> 
> (two programmers worked this out).
> 
> Alex
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Thu Jul  6 09:32:51 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5338D131633 for ; Thu,  6 Jul 2017 09:32:43 -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 9_GNrxCUf9JN for ; Thu,  6 Jul 2017 09:32:41 -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 0E876131806 for ; Thu,  6 Jul 2017 09:32:40 -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 v66GWdnK023130; Thu, 6 Jul 2017 18:32:39 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2C181202EAB; Thu,  6 Jul 2017 18:32: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 1B82A202EAF; Thu,  6 Jul 2017 18:32: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 v66GWcZt026333; Thu, 6 Jul 2017 18:32:38 +0200
To: Mark Andrews 
Cc: "v6ops@ietf.org" 
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org>
From: Alexandre Petrescu 
Message-ID: <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com>
Date: Thu, 6 Jul 2017 18:32:36 +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: <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jul 2017 16:32:43 -0000

Mark, noted, will try.

Just a note...

Le 06/07/2017 à 03:16, Mark Andrews a écrit :
> 
> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, Alexandre Petrescu writes:
>> Hello,
>>
>> We discussed extensively about the potential use of DHCPv6 Prefix
>> Delegation on cellular links.
>>
>> The chicken issue is the lack of DHCPv6 PD software on typical User
>> Equipment.  For example, there is no DHCPv6-PD app on Android.  The egg
>> issue is the lack of operator support of DHCPv6-PD towards the User
>> Terminal.  For example, there is no cellular operator answering to
>> DHCPv6-PD requests issued by the User Terminal.
>>
>> To address the chicken issue, we started with an ISC DHCP open software
>> client, which does implement Prefix Delegation.  It can be
>> (cross)compiled on various platforms; then type "./dhclient -6 -P"; this
>> sends an DHCPv6 Solicit Identity Associtaion for Prefix Delegation
>> message on the interface.
>>
>> However, whereas this software runs ok on interfaces such as Ethernet,
>> USBnet and WiFi interfaces, it breaks if run on the cellular interface
>> of some IoT cellular platform.  The error can be corrected by the
>> quick-and-dirty solution below.
> 
> The hack would be better as
> 
> #ifdef ARPHRD_XXXX
> 	case ARPHRD_XXXX:
> 		hw->hlen = 7;
> 		hw->hbuf[0] = HTYPE_ETHER;
> 		memcpy(&hw->hbuf[1], sa->sa_data, 6);
> 		break;
> #endif
> 	default:
> 		log_fatal("Unsupported device type %ld for \"%s\"",
> 			  (long int)sa->sa_family, name);
> 		break;
> 
> with ARPHRD_XXXX being replaced by the correct macro for 503
> from .  Something like that is at least portable.

But it means when I go to other platform will have to modify again the 
ISC client source code?

In cellular terminals there are so many non-IEEE different kinds of links.

Other clients work out of the box on this - I agree with you, strange - 
"rmnet0" interface.

Alex

> 
> As for the rest of it I have no idea about the presented hardware
> address of this type so I don't know it the rest of it make sense.
> 
>> Alex
>>
>> ------------------------------------------------------------------------
>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
>> dhcp-4.3.5
>> ./common/lpf.c
>> line number: 551
>>
>> //default:
>> //      log_fatal("Unsupported device type %ld for \"%s\"",
>> //                (long int)sa->sa_family, name);
>>     default:
>>           hw->hlen = 7;
>>           hw->hbuf[0] = HTYPE_ETHER;
>>           memcpy(&hw->hbuf[1], sa->sa_data, 6);
>>     break;
>>
>> (two programmers worked this out).
>>
>> Alex
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Jul  6 16:03:54 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36398131676 for ; Thu,  6 Jul 2017 16:03:53 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 iAcfCRxeoIeS for ; Thu,  6 Jul 2017 16:03:51 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1C312EC34 for ; Thu,  6 Jul 2017 16:03:51 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2681258C4AE; Fri,  7 Jul 2017 01:03:48 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id F205FB0C4E5; Fri,  7 Jul 2017 01:03:47 +0200 (CEST)
Date: Fri, 7 Jul 2017 01:03:47 +0200
From: Toerless Eckert 
To: v6ops@ietf.org
Message-ID: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jul 2017 23:03:53 -0000

For a protocol design, we are wondering what the current state of the
art is wrt to IPv6 link local addresses potentially being the same
on multiple interfaces of a network device like a router.

I was told by Brian that RFC7217 is recommended, but recommendations are
one thing and reality can be another thing. If there are widely deployed
network devices that do have the same link local address across multiple
interfaces then it could take quite a while for this to get changed,
so it might be prudent for a protocol design NOT to expect that eg: RFC7217
is supported everywhere.

The one type of datapoint i seem to vaguely remember is that routers
with large number of "cheap" L3 interfaces often derive their MAC
utilization designs from L2 switches where you do not automatically
assign a separate MAC address to every port because thats a cost factor,
and instead there is just a limited number of MAC addresses assigned to
the box (i think i remember '8' from some cisco products) and
once those are exhausted, additional L3 interfaces repeat the MAC
addresses. And of course if the link-local addresses are derived from
interfaces MAC addresses then we have the problem in question.

Standard disclaimer:
Just because i am paranoid does not mean they are not after me.

So, would love to hear that duplicate link-local IPv6 addresses are
not to be found anywhere in deployed  IPv6 networks and that i am
just paranoid ;-) Or else we know that we should take this into
consideration.

Thanks
    Toerless


From nobody Thu Jul  6 16:51:58 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F991317DE for ; Thu,  6 Jul 2017 16:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dGuBFb-CyAB for ; Thu,  6 Jul 2017 16:51:54 -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 AE265131684 for ; Thu,  6 Jul 2017 16:51:54 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id r126so9321539vkg.0 for ; Thu, 06 Jul 2017 16:51: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=btSgAJ2dz9X47ggLj+xl+55/ja2GmaIUnSq323/hpRs=; b=pg09X00BFH2QGlkxvvqcQWcxwf6WxEk21hGkgDEJEjwdoVAU+gm8SM9NN6Xf3ObuE7 /5FIJtDMrB6Jf3iT82v+yPe3RC9nlvcOKV21agaDWgKvt7UJBwwMOn1B0KepH34LzITM zaYQi4xDVtANhVa+McYis6YdkH5VYzkGbIneGQVjd+pVmQMzX9lEFGO5Pm+0tKdtpJXF NhsXwanjAchfhwcqijDZbN5iFDhL7CS3eg6Sd4pgkfRtzKVpwTXjlbql8ZNYOxRTc3Wh Dk+vqIkzExor3rJcEOW5oqbYMKRLV2rVL9TiGHuOxYhhEByB6coFHR2X6xVCKc9nEF8z j0lA==
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=btSgAJ2dz9X47ggLj+xl+55/ja2GmaIUnSq323/hpRs=; b=niBhlmGqOssNqnQMDnnuNbBu6jiMYkZfSTG0TbL5pUjQdojrfCCx+EHDWuiIcfgebO hRbWdFvkksHIJjTQcJrqqqS1Ntzj5dCEAMifzOI926X7TrNbP6NNnISQk7QMXNsj+qeQ xeEaVe3dEdjmUaQBwgPzF3JCNC37ccyCp1qbuObVr5URhFduKyE2G4uOEShZoFfQxmr9 Z46UDcIGzMrUo1PQOjmmJpMGWVpajp2X5W7A//bbobr74DFbHv3YevszQyEpDYu2Cu9G iIgaD/GHWwcKbYfipzJNJkp5J08BrPOoSGDQ/Xut8ra8r/fz4iLNyeUj9+AS0qC2Fpmr FO8w==
X-Gm-Message-State: AKS2vOzKaUyLhiakOmYP0CixK6yq0I2wLQiSmgEIACjAzFoI15Q4sbY7 SBjSxA1x9wdU978+GWETD1yjrd1h1APx
X-Received: by 10.31.10.198 with SMTP id 189mr29586702vkk.36.1499385113697; Thu, 06 Jul 2017 16:51:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.81.100 with HTTP; Thu, 6 Jul 2017 16:51:23 -0700 (PDT)
In-Reply-To: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
From: Mark Smith 
Date: Fri, 7 Jul 2017 09:51:23 +1000
Message-ID: 
To: Toerless Eckert 
Cc: v6ops list 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jul 2017 23:51:56 -0000

On 7 July 2017 at 09:03, Toerless Eckert  wrote:
> For a protocol design, we are wondering what the current state of the
> art is wrt to IPv6 link local addresses potentially being the same
> on multiple interfaces of a network device like a router.
>
> I was told by Brian that RFC7217 is recommended, but recommendations are
> one thing and reality can be another thing. If there are widely deployed
> network devices that do have the same link local address across multiple
> interfaces then it could take quite a while for this to get changed,
> so it might be prudent for a protocol design NOT to expect that eg: RFC7217
> is supported everywhere.
>

It would be prudent.

RFC4291bis explicitly says that the same IID can be used on a device's
different interfaces.

"The same
   interface identifier may be used on multiple interfaces on a single
   node, as long as they are attached to different subnets."

This might sound a little ambiguous because the LL prefix ("subnet")
is the same on all links, however I think "different subnets or
instances of the same subnet" would be accurate. The overriding
requirement is

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

An Internet search for "fe80::1" shows that this is also a common
value being used for router interfaces.


> The one type of datapoint i seem to vaguely remember is that routers
> with large number of "cheap" L3 interfaces often derive their MAC
> utilization designs from L2 switches where you do not automatically
> assign a separate MAC address to every port because thats a cost factor,
> and instead there is just a limited number of MAC addresses assigned to
> the box (i think i remember '8' from some cisco products) and
> once those are exhausted, additional L3 interfaces repeat the MAC
> addresses. And of course if the link-local addresses are derived from
> interfaces MAC addresses then we have the problem in question.
>
> Standard disclaimer:
> Just because i am paranoid does not mean they are not after me.
>
> So, would love to hear that duplicate link-local IPv6 addresses are
> not to be found anywhere in deployed  IPv6 networks and that i am
> just paranoid ;-) Or else we know that we should take this into
> consideration.
>
> Thanks
>     Toerless
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Jul  6 19:13:10 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7725A13164D for ; Thu,  6 Jul 2017 19:13:08 -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 3PdU0W1nFsJp for ; Thu,  6 Jul 2017 19:13:06 -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 43E62131630 for ; Thu,  6 Jul 2017 19:13:06 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id c73so9618681pfk.2 for ; Thu, 06 Jul 2017 19:13: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=aiubUwdIaSpgLZaDd1CBIT2jW7jQXXNQw+0fvt3x+VI=; b=Gf+FzzzKMf7ICB2kiZT1JZc9eE7qgxYZqFuKRPvZFGC1GWRE1eyN+HyzdpTC4dHsry k8GuWF+nz+9Ro7v5TDDAZTFMk2IAXr5l+S2Xe+sc03qX2StbL3kBH3gH6C4fsTi4AA3l fbLUoRxyzwHgdpaGLJ2iE014fksdie3nh6/2f4odhk+p1UjuZZ3SWiYY92CzwU1Mb+bE oFeyvcE3LZDk39hSdoAD3nARs/dQgWjnTu2jYylAubK9pFP8DtmKyEzdoAyPw0IuFvYB 12kTGv7J8UOgtMKGkl6up6bPV8RLw5jExHcbXC72GZvaXgxkTa10Y3+8YkVAOMzJwbUz 2C5A==
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=aiubUwdIaSpgLZaDd1CBIT2jW7jQXXNQw+0fvt3x+VI=; b=SmnE+oyslDLkTPVxd1nRo/s+tAw7Lh7m7lW5AkXCclTqDh9Qnxn7R3ozQDhxF90BpW h8Xl5fDh26yyrpMMQ/RvQXgRUoOMAWdjC8zE9wyuaa4U9YzORHrwwdDhbB+BQ54sK3eC 9L0S5pcZ71Yh80SK6aG1sLoMgrQ9Y/jtRy6v+ba//naI8DhNWSa0YDtfJn8vQscdG9xV XqOvRreWuIpf7CaJmH2tU9+7rtX0gw2uxrcn06dk2L3GUGwDuewiQtbXE8rEPL2QvFtf ERZEt1mivrlprBT4IyaIYgk9A7pMR4rdNrmbmFSN9E236HafkSqZqT5bTehBzu58s+H8 Kk+g==
X-Gm-Message-State: AIVw111XV7AZToOQEuW2Lvdn4WvZ8j9mdfgorqCOYqQVZ7uOEDf/XHYs 9z4Hxp806nipEY5f
X-Received: by 10.99.175.18 with SMTP id w18mr29775492pge.67.1499393585455; Thu, 06 Jul 2017 19:13:05 -0700 (PDT)
Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w66sm3318846pfi.63.2017.07.06.19.13.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 19:13:04 -0700 (PDT)
To: Mark Smith , Toerless Eckert 
Cc: v6ops list 
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 7 Jul 2017 14:13:09 +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: 7bit
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 02:13:08 -0000

> 
> "They are required to be unique within a subnet prefix."
> 
> An Internet search for "fe80::1" shows that this is also a common
> value being used for router interfaces.

Which makes my head hurt, since it's a guaranteed failure if two
such routers are on the same subnet.

Thanks for reminding us of the "may" in RFC4291(bis). We'd be
foolish to ignore that.

Regards
   Brian

On 07/07/2017 11:51, Mark Smith wrote:
> On 7 July 2017 at 09:03, Toerless Eckert  wrote:
>> For a protocol design, we are wondering what the current state of the
>> art is wrt to IPv6 link local addresses potentially being the same
>> on multiple interfaces of a network device like a router.
>>
>> I was told by Brian that RFC7217 is recommended, but recommendations are
>> one thing and reality can be another thing. If there are widely deployed
>> network devices that do have the same link local address across multiple
>> interfaces then it could take quite a while for this to get changed,
>> so it might be prudent for a protocol design NOT to expect that eg: RFC7217
>> is supported everywhere.
>>
> 
> It would be prudent.
> 
> RFC4291bis explicitly says that the same IID can be used on a device's
> different interfaces.
> 
> "The same
>    interface identifier may be used on multiple interfaces on a single
>    node, as long as they are attached to different subnets."
> 
> This might sound a little ambiguous because the LL prefix ("subnet")
> is the same on all links, however I think "different subnets or
> instances of the same subnet" would be accurate. The overriding
> requirement is
> 
> "They are required to be unique within a subnet prefix."
> 
> An Internet search for "fe80::1" shows that this is also a common
> value being used for router interfaces.
> 
> 
>> The one type of datapoint i seem to vaguely remember is that routers
>> with large number of "cheap" L3 interfaces often derive their MAC
>> utilization designs from L2 switches where you do not automatically
>> assign a separate MAC address to every port because thats a cost factor,
>> and instead there is just a limited number of MAC addresses assigned to
>> the box (i think i remember '8' from some cisco products) and
>> once those are exhausted, additional L3 interfaces repeat the MAC
>> addresses. And of course if the link-local addresses are derived from
>> interfaces MAC addresses then we have the problem in question.
>>
>> Standard disclaimer:
>> Just because i am paranoid does not mean they are not after me.
>>
>> So, would love to hear that duplicate link-local IPv6 addresses are
>> not to be found anywhere in deployed  IPv6 networks and that i am
>> just paranoid ;-) Or else we know that we should take this into
>> consideration.
>>
>> Thanks
>>     Toerless
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Thu Jul  6 20:26:51 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C927126E3A for ; Thu,  6 Jul 2017 20:26:49 -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 MRgsOnFQSqIx for ; Thu,  6 Jul 2017 20:26:47 -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 6466A12741D for ; Thu,  6 Jul 2017 20:26:47 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id y70so10865830vky.3 for ; Thu, 06 Jul 2017 20:26:47 -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=bGpdUOFrrn2hm9k/kDYRPfFAkYssE3esFJ7si7kcRb0=; b=S6M8B0fmuRFeKSInp6TIyd+eihQ9IO4dDUOLpN6JfknTTBN8yLrsSCyJeL262XUjar XeWK/e4Z1BTvG7eLpuwt2Q2dDTU2ABcI86kYZyey/+vA5JnqxciDdSyI9UFKwWvETcrT jrSJkanu/bsuF1azB99DjJf0qGjyD7vlA+d/HUXj5eM2E+AAo4ZNIQEZ7HQZNwmO+Ley HJqd2WfXLNA+2ffhNUuRbF6/ANVz6launWjj3Rc0/qQN+McTTJr6KWXzMnG23LpVGf/e voALZJUHc0hnv9zQy5WBs+sdSG2RU1O8pUTSVfCSV1sZNqqhbXQSnaXmN+wwnKGLuhVF Oakg==
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=bGpdUOFrrn2hm9k/kDYRPfFAkYssE3esFJ7si7kcRb0=; b=nPY4vSqurrOLh5x0YM/9kDCn/qHyQGy9yklv4WBatUYKFGoteUjeEhxOAyomw+kjv9 1LlpCy1F7wsif7MUB04vllqHra2ugIaUX0GeFmlo72cCtru0VaL20/XaqQV7dS3uIiM+ gZ8PZPOMK9aLqJb8O3pcC6+0t0ZrPY5S+fsNmhss67XOsgKnDeBpMzcvSaQ8cQPZVZbT ZM1Dqd5/isFgPPgS7bvkcgTKkiWHV4mZ0/w2PeY14p1GzG2aOrU9TdooetM6nJ4+DOXN tGDdcDjzds3HwzG4wa1qPoUKcggatWz6vSv4k8eBW8Z05FVn8sc2vbRuTabSmVZdykHD vC3w==
X-Gm-Message-State: AKS2vOx9Z8DdeHof7nQEl63A9/u08X2pl/xbm6x1aUkPRtZPwBanoJcY j2OaA3QQ5XsVNpKL4xkHQe3Ih8gdow==
X-Received: by 10.31.106.2 with SMTP id f2mr29676585vkc.112.1499398006544; Thu, 06 Jul 2017 20:26:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.81.100 with HTTP; Thu, 6 Jul 2017 20:26:46 -0700 (PDT)
Received: by 10.176.81.100 with HTTP; Thu, 6 Jul 2017 20:26:46 -0700 (PDT)
In-Reply-To: 
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>   
From: Mark Smith 
Date: Fri, 7 Jul 2017 13:26:46 +1000
Message-ID: 
To: Brian E Carpenter 
Cc: v6ops list , Toerless Eckert 
Content-Type: multipart/alternative; boundary="001a114db3f48e9df80553b1cdfb"
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 03:26:49 -0000

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

On 7 Jul. 2017 12:13, "Brian E Carpenter" 
wrote:

>
> "They are required to be unique within a subnet prefix."
>
> An Internet search for "fe80::1" shows that this is also a common
> value being used for router interfaces.

Which makes my head hurt, since it's a guaranteed failure if two
such routers are on the same subnet.


DAD should catch it and stop the latter one coming up. Alternatively poor
man's VRRP by having them as anycast addresses.



Thanks for reminding us of the "may" in RFC4291(bis). We'd be
foolish to ignore that.

Regards
   Brian

On 07/07/2017 11:51, Mark Smith wrote:
> On 7 July 2017 at 09:03, Toerless Eckert  wrote:
>> For a protocol design, we are wondering what the current state of the
>> art is wrt to IPv6 link local addresses potentially being the same
>> on multiple interfaces of a network device like a router.
>>
>> I was told by Brian that RFC7217 is recommended, but recommendations are
>> one thing and reality can be another thing. If there are widely deployed
>> network devices that do have the same link local address across multiple
>> interfaces then it could take quite a while for this to get changed,
>> so it might be prudent for a protocol design NOT to expect that eg:
RFC7217
>> is supported everywhere.
>>
>
> It would be prudent.
>
> RFC4291bis explicitly says that the same IID can be used on a device's
> different interfaces.
>
> "The same
>    interface identifier may be used on multiple interfaces on a single
>    node, as long as they are attached to different subnets."
>
> This might sound a little ambiguous because the LL prefix ("subnet")
> is the same on all links, however I think "different subnets or
> instances of the same subnet" would be accurate. The overriding
> requirement is
>
> "They are required to be unique within a subnet prefix."
>
> An Internet search for "fe80::1" shows that this is also a common
> value being used for router interfaces.
>
>
>> The one type of datapoint i seem to vaguely remember is that routers
>> with large number of "cheap" L3 interfaces often derive their MAC
>> utilization designs from L2 switches where you do not automatically
>> assign a separate MAC address to every port because thats a cost factor,
>> and instead there is just a limited number of MAC addresses assigned to
>> the box (i think i remember '8' from some cisco products) and
>> once those are exhausted, additional L3 interfaces repeat the MAC
>> addresses. And of course if the link-local addresses are derived from
>> interfaces MAC addresses then we have the problem in question.
>>
>> Standard disclaimer:
>> Just because i am paranoid does not mean they are not after me.
>>
>> So, would love to hear that duplicate link-local IPv6 addresses are
>> not to be found anywhere in deployed  IPv6 networks and that i am
>> just paranoid ;-) Or else we know that we should take this into
>> consideration.
>>
>> Thanks
>>     Toerless
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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




On 7 Jul. 2017 12:13, "Brian E Carpenter" <brian.e.carpenter=
@gmail.com> wrote:
>

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

>

> An Internet search for "fe80::1" shows that this is also a c=
ommon

> value being used for router interfaces.




Which makes my head hurt, since it's a guaranteed failure if two<=
br>
such routers are on the same subnet.

DAD should catch it and stop the =
latter one coming up. Alternatively poor man's VRRP by having them as a=
nycast addresses.





Thanks for reminding us of the "may" in RFC4291(bis). We'd be=


foolish to ignore that.



Regards

=C2=A0 =C2=A0Brian




On 07/07/2017 11:51, Mark Smith wrote:

> On 7 July 2017 at 09:03, Toerless Eckert <tte@cs.fau.de> wrote:

>> For a protocol design, we are wondering what the current state of =
the

>> art is wrt to IPv6 link local addresses potentially being the same=


>> on multiple interfaces of a network device like a router.

>>

>> I was told by Brian that RFC7217 is recommended, but recommendatio=
ns are

>> one thing and reality can be another thing. If there are widely de=
ployed

>> network devices that do have the same link local address across mu=
ltiple

>> interfaces then it could take quite a while for this to get change=
d,

>> so it might be prudent for a protocol design NOT to expect that eg=
: RFC7217

>> is supported everywhere.

>>

>

> It would be prudent.

>

> RFC4291bis explicitly says that the same IID can be used on a device&#=
39;s

> different interfaces.

>

> "The same

>=C2=A0 =C2=A0 interface identifier may be used on multiple interfaces o=
n a single

>=C2=A0 =C2=A0 node, as long as they are attached to different subnets.&=
quot;

>

> This might sound a little ambiguous because the LL prefix ("subne=
t")

> is the same on all links, however I think "different subnets or
> instances of the same subnet" would be accurate. The overriding
> requirement is

>

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

>

> An Internet search for "fe80::1" shows that this is also a c=
ommon

> value being used for router interfaces.

>

>

>> The one type of datapoint i seem to vaguely remember is that route=
rs

>> with large number of "cheap" L3 interfaces often derive =
their MAC

>> utilization designs from L2 switches where you do not automaticall=
y

>> assign a separate MAC address to every port because thats a cost f=
actor,

>> and instead there is just a limited number of MAC addresses assign=
ed to

>> the box (i think i remember '8' from some cisco products) =
and

>> once those are exhausted, additional L3 interfaces repeat the MAC<=
br>
>> addresses. And of course if the link-local addresses are derived f=
rom

>> interfaces MAC addresses then we have the problem in question.

>>

>> Standard disclaimer:

>> Just because i am paranoid does not mean they are not after me.
>>

>> So, would love to hear that duplicate link-local IPv6 addresses ar=
e

>> not to be found anywhere in deployed=C2=A0 IPv6 networks and that =
i am

>> just paranoid ;-) Or else we know that we should take this into
>> consideration.

>>

>> Thanks

>>=C2=A0 =C2=A0 =C2=A0Toerless

>>

>> _______________________________________________

>> v6ops mailing list

>> v6ops@ietf.org=


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


>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org=


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


>





--001a114db3f48e9df80553b1cdfb--


From nobody Thu Jul  6 23:48:09 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113F9128B8F for ; Thu,  6 Jul 2017 23:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level: 
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=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 vgkB0zHuJdZA for ; Thu,  6 Jul 2017 23:48:06 -0700 (PDT)
Received: from mta05.svc.cra.dublin.eircom.net (mta05.svc.cra.dublin.eircom.net [159.134.118.221]) by ietfa.amsl.com (Postfix) with SMTP id 06694126579 for ; Thu,  6 Jul 2017 23:48:05 -0700 (PDT)
Received: (qmail 39295 messnum 273167 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 7 Jul 2017 06:48:02 -0000
Received: from avas01.vendorsvc.cra.dublin.eircom.net (HELO avas01) (213.94.190.12) by mta05.svc.cra.dublin.eircom.net (qp 39295) with SMTP; 7 Jul 2017 06:48:02 -0000
Received: from [192.168.1.6] ([86.40.118.133]) by Cloudmark Gateway with SMTP id TN3aduLNIcTICTN3adGNaY; Fri, 07 Jul 2017 07:48:02 +0100
X-CNFS-Analysis: v=2.2 cv=DPn/22Fb c=1 sm=1 tr=0 a=GiPPpUk0tzTpajBNWewD7A==:117 a=GiPPpUk0tzTpajBNWewD7A==:17 a=pGLkceISAAAA:8 a=x1vu-Gx1UE7F_9ftOPIA:9 a=-81IOA53tYf91z68:21 a=ojvzlh0RrXYd87wq:21 a=QEXdDO2ut3YA:10 a=-sLWDbW0B2KgHMklUcUA:9 a=WwzX-bMQBkr9lMDq:21 a=QP0oexxo3affDTm4:21 a=qAJ0mL2oRvER640-:21 a=_W_S_7VecoQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22
From: Ross Chandler 
Message-Id: <7B601616-4809-491F-BB64-B7CC042B264A@eircom.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_208221CD-943A-4A6A-9ADF-CF6BFD56F0D7"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3436.2\))
Date: Fri, 7 Jul 2017 07:42:53 +0100
In-Reply-To: 
Cc: Brian E Carpenter , v6ops list , Toerless Eckert 
To: Mark Smith 
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>    
X-Mailer: Apple Mail (2.3436.2)
X-CMAE-Envelope: MS4wfBh+oagMThiojdAZnTUI+9PsTikSOkUvztcoFin9pDE2lfppU3R+S8ptnaq3v/TEEMQptohGeJ6ENrx0kzWFBNBcWhoCHe0StchL2f9qpff5NVzt4Zvp AqmPg+Z4TCs1zq5Qc4SZQu+meHBkjoSzShdRZgORyGxFgiTHcf0WuQ7INtHK0F3H5940a62sv4vCgbf6bHmstBc/3M/bRrcNyeLPENVR+Bx3rtiSWnj77CUv T5+PyKOn+U6OyHz59y2Rfw==
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 06:48:08 -0000

--Apple-Mail=_208221CD-943A-4A6A-9ADF-CF6BFD56F0D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 7 Jul 2017, at 04:26, Mark Smith > wrote:
>=20
> On 7 Jul. 2017 12:13, "Brian E Carpenter" > wrote:
>=20
> > An Internet search for "fe80::1" shows that this is also a common
> > value being used for router interfaces.
>=20
> Which makes my head hurt, since it's a guaranteed failure if two
> such routers are on the same subnet.
>=20
> DAD should catch it and stop the latter one coming up. Alternatively =
poor man=E2=80=99s VRRP by having them as anycast addresses.


DAD protection on the well behaved router yes but it would be better if =
the router Ethernet interface used an address formed from using its MAC.
The misbehaving router might also have its DNS proxy responding with =
AAAA records for its webgui that point at the link-local instead of a =
GUA or horror a ULA.
I find that http://[fe80::1]/  currently works on =
Windows as that assumes to forward out the default interface.
Access to the same link-local URL using macOS doesn=E2=80=99t work as =
might be reasonably expected.

Anycast doesn=E2=80=99t apply as the two routers RAing fe80::1 share the =
same LAN.

Ross




--Apple-Mail=_208221CD-943A-4A6A-9ADF-CF6BFD56F0D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 7 Jul =
2017, at 04:26, Mark Smith <markzzzsmith@gmail.com> wrote:

On 7 Jul. 2017 12:13, "Brian E =
Carpenter" <brian.e.carpenter@gmail.com> =
wrote:


> An Internet search for "fe80::1" shows that this is also a =
common

> value being used for router interfaces.




Which makes my head hurt, since it's a guaranteed failure if =
two

such routers are on the same subnet.
DAD should catch it and =
stop the latter one coming up. Alternatively poor man=E2=80=99s VRRP by =
having them as anycast =
addresses.

DAD protection on the well behaved =
router yes but it would be better if the router Ethernet interface used =
an address formed from using its MAC.
The =
misbehaving router might also have its DNS proxy responding with AAAA =
records for its webgui that point at the link-local instead of a GUA or =
horror a ULA.
I find that http://[fe80::1]/ currently=
 works on Windows as that assumes to forward out the default =
interface.
Access to the same link-local URL using =
macOS doesn=E2=80=99t work as might be reasonably expected.

Anycast doesn=E2=80=99t =
apply as the two routers RAing fe80::1 share the same LAN.

Ross



=

--Apple-Mail=_208221CD-943A-4A6A-9ADF-CF6BFD56F0D7--


From nobody Fri Jul  7 01:42:38 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C21204DA for ; Fri,  7 Jul 2017 01:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4b00NCnghcO for ; Fri,  7 Jul 2017 01:42:35 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29451200C5 for ; Fri,  7 Jul 2017 01:42:34 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D570D41BF3 for ; Fri,  7 Jul 2017 10:42:32 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A38C641BD8; Fri,  7 Jul 2017 10:42:32 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id A0602737D2; Fri,  7 Jul 2017 10:42:32 +0200 (CEST)
Date: Fri, 7 Jul 2017 10:42:32 +0200
From: Gert Doering 
To: Toerless Eckert 
Cc: v6ops@ietf.org
Message-ID: <20170707084232.GS45648@Space.Net>
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 08:42:37 -0000

Hi,

On Fri, Jul 07, 2017 at 01:03:47AM +0200, Toerless Eckert wrote:
> I was told by Brian that RFC7217 is recommended, but recommendations are
> one thing and reality can be another thing. If there are widely deployed
> network devices that do have the same link local address across multiple
> interfaces then it could take quite a while for this to get changed,
> so it might be prudent for a protocol design NOT to expect that eg: RFC7217
> is supported everywhere.

Checking one of our boxes, which was not exactly "cheap":

Cisco#sh ipv int | inc FE80
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
[..]
  IPv6 is enabled, link-local address is FE80::1 
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
[..]
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 [UNA]
    FE80::5:73FF:FEA0:6 [OOD]
  IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 [UNA]
    FE80::5:73FF:FEA0:6 [OOD]

... so yes, it seems to use the same LLA on all L3 interfaces, unless
configured otherwise...  (UNA and OOD seem to appear "if HSRPv2 is
involved", but even then, the box picks the same LLA for all HSRPv2-
enabled interfaces if the HSRPv2 group is the same)


Checking on a much newer box with IOS XR and "router hardware", things
look different, but still not sufficiently uniqe:

RP/0/RSP0/CPU0:Cisco#sh ipv6 int | inc fe80
Fri Jul  7 10:39:55.203 MEDST
  IPv6 is enabled, link-local address is fe80::d80:22ff:fe39:18cf 
  IPv6 is enabled, link-local address is fe80::d80:22ff:fe39:18cf 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a00 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a01 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a02 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a02 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e8 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e9 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e9 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
  IPv6 is enabled, link-local address is fe80::21a:6cff:fe9e:6529 

(this one is "there are dot1q subinterfaces involved, and all subifs
have the same LLA as the parent interface" - which is unsurprising,
when you think about it :-) - and I expect this part to be the same
across most vendors that assign MAC-address derived LLA addresses)

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

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


From nobody Fri Jul  7 08:30:05 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC83131544 for ; Fri,  7 Jul 2017 08:30:02 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 kRxkD6S7HnGw for ; Fri,  7 Jul 2017 08:30:01 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC11129B37 for ; Fri,  7 Jul 2017 08:30:01 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7B5D158C4BB; Fri,  7 Jul 2017 17:29:55 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 61E77B0C4EF; Fri,  7 Jul 2017 17:29:55 +0200 (CEST)
Date: Fri, 7 Jul 2017 17:29:55 +0200
From: Toerless Eckert 
To: Mark Smith 
Cc: v6ops list 
Message-ID: <20170707152955.GA16808@faui40p.informatik.uni-erlangen.de>
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 15:30:03 -0000

Thanks, Mark, Gert,...:

So in summary & followup Q:
- Address architecture says addresses MAY be the same (RFC4291bis)

- MAC based LL assignment is still common and leads to this

- Q: fe80::1 - i assume this is manual config ? Wasn't even aware 
  whether manual config of LL was possible in all/most routers.
  (but i can see how this may be attractive to operators whose
   habits have been formed by too many decades with IPv4).
  
- Also: Wrt RFC7217, 
  Whats the motivation for device vendors to implement this on
  network devices ? Would operators ask for this for their network
  devices ? MAC address could be considered randomn enough but the operators
  might have databases with them, so they could identify them.
  (not arguing about the obvious benefits for host addresses of rfc7217)


On Fri, Jul 07, 2017 at 09:51:23AM +1000, Mark Smith wrote:
> > I was told by Brian that RFC7217 is recommended, but recommendations are
> > one thing and reality can be another thing. If there are widely deployed
> > network devices that do have the same link local address across multiple
> > interfaces then it could take quite a while for this to get changed,
> > so it might be prudent for a protocol design NOT to expect that eg: RFC7217
> > is supported everywhere.
> >
> 
> It would be prudent.
> 
> RFC4291bis explicitly says that the same IID can be used on a device's
> different interfaces.
> 
> "The same
>    interface identifier may be used on multiple interfaces on a single
>    node, as long as they are attached to different subnets."
> 
> This might sound a little ambiguous because the LL prefix ("subnet")
> is the same on all links, however I think "different subnets or
> instances of the same subnet" would be accurate. The overriding
> requirement is
> 
> "They are required to be unique within a subnet prefix."
> 
> An Internet search for "fe80::1" shows that this is also a common
> value being used for router interfaces.
> 
> 
> > The one type of datapoint i seem to vaguely remember is that routers
> > with large number of "cheap" L3 interfaces often derive their MAC
> > utilization designs from L2 switches where you do not automatically
> > assign a separate MAC address to every port because thats a cost factor,
> > and instead there is just a limited number of MAC addresses assigned to
> > the box (i think i remember '8' from some cisco products) and
> > once those are exhausted, additional L3 interfaces repeat the MAC
> > addresses. And of course if the link-local addresses are derived from
> > interfaces MAC addresses then we have the problem in question.
> >
> > Standard disclaimer:
> > Just because i am paranoid does not mean they are not after me.
> >
> > So, would love to hear that duplicate link-local IPv6 addresses are
> > not to be found anywhere in deployed  IPv6 networks and that i am
> > just paranoid ;-) Or else we know that we should take this into
> > consideration.
> >
> > Thanks
> >     Toerless
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops

-- 
---
tte@cs.fau.de


From nobody Fri Jul  7 09:09:36 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7BC12EB21 for ; Fri,  7 Jul 2017 09:09: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, 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 qgCHpBzawVCG for ; Fri,  7 Jul 2017 09:09:33 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 172361201FA for ; Fri,  7 Jul 2017 09:09:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BDBDE49; Fri,  7 Jul 2017 18:09:30 +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=1499443769; bh=enDsdVwJGMC/Xno/x4V uZgo6/N+Swx4SlGtRAR6BSxw=; b=a8OA41zFsJW45/Vi8O6N8u4WouwhgxxXJBZ 3NE5Zg8MaROxAhyozjjjvDz/n/97WBrNZ5B8nw8c7eBBF0dQISJ+uVuggUAoCOaB BhjcUftYmAx3sciI62BC6wZCumtVf2GxRfmmP/Zy3kibst61MMb2p8/U0qgd/mRj WZJtji74=
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 6GgdtyhPdsXZ; Fri,  7 Jul 2017 18:09:29 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:9300:615c:e41f:2538:1e7e] (unknown [IPv6:2a02:a213:a300:9300:615c:e41f:2538:1e7e]) (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 DD8B83C; Fri,  7 Jul 2017 18:09:28 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_C38B3092-F3A6-45FC-BDB4-AD6A7826C5E0"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 7 Jul 2017 18:09:24 +0200
In-Reply-To: <20170707152955.GA16808@faui40p.informatik.uni-erlangen.de>
Cc: Mark Smith , v6ops list 
To: Toerless Eckert 
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>  <20170707152955.GA16808@faui40p.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 16:09:35 -0000

--Apple-Mail=_C38B3092-F3A6-45FC-BDB4-AD6A7826C5E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

> - Q: fe80::1 - i assume this is manual config ? Wasn't even aware
>  whether manual config of LL was possible in all/most routers.
>  (but i can see how this may be attractive to operators whose
>   habits have been formed by too many decades with IPv4).

Also: if you use things like fe80:: then looking at your =
default gateway from RA will immediately show you if you accidentally =
connected to the wrong VLAN :)

Cheers,
Sander


--Apple-Mail=_C38B3092-F3A6-45FC-BDB4-AD6A7826C5E0
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-----

iQEcBAEBCAAGBQJZX7I0AAoJEKAtA7D+JBO5ytsIAJVZgi3BfZzRAwzKZpAvGpyR
iEWUErmlPzvjfNJ7M+stG7UD/mtjRXirG5yKfaCesbDjLQWOOsn2gvgykrnc/fiD
7WFFmPdkivjS2Fg7olkWlIsvyDoy4h+roC1SGoMY5cGyupVvRcvg9Mm0otwM6coS
xW1ieEAqB0690rt3eJGcgFLbUZ5UXuUmQmUyhcvZICfVmPezkBrc3TZyJRG2LKEG
ajsf4tsmuPHVgJnfyH/rq9fk0FkKuVUcJIcQQq5X9JAgRn57zOSrECMM1EXbPDfy
DKKK88bU3HosqddbAdMgsV1yvBSyDE+zkKu18dtrhJSdbk78xabicD/Ux2vgQz0=
=EtFH
-----END PGP SIGNATURE-----

--Apple-Mail=_C38B3092-F3A6-45FC-BDB4-AD6A7826C5E0--


From nobody Fri Jul  7 10:38:30 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC371317A0 for ; Fri,  7 Jul 2017 10:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoTYInNi1m75 for ; Fri,  7 Jul 2017 10:38:27 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3EC12700F for ; Fri,  7 Jul 2017 10:38:26 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CF1A841BF3 for ; Fri,  7 Jul 2017 19:38:23 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A73BA41B94; Fri,  7 Jul 2017 19:38:23 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 990EC73719; Fri,  7 Jul 2017 19:38:23 +0200 (CEST)
Date: Fri, 7 Jul 2017 19:38:23 +0200
From: Gert Doering 
To: Toerless Eckert 
Cc: Mark Smith , v6ops list 
Message-ID: <20170707173823.GJ45648@Space.Net>
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>  <20170707152955.GA16808@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170707152955.GA16808@faui40p.informatik.uni-erlangen.de>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 17:38:29 -0000

Hi,

On Fri, Jul 07, 2017 at 05:29:55PM +0200, Toerless Eckert wrote:
> - Q: fe80::1 - i assume this is manual config ? Wasn't even aware 
>   whether manual config of LL was possible in all/most routers.
>   (but i can see how this may be attractive to operators whose
>    habits have been formed by too many decades with IPv4).

All (real) routers I've seen so far can do it, and I wouldn't call
my habits "formed by too many decades with IPv4" :-)

It's more like "if you standardize on fe80::1, misconfiguration of the
default gateway address on the host side is a thing of the past" - and
no, we don't do RA/SLAAC, we do static v6 addresses, no privacy extention,
and static default routes.  With HSRP/VRRP for quick failover in case
one router goes down.

So, single-gateway setups have the router set to fe80::1, redundant-gateway
setups have the HSRP/VRRP address set to fe80::1

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

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


From nobody Fri Jul  7 15:40:51 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60441316EC for ; Fri,  7 Jul 2017 15:40: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 hUzDDA-4-6m8 for ; Fri,  7 Jul 2017 15:40:48 -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 3385D12EC46 for ; Fri,  7 Jul 2017 15:40:47 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id e7so23301891pfk.0 for ; Fri, 07 Jul 2017 15:40: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=CojeZExYbqlHsi/wIwPHLSHa+F4JqfdyFLqmuliXmdo=; b=fAMPz3pWBjwPtt51RdPhXUMuVFu6mRhHpluvY9U28dhnBtupmKrM+8YDtppUsLGM+Q WIEp+SMLXVybeBIFRCFcItG+4JaBnaiHLVCHJjg/ZQjubFjXkPCb8QyYBCB37PkrqYgj WYo6FS//PdNHiJVTL23GBVZZUBNCR1OgQGQGvWv+Cjiz1bqh5h70XFlS6FGVllZOgN5C PNsuX/52wFC3QvgS7Sj+5kArnfRlyW1o6o/j/C1Oev4kQtyPZjf69sUgXZ9MWMA2qjUM Apzv4vBu0ZmpzCy1tw8Sel07c8vTImCZ5Z8fKVPmdlMg16r191inP+0si54BcG8G7oax N6KQ==
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=CojeZExYbqlHsi/wIwPHLSHa+F4JqfdyFLqmuliXmdo=; b=Sxq4pmbDNEC1aQu1gF46HywEF+AY7zBLexVC9cTyRYI36W+DnLk+Lqm/S/3Cs+4DNY rSowe3c2Tj/m9sOUpnZ767f5aWllN0hNaudOYufTEM9qjl6bl2ZlaNAJsgX6tDxFtZ7F dK4q8P2otwcd3j+XuCRIltmA3RPY622i/tzWWOmppS/RsBRDi/DUbNBdp3cRkZ29PTxI kz8It6RQkxN+zgOnpBLy0VRJB5lQbz1fGKUbr3S4nuPIwiKCVzq3V6S9Z3/gA5DvKrkf YEVOXeHwyN3PB9O9hBgZP/CCJJq7vY36xzPcI+X0UlF7jVmyn8fr1wON/uUFxCFcG2jm PqaA==
X-Gm-Message-State: AIVw112B6lctZgPHae0IMYprB8h9GB45l45I8OVcUCMJrvwLXyj/+Mha YX4Vv2xIcX9Znf/l
X-Received: by 10.99.107.66 with SMTP id g63mr3551094pgc.277.1499467247313; Fri, 07 Jul 2017 15:40:47 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 8sm9177403pfs.23.2017.07.07.15.40.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 15:40:46 -0700 (PDT)
To: Gert Doering , Toerless Eckert 
Cc: v6ops@ietf.org
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de> <20170707084232.GS45648@Space.Net>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 8 Jul 2017 10:40:54 +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: <20170707084232.GS45648@Space.Net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 22:40:50 -0000

Gert,

Very interesting, but I have to ask a picky question to be sure 
I understand 100%.

For code running in the box *above* layer 3, are these really different
interfaces? In other words, are the complete addresses with zone IDs,
such as you would get from getsockname(), all different:
FE80::222:55FF:FE93:8480%eth0
FE80::222:55FF:FE93:8480%eth1  (or whatever Cisco uses as interface names)

Regards
   Brian

On 07/07/2017 20:42, Gert Doering wrote:
> Hi,
> 
> On Fri, Jul 07, 2017 at 01:03:47AM +0200, Toerless Eckert wrote:
>> I was told by Brian that RFC7217 is recommended, but recommendations are
>> one thing and reality can be another thing. If there are widely deployed
>> network devices that do have the same link local address across multiple
>> interfaces then it could take quite a while for this to get changed,
>> so it might be prudent for a protocol design NOT to expect that eg: RFC7217
>> is supported everywhere.
> 
> Checking one of our boxes, which was not exactly "cheap":
> 
> Cisco#sh ipv int | inc FE80
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
> [..]
>   IPv6 is enabled, link-local address is FE80::1 
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 
> [..]
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 [UNA]
>     FE80::5:73FF:FEA0:6 [OOD]
>   IPv6 is enabled, link-local address is FE80::222:55FF:FE93:8480 [UNA]
>     FE80::5:73FF:FEA0:6 [OOD]
> 
> ... so yes, it seems to use the same LLA on all L3 interfaces, unless
> configured otherwise...  (UNA and OOD seem to appear "if HSRPv2 is
> involved", but even then, the box picks the same LLA for all HSRPv2-
> enabled interfaces if the HSRPv2 group is the same)
> 
> 
> Checking on a much newer box with IOS XR and "router hardware", things
> look different, but still not sufficiently uniqe:
> 
> RP/0/RSP0/CPU0:Cisco#sh ipv6 int | inc fe80
> Fri Jul  7 10:39:55.203 MEDST
>   IPv6 is enabled, link-local address is fe80::d80:22ff:fe39:18cf 
>   IPv6 is enabled, link-local address is fe80::d80:22ff:fe39:18cf 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a00 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a01 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a02 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:5a02 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e8 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e9 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59e9 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
>   IPv6 is enabled, link-local address is fe80::d66d:50ff:fe6c:59fe 
>   IPv6 is enabled, link-local address is fe80::21a:6cff:fe9e:6529 
> 
> (this one is "there are dot1q subinterfaces involved, and all subifs
> have the same LLA as the parent interface" - which is unsurprising,
> when you think about it :-) - and I expect this part to be the same
> across most vendors that assign MAC-address derived LLA addresses)
> 
> Gert Doering
>         -- NetMaster
> 


From nobody Fri Jul  7 16:10:26 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E13F12EC14 for ; Fri,  7 Jul 2017 16:10: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, 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 4vUXnfPNqwPk for ; Fri,  7 Jul 2017 16:10:23 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 1FC66126DED for ; Fri,  7 Jul 2017 16:10:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7B0C949; Sat,  8 Jul 2017 01:10:19 +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=1499469015; bh=xqBUpV2p9OywuY2/C7j lDkx8OEe4I5HEnVeOO8MdsZQ=; b=A2oElK5RmyA302pGtO97UROVyZqBJ4VmlB2 5rnWAV9PaR/kqXGiiYSspHsW627Yo65Ut0EVmtcJYnQKI0K6LriS/ou9sLXd011e TKK5oSq2GvBg2DxIYT73QFXABQjrdT2KY9Dw87JvZuhPl5vwWnpQUltQhQa5z+ur GNJG7toQ=
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 alDpGk7n_mIm; Sat,  8 Jul 2017 01:10:15 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:9300:615c:e41f:2538:1e7e] (unknown [IPv6:2a02:a213:a300:9300:615c:e41f:2538:1e7e]) (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 AE8F83C; Sat,  8 Jul 2017 01:10:14 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_59FDD0D5-2371-4512-8F35-E586C76B4AB6"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 8 Jul 2017 01:10:16 +0200
In-Reply-To: 
Cc: =?utf-8?Q?Gert_D=C3=B6ring?= , Toerless Eckert , v6ops@ietf.org
To: Brian E Carpenter 
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de> <20170707084232.GS45648@Space.Net> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jul 2017 23:10:25 -0000

--Apple-Mail=_59FDD0D5-2371-4512-8F35-E586C76B4AB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Brian,

> Very interesting, but I have to ask a picky question to be sure
> I understand 100%.
>=20
> For code running in the box *above* layer 3, are these really =
different
> interfaces? In other words, are the complete addresses with zone IDs,
> such as you would get from getsockname(), all different:
> FE80::222:55FF:FE93:8480%eth0
> FE80::222:55FF:FE93:8480%eth1  (or whatever Cisco uses as interface =
names)

I have another example right here. With interface names:

TenGigabitEthernet1/6 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
TenGigabitEthernet1/13 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Loopback0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel2 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel5 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...
Port-channel6 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::7E0E:CEFF:FE02:AAC0
  ...

Loopback, TenGig, Port channels, all the same link-local address. Those =
are definitely separate interfaces connected to different devices having =
separate routes etc. All full layer-3 interfaces.

#ping FE80::7E0E:CEFF:FE02:AAC0%TenGigabitEthernet1/13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::7E0E:CEFF:FE02:AAC0, timeout is =
2 seconds:
Packet sent with a source address of =
FE80::7E0E:CEFF:FE02:AAC0%TenGigabitEthernet1/13
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =3D 1/1/1 ms

Cheers!
Sander


--Apple-Mail=_59FDD0D5-2371-4512-8F35-E586C76B4AB6
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-----

iQEcBAEBCAAGBQJZYBTYAAoJEKAtA7D+JBO55ZAIAIXgtMLHlHGYkS4ctpZ/doZW
ZOZaNpQa5q8+qwdMhJoUrTQxgPwrve+ZoCAqTh/KPIwJlhIlOanTrl9nCGcfiSzy
DLlOph2IDTl/Sma/R676+qX1UlmuKtiPN1SgFSynUKrgJWgY7CDdPicSXe7DJ4E3
gmHsvUFQpsjEMBhuWd5Ij5OV1sb3BpOeiEfnOJNtIdU73WhpwB8YYV+QfKvJmhtk
d/MBTD1byx46Xql+4mj31DwLuWqsjVfylHD0KOCZj/8SBJGJ7QwdkAD3h3fPs4GT
c4kAiL0CLDNwyc6pVh25tR+mCNTHtaxVzRQSYUK2WDRBVmTRtKlbT5sezGyGoJs=
=YgJp
-----END PGP SIGNATURE-----

--Apple-Mail=_59FDD0D5-2371-4512-8F35-E586C76B4AB6--


From nobody Sat Jul  8 12:34:53 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477CE129687 for ; Sat,  8 Jul 2017 12:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6-Gnzjp3_dO for ; Sat,  8 Jul 2017 12:34:42 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CD112EC4B for ; Sat,  8 Jul 2017 12:34:41 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D3D4841B97 for ; Sat,  8 Jul 2017 21:34:38 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id AA7F541B72; Sat,  8 Jul 2017 21:34:38 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 9C05175B40; Sat,  8 Jul 2017 21:34:38 +0200 (CEST)
Date: Sat, 8 Jul 2017 21:34:38 +0200
From: Gert Doering 
To: Brian E Carpenter 
Cc: Gert Doering , Toerless Eckert , v6ops@ietf.org
Message-ID: <20170708193438.GM45648@Space.Net>
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de> <20170707084232.GS45648@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mTZwSlL/nbp4OXbB"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 08 Jul 2017 19:34:44 -0000

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

Hi,

On Sat, Jul 08, 2017 at 10:40:54AM +1200, Brian E Carpenter wrote:
> Very interesting, but I have to ask a picky question to be sure=20
> I understand 100%.
>=20
> For code running in the box *above* layer 3, are these really different
> interfaces? In other words, are the complete addresses with zone IDs,
> such as you would get from getsockname(), all different:
> FE80::222:55FF:FE93:8480%eth0
> FE80::222:55FF:FE93:8480%eth1  (or whatever Cisco uses as interface names)

Yes.  These are "vlan 3", "vlan 570", etc. - that's the routed interface
tied to a given VLAN in the switch fabric (Cisco used to call them "SVI"
or "BVI" - bridge virtual interface - no idea how anyone else calls them).

In other words, from a routing protocol point of view, like OSPFv3,=20
these are all fully independent layer3 interfaces.  The fact that they
are tied to the switch fabric is not visible further up.

(The other example also involves VLANs, but as dot1q subinterfaces on
a router that is not really a switch inside - so that would be akin
to Linux' %eth0.3, %eth0.75, etc.)

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

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

--mTZwSlL/nbp4OXbB
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAllhM8sACgkQ31bAZeTO
f8XpBg//ehGmDwC35Cn02bTurHxfQ+zn4qjDM3VfI8mcZuyYid/BlOol/bLZGKqE
mGow2NWV0SYztm+lVeyfFmKl5nPaysIYxAtQpfyGn/dZPblrpwSTxIZokTTed9Za
wJ+8I7af5MEiD9HdvIcA3T36PA5K+n9oPSl6szofD/FdCzuMq9L5luGh8JiyVLo6
bcXKE3L7GJN+TUkHrUFjod+Of9ynO0cALRe0qAwA7wSNk/w3NkcRXE+LK+Bc0iGk
0WKEeubnTyF306+6BiSA0M5c8LRhRLFRrB0r8LYP+qEqbMBggXNv9mJ9Z9VF1+K8
bg3T+1KkqB+xn6W9OwaEhg9XNzac44scvrtY3l3Az1MXMtpGkTW1fmBeRii29Dnr
v0nCp4RjSao6Dr4XTxyg8GE16pVbl7266fmcLIt0Ui5L38IG2/W9P2zgggZgIMcC
oJDWu/0fVAKhlfRSopTJsa0XkbxhKnC7r9MAxT7Ith516sEHl6axHECaEWfmuPfY
4ARohwlVk5Bzgrzjjqe82w+gmfpGXDrFziIB3dB5p3Ik4EfMYlwr1QufUsRTemoV
QPDY4bsqrdB0TsRpqnL9vx2QxZo9zdEQfaHYioVrrTSfZkErI5mFmU+na1e61c6d
Ab4DSW4oDT2QdMXeudpEsgFTx/YabqUhNhoZVcuI0dLOEYK1uG0=
=7Dkx
-----END PGP SIGNATURE-----

--mTZwSlL/nbp4OXbB--


From nobody Sun Jul  9 09:45:38 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30B012EAF7 for ; Sun,  9 Jul 2017 09:45:36 -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_HELO_PASS=-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 S2NG-dRlsgDb for ; Sun,  9 Jul 2017 09:45:35 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBDA129B19 for ; Sun,  9 Jul 2017 09:45:35 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v69GTMRQ061372; Sun, 9 Jul 2017 18:29:22 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201707091629.v69GTMRQ061372@givry.fdupont.fr>
From: Francis Dupont 
To: Toerless Eckert 
cc: v6ops@ietf.org
In-reply-to: Your message of Fri, 07 Jul 2017 01:03:47 +0200. <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
Date: Sun, 09 Jul 2017 18:29:22 +0200
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 09 Jul 2017 16:45:37 -0000

 In your previous mail you wrote:

>  For a protocol design, we are wondering what the current state of the
>  art is wrt to IPv6 link local addresses potentially being the same
>  on multiple interfaces of a network device like a router.

=> in fact the IEEE spec were loose enough to have Sun to intepret them
as to give a MAC address per box instead of a MAC address per NIC
(i.e., device = box vs device = Network Interface Card).
So the problem is very far to be new and the answer is you can get
the same link-local address on different links. Of course this led
to some bugs but this was a long time ago so they were repaired
and ready to come back (:-)...

>  I was told by Brian that RFC7217 is recommended, but recommendations are
>  one thing and reality can be another thing. If there are widely deployed
>  network devices that do have the same link local address across multiple
>  interfaces then it could take quite a while for this to get changed,
>  so it might be prudent for a protocol design NOT to expect that eg: RFC7217
>  is supported everywhere.

=> the purpose of RFC 7217 was very different but of course if the MAC
address is not embedded into the link-local address this solves
any issue with multiple interfaces using the same MAC address...

>  Standard disclaimer:
>  Just because i am paranoid does not mean they are not after me.

=> no, the oppostunity of new bugs or old bugs to come back is too high
to not justify some kind of paranoia.

>  So, would love to hear that duplicate link-local IPv6 addresses are
>  not to be found anywhere in deployed  IPv6 networks and that i am
>  just paranoid ;-) Or else we know that we should take this into
>  consideration.

=> in fact the first time someone reported a link-local IPv6
address collision it came from a blind copy of a router config.
Unfortunately the fact routers derived link-local addresses from
MAC addresses did not save in that particular case because they
were DEC routers with the standard DECnet setup (*).

Regards

Francis.Dupont@fdupont.fr

PS (*): (for young people) DECnet derived the MAC address from
the DECnet one (i.e. the exact opposite of (early?) IPv6).


From nobody Sun Jul  9 09:52:10 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0612EC01 for ; Sun,  9 Jul 2017 09:52:09 -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_HELO_PASS=-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 wF8gn8MmOXq1 for ; Sun,  9 Jul 2017 09:52:08 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06140129B5B for ; Sun,  9 Jul 2017 09:52:07 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v69GZtt8061813; Sun, 9 Jul 2017 18:35:55 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201707091635.v69GZtt8061813@givry.fdupont.fr>
From: Francis Dupont 
To: Brian E Carpenter 
cc: Mark Smith , Toerless Eckert , v6ops list 
In-reply-to: Your message of Fri, 07 Jul 2017 14:13:09 +1200. 
Date: Sun, 09 Jul 2017 18:35:55 +0200
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 09 Jul 2017 16:52:09 -0000

 In your previous mail you wrote:

>  > An Internet search for "fe80::1" shows that this is also a common
>  > value being used for router interfaces.
>  
>  Which makes my head hurt, since it's a guaranteed failure if two
>  such routers are on the same subnet.

=> if you want to give the same address to all routers I recommend
the fe80:: address. At least it is very officially an anycast address!

Regards

Francis.Dupont@fdupont.fr

PS: and of course it won't work as you expect (I tried a very long
time ago: a fine idea on and only on the paper :-).


From nobody Mon Jul 10 03:11:43 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE659131687 for ; Mon, 10 Jul 2017 03:11:41 -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 47Ki3kwYNgUO for ; Mon, 10 Jul 2017 03:11:40 -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 3F59B129461 for ; Mon, 10 Jul 2017 03:11:39 -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 v6AABbj9044731 for ; Mon, 10 Jul 2017 12:11:37 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D6087204328 for ; Mon, 10 Jul 2017 12:11:37 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C3CC32042FC for ; Mon, 10 Jul 2017 12:11:37 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6AABbnK022817 for ; Mon, 10 Jul 2017 12:11:37 +0200
To: "v6ops@ietf.org" 
From: Alexandre Petrescu 
Message-ID: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
Date: Mon, 10 Jul 2017 12:11:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 10:11:42 -0000

Hi,

The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
> The 3GPP network allocates each default bearer a unique /64 prefix, 
> and uses layer-2 signaling to suggest to the UE an Interface 
> Identifier that is guaranteed not to conflict with the gateway's 
> Interface Identifier.  The UE must configure its link-local address 
> using this Interface Identifier.

I disagree that the UE must configure its LL using this IID.  Where is
this requirement from?

The UE should be allowed to form an IID at its will, if so it wishes.

This has consequences on privacy, and may impact interoperability when
DHCPv6-PD is used later in the process.

Also, this being an INFORMATIONAL document, in no case a party
implementing it could impose it on some other party.

Alex


From nobody Mon Jul 10 03:49:13 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E80129AA0 for ; Mon, 10 Jul 2017 03:49:11 -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, 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 HweWMu3Bobra for ; Mon, 10 Jul 2017 03:49:09 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428E8126D85 for ; Mon, 10 Jul 2017 03:49:09 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id x125so33988740ywa.0 for ; Mon, 10 Jul 2017 03:49:09 -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=1YRngpAMZzQW1EcK14Fo5g83ADAMTSCLJiq7WorbImA=; b=LiJ2WDCmfxsmaCZvneHNsj/yf3A4IyVgUkbFATUM7+TAXpttADWOeGTgYMwc5WzB/0 W1F8S8RNUw9Cb9tUQ17NcdnPOkemi7hXuxn3nJkcQ1RvEg6/p2b6AM/9WwFyid9HeE8u Zvf5qjBQ5n5j2efdKDdnQwvIXFvo0BCt96De0zdhKKZPEWVi+oCix/p5xfWU0tkij3bD yQJemFojpub6XoLo/CfWR0uf/z7Mt8rQMRV785Ciw3/8cT+R5IJh2c8kScLB3m42VfSJ NHmks2DEiDUGMHF5r9iHyd7/13VEkilT8uXZoOObWOwDQd4rebqdYS/ChsijLA76zoe8 jGXA==
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=1YRngpAMZzQW1EcK14Fo5g83ADAMTSCLJiq7WorbImA=; b=RoQwh26yKfH99EZT/zQBNdKhndT7QMUg6T4cwQ4raR/xZk9nsm73+urGQT2L/atb8I RT40xdE0HplJ+T2/9IjKuL2A3A9WHyzUZcRk8P+oRLisUJ8naGoDMbhcWWFtsRPni12l ma/1iKwwocW1DiBtSiFP9TfbRvuctFrmEZ4QeoU7QOF4rRbvgBUE3R65ZnA2YFfRH/+c K0sGtjTdJZAsjTZ2IN6i/G0U/9C8O95E67pTt644y8B/AfIH5Pm4GuRCfFIJNO24A8Kw 6D5GicZpzU6uO0tJ+1V/wQUHR5Ctou2kpRK0dmcbsLiS0gwGsf2I8e8MA5uOufZXHbBF n9Qw==
X-Gm-Message-State: AIVw111sd9T2VJ3x8rY/QatQqpmEzFGithC9l2eI80m59fYnt4OKjx6C yBw5o+huV/eNwBF7T5WF8MUT+QRe/IY3Zdc=
X-Received: by 10.129.50.140 with SMTP id y134mr99700ywy.312.1499683748310; Mon, 10 Jul 2017 03:49:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.217.69 with HTTP; Mon, 10 Jul 2017 03:48:47 -0700 (PDT)
In-Reply-To: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
From: Erik Kline 
Date: Mon, 10 Jul 2017 19:48:47 +0900
Message-ID: 
To: Alexandre Petrescu 
Cc: "v6ops@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140932a1d2f710553f4550e"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 10:49:11 -0000

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

It can form other IIDs, but (a) it uses this for link-local and (b)
it's the default used for its GUA.  But sending traffic from other
IIDs is perfectly fine (464xlat on Android does this in fact).

I'm not yet convinced there's much to worry about here.

On 10 July 2017 at 19:11, Alexandre Petrescu
 wrote:
> Hi,
>
> The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
>>
>> The 3GPP network allocates each default bearer a unique /64 prefix, and
>> uses layer-2 signaling to suggest to the UE an Interface Identifier that is
>> guaranteed not to conflict with the gateway's Interface Identifier.  The UE
>> must configure its link-local address using this Interface Identifier.
>
>
> I disagree that the UE must configure its LL using this IID.  Where is
> this requirement from?
>
> The UE should be allowed to form an IID at its will, if so it wishes.
>
> This has consequences on privacy, and may impact interoperability when
> DHCPv6-PD is used later in the process.
>
> Also, this being an INFORMATIONAL document, in no case a party
> implementing it could impose it on some other party.
>
> Alex
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--001a1140932a1d2f710553f4550e
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgPmEUf3WLa5TKkbhdRRLBArA0ixJLF0F3
HAIHQV+IWeswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzEw
MTA0OTA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBANEgIDStfaBLX92geyGNHUmOFOp+qK+pymmKkQAOt5oFkH2m3Nju
XqEjsyPSlzsEkkEKtO9Z/AZtds+eqXoimgH97iYqup0dznbiWbgMkgHpO+niNepfTc5kwm1Zxw0p
0IehNJgzfb/jlNpkqlB7zOdoX7VQuYl0N3BwaF3ebsc/n5S1CwrKBj3TgYpf9cZK2r0+G7E3trp0
aVdAIB5QV0TfhnQxHVPbEpkn3mMvzJIae4QpC54EV9G1yxBInem3TsPHpAecL79xHGjd8snBpeEI
9KE7rpnb0vYFstWEyjCYDaTgwfs3evKpluMaw1l09zEmM+jjFKr5Mak2MhRrv7c=
--001a1140932a1d2f710553f4550e--


From nobody Mon Jul 10 04:14:44 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCEF1242F7 for ; Mon, 10 Jul 2017 04:14:42 -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 pOtwOTysjQkH for ; Mon, 10 Jul 2017 04:14:40 -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 BB985128BC8 for ; Mon, 10 Jul 2017 04:14: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 v6ABEaSq128589; Mon, 10 Jul 2017 13:14:36 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B518E2043D3; Mon, 10 Jul 2017 13:14: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 A7CA92041C2; Mon, 10 Jul 2017 13:14:36 +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 v6ABEaO9027028; Mon, 10 Jul 2017 13:14:36 +0200
To: Erik Kline 
Cc: "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <58673f9a-b135-f8a4-0ceb-97d939e4c2bf@gmail.com>
Date: Mon, 10 Jul 2017 13:14:36 +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: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 11:14:42 -0000

Le 10/07/2017 à 12:48, Erik Kline a écrit :
> It can form other IIDs,

The RFC does not say it can.

> but (a) it uses this for link-local

It is an alternative, not a mandate.

RFC5072 "IPv6 over PPP" makes it clear that the IID matter is a peer to 
peer negotiation, and that the UE proposes it first.

> and (b) it's the default used for its GUA.

Should not be the default.  Should be an alternative.

Defaulting the operator-provided IID in a GUA may contradict
Recent Stds Track RFCs like RFC8064 "Recomm'n on stable IIDs".

> But sending traffic from other IIDs is perfectly fine

I agree.

> (464xlat on Android does this in fact).

It's good to know.

Also, other applications on HTTP with IIDs generated by the UE are also 
accepted by the operator.

> I'm not yet convinced there's much to worry about here.

There could be.

There is an operator that may condition acceptance of DHCP Solicit, and 
NA, only if issued from what that operator generated as IID.

My oppinion is that it should accept the DHCP Solicit and NA coming from 
an address formed from an IID generated by the UE as well.

Otherwise there could be some privacy concerns.

Alex

> On 10 July 2017 at 19:11, Alexandre Petrescu 
>  wrote:
>> Hi,
>> 
>> The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
>>> 
>>> The 3GPP network allocates each default bearer a unique /64 
>>> prefix, and uses layer-2 signaling to suggest to the UE an 
>>> Interface Identifier that is guaranteed not to conflict with the 
>>> gateway's Interface Identifier.  The UE must configure its 
>>> link-local address using this Interface Identifier.
>> 
>> 
>> I disagree that the UE must configure its LL using this IID. Where 
>> is this requirement from?
>> 
>> The UE should be allowed to form an IID at its will, if so it 
>> wishes.
>> 
>> This has consequences on privacy, and may impact interoperability 
>> when DHCPv6-PD is used later in the process.
>> 
>> Also, this being an INFORMATIONAL document, in no case a party 
>> implementing it could impose it on some other party.
>> 
>> Alex
>> 
>> _______________________________________________ v6ops mailing list
>>  v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Jul 10 05:06:01 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415B31316F2 for ; Mon, 10 Jul 2017 05:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvMfHlGZ5T6R for ; Mon, 10 Jul 2017 05:05:59 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CA71316DA for ; Mon, 10 Jul 2017 05:05:58 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id r126so45941854vkg.0 for ; Mon, 10 Jul 2017 05:05:58 -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=tMBQFBSQYVY4JRLVeaXiD+q0S0Ji9Rq4+R80UR4WWe4=; b=AcdeBoARJFCVIFVXCjFZhWzUvH8OeaySt11mPgdiOGdWixg9BGFDFsYsBX1uXLgvgG jHs1wkoi+jd5FvNFEGGiu09vrMRb7JvpKbREIkXR2b1heKJiVPqjG9vZ0hwn2S4o8SVN fNmhzOmao2pANmS+b8tDaM2zxGwt5M4VN4eiMs0unA+KtVuNtts5Htjr051w4ThfBCQU dD0vugibdGgLF/dJDNEIM+44YAZzqbr3tJBqvYwkJJ5MIJRe1EXpBaR2boW/O2Q49WZ/ 4Kmt2Kbut7e2/Ad7PAHYd/XmFKtiJS9qI8jMP6N7Xbe4IwApR3Lh/cM5uKqI4WbI27KA y5WA==
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=tMBQFBSQYVY4JRLVeaXiD+q0S0Ji9Rq4+R80UR4WWe4=; b=Ugn4D2ZAycFcUn9xIRHk7R6SZjrQXmqxhoXpfK7C6sFdOsDtaiXQIw9rB7GtrLvSOy U1XTltJ6Rq7d3cMcedNICuo2RGYSf/h6n8Ig7TPJTDV1aR32TLtPsGlvoAB4tPcI9Ey3 1hnG+W/PFpR4Do+4pN8+LcMVqzg41dJEMDPc4GiIhd4CQw+Xte7IeXmk3QsFx2qWai8F wqnZBr31PoJZmQTaF/2+8Vjo349c/3hzeF3tLsYjPBDeSpKd/HDrvAl5YpHusLsZ0N2P 1R+NvY8qcx9EakEf1L9v+O/av2MT4oajgbm2PK6MiaA1mJptpmIhTatzhodX4kMrnF/m 8YWQ==
X-Gm-Message-State: AIVw110jpd0eD+yDSDmY3wpwW1BGHZbhKrKBzPwXDzaP8C0L50riagjj 9samIgfblIa2xjqXZ52VU8pGff3u+g==
X-Received: by 10.31.180.80 with SMTP id d77mr6283240vkf.110.1499688357904; Mon, 10 Jul 2017 05:05:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.81.100 with HTTP; Mon, 10 Jul 2017 05:05:27 -0700 (PDT)
In-Reply-To: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
From: Mark Smith 
Date: Mon, 10 Jul 2017 22:05:27 +1000
Message-ID: 
To: Alexandre Petrescu 
Cc: "v6ops@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 12:06:00 -0000

On 10 July 2017 at 20:11, Alexandre Petrescu
 wrote:
> Hi,
>
> The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
>>
>> The 3GPP network allocates each default bearer a unique /64 prefix, and
>> uses layer-2 signaling to suggest to the UE an Interface Identifier that is
>> guaranteed not to conflict with the gateway's Interface Identifier.  The UE
>> must configure its link-local address using this Interface Identifier.
>
>
> I disagree that the UE must configure its LL using this IID.  Where is
> this requirement from?
>
> The UE should be allowed to form an IID at its will, if so it wishes.
>
> This has consequences on privacy, and may impact interoperability when
> DHCPv6-PD is used later in the process.
>
> Also, this being an INFORMATIONAL document, in no case a party
> implementing it could impose it on some other party.
>

I think the reason why it is INFORMATIONAL is that this is not an IETF
document on how to do IPv6, rather, it is the 3GPPs specification on
how to do IPv6 on their devices.

I think the IETF and the 3GPP's device models are different.

The IETF considers hosts and links to be separate things, so
supporting a new link type means no more than an IPv6-over-link RFC
that provides the required functionality to run IPv6 using generic
next layer up mechanisms. In the IETF model, there would be an
IPv6-over-3G RFC that resembled the IPv6 over PPP, IPv6 over Ethernet
etc. RFCs. After that, standard IPv6 mechanisms would be used to
bootstrap over the 3G link e.g., RAs, DHCPv6-PD etc.

3GPP seem to conflate hosts and links, and seem to be whole of device
generation or release oriented, rather than being piecemeal and
evolving feature and negotiated capability oriented that the IETF are.
As you've found they're much more prescriptive about device
capabilities and behaviours that occur higher in the stack than just
what is necessary to get IPv6 over the 3G link running.

The 3GPP model creates constraints that then have to be worked around
e.g., RFC7278, "Extending an IPv6 /64 Prefix from a Third Generation
Partnership Project (3GPP) Mobile Interface to a LAN Link".


Regards,
Mark.


From nobody Mon Jul 10 05:49:45 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5E212741D for ; Mon, 10 Jul 2017 05:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vI0cv7G95Ijn for ; Mon, 10 Jul 2017 05:49:41 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EBD120724 for ; Mon, 10 Jul 2017 05:49:41 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 1C4401C3BAB; Mon, 10 Jul 2017 14:49:40 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id F21FD40086; Mon, 10 Jul 2017 14:49:39 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 14:49:39 +0200
From: 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
Thread-Index: AQHS+WT3otBN7zfZMk2dZFSkARCJuqJNAJ/A
Date: Mon, 10 Jul 2017 12:49:39 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
In-Reply-To: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 12:49:43 -0000

Hi Alex,=20

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandre
> Petrescu
> Envoy=E9=A0: lundi 10 juillet 2017 12:12
> =C0=A0: v6ops@ietf.org
> Objet=A0: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>=20
> Hi,
>=20
> The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
> > The 3GPP network allocates each default bearer a unique /64 prefix,
> > and uses layer-2 signaling to suggest to the UE an Interface
> > Identifier that is guaranteed not to conflict with the gateway's
> > Interface Identifier.  The UE must configure its link-local address
> > using this Interface Identifier.
>=20
> I disagree that the UE must configure its LL using this IID.  Where is
> this requirement from?
>=20

[Med] This is part of 3GPP spec. The GGSN/PGW selects an IID to be used whe=
n forming the link-local address. The goal is called in 3GPP specs :

"in order to avoid any conflict between the link-local address of the MS an=
d that of the GGSN, the Interface-Identifier used by the MS to build its li=
nk-local address shall be assigned by the GGSN. The GGSN ensures the unique=
ness of this interface-identifier. The MT shall then enforce the use of thi=
s Interface-Identifier by the TE."

BTW, this was inspired by https://tools.ietf.org/html/rfc5072#section-5:=20

   As long as the interface identifier is negotiated in the IPV6CP phase
   of the PPP connection setup, it is redundant to perform duplicate
   address detection (DAD) as a part of the IPv6 Stateless Address
   Autoconfiguration protocol [3] on the IPv6 link-local address
   generated by the PPP peer.


> The UE should be allowed to form an IID at its will, if so it wishes.

[Med] It is allowed to do so...for non link-local addresses.=20

>=20
> This has consequences on privacy, and may impact interoperability when
> DHCPv6-PD is used later in the process.

[Med] I don't follow you here. There is no privacy concern out there. The I=
ID used when forming a global IPv6 address will be selected by the terminal=
; no assumption is made about those bits.=20

>=20
> Also, this being an INFORMATIONAL document, in no case a party
> implementing it could impose it on some other party.
>=20
> Alex
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Jul 10 06:51:00 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643A131789 for ; Mon, 10 Jul 2017 06:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 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] 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 kIrvC9USsvW0 for ; Mon, 10 Jul 2017 06:50:58 -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 1656513178D for ; Mon, 10 Jul 2017 06:50:56 -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 v6ADot5q025041; Mon, 10 Jul 2017 15:50:55 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4ADDF204576; Mon, 10 Jul 2017 15:50:55 +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 3DBBF20159C; Mon, 10 Jul 2017 15:50:55 +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 v6ADosR5001318; Mon, 10 Jul 2017 15:50:55 +0200
To: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: 
Date: Mon, 10 Jul 2017 15:50:54 +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: <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 13:51:00 -0000

Med,

I think this is an issue _if_ the operator filters all incoming messages 
generated by the UE whose LL includes an IID different than what the 
network may have suggested to it.

If there is no such filter, then no need to debate specs.

Le 10/07/2017 à 14:49, mohamed.boucadair@orange.com a écrit :
> Hi Alex,
> 
> Please see inline.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : v6ops 
>> [mailto:v6ops-bounces@ietf.org] De la part de Alexandre Petrescu 
>> Envoyé : lundi 10 juillet 2017 12:12 À : v6ops@ietf.org Objet : 
>> [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>> 
>> Hi,
>> 
>> The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
>>> The 3GPP network allocates each default bearer a unique /64 
>>> prefix, and uses layer-2 signaling to suggest to the UE an 
>>> Interface Identifier that is guaranteed not to conflict with the 
>>> gateway's Interface Identifier.  The UE must configure its 
>>> link-local address using this Interface Identifier.
>> 
>> I disagree that the UE must configure its LL using this IID. Where 
>> is this requirement from?
>> 
> 
> [Med] This is part of 3GPP spec. The GGSN/PGW selects an IID to be 
> used when forming the link-local address. The goal is called in 3GPP 
> specs :
> 
> "in order to avoid any conflict between the link-local address of
> the MS and that of the GGSN,

That conflict is avoided by DAD.

The potential of conflict is very low anyways.

The 3GPP specs should be updated to allow the UE to form the IID as it
pleases, and use maybe DAD, or maybe PPP-style negotiation.

> the Interface-Identifier used by the MS to build its link-local 
> address shall be assigned by the GGSN. The GGSN ensures the 
> uniqueness of this interface-identifier. The MT shall then enforce 
> the use of this Interface-Identifier by the TE."
> 
> BTW, this was inspired by 
> https://tools.ietf.org/html/rfc5072#section-5:
> 
> As long as the interface identifier is negotiated in the IPV6CP phase
> of the PPP connection setup,

YEs, it is called "negotiation", it means that the UE can equally well
impose its IID.

> it is redundant to perform duplicate address detection (DAD) as a
> part of the IPv6 Stateless Address Autoconfiguration protocol [3] on
> the IPv6 link-local address generated by the PPP peer.

Well, I wonder what kind of redundancy could seem offensive?
There is already a lot NS/NA messaging for the multiple "privacy" GUAs, 
so one more NS/NA would not hurt.

>> The UE should be allowed to form an IID at its will, if so it 
>> wishes.
> 
> [Med] It is allowed to do so...for non link-local addresses.

Should be so for all, be them LLs or GUAs.

>> This has consequences on privacy, and may impact interoperability 
>> when DHCPv6-PD is used later in the process.
> 
> [Med] I don't follow you here. There is no privacy concern out
> there. The IID used when forming a global IPv6 address will be
> selected by the terminal; no assumption is made about those bits.

There is a privacy concern: if the operator enforces the UE to always
use the network-assigned IID then that UE is trackable.

Alex

> 
>> 
>> Also, this being an INFORMATIONAL document, in no case a party 
>> implementing it could impose it on some other party.
>> 
>> Alex
>> 
>> _______________________________________________ v6ops mailing list
>>  v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Mon Jul 10 07:16:21 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15812F3D6 for ; Mon, 10 Jul 2017 07:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level: 
X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 aWzjbfTJ0KwE for ; Mon, 10 Jul 2017 07:16:18 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661CC13174D for ; Mon, 10 Jul 2017 07:16:18 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id C6AA94053D; Mon, 10 Jul 2017 16:16:16 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id A314F1A00A4; Mon, 10 Jul 2017 16:16:16 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 16:16:16 +0200
From: 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
Thread-Index: AQHS+YOPPey6jPfoA0yB3PY8fHlvUKJNGKhg
Date: Mon, 10 Jul 2017 14:16:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 14:16:19 -0000

QWxleCwgDQoNCkknbSBmb2N1c2luZyBvbiB0aGlzIHBhcnQgb2YgeW91ciBhbnN3ZXIuIA0KDQpQ
bGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29y
aWdpbmUtLS0tLQ0KPiBEZcKgOiBBbGV4YW5kcmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUu
cGV0cmVzY3VAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDEwIGp1aWxsZXQgMjAxNyAx
NTo1MQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyB2Nm9wc0BpZXRmLm9yZw0K
PiBPYmpldMKgOiBSZTogW3Y2b3BzXSBSRkM2NDU5ICJJUHY2IGluIDNHUFAiIC0gdGhlIElJRCBp
biB0aGUgTEwgYWRkcmVzcw0KPiANCj4gTWVkLA0KPiANCj4gDQo+ID4+IFRoaXMgaGFzIGNvbnNl
cXVlbmNlcyBvbiBwcml2YWN5LCBhbmQgbWF5IGltcGFjdCBpbnRlcm9wZXJhYmlsaXR5DQo+ID4+
IHdoZW4gREhDUHY2LVBEIGlzIHVzZWQgbGF0ZXIgaW4gdGhlIHByb2Nlc3MuDQo+ID4NCj4gPiBb
TWVkXSBJIGRvbid0IGZvbGxvdyB5b3UgaGVyZS4gVGhlcmUgaXMgbm8gcHJpdmFjeSBjb25jZXJu
IG91dA0KPiA+IHRoZXJlLiBUaGUgSUlEIHVzZWQgd2hlbiBmb3JtaW5nIGEgZ2xvYmFsIElQdjYg
YWRkcmVzcyB3aWxsIGJlDQo+ID4gc2VsZWN0ZWQgYnkgdGhlIHRlcm1pbmFsOyBubyBhc3N1bXB0
aW9uIGlzIG1hZGUgYWJvdXQgdGhvc2UgYml0cy4NCj4gDQo+IFRoZXJlIGlzIGEgcHJpdmFjeSBj
b25jZXJuOiBpZiB0aGUgb3BlcmF0b3IgZW5mb3JjZXMgdGhlIFVFIHRvIGFsd2F5cw0KPiB1c2Ug
dGhlIG5ldHdvcmstYXNzaWduZWQgSUlEIHRoZW4gdGhhdCBVRSBpcyB0cmFja2FibGUuDQo+IA0K
DQpbTWVkXSBJJ20gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSAidHJhY2thYmxlIiBpbiB0aGlz
IGNvbnRleHQuIElmIHlvdSBtZWFuIHRoYXQgImEgVUUgY2FuIGJlIGlkZW50aWZpZWQgYnkgdGhl
IG5ldHdvcmsiLCB0aGVuIGFuIFVFIGlzIGFsd2F5cyBpZGVudGlmaWVkIGJ5IHRoZSBuZXR3b3Jr
IGl0IGNvbm5lY3RzIHRvISBBdCB0aGUgSVAgbGV2ZWwsIGFuIFVFIGlzIGlkZW50aWZpZWQgYnkg
dGhlIGJpdHMgb2YgdGhlIElQdjYgcHJlZml4LCBub3QgSUlEIGJpdHMuIEZ1cnRoZXIsIGEgbmV0
d29yayBkb2VzIG5vdCBuZWVkIElQLXJlbGF0ZWQgaW5mb3JtYXRpb24gdG8gaWRlbnRpZnkgYW4g
VUUuIA0KDQpJIHN0aWxsIGRvbid0IHNlZSBhbnkgcHJpdmFjeSBjb25jZXJuIGluIHN1cHBseWlu
ZyBhbiBJSUQgdG8gYW4gVUUgdG8gYmUgdXNlZCBmb3IgZm9ybWluZyBpdHMgbGluay1sb2NhbCBh
ZGRyZXNzLiANCg0KDQoNCg==


From nobody Mon Jul 10 07:46:07 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA16124B0A for ; Mon, 10 Jul 2017 07:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 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] 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 RZoKqzhWOASQ for ; Mon, 10 Jul 2017 07:46:04 -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 6D0091317B1 for ; Mon, 10 Jul 2017 07:45:54 -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 v6AEjqdq048778; Mon, 10 Jul 2017 16:45:52 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5561D20470D; Mon, 10 Jul 2017 16:45:52 +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 4841C2046F9; Mon, 10 Jul 2017 16:45:52 +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 v6AEjpLb009269; Mon, 10 Jul 2017 16:45:52 +0200
To: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com>
Date: Mon, 10 Jul 2017 16:45:51 +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: <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 14:46:06 -0000

Le 10/07/2017 à 16:16, mohamed.boucadair@orange.com a écrit :
> Alex,
> 
> I'm focusing on this part of your answer.
> 
> Please see inline.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : Alexandre Petrescu 
>> [mailto:alexandre.petrescu@gmail.com] Envoyé : lundi 10 juillet 
>> 2017 15:51 À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org Objet : 
>> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>> 
>> Med,
>> 
>> 
>>>> This has consequences on privacy, and may impact 
>>>> interoperability when DHCPv6-PD is used later in the process.
>>> 
>>> [Med] I don't follow you here. There is no privacy concern out 
>>> there. The IID used when forming a global IPv6 address will be 
>>> selected by the terminal; no assumption is made about those 
>>> bits.
>> 
>> There is a privacy concern: if the operator enforces the UE to 
>> always use the network-assigned IID then that UE is trackable.
>> 
> 
> [Med] I'm not sure what you mean by "trackable" in this context. If 
> you mean that "a UE can be identified by the network", then an UE is 
> always identified by the network it connects to!

YEs, and I thought that is a device-specific identifier like the IMEI,
not the link-local address.

> At the IP level, an UE is identified by the bits of the IPv6 prefix,
>  not IID bits.

Well - by the IP address.

> Further, a network does not need IP-related information to identify 
> an UE.

I agree, so why does it want to impose an IID to the UE?

> I still don't see any privacy concern in supplying an IID to an UE
> to be used for forming its link-local address.

Err...

It's because the supplied IID is very much like an IEEE MAC 48bit
address.  It is guaranteed unique, so it can also be used to track.

Why do you think it can not be used to track?

Alex

> 
> 
> 


From nobody Mon Jul 10 08:07:52 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE511317B6 for ; Mon, 10 Jul 2017 08:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jqAUDuADL05k for ; Mon, 10 Jul 2017 08:07:50 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7594131535 for ; Mon, 10 Jul 2017 08:07:49 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id AE8F4120FAD; Mon, 10 Jul 2017 16:58:23 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 93A3A160097; Mon, 10 Jul 2017 16:58:23 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 16:58:23 +0200
From: 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
Thread-Index: AQHS+Ys8478LJa2HdUu4Hc6zAuAbyKJNJSLw
Date: Mon, 10 Jul 2017 14:58:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com>
In-Reply-To: <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 15:07:51 -0000

UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz
YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRvOmFs
ZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dDQo+IEVudm95w6nCoDogbHVuZGkgMTAganVpbGxl
dCAyMDE3IDE2OjQ2DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IHY2b3BzQGll
dGYub3JnDQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIFJGQzY0NTkgIklQdjYgaW4gM0dQUCIgLSB0
aGUgSUlEIGluIHRoZSBMTCBhZGRyZXNzDQo+IA0KPiANCj4gDQo+IExlIDEwLzA3LzIwMTcgw6Ag
MTY6MTYsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gYSDDqWNyaXQgOg0KPiA+IEFsZXgs
DQo+ID4NCj4gPiBJJ20gZm9jdXNpbmcgb24gdGhpcyBwYXJ0IG9mIHlvdXIgYW5zd2VyLg0KPiA+
DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBDaGVlcnMsIE1lZA0KPiA+DQo+ID4+
IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZSA6IEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA+
PiBbbWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dIEVudm95w6kgOiBsdW5kaSAx
MCBqdWlsbGV0DQo+ID4+IDIwMTcgMTU6NTEgw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xO
OyB2Nm9wc0BpZXRmLm9yZyBPYmpldCA6DQo+ID4+IFJlOiBbdjZvcHNdIFJGQzY0NTkgIklQdjYg
aW4gM0dQUCIgLSB0aGUgSUlEIGluIHRoZSBMTCBhZGRyZXNzDQo+ID4+DQo+ID4+IE1lZCwNCj4g
Pj4NCj4gPj4NCj4gPj4+PiBUaGlzIGhhcyBjb25zZXF1ZW5jZXMgb24gcHJpdmFjeSwgYW5kIG1h
eSBpbXBhY3QNCj4gPj4+PiBpbnRlcm9wZXJhYmlsaXR5IHdoZW4gREhDUHY2LVBEIGlzIHVzZWQg
bGF0ZXIgaW4gdGhlIHByb2Nlc3MuDQo+ID4+Pg0KPiA+Pj4gW01lZF0gSSBkb24ndCBmb2xsb3cg
eW91IGhlcmUuIFRoZXJlIGlzIG5vIHByaXZhY3kgY29uY2VybiBvdXQNCj4gPj4+IHRoZXJlLiBU
aGUgSUlEIHVzZWQgd2hlbiBmb3JtaW5nIGEgZ2xvYmFsIElQdjYgYWRkcmVzcyB3aWxsIGJlDQo+
ID4+PiBzZWxlY3RlZCBieSB0aGUgdGVybWluYWw7IG5vIGFzc3VtcHRpb24gaXMgbWFkZSBhYm91
dCB0aG9zZQ0KPiA+Pj4gYml0cy4NCj4gPj4NCj4gPj4gVGhlcmUgaXMgYSBwcml2YWN5IGNvbmNl
cm46IGlmIHRoZSBvcGVyYXRvciBlbmZvcmNlcyB0aGUgVUUgdG8NCj4gPj4gYWx3YXlzIHVzZSB0
aGUgbmV0d29yay1hc3NpZ25lZCBJSUQgdGhlbiB0aGF0IFVFIGlzIHRyYWNrYWJsZS4NCj4gPj4N
Cj4gPg0KPiA+IFtNZWRdIEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJ0cmFja2FibGUi
IGluIHRoaXMgY29udGV4dC4gSWYNCj4gPiB5b3UgbWVhbiB0aGF0ICJhIFVFIGNhbiBiZSBpZGVu
dGlmaWVkIGJ5IHRoZSBuZXR3b3JrIiwgdGhlbiBhbiBVRSBpcw0KPiA+IGFsd2F5cyBpZGVudGlm
aWVkIGJ5IHRoZSBuZXR3b3JrIGl0IGNvbm5lY3RzIHRvIQ0KPiANCj4gWUVzLCBhbmQgSSB0aG91
Z2h0IHRoYXQgaXMgYSBkZXZpY2Utc3BlY2lmaWMgaWRlbnRpZmllciBsaWtlIHRoZSBJTUVJLA0K
PiBub3QgdGhlIGxpbmstbG9jYWwgYWRkcmVzcy4NCj4gDQo+ID4gQXQgdGhlIElQIGxldmVsLCBh
biBVRSBpcyBpZGVudGlmaWVkIGJ5IHRoZSBiaXRzIG9mIHRoZSBJUHY2IHByZWZpeCwNCj4gPiAg
bm90IElJRCBiaXRzLg0KPiANCj4gV2VsbCAtIGJ5IHRoZSBJUCBhZGRyZXNzLg0KDQpbTWVkXSBO
by4gSSByZWl0ZXJhdGUgbXkgYW5zd2VyOiBpdCBpcyBpZGVudGlmaWVkIGJ5IHRoZSBwcmVmaXgg
bm90IHRoZSBmdWxsIElQdjYgYWRkcmVzcy4gIFBvbGljaWVzIGF0IHRoZSBuZXR3b3JrIGFyZSBl
bmZvcmNlZCBiYXNlZCBvbiB0aGUgcHJlZml4LCBub3QgdGhlIGZ1bGwgSVB2NiBhZGRyZXNzLiAg
DQoNCj4gDQo+ID4gRnVydGhlciwgYSBuZXR3b3JrIGRvZXMgbm90IG5lZWQgSVAtcmVsYXRlZCBp
bmZvcm1hdGlvbiB0byBpZGVudGlmeQ0KPiA+IGFuIFVFLg0KPiANCj4gSSBhZ3JlZSwgc28gd2h5
IGRvZXMgaXQgd2FudCB0byBpbXBvc2UgYW4gSUlEIHRvIHRoZSBVRT8NCg0KW01lZF0gVGhpcyBp
cyBhbiBvcHRpbWl6YXRpb24gdG8gYXZvaWQgREFELiANCg0KPiANCj4gPiBJIHN0aWxsIGRvbid0
IHNlZSBhbnkgcHJpdmFjeSBjb25jZXJuIGluIHN1cHBseWluZyBhbiBJSUQgdG8gYW4gVUUNCj4g
PiB0byBiZSB1c2VkIGZvciBmb3JtaW5nIGl0cyBsaW5rLWxvY2FsIGFkZHJlc3MuDQo+IA0KPiBF
cnIuLi4NCj4gDQo+IEl0J3MgYmVjYXVzZSB0aGUgc3VwcGxpZWQgSUlEIGlzIHZlcnkgbXVjaCBs
aWtlIGFuIElFRUUgTUFDIDQ4Yml0DQo+IGFkZHJlc3MuIA0KDQpbTWVkXSBUaGlzIGlzIGEgbGlu
ay1sb2NhbCBhZGRyZXNzIG5vdCBhIEdVQS4gU28sIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgeW91
ciBwb2ludC4gDQoNCiBJdCBpcyBndWFyYW50ZWVkIHVuaXF1ZSwgc28gaXQgY2FuIGFsc28gYmUg
dXNlZCB0byB0cmFjay4NCg0KW01lZF0gdG8gYmUgdHJhY2tlZCBieSB3aG9tPw0KDQo+IA0KPiBX
aHkgZG8geW91IHRoaW5rIGl0IGNhbiBub3QgYmUgdXNlZCB0byB0cmFjaz8NCj4gDQo+IEFsZXgN
Cj4gDQo+ID4NCj4gPg0KPiA+DQo=


From nobody Mon Jul 10 08:24:07 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFEA131502 for ; Mon, 10 Jul 2017 08:24:01 -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 Ggsj7hLEP8Bv for ; Mon, 10 Jul 2017 08:23:59 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002: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 9CA02127868 for ; Mon, 10 Jul 2017 08:23:59 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id f194so29087320yba.3 for ; Mon, 10 Jul 2017 08:23: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=DUESzVY+Y7S02JHiPXi/0yQOVSqMVoHmtDxYYOC9H9I=; b=rw0niGuPvEnbquroLLwhNENFhNUra/etRed7fyWEyVfrThfIw8j5Rma3aAwSoUABoq PraJWKksij3gL0RQD3+Uk6xz9KWDc4nTDUIqKy+bw1w42LpvgWXQcCry291gBg0mvqWB lv705MTf8Sjn1FUwHlh+htEyzMGe5MiMobzfOkBhU2y6/lPAHTMLcUsTJx4yYkCHsTQg SKM/8fBEJ4B3WSskKrOuOyA7OIJf3t0hqGdRCKoOIS26FEaFgcriaqfDvvPTxssr3SXn II9gGIrKwalog0SYGVX8R2Q+b1/MlA7q98LbWLaFxgBxH7ZMjOmP81DiTZ6Nd5Dg5t1y AmrQ==
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=DUESzVY+Y7S02JHiPXi/0yQOVSqMVoHmtDxYYOC9H9I=; b=mgIzvNwRcH3ykbSxG41wMqn/F7ySkd/LfB86s0yLTIw3u7pBiKcZ7+EnOs+IMU8VZ0 kVf/nKmQonxCRbVe9b+bGOINzB9z/HkXonDUqRnI/pn6Ahkuf4Mb3OTXrOEXX7Tect5B VZ4sjLt+uDVyLYTcobSrLOUrTPIlDqsjV5dlJ6fNLpmMU+28vC+Zxls3cnmjTP7lR8TQ YDceHuNwsz8nYrm6isz4jkm1RbPJVsf18gjgJajNWgMRUQjqON4hehS2oq/Zl7ZHhRdb sX775ViyqdChmxEatM3qwB92F+tnCgdU32eAoHNCkgtxSPfixZcdJ59B0RJG74ghQ6+S va1g==
X-Gm-Message-State: AIVw112Q6h30WsHsSVk5BHrDR/LBDJdX/JEF2JVR8XqKzo/feoxu3aXj DnlfmkhRQ/gfQE6wOE/4Ux1KClVYFtsG
X-Received: by 10.37.209.66 with SMTP id i63mr15589603ybg.98.1499700238491; Mon, 10 Jul 2017 08:23:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.217.69 with HTTP; Mon, 10 Jul 2017 08:23:37 -0700 (PDT)
In-Reply-To: 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
From: Erik Kline 
Date: Tue, 11 Jul 2017 00:23:37 +0900
Message-ID: 
To: Alexandre Petrescu 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c06f6100502a60553f82c4b"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 15:24:01 -0000

--94eb2c06f6100502a60553f82c4b
Content-Type: multipart/alternative; boundary="94eb2c06f610fca8bc0553f82b61"

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

On 10 July 2017 at 22:50, Alexandre Petrescu 
wrote:

> Med,
>
> I think this is an issue _if_ the operator filters all incoming messages
> generated by the UE whose LL includes an IID different than what the
> network may have suggested to it.
>
> If there is no such filter, then no need to debate specs.


There is definitely various filtering going on.  In general you cannot, for
example, ping the default router on the mobile link (neither in v4 nor
v6).  Lots of other link-local broadcast/multicast stuff is dropped to save
radio.

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


On 1=
0 July 2017 at 22:50, Alexandre Petrescu <alexandre.petrescu@gm=
ail.com> wrote:
Med,



I think this is an issue _if_ the operator filters all incoming messages ge=
nerated by the UE whose LL includes an IID different than what the network =
may have suggested to it.



If there is no such filter, then no need to debate specs.
=

There is definitely various filtering going on.=C2=A0 In gen=
eral you cannot, for example, ping the default router on the mobile link (n=
either in v4 nor v6).=C2=A0 Lots of other link-local broadcast/multicast st=
uff is dropped to save radio.


--94eb2c06f610fca8bc0553f82b61--

--94eb2c06f6100502a60553f82c4b
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgkQ8VBQ9SajlJ2mIUOL5s/1Nl9sta2ktV
wEt1ExZ0k0swGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzEw
MTUyMzU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBACUHMOeiUKr3o2252DX+vBJ3xXEaGUjezh5mZomruYRz3bs0fUHF
5SxWpU7VBgNhzca99DEwIl+xjxjF6SRhnrfYu4B8inDS3BnT9qWGKqyQRtz4moUhpUNeGBglYY62
bPmBB9oEHuBaiBH1wM0R7oFJR85gPOS5aaEytvIdDAe4LiEwo6w1Sps/TWwITeMEiWRX7FhWAwH8
RO9/B7qbc9AnpzshByl2OKamvTT5hTmJHIF6CTWGtpqJ/kbEAIH9T3uvkHsu1Ag9s5wxwiN+z/Ri
Ay3DXxhLVPz2W7ZmljMMbL0B0FCz1bWMDrwJjpq8Z9J08JUiOMMbYo6Oab2M+B8=
--94eb2c06f6100502a60553f82c4b--


From nobody Mon Jul 10 09:27:53 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E4129AA8 for ; Mon, 10 Jul 2017 09:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 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] 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 es1g7DoScfhz for ; Mon, 10 Jul 2017 09:27:50 -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 59D8B127076 for ; Mon, 10 Jul 2017 09:27:50 -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 v6AGRm8p034916; Mon, 10 Jul 2017 18:27:48 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 46EB420476B; Mon, 10 Jul 2017 18:27:48 +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 39559204462; Mon, 10 Jul 2017 18:27:48 +0200 (CEST)
Received: from [132.166.84.36] ([132.166.84.36]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6AGRl7D032010; Mon, 10 Jul 2017 18:27:47 +0200
To: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: <2c325097-651e-501c-747a-e7a322c3d844@gmail.com>
Date: Mon, 10 Jul 2017 18:27:47 +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: <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 16:27:51 -0000

Le 10/07/2017 à 16:58, mohamed.boucadair@orange.com a écrit :
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>> Envoyé : lundi 10 juillet 2017 16:46
>> À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>
>>
>>
>> Le 10/07/2017 à 16:16, mohamed.boucadair@orange.com a écrit :
>>> Alex,
>>>
>>> I'm focusing on this part of your answer.
>>>
>>> Please see inline.
>>>
>>> Cheers, Med
>>>
>>>> -----Message d'origine----- De : Alexandre Petrescu
>>>> [mailto:alexandre.petrescu@gmail.com] Envoyé : lundi 10 juillet
>>>> 2017 15:51 À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org Objet :
>>>> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>
>>>> Med,
>>>>
>>>>
>>>>>> This has consequences on privacy, and may impact
>>>>>> interoperability when DHCPv6-PD is used later in the process.
>>>>>
>>>>> [Med] I don't follow you here. There is no privacy concern out
>>>>> there. The IID used when forming a global IPv6 address will be
>>>>> selected by the terminal; no assumption is made about those
>>>>> bits.
>>>>
>>>> There is a privacy concern: if the operator enforces the UE to
>>>> always use the network-assigned IID then that UE is trackable.
>>>>
>>>
>>> [Med] I'm not sure what you mean by "trackable" in this context. If
>>> you mean that "a UE can be identified by the network", then an UE is
>>> always identified by the network it connects to!
>>
>> YEs, and I thought that is a device-specific identifier like the IMEI,
>> not the link-local address.
>>
>>> At the IP level, an UE is identified by the bits of the IPv6 prefix,
>>>   not IID bits.
>>
>> Well - by the IP address.
> 
> [Med] No. I reiterate my answer: it is identified by the prefix not the full IPv6 address.  Policies at the network are enforced based on the prefix, not the full IPv6 address.
> 
>>
>>> Further, a network does not need IP-related information to identify
>>> an UE.
>>
>> I agree, so why does it want to impose an IID to the UE?
> 
> [Med] This is an optimization to avoid DAD.

Ok about LL, but how about the GUA?  If the network uses a GUA same as 
the UE then there should be DAD for that GUA.

I dont think there is any spec that tells that the network MUST NOT 
assign a GUA on its interface towards the UE.



>>> I still don't see any privacy concern in supplying an IID to an UE
>>> to be used for forming its link-local address.
>>
>> Err...
>>
>> It's because the supplied IID is very much like an IEEE MAC 48bit
>> address.
> 
> [Med] This is a link-local address not a GUA. So, not sure to understand your point.

I can understand your point about GUA privacy vs LL privacy.

But.

Some packets with LLs as src have been witnessed in the Internet at large.

Some times some UE apps may put a link-local address in 
application-layer payloads.  Some protocols do it too (e.g. OSPF puts 
LLs in LSAs, DHCP puts interface IDs and LLs in payloads, etc).

>   It is guaranteed unique, so it can also be used to track.
> 
> [Med] to be tracked by whom?

By the operator, and by other parties outside the operator network.

Also at the same time do not get me wrong: I do agree that in some cases 
some devices must be tracked by things like law enforcement; it's just 
that it should not be by the IP address.  There is operator-specific 
identifiers like IMEI, SIM card and other IDs for that.

Alex

> 
>>
>> Why do you think it can not be used to track?
>>
>> Alex
>>
>>>
>>>
>>>


From nobody Mon Jul 10 10:09:17 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67924131824 for ; Mon, 10 Jul 2017 10:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWYSsNHr2k6E for ; Mon, 10 Jul 2017 10:09:14 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5A113181C for ; Mon, 10 Jul 2017 10:09:13 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7C5DE41BF3 for ; Mon, 10 Jul 2017 19:09:11 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4D8F841BD8; Mon, 10 Jul 2017 19:09:11 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 3557C758CD; Mon, 10 Jul 2017 19:09:11 +0200 (CEST)
Date: Mon, 10 Jul 2017 19:09:11 +0200
From: Gert Doering 
To: Alexandre Petrescu 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
Message-ID: <20170710170911.GU45648@Space.Net>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2c325097-651e-501c-747a-e7a322c3d844@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 17:09:16 -0000

Hi,

On Mon, Jul 10, 2017 at 06:27:47PM +0200, Alexandre Petrescu wrote:
> > [Med] This is an optimization to avoid DAD.
> 
> Ok about LL, but how about the GUA?  If the network uses a GUA same as 
> the UE then there should be DAD for that GUA.

The network is not using addresses out of the /64 assigned to the handset.

> I dont think there is any spec that tells that the network MUST NOT 
> assign a GUA on its interface towards the UE.

Do not "think" when 3GPP specs are confirmed - just check.  This is
(as has been explained before) standardized quite well.

[..]
> Some packets with LLs as src have been witnessed in the Internet at large.

This is a bug in all the forwarding entities on the path and needs to be
fixed.

> Some times some UE apps may put a link-local address in 
> application-layer payloads.  Some protocols do it too (e.g. OSPF puts 
> LLs in LSAs, DHCP puts interface IDs and LLs in payloads, etc).

This would be a bug in the application, which would need to be fixed.

(Nobody stated, btw, that you'll get the *same* IID on every PDP setup...)

> >   It is guaranteed unique, so it can also be used to track.
> > [Med] to be tracked by whom?
> By the operator, and by other parties outside the operator network.

The operator knows where you are and what you do, without having to refer
to LLAs.

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

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


From nobody Mon Jul 10 10:53:59 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AAB1289B0 for ; Mon, 10 Jul 2017 10:53:56 -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 NZUM_YmMDPqp for ; Mon, 10 Jul 2017 10:53:55 -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 DC80813182D for ; Mon, 10 Jul 2017 10:53:54 -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 v6AHrreg011215; Mon, 10 Jul 2017 19:53:53 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 20F47204758; Mon, 10 Jul 2017 19:53:53 +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 11884204714; Mon, 10 Jul 2017 19:53:53 +0200 (CEST)
Received: from [132.166.84.36] ([132.166.84.36]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6AHrq3w020172; Mon, 10 Jul 2017 19:53:52 +0200
To: Gert Doering 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <20170710170911.GU45648@Space.Net>
From: Alexandre Petrescu 
Message-ID: <722c7c25-46f1-53c3-78a3-39600a60d880@gmail.com>
Date: Mon, 10 Jul 2017 19:53:52 +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: <20170710170911.GU45648@Space.Net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 17:53:57 -0000

Le 10/07/2017 à 19:09, Gert Doering a écrit :
> Hi,
> 
> On Mon, Jul 10, 2017 at 06:27:47PM +0200, Alexandre Petrescu wrote:
>>> [Med] This is an optimization to avoid DAD.
>>
>> Ok about LL, but how about the GUA?  If the network uses a GUA same as
>> the UE then there should be DAD for that GUA.
> 
> The network is not using addresses out of the /64 assigned to the handset.
> 
>> I dont think there is any spec that tells that the network MUST NOT
>> assign a GUA on its interface towards the UE.
> 
> Do not "think" when 3GPP specs are confirmed - just check.  This is
> (as has been explained before) standardized quite well.

I am not sure what you mean there.

> [..]
>> Some packets with LLs as src have been witnessed in the Internet at large.
> 
> This is a bug in all the forwarding entities on the path and needs to be
> fixed.

That is your oppinion.

There should be nothing wrong in sending packets to the Internet. 
Forwarding is based on the dst address.

Some people say that the src and dst addresses should have the same 
scope, but that is not true either.  Some protocols dont work w/o src 
GUA and dst link-scope multicast.

>> Some times some UE apps may put a link-local address in
>> application-layer payloads.  Some protocols do it too (e.g. OSPF puts
>> LLs in LSAs, DHCP puts interface IDs and LLs in payloads, etc).
> 
> This would be a bug in the application, which would need to be fixed.

Well - I think you dont understand.

Speaking only for DHCP here:

DHCP carries interface IDs in UDP payloads.  They're called "Link-layer 
address" 48bit, in Client Identifier, as an UDP payload in DHCPv6 
Solicit, by the User Terminal.

If the Server is in the operator's network, then one could think that 
there is no more tracking danger than without DHCP.  But if the Server 
and intermediary routers are outside the operator's network then there's 
real risk of tracking.

One could not fix the DHCP protocol to eliminate that Client identifier, 
because if so then DHCP will no longer work.

And we said we want DHCP to work in order to get this DHCPv6 Prefix 
Delegation.

Do you see?

> (Nobody stated, btw, that you'll get the *same* IID on every PDP setup...)

I agree.

>>>    It is guaranteed unique, so it can also be used to track.
>>> [Med] to be tracked by whom?
>> By the operator, and by other parties outside the operator network.
> 
> The operator knows where you are and what you do, without having to refer
> to LLAs.

So why does it mandate an IID on the UE?  What is that protocol?

Alex

> 
> Gert Doering
>          -- NetMaster
> 


From nobody Mon Jul 10 10:59:49 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272091289B0 for ; Mon, 10 Jul 2017 10:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncsJ45uevrFO for ; Mon, 10 Jul 2017 10:59:45 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2161A131834 for ; Mon, 10 Jul 2017 10:59:44 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 749C641BF3 for ; Mon, 10 Jul 2017 19:59:42 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 5025841BD6; Mon, 10 Jul 2017 19:59:42 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 41A39759AD; Mon, 10 Jul 2017 19:59:42 +0200 (CEST)
Date: Mon, 10 Jul 2017 19:59:42 +0200
From: Gert Doering 
To: Alexandre Petrescu 
Cc: Gert Doering , mohamed.boucadair@orange.com, "v6ops@ietf.org" 
Message-ID: <20170710175942.GW45648@Space.Net>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <20170710170911.GU45648@Space.Net> <722c7c25-46f1-53c3-78a3-39600a60d880@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o03slR/1rgEAVnD3"
Content-Disposition: inline
In-Reply-To: <722c7c25-46f1-53c3-78a3-39600a60d880@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 17:59:48 -0000

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

Hi,

On Mon, Jul 10, 2017 at 07:53:52PM +0200, Alexandre Petrescu wrote:
> > [..]
> >> Some packets with LLs as src have been witnessed in the Internet at la=
rge.
> >=20
> > This is a bug in all the forwarding entities on the path and needs to be
> > fixed.
>=20
> That is your oppinion.

It's clear violation of internet standards that say "such packets MUST NOT
be forwarded", so what else can it be but "a bug"?

> There should be nothing wrong in sending packets to the Internet.=20
> Forwarding is based on the dst address.

Please do less thinking, and more reading of standards.

We've been here before.

[..]
> >> Some times some UE apps may put a link-local address in
> >> application-layer payloads.  Some protocols do it too (e.g. OSPF puts
> >> LLs in LSAs, DHCP puts interface IDs and LLs in payloads, etc).
> >=20
> > This would be a bug in the application, which would need to be fixed.
>=20
> Well - I think you dont understand.

Yeah.

> Speaking only for DHCP here:
>=20
> DHCP carries interface IDs in UDP payloads.  They're called "Link-layer=
=20
> address" 48bit, in Client Identifier, as an UDP payload in DHCPv6=20
> Solicit, by the User Terminal.

That is not a protocol commonly routed across the internet, so it is of
total irrelevance in this context (and, using MAC address as client=20
identifier is strictly optional in DHCPv6, unlike IPv4)

> If the Server is in the operator's network, then one could think that=20
> there is no more tracking danger than without DHCP.  But if the Server=20
> and intermediary routers are outside the operator's network then there's=
=20
> real risk of tracking.

How many networks do you know that route DHCPv6 requests about arbitrary
third party infrastructure?

> One could not fix the DHCP protocol to eliminate that Client identifier,=
=20
> because if so then DHCP will no longer work.

Less thinking, more reading.  DHCPv6 initially was specified based on
DUIDs, and *not* MAC addresses.

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

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

--o03slR/1rgEAVnD3
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlljwIsACgkQ31bAZeTO
f8VF6Q/+JfOP0VLgQVkz5ZUKMpI0owQN5KxKYqjuPFtSHTY5jCzsPfYsw0fiYnjV
kgaUnnGsJrxtA7ACHi1kuXwNHBvHxqKTZWCCTn7ewijiDYD21g4r1uye4WU/EUkr
QTqBPX2B4wdB7rKnB4F820azSAIz5+t2wmR6fIk4AGjLiRfh/tvgV6h3eT4BldUO
NHx9ivgoikT6wZF7s7FdMEV9GqgUIZt9pZp/5sDnN6yFS0nWPVJ0lhEKvh3p6I3X
fSPZ+IKps6yZw0nU6QKMl+xmPyzDu3lWUSTwH9hShimrjlHQQpalMK3iWN/rjRKj
oKxy1hUFudy6sE7EliPCedhnZIOerszAPVLdZ+ntmXG/fQ5GJVzFFxNFbiODxBvu
a2efhgTte9Brzp+ICs13HEHXUsb5kd1BRbAcGDnL55Y4jIZmhQDA4q4kDbkyO27B
l83HEzcwPzAUHfBnnvRyApkbpUaaOqkptop5vfuDt2/8x768hxbw9gAzGBVMt075
PjUYui3TDGGiMUWSACq8R7srasBkNJZYTYvoTY2eV9jddcp6TJWzLfkU87I3yjVO
pXQzxlZ8+MjhbFS+uZlxYe+lbBRN4Zgtm6SftLqZFF85qFjcDGuLq8W5lt9NRMLA
b7bhFQOtmVyWy6GoX/pYBPshtI1xlXCvofmzUM74Vl3h/NGIbXI=
=IMbv
-----END PGP SIGNATURE-----

--o03slR/1rgEAVnD3--


From nobody Mon Jul 10 12:24:20 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9618131866 for ; Mon, 10 Jul 2017 12:24:18 -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 ViA_x11D0Umj for ; Mon, 10 Jul 2017 12:24:17 -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 9E589131880 for ; Mon, 10 Jul 2017 12:24:16 -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 v6AJOEPG075968; Mon, 10 Jul 2017 21:24:14 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6699D204895; Mon, 10 Jul 2017 21:24:14 +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 5775F204697; Mon, 10 Jul 2017 21:24:14 +0200 (CEST)
Received: from [132.166.84.36] ([132.166.84.36]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6AJODRN007837; Mon, 10 Jul 2017 21:24:14 +0200
To: Gert Doering 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <20170710170911.GU45648@Space.Net> <722c7c25-46f1-53c3-78a3-39600a60d880@gmail.com> <20170710175942.GW45648@Space.Net>
From: Alexandre Petrescu 
Message-ID: <89c968a2-056f-2a09-c0df-2d567cfd5e58@gmail.com>
Date: Mon, 10 Jul 2017 21:24:12 +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: <20170710175942.GW45648@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jul 2017 19:24:19 -0000

Gert,

Le 10/07/2017  19:59, Gert Doering a crit :
> Hi,
> 
> On Mon, Jul 10, 2017 at 07:53:52PM +0200, Alexandre Petrescu wrote:
>>> [..]
>>>> Some packets with LLs as src have been witnessed in the Internet at large.
>>>
>>> This is a bug in all the forwarding entities on the path and needs to be
>>> fixed.
>>
>> That is your oppinion.
> 
> It's clear violation of internet standards that say "such packets MUST NOT
> be forwarded", so what else can it be but "a bug"?

Well I can only agree with you here, but I will come back later.

[...]

>> DHCP carries interface IDs in UDP payloads.  They're called "Link-layer
>> address" 48bit, in Client Identifier, as an UDP payload in DHCPv6
>> Solicit, by the User Terminal.
> 
> That is not a protocol commonly routed across the internet, so it is of
> total irrelevance in this context (and, using MAC address as client
> identifier is strictly optional in DHCPv6, unlike IPv4)

So, you seem to mean that the use of the IID in the payload of a DHCP 
Solicit is not necessarily mandatory.

So it is not because I dont set the right Client Identifier in the DHCP 
Solicit that I dont get replies.

>> If the Server is in the operator's network, then one could think that
>> there is no more tracking danger than without DHCP.  But if the Server
>> and intermediary routers are outside the operator's network then there's
>> real risk of tracking.
> 
> How many networks do you know that route DHCPv6 requests about arbitrary
> third party infrastructure?

Well, I think it will come.

The DHCPv6 requests could go very far - they're UDP.  I think the 
Solicit can go beyond link scope (site scope?), and can also be 
addressed to a GUA.

> Less thinking, more reading.  DHCPv6 initially was specified based on
> DUIDs, and *not* MAC addresses.

Initially yes.

Alex

> 
> Gert Doering
>          -- NetMaster
> 


From nobody Mon Jul 10 23:51:51 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69159131472 for ; Mon, 10 Jul 2017 23:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FvL10CO5gtES for ; Mon, 10 Jul 2017 23:51:48 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB6E126CF6 for ; Mon, 10 Jul 2017 23:51:47 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 6772360517; Tue, 11 Jul 2017 08:51:46 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 47A9F1800CE; Tue, 11 Jul 2017 08:51:46 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 08:51:45 +0200
From: 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
Thread-Index: AQHS+Ys8478LJa2HdUu4Hc6zAuAbyKJNJSLw///5LoCAARCxoA==
Date: Tue, 11 Jul 2017 06:51:44 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com>
In-Reply-To: <2c325097-651e-501c-747a-e7a322c3d844@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jul 2017 06:51:49 -0000

SGkgQWxleCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t
TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBBbGV4YW5kcmUgUGV0cmVzY3UgW21haWx0
bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDEwIGp1
aWxsZXQgMjAxNyAxODoyOA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyB2Nm9w
c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBSRkM2NDU5ICJJUHY2IGluIDNHUFAi
IC0gdGhlIElJRCBpbiB0aGUgTEwgYWRkcmVzcw0KPiANCj4gDQo+IA0KPiBMZSAxMC8wNy8yMDE3
IMOgIDE2OjU4LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIGEgw6ljcml0IDoNCj4gPiBS
ZS0sDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBN
ZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGUgOiBBbGV4
YW5kcmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiA+
PiBFbnZvecOpIDogbHVuZGkgMTAganVpbGxldCAyMDE3IDE2OjQ2DQo+ID4+IMOAIDogQk9VQ0FE
QUlSIE1vaGFtZWQgSU1UL09MTjsgdjZvcHNAaWV0Zi5vcmcNCj4gPj4gT2JqZXQgOiBSZTogW3Y2
b3BzXSBSRkM2NDU5ICJJUHY2IGluIDNHUFAiIC0gdGhlIElJRCBpbiB0aGUgTEwgYWRkcmVzcw0K
PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBMZSAxMC8wNy8yMDE3IMOgIDE2OjE2LCBtb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tIGEgw6ljcml0IDoNCj4gPj4+IEFsZXgsDQo+ID4+Pg0KPiA+Pj4g
SSdtIGZvY3VzaW5nIG9uIHRoaXMgcGFydCBvZiB5b3VyIGFuc3dlci4NCj4gPj4+DQo+ID4+PiBQ
bGVhc2Ugc2VlIGlubGluZS4NCj4gPj4+DQo+ID4+PiBDaGVlcnMsIE1lZA0KPiA+Pj4NCj4gPj4+
PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBBbGV4YW5kcmUgUGV0cmVzY3UNCj4g
Pj4+PiBbbWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dIEVudm95w6kgOiBsdW5k
aSAxMCBqdWlsbGV0DQo+ID4+Pj4gMjAxNyAxNTo1MSDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElN
VC9PTE47IHY2b3BzQGlldGYub3JnIE9iamV0IDoNCj4gPj4+PiBSZTogW3Y2b3BzXSBSRkM2NDU5
ICJJUHY2IGluIDNHUFAiIC0gdGhlIElJRCBpbiB0aGUgTEwgYWRkcmVzcw0KPiA+Pj4+DQo+ID4+
Pj4gTWVkLA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+IFRoaXMgaGFzIGNvbnNlcXVlbmNlcyBv
biBwcml2YWN5LCBhbmQgbWF5IGltcGFjdA0KPiA+Pj4+Pj4gaW50ZXJvcGVyYWJpbGl0eSB3aGVu
IERIQ1B2Ni1QRCBpcyB1c2VkIGxhdGVyIGluIHRoZSBwcm9jZXNzLg0KPiA+Pj4+Pg0KPiA+Pj4+
PiBbTWVkXSBJIGRvbid0IGZvbGxvdyB5b3UgaGVyZS4gVGhlcmUgaXMgbm8gcHJpdmFjeSBjb25j
ZXJuIG91dA0KPiA+Pj4+PiB0aGVyZS4gVGhlIElJRCB1c2VkIHdoZW4gZm9ybWluZyBhIGdsb2Jh
bCBJUHY2IGFkZHJlc3Mgd2lsbCBiZQ0KPiA+Pj4+PiBzZWxlY3RlZCBieSB0aGUgdGVybWluYWw7
IG5vIGFzc3VtcHRpb24gaXMgbWFkZSBhYm91dCB0aG9zZQ0KPiA+Pj4+PiBiaXRzLg0KPiA+Pj4+
DQo+ID4+Pj4gVGhlcmUgaXMgYSBwcml2YWN5IGNvbmNlcm46IGlmIHRoZSBvcGVyYXRvciBlbmZv
cmNlcyB0aGUgVUUgdG8NCj4gPj4+PiBhbHdheXMgdXNlIHRoZSBuZXR3b3JrLWFzc2lnbmVkIElJ
RCB0aGVuIHRoYXQgVUUgaXMgdHJhY2thYmxlLg0KPiA+Pj4+DQo+ID4+Pg0KPiA+Pj4gW01lZF0g
SSdtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgInRyYWNrYWJsZSIgaW4gdGhpcyBjb250ZXh0
LiBJZg0KPiA+Pj4geW91IG1lYW4gdGhhdCAiYSBVRSBjYW4gYmUgaWRlbnRpZmllZCBieSB0aGUg
bmV0d29yayIsIHRoZW4gYW4gVUUgaXMNCj4gPj4+IGFsd2F5cyBpZGVudGlmaWVkIGJ5IHRoZSBu
ZXR3b3JrIGl0IGNvbm5lY3RzIHRvIQ0KPiA+Pg0KPiA+PiBZRXMsIGFuZCBJIHRob3VnaHQgdGhh
dCBpcyBhIGRldmljZS1zcGVjaWZpYyBpZGVudGlmaWVyIGxpa2UgdGhlIElNRUksDQo+ID4+IG5v
dCB0aGUgbGluay1sb2NhbCBhZGRyZXNzLg0KPiA+Pg0KPiA+Pj4gQXQgdGhlIElQIGxldmVsLCBh
biBVRSBpcyBpZGVudGlmaWVkIGJ5IHRoZSBiaXRzIG9mIHRoZSBJUHY2IHByZWZpeCwNCj4gPj4+
ICAgbm90IElJRCBiaXRzLg0KPiA+Pg0KPiA+PiBXZWxsIC0gYnkgdGhlIElQIGFkZHJlc3MuDQo+
ID4NCj4gPiBbTWVkXSBOby4gSSByZWl0ZXJhdGUgbXkgYW5zd2VyOiBpdCBpcyBpZGVudGlmaWVk
IGJ5IHRoZSBwcmVmaXggbm90IHRoZQ0KPiBmdWxsIElQdjYgYWRkcmVzcy4gIFBvbGljaWVzIGF0
IHRoZSBuZXR3b3JrIGFyZSBlbmZvcmNlZCBiYXNlZCBvbiB0aGUNCj4gcHJlZml4LCBub3QgdGhl
IGZ1bGwgSVB2NiBhZGRyZXNzLg0KPiA+DQo+ID4+DQo+ID4+PiBGdXJ0aGVyLCBhIG5ldHdvcmsg
ZG9lcyBub3QgbmVlZCBJUC1yZWxhdGVkIGluZm9ybWF0aW9uIHRvIGlkZW50aWZ5DQo+ID4+PiBh
biBVRS4NCj4gPj4NCj4gPj4gSSBhZ3JlZSwgc28gd2h5IGRvZXMgaXQgd2FudCB0byBpbXBvc2Ug
YW4gSUlEIHRvIHRoZSBVRT8NCj4gPg0KPiA+IFtNZWRdIFRoaXMgaXMgYW4gb3B0aW1pemF0aW9u
IHRvIGF2b2lkIERBRC4NCj4gDQo+IE9rIGFib3V0IExMLCBidXQgaG93IGFib3V0IHRoZSBHVUE/
DQoNCltNZWRdIE5vIHByb2JsZW0gYXQgdGhhdCBmcm9udCBlaXRoZXIgKHJlYWRpbmcgZnJvbSB0
aGUgM0dQUCBzcGVjKToNCg0KPT0NClNpbmNlIHRoZSBHR1NOIGd1YXJhbnRlZXMgdGhhdCB0aGUg
UHJlZml4IGlzIHVuaXF1ZSwgdGhlIE1TIGRvZXMgbm90IG5lZWQgdG8gcGVyZm9ybSBhbnkgRHVw
bGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uIG9uIGFkZHJlc3NlcyBpdCBjcmVhdGVzLg0KPT0NCg0K
ICBJZiB0aGUgbmV0d29yayB1c2VzIGEgR1VBIHNhbWUgYXMNCj4gdGhlIFVFIHRoZW4gdGhlcmUg
c2hvdWxkIGJlIERBRCBmb3IgdGhhdCBHVUEuDQoNCltNZWRdIElkZW0gYXMgYWJvdmUsIHRoZSBz
cGVjIGlzIGNsZWFyOiANCg0KPT0NClRoZSBHR1NOIHNoYWxsIG5vdCBnZW5lcmF0ZSBhbnkgZ2xv
YmFsbHkgdW5pcXVlIElQdjYgYWRkcmVzc2VzIGZvciBpdHNlbGYgdXNpbmcgdGhlIFByZWZpeCBh
c3NpZ25lZCB0byB0aGUgTVMgaW4gdGhlIFJvdXRlciBBZHZlcnRpc2VtZW50Lg0KPT0NCg0KPiAN
Cj4gSSBkb250IHRoaW5rIHRoZXJlIGlzIGFueSBzcGVjIHRoYXQgdGVsbHMgdGhhdCB0aGUgbmV0
d29yayBNVVNUIE5PVA0KPiBhc3NpZ24gYSBHVUEgb24gaXRzIGludGVyZmFjZSB0b3dhcmRzIHRo
ZSBVRS4NCg0KW01lZF0gU2VlIGZvciBleGFtcGxlLCAzR1BQIFRTLiAyOS4wNjENCg0KPiANCj4g
DQo+IA0KPiA+Pj4gSSBzdGlsbCBkb24ndCBzZWUgYW55IHByaXZhY3kgY29uY2VybiBpbiBzdXBw
bHlpbmcgYW4gSUlEIHRvIGFuIFVFDQo+ID4+PiB0byBiZSB1c2VkIGZvciBmb3JtaW5nIGl0cyBs
aW5rLWxvY2FsIGFkZHJlc3MuDQo+ID4+DQo+ID4+IEVyci4uLg0KPiA+Pg0KPiA+PiBJdCdzIGJl
Y2F1c2UgdGhlIHN1cHBsaWVkIElJRCBpcyB2ZXJ5IG11Y2ggbGlrZSBhbiBJRUVFIE1BQyA0OGJp
dA0KPiA+PiBhZGRyZXNzLg0KPiA+DQo+ID4gW01lZF0gVGhpcyBpcyBhIGxpbmstbG9jYWwgYWRk
cmVzcyBub3QgYSBHVUEuIFNvLCBub3Qgc3VyZSB0byB1bmRlcnN0YW5kDQo+IHlvdXIgcG9pbnQu
DQo+IA0KPiBJIGNhbiB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgYWJvdXQgR1VBIHByaXZhY3kgdnMg
TEwgcHJpdmFjeS4NCg0KW01lZF0gT0suDQoNCg==


From nobody Tue Jul 11 00:47:42 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61461319C6 for ; Tue, 11 Jul 2017 00:47:40 -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 i-z-qmEbDJXX for ; Tue, 11 Jul 2017 00:47:39 -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 ECD601319BD for ; Tue, 11 Jul 2017 00:47:38 -0700 (PDT)
Received: from [10.138.142.112] (unknown [80.188.30.113]) (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 0B288825AD; Tue, 11 Jul 2017 09:49:02 +0200 (CEST)
To: Toerless Eckert , v6ops@ietf.org
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
From: Fernando Gont 
Message-ID: <53bdcce4-3aae-e5c2-e7d5-816eef8c3cf9@si6networks.com>
Date: Tue, 11 Jul 2017 10:10:09 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jul 2017 07:47:41 -0000

On 07/07/2017 02:03 AM, Toerless Eckert wrote:
> For a protocol design, we are wondering what the current state of the
> art is wrt to IPv6 link local addresses potentially being the same
> on multiple interfaces of a network device like a router.
> 
> I was told by Brian that RFC7217 is recommended, but recommendations are
> one thing and reality can be another thing. If there are widely deployed
> network devices that do have the same link local address across multiple
> interfaces then it could take quite a while for this to get changed,
> so it might be prudent for a protocol design NOT to expect that eg: RFC7217
> is supported everywhere.
> 
> The one type of datapoint i seem to vaguely remember is that routers
> with large number of "cheap" L3 interfaces often derive their MAC
> utilization designs from L2 switches where you do not automatically
> assign a separate MAC address to every port because thats a cost factor,
> and instead there is just a limited number of MAC addresses assigned to
> the box (i think i remember '8' from some cisco products) and
> once those are exhausted, additional L3 interfaces repeat the MAC
> addresses. And of course if the link-local addresses are derived from
> interfaces MAC addresses then we have the problem in question.
> 
> Standard disclaimer:
> Just because i am paranoid does not mean they are not after me.
> 
> So, would love to hear that duplicate link-local IPv6 addresses are
> not to be found anywhere in deployed  IPv6 networks and that i am
> just paranoid ;-) Or else we know that we should take this into
> consideration.

Well, for legacy systems, you could have duplicate link-local addresses
for a umber of reasons:

* vendors re-using the same MAC address in different devices
* Products using the same MAC address on multiple interfaces (as you
describe)
* virtualization technolgies 8which, in many cases, obtain a randomized
MAC address at the time the VM was fist created).

RFC7217 reduces the likelihood of this happening...


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





From nobody Tue Jul 11 00:47:57 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4311319BD for ; Tue, 11 Jul 2017 00:47: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 h8knc0Kl-39k for ; Tue, 11 Jul 2017 00:47: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 A3F581319C4 for ; Tue, 11 Jul 2017 00:47:40 -0700 (PDT)
Received: from [10.138.142.112] (unknown [80.188.30.113]) (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 4D8B682590; Tue, 11 Jul 2017 09:49:05 +0200 (CEST)
To: Brian E Carpenter , Mark Smith , Toerless Eckert 
Cc: v6ops list 
References: <20170706230347.GA24940@faui40p.informatik.uni-erlangen.de>  
From: Fernando Gont 
Message-ID: 
Date: Tue, 11 Jul 2017 10:35:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: 7bit
Archived-At: 
Subject: Re: [v6ops] Use of MAC addresses in IPv6 link local addresses
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jul 2017 07:47:42 -0000

On 07/07/2017 05:13 AM, Brian E Carpenter wrote:
>>
>> "They are required to be unique within a subnet prefix."
>>
>> An Internet search for "fe80::1" shows that this is also a common
>> value being used for router interfaces.
> 
> Which makes my head hurt, since it's a guaranteed failure if two
> such routers are on the same subnet.

+1


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





From nobody Tue Jul 11 02:28:08 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2B1277BB for ; Tue, 11 Jul 2017 02:28:07 -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 Wj4PjF_bF2Uw for ; Tue, 11 Jul 2017 02:28: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 A43901272E1 for ; Tue, 11 Jul 2017 02:28:05 -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 v6B9S3us047522; Tue, 11 Jul 2017 11:28:03 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A88CC204BC7; Tue, 11 Jul 2017 11:28: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 9B08C204AF6; Tue, 11 Jul 2017 11:28: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 v6B9S3nQ005778; Tue, 11 Jul 2017 11:28:03 +0200
To: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: 
Date: Tue, 11 Jul 2017 11:28:03 +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: <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jul 2017 09:28:07 -0000

Le 11/07/2017 à 08:51, mohamed.boucadair@orange.com a écrit :
> Hi Alex,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>> Envoyé : lundi 10 juillet 2017 18:28
>> À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>
>>
>>
>> Le 10/07/2017 à 16:58, mohamed.boucadair@orange.com a écrit :
>>> Re-,
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>>>> Envoyé : lundi 10 juillet 2017 16:46
>>>> À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>>>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>
>>>>
>>>>
>>>> Le 10/07/2017 à 16:16, mohamed.boucadair@orange.com a écrit :
>>>>> Alex,
>>>>>
>>>>> I'm focusing on this part of your answer.
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> Cheers, Med
>>>>>
>>>>>> -----Message d'origine----- De : Alexandre Petrescu
>>>>>> [mailto:alexandre.petrescu@gmail.com] Envoyé : lundi 10 juillet
>>>>>> 2017 15:51 À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org Objet :
>>>>>> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>>>
>>>>>> Med,
>>>>>>
>>>>>>
>>>>>>>> This has consequences on privacy, and may impact
>>>>>>>> interoperability when DHCPv6-PD is used later in the process.
>>>>>>>
>>>>>>> [Med] I don't follow you here. There is no privacy concern out
>>>>>>> there. The IID used when forming a global IPv6 address will be
>>>>>>> selected by the terminal; no assumption is made about those
>>>>>>> bits.
>>>>>>
>>>>>> There is a privacy concern: if the operator enforces the UE to
>>>>>> always use the network-assigned IID then that UE is trackable.
>>>>>>
>>>>>
>>>>> [Med] I'm not sure what you mean by "trackable" in this context. If
>>>>> you mean that "a UE can be identified by the network", then an UE is
>>>>> always identified by the network it connects to!
>>>>
>>>> YEs, and I thought that is a device-specific identifier like the IMEI,
>>>> not the link-local address.
>>>>
>>>>> At the IP level, an UE is identified by the bits of the IPv6 prefix,
>>>>>    not IID bits.
>>>>
>>>> Well - by the IP address.
>>>
>>> [Med] No. I reiterate my answer: it is identified by the prefix not the
>> full IPv6 address.  Policies at the network are enforced based on the
>> prefix, not the full IPv6 address.
>>>
>>>>
>>>>> Further, a network does not need IP-related information to identify
>>>>> an UE.
>>>>
>>>> I agree, so why does it want to impose an IID to the UE?
>>>
>>> [Med] This is an optimization to avoid DAD.
>>
>> Ok about LL, but how about the GUA?
> 
> [Med] No problem at that front either (reading from the 3GPP spec):
> 
> ==
> Since the GGSN guarantees that the Prefix is unique, the MS does not need to perform any Duplicate Address Detection on addresses it creates.
> ==
> 
>    If the network uses a GUA same as
>> the UE then there should be DAD for that GUA.
> 
> [Med] Idem as above, the spec is clear:
> 
> ==
> The GGSN shall not generate any globally unique IPv6 addresses for itself using the Prefix assigned to the MS in the Router Advertisement.
> ==
> 
>>
>> I dont think there is any spec that tells that the network MUST NOT
>> assign a GUA on its interface towards the UE.
> 
> [Med] See for example, 3GPP TS. 29.061
> 
>>
>>
>>
>>>>> I still don't see any privacy concern in supplying an IID to an UE
>>>>> to be used for forming its link-local address.
>>>>
>>>> Err...
>>>>
>>>> It's because the supplied IID is very much like an IEEE MAC 48bit
>>>> address.
>>>
>>> [Med] This is a link-local address not a GUA. So, not sure to understand
>> your point.
>>
>> I can understand your point about GUA privacy vs LL privacy.
> 
> [Med] OK.

Med - why there is no answer to my DHCPv6 PD Solicit?  I am using a GUA 
without the IID from the operator.

Alex

> 


From nobody Tue Jul 11 02:50:23 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C501242F7 for ; Tue, 11 Jul 2017 02:50: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, 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 JcLhcAosBzkH for ; Tue, 11 Jul 2017 02:50:18 -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 9C1A112EB99 for ; Tue, 11 Jul 2017 02:50:18 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id p207so36199100yba.2 for ; Tue, 11 Jul 2017 02:50:18 -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=wL2bjXh17Nex7jEmfVgix/0O9/ImAf/CXIrCCsmUDyg=; b=dKAspF58JfIYeISro4fo7lM/1KRcu7GAR6uSF5OcZ/rdEghCSIK0SncmOkfZfFmju6 ZY3fEJjl/jv/DioGRp1FfELqzZbTAXDm3c041lY0JVKL0zKWTJMCmUtprY5C0qQUL003 1nOS5o1z1e6mTI2d9nENjEMp6wNib0NYzYpdpqRxD7b2vBVReUKrbIR+BPD+dLcVkrMu ZsGM3OpbgCn5mXHbSCCz/oPFNO4vHJHTdhbKKvSahVJXGPyYVE0RIWcMlTHlEakQvPhk dpY3e0LXdWkJr7qbU/o+c7vHl/2WOVax9iKVUAajcNWpjrkwf6Bn2RIuvoq9cKg4TZXl 2ZCQ==
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=wL2bjXh17Nex7jEmfVgix/0O9/ImAf/CXIrCCsmUDyg=; b=At6NNQo5PhVn1K0n/9tE4cGUO2lSF174WqJOLae6RNG8+uxCUzw4Hf6q5kSbIvz6R0 v+50EVAxbSs1JmXk0TSINwjIcudbF63SkPEevjQvZkvtZx2As6jjHOr75Aaykyz73Iqu EbRMEAsg9nYngA5Lf9ultOyqrPuvV7t8/qTXBmzRUpc63mYzpc24lgqnrAP62XiY6fov LUdjvrZOgaBzFLmXwmB0wbvCH2dgb7lkBCjBHx0kf4PR4Dva6vqP9p1WGxT2y654iuA8 aUB2iumZbSS2xR6x6NymTW3YLmyCp7dAUZuksqMi0gd3GDqRWxaLwysEgExgOSAl1lvL GmBw==
X-Gm-Message-State: AIVw110O/jFkABfr49I3Tv2DUls1ad4BuIM6jqaanjpLs1nVa5rFgCqg BXhIYITlp2tf/oFJDGpsjYEo6NbkrQQi
X-Received: by 10.37.11.5 with SMTP id 5mr1290123ybl.235.1499766617682; Tue, 11 Jul 2017 02:50:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.217.69 with HTTP; Tue, 11 Jul 2017 02:49:56 -0700 (PDT)
In-Reply-To: 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
From: Erik Kline 
Date: Tue, 11 Jul 2017 18:49:56 +0900
Message-ID: 
To: Alexandre Petrescu 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11c047c084e907055407a011"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jul 2017 09:50:21 -0000

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

Is your carrier known to support PD?  I don't think it's very common
yet.  Also, shouldn't you be sending your PD request from a link-local
source address?

On 11 July 2017 at 18:28, Alexandre Petrescu
 wrote:
>
>
> Le 11/07/2017 =C3=A0 08:51, mohamed.boucadair@orange.com a =C3=A9crit :
>>
>> Hi Alex,
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>>> Envoy=C3=A9 : lundi 10 juillet 2017 18:28
>>> =C3=80 : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>
>>>
>>>
>>> Le 10/07/2017 =C3=A0 16:58, mohamed.boucadair@orange.com a =C3=A9crit :
>>>>
>>>> Re-,
>>>>
>>>> Please see inline.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>>>>> Envoy=C3=A9 : lundi 10 juillet 2017 16:46
>>>>> =C3=80 : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>>>>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL addres=
s
>>>>>
>>>>>
>>>>>
>>>>> Le 10/07/2017 =C3=A0 16:16, mohamed.boucadair@orange.com a =C3=A9crit=
 :
>>>>>>
>>>>>> Alex,
>>>>>>
>>>>>> I'm focusing on this part of your answer.
>>>>>>
>>>>>> Please see inline.
>>>>>>
>>>>>> Cheers, Med
>>>>>>
>>>>>>> -----Message d'origine----- De : Alexandre Petrescu
>>>>>>> [mailto:alexandre.petrescu@gmail.com] Envoy=C3=A9 : lundi 10 juille=
t
>>>>>>> 2017 15:51 =C3=80 : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org Objet=
 :
>>>>>>> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>>>>
>>>>>>> Med,
>>>>>>>
>>>>>>>
>>>>>>>>> This has consequences on privacy, and may impact
>>>>>>>>> interoperability when DHCPv6-PD is used later in the process.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Med] I don't follow you here. There is no privacy concern out
>>>>>>>> there. The IID used when forming a global IPv6 address will be
>>>>>>>> selected by the terminal; no assumption is made about those
>>>>>>>> bits.
>>>>>>>
>>>>>>>
>>>>>>> There is a privacy concern: if the operator enforces the UE to
>>>>>>> always use the network-assigned IID then that UE is trackable.
>>>>>>>
>>>>>>
>>>>>> [Med] I'm not sure what you mean by "trackable" in this context. If
>>>>>> you mean that "a UE can be identified by the network", then an UE is
>>>>>> always identified by the network it connects to!
>>>>>
>>>>>
>>>>> YEs, and I thought that is a device-specific identifier like the IMEI=
,
>>>>> not the link-local address.
>>>>>
>>>>>> At the IP level, an UE is identified by the bits of the IPv6 prefix,
>>>>>>    not IID bits.
>>>>>
>>>>>
>>>>> Well - by the IP address.
>>>>
>>>>
>>>> [Med] No. I reiterate my answer: it is identified by the prefix not th=
e
>>>
>>> full IPv6 address.  Policies at the network are enforced based on the
>>> prefix, not the full IPv6 address.
>>>>
>>>>
>>>>>
>>>>>> Further, a network does not need IP-related information to identify
>>>>>> an UE.
>>>>>
>>>>>
>>>>> I agree, so why does it want to impose an IID to the UE?
>>>>
>>>>
>>>> [Med] This is an optimization to avoid DAD.
>>>
>>>
>>> Ok about LL, but how about the GUA?
>>
>>
>> [Med] No problem at that front either (reading from the 3GPP spec):
>>
>> =3D=3D
>> Since the GGSN guarantees that the Prefix is unique, the MS does not nee=
d
>> to perform any Duplicate Address Detection on addresses it creates.
>> =3D=3D
>>
>>    If the network uses a GUA same as
>>>
>>> the UE then there should be DAD for that GUA.
>>
>>
>> [Med] Idem as above, the spec is clear:
>>
>> =3D=3D
>> The GGSN shall not generate any globally unique IPv6 addresses for itsel=
f
>> using the Prefix assigned to the MS in the Router Advertisement.
>> =3D=3D
>>
>>>
>>> I dont think there is any spec that tells that the network MUST NOT
>>> assign a GUA on its interface towards the UE.
>>
>>
>> [Med] See for example, 3GPP TS. 29.061
>>
>>>
>>>
>>>
>>>>>> I still don't see any privacy concern in supplying an IID to an UE
>>>>>> to be used for forming its link-local address.
>>>>>
>>>>>
>>>>> Err...
>>>>>
>>>>> It's because the supplied IID is very much like an IEEE MAC 48bit
>>>>> address.
>>>>
>>>>
>>>> [Med] This is a link-local address not a GUA. So, not sure to understa=
nd
>>>
>>> your point.
>>>
>>> I can understand your point about GUA privacy vs LL privacy.
>>
>>
>> [Med] OK.
>
>
> Med - why there is no answer to my DHCPv6 PD Solicit?  I am using a GUA
> without the IID from the operator.
>
> Alex
>
>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--001a11c047c084e907055407a011
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgnIS36ELDnNJHjp3PSZV9hJiFNy41yZFs
PWUdYdi80DowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzEx
MDk1MDE4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAMfTY3BQv35/P/B9PzHpYRrM0IbQtqwMHAa6zWK1XtxhQiVN79WL
nTGk1TQ+rhdtDSwo+AN4rj7N7tJGqK8IeechCT3Uppuvx8YQlC/JdTChyCo8+wgoTL8HLpjQ4Lhe
cDib5QcfL9ogugWF/L+NSGqNE7viScEpovMdlQasGMVg7yTmEddZYAsm0rQ9YeR2E75U/ZEHp/Uq
KAbjmv4w+ic75622UgFG/KY/oLstMjXiOUFymV9munpjVYFKzu/cG2TLneskeZHi+ELpGzSvwOJS
hoO4xCvRNSFf0IyTIbnCmb30BsGUasQVT/2fVmYYxaRgzw41vWX+GL/8+RuFb1o=
--001a11c047c084e907055407a011--


From nobody Tue Jul 11 03:09:33 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EF8127866 for ; Tue, 11 Jul 2017 03:09:31 -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 oYXTVWe4R7as for ; Tue, 11 Jul 2017 03:09:30 -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 C40ED127180 for ; Tue, 11 Jul 2017 03:09:29 -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 v6BA9RHL017000; Tue, 11 Jul 2017 12:09:27 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F3580204B64; Tue, 11 Jul 2017 12:09:26 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E3EC1201587; Tue, 11 Jul 2017 12:09:26 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6BA9Q2d013223; Tue, 11 Jul 2017 12:09:26 +0200
To: Erik Kline 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  
From: Alexandre Petrescu 
Message-ID: 
Date: Tue, 11 Jul 2017 12:09:26 +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: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jul 2017 10:09:32 -0000

What do you mean by 'not very common'?  Is it little common in some 
small place?

PD from ll src: I think the DHCP spec does not tell whether it could be 
an LL or a GUA.  I asked on the DHC WG email list.  The operator seems 
to prefer to hear the DHCP Solicit to be issued from a GUA.

Le 11/07/2017 à 11:49, Erik Kline a écrit :
> Is your carrier known to support PD?  I don't think it's very common
> yet.  Also, shouldn't you be sending your PD request from a link-local
> source address?
> 
> On 11 July 2017 at 18:28, Alexandre Petrescu
>  wrote:
>>
>>
>> Le 11/07/2017 à 08:51, mohamed.boucadair@orange.com a écrit :
>>>
>>> Hi Alex,
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>>>> Envoyé : lundi 10 juillet 2017 18:28
>>>> À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>>>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>
>>>>
>>>>
>>>> Le 10/07/2017 à 16:58, mohamed.boucadair@orange.com a écrit :
>>>>>
>>>>> Re-,
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>>>>>> Envoyé : lundi 10 juillet 2017 16:46
>>>>>> À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>>>>>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 10/07/2017 à 16:16, mohamed.boucadair@orange.com a écrit :
>>>>>>>
>>>>>>> Alex,
>>>>>>>
>>>>>>> I'm focusing on this part of your answer.
>>>>>>>
>>>>>>> Please see inline.
>>>>>>>
>>>>>>> Cheers, Med
>>>>>>>
>>>>>>>> -----Message d'origine----- De : Alexandre Petrescu
>>>>>>>> [mailto:alexandre.petrescu@gmail.com] Envoyé : lundi 10 juillet
>>>>>>>> 2017 15:51 À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org Objet :
>>>>>>>> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>>>>>>>>
>>>>>>>> Med,
>>>>>>>>
>>>>>>>>
>>>>>>>>>> This has consequences on privacy, and may impact
>>>>>>>>>> interoperability when DHCPv6-PD is used later in the process.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [Med] I don't follow you here. There is no privacy concern out
>>>>>>>>> there. The IID used when forming a global IPv6 address will be
>>>>>>>>> selected by the terminal; no assumption is made about those
>>>>>>>>> bits.
>>>>>>>>
>>>>>>>>
>>>>>>>> There is a privacy concern: if the operator enforces the UE to
>>>>>>>> always use the network-assigned IID then that UE is trackable.
>>>>>>>>
>>>>>>>
>>>>>>> [Med] I'm not sure what you mean by "trackable" in this context. If
>>>>>>> you mean that "a UE can be identified by the network", then an UE is
>>>>>>> always identified by the network it connects to!
>>>>>>
>>>>>>
>>>>>> YEs, and I thought that is a device-specific identifier like the IMEI,
>>>>>> not the link-local address.
>>>>>>
>>>>>>> At the IP level, an UE is identified by the bits of the IPv6 prefix,
>>>>>>>     not IID bits.
>>>>>>
>>>>>>
>>>>>> Well - by the IP address.
>>>>>
>>>>>
>>>>> [Med] No. I reiterate my answer: it is identified by the prefix not the
>>>>
>>>> full IPv6 address.  Policies at the network are enforced based on the
>>>> prefix, not the full IPv6 address.
>>>>>
>>>>>
>>>>>>
>>>>>>> Further, a network does not need IP-related information to identify
>>>>>>> an UE.
>>>>>>
>>>>>>
>>>>>> I agree, so why does it want to impose an IID to the UE?
>>>>>
>>>>>
>>>>> [Med] This is an optimization to avoid DAD.
>>>>
>>>>
>>>> Ok about LL, but how about the GUA?
>>>
>>>
>>> [Med] No problem at that front either (reading from the 3GPP spec):
>>>
>>> ==
>>> Since the GGSN guarantees that the Prefix is unique, the MS does not need
>>> to perform any Duplicate Address Detection on addresses it creates.
>>> ==
>>>
>>>     If the network uses a GUA same as
>>>>
>>>> the UE then there should be DAD for that GUA.
>>>
>>>
>>> [Med] Idem as above, the spec is clear:
>>>
>>> ==
>>> The GGSN shall not generate any globally unique IPv6 addresses for itself
>>> using the Prefix assigned to the MS in the Router Advertisement.
>>> ==
>>>
>>>>
>>>> I dont think there is any spec that tells that the network MUST NOT
>>>> assign a GUA on its interface towards the UE.
>>>
>>>
>>> [Med] See for example, 3GPP TS. 29.061
>>>
>>>>
>>>>
>>>>
>>>>>>> I still don't see any privacy concern in supplying an IID to an UE
>>>>>>> to be used for forming its link-local address.
>>>>>>
>>>>>>
>>>>>> Err...
>>>>>>
>>>>>> It's because the supplied IID is very much like an IEEE MAC 48bit
>>>>>> address.
>>>>>
>>>>>
>>>>> [Med] This is a link-local address not a GUA. So, not sure to understand
>>>>
>>>> your point.
>>>>
>>>> I can understand your point about GUA privacy vs LL privacy.
>>>
>>>
>>> [Med] OK.
>>
>>
>> Med - why there is no answer to my DHCPv6 PD Solicit?  I am using a GUA
>> without the IID from the operator.
>>
>> Alex
>>
>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Wed Jul 12 04:41:44 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778BE12ECC1 for ; Wed, 12 Jul 2017 04:41:43 -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 qQe4jbH72o20 for ; Wed, 12 Jul 2017 04:41:42 -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 C8554127342 for ; Wed, 12 Jul 2017 04:41:41 -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 v6CBfe3N018967; Wed, 12 Jul 2017 13:41:40 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 023DE2081BF; Wed, 12 Jul 2017 13:41:40 +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 E94062055A4; Wed, 12 Jul 2017 13:41:39 +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 v6CBfdwo010710; Wed, 12 Jul 2017 13:41:39 +0200
To: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
Date: Wed, 12 Jul 2017 13:41:39 +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: <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 11:41:43 -0000

Med,

[...]
>>>>> Further, a network does not need IP-related information to
>>>>> identify an UE.
>>>> 
>>>> I agree, so why does it want to impose an IID to the UE?
>>> 
>>> [Med] This is an optimization to avoid DAD.
>> 
>> Ok about LL, but how about the GUA?
> 
> [Med] No problem at that front either (reading from the 3GPP spec):
> 
> == Since the GGSN guarantees that the Prefix is unique, the MS does
> not need to perform any Duplicate Address Detection on addresses it
> creates. ==
 >
> 
> If the network uses a GUA same as
>> the UE then there should be DAD for that GUA.
> 
> [Med] Idem as above, the spec is clear:
> 
> == The GGSN shall not generate any globally unique IPv6 addresses for
> itself using the Prefix assigned to the MS in the Router
> Advertisement. ==

I think that spec is wrong (3GPP TS. 29.061?).

Because, in practice some operator on some APN puts a GUA (not an LLA) 
on its router's interface towards the UE.  It uses that GUA in the src 
of the RA sent to the UE.  Packet dump available upon request.

Alex

> 
>> 
>> I dont think there is any spec that tells that the network MUST
>> NOT assign a GUA on its interface towards the UE.
> 
> [Med] See for example, 3GPP TS. 29.061
> 
>> 
>> 
>> 
>>>>> I still don't see any privacy concern in supplying an IID to
>>>>> an UE to be used for forming its link-local address.
>>>> 
>>>> Err...
>>>> 
>>>> It's because the supplied IID is very much like an IEEE MAC
>>>> 48bit address.
>>> 
>>> [Med] This is a link-local address not a GUA. So, not sure to
>>> understand
>> your point.
>> 
>> I can understand your point about GUA privacy vs LL privacy.
> 
> [Med] OK.
> 


From nobody Wed Jul 12 04:44:03 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7343131686 for ; Wed, 12 Jul 2017 04:44: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, 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 Dv71_wNjicDC for ; Wed, 12 Jul 2017 04:44:01 -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 20201127342 for ; Wed, 12 Jul 2017 04:44:01 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id w19so12610972uac.0 for ; Wed, 12 Jul 2017 04:44: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=UKRNQI/WA4w/XMHAbsHGRAm06nn3A8jtYAblwSljJL4=; b=lMDvAj1/820xKbdMqKUiCLMaNObJU3P2SmnQwlSHNrq9q1Bc1y0PcfuqYmJkT4vn7O O7mWcBOV3Fgwrv6/DY9sHzLKBwG6PLJIYoiIMBNzgI77H8CsH6Q1/F1qZvYWIoawf9y7 chkgZfUkdU6b6SpaD7M3McORHkwlEPlfCwjmvPmUqhMFN6bx6AvA54MBkLJvyBplucUR FtU/q3vADgb0g7x1cTnavcJGARS/HnYo9tzHEhsWjXi5G8QcNHAZVOacQQSTfpgzvtZQ jz82AuTg6hU/AGV9WsK5ZW00t8UUEERY05Wu4NsOzzJjwxIZhajzGH94aKrFglL4AiTp AAQQ==
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=UKRNQI/WA4w/XMHAbsHGRAm06nn3A8jtYAblwSljJL4=; b=T68oOA3F9lANcUNtj4ZbW+iMwIEglcGF7CNRS5gOkdR8B4jNvYySIRjj2isu3EANse Yy5ziFP1WBTGexfoIu2LnGWBv4K1XxXGw3btUTzIJvbHzTWfMVDflTvPdh25BC0jRekK EODES7nLemtA8284RaL2S/HBr5cYOEKmgdxS0LoXGM40DP8EGcyYF9D/Ld8t6Bnk4nBl PjSfJCpq8xWu6wRrY9X1FXaF+XmxZE7PhszdITXuhDu7y6vZLsr2z803eJnJsOq1x63Z vv/2E8p+vTbzAf+mjLVboMWvVURtFyAmAF+ReOnwrDnUWKd6yrfSLqbmwx1jIHfGbyea sxFQ==
X-Gm-Message-State: AIVw112Da8/rxMn48EtH6TOg+nlMXjZ5ecWsB5+jcc7QErs1kjo95moT BiK6qS7Wuto32TYNl96gX3inngQN9y49
X-Received: by 10.176.2.84 with SMTP id 78mr2831950uas.80.1499859840001; Wed, 12 Jul 2017 04:44:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.48.129 with HTTP; Wed, 12 Jul 2017 04:43:39 -0700 (PDT)
In-Reply-To: <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
From: Lorenzo Colitti 
Date: Wed, 12 Jul 2017 20:43:39 +0900
Message-ID: 
To: Alexandre Petrescu 
Cc: "" , "v6ops@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11376f00fa50a705541d542f"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 11:44:03 -0000

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

On Wed, Jul 12, 2017 at 8:41 PM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> Because, in practice some operator on some APN puts a GUA (not an LLA) on
> its router's interface towards the UE.  It uses that GUA in the src of the
> RA sent to the UE.  Packet dump available upon request.
>

Just because you see it on a USB dongle does not mean the operator is doing
it.

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


On W=
ed, Jul 12, 2017 at 8:41 PM, Alexandre Petrescu <alexandre.petr=
escu@gmail.com> wrote:
Beca=
use, in practice some operator on some APN puts a GUA (not an LLA) on its r=
outer's interface towards the UE.=C2=A0 It uses that GUA in the src of =
the RA sent to the UE.=C2=A0 Packet dump available upon request.

Just because you see it on a USB dongle does not =
mean the operator is doing it.=C2=A0


--001a11376f00fa50a705541d542f--


From nobody Wed Jul 12 05:02:20 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458BC12EB99 for ; Wed, 12 Jul 2017 05:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZAyAYh5r5ERW for ; Wed, 12 Jul 2017 05:02:18 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24838131562 for ; Wed, 12 Jul 2017 05:02:18 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id C852A160317; Wed, 12 Jul 2017 14:02:16 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id A8B9F600DF; Wed, 12 Jul 2017 14:02:16 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0352.000; Wed, 12 Jul 2017 14:02:16 +0200
From: 
To: Alexandre Petrescu , "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
Thread-Index: AQHS+wPV7ER1Db9IiEeiglihfmhZ7KJQFg7A
Date: Wed, 12 Jul 2017 12:02:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A003E4C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
In-Reply-To: <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 12:02:19 -0000

QWxleCwgDQoNClRoZSBrZXkgcGFydCBpcyBub3QgdG8gdXNlIChvciBub3QpIGEgR1VBLCBidXQg
Li4uDQoNClRoZSBHR1NOIHNoYWxsIG5vdCBnZW5lcmF0ZSBhbnkgZ2xvYmFsbHkgdW5pcXVlIElQ
djYgYWRkcmVzc2VzIGZvcg0KaXRzZWxmIHVzaW5nIHRoZSBQcmVmaXggYXNzaWduZWQgdG8gdGhl
IE1TIGluIHRoZSBSb3V0ZXINCl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e
Xl5eXiAgICAgDQpBZHZlcnRpc2VtZW50Lg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3Nh
Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQWxleGFuZHJlIFBldHJlc2N1IFttYWlsdG86YWxl
eGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAxMiBqdWls
bGV0IDIwMTcgMTM6NDINCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgdjZvcHNA
aWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFt2Nm9wc10gUkZDNjQ1OSAiSVB2NiBpbiAzR1BQIiAt
IHRoZSBJSUQgaW4gdGhlIExMIGFkZHJlc3MgYW5kDQo+IEdVQQ0KPiANCj4gTWVkLA0KPiANCj4g
Wy4uLl0NCj4gPj4+Pj4gRnVydGhlciwgYSBuZXR3b3JrIGRvZXMgbm90IG5lZWQgSVAtcmVsYXRl
ZCBpbmZvcm1hdGlvbiB0bw0KPiA+Pj4+PiBpZGVudGlmeSBhbiBVRS4NCj4gPj4+Pg0KPiA+Pj4+
IEkgYWdyZWUsIHNvIHdoeSBkb2VzIGl0IHdhbnQgdG8gaW1wb3NlIGFuIElJRCB0byB0aGUgVUU/
DQo+ID4+Pg0KPiA+Pj4gW01lZF0gVGhpcyBpcyBhbiBvcHRpbWl6YXRpb24gdG8gYXZvaWQgREFE
Lg0KPiA+Pg0KPiA+PiBPayBhYm91dCBMTCwgYnV0IGhvdyBhYm91dCB0aGUgR1VBPw0KPiA+DQo+
ID4gW01lZF0gTm8gcHJvYmxlbSBhdCB0aGF0IGZyb250IGVpdGhlciAocmVhZGluZyBmcm9tIHRo
ZSAzR1BQIHNwZWMpOg0KPiA+DQo+ID4gPT0gU2luY2UgdGhlIEdHU04gZ3VhcmFudGVlcyB0aGF0
IHRoZSBQcmVmaXggaXMgdW5pcXVlLCB0aGUgTVMgZG9lcw0KPiA+IG5vdCBuZWVkIHRvIHBlcmZv
cm0gYW55IER1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbiBvbiBhZGRyZXNzZXMgaXQNCj4gPiBj
cmVhdGVzLiA9PQ0KPiAgPg0KPiA+DQo+ID4gSWYgdGhlIG5ldHdvcmsgdXNlcyBhIEdVQSBzYW1l
IGFzDQo+ID4+IHRoZSBVRSB0aGVuIHRoZXJlIHNob3VsZCBiZSBEQUQgZm9yIHRoYXQgR1VBLg0K
PiA+DQo+ID4gW01lZF0gSWRlbSBhcyBhYm92ZSwgdGhlIHNwZWMgaXMgY2xlYXI6DQo+ID4NCj4g
PiA9PSBUaGUgR0dTTiBzaGFsbCBub3QgZ2VuZXJhdGUgYW55IGdsb2JhbGx5IHVuaXF1ZSBJUHY2
IGFkZHJlc3NlcyBmb3INCj4gPiBpdHNlbGYgdXNpbmcgdGhlIFByZWZpeCBhc3NpZ25lZCB0byB0
aGUgTVMgaW4gdGhlIFJvdXRlcg0KPiA+IEFkdmVydGlzZW1lbnQuID09DQo+IA0KPiBJIHRoaW5r
IHRoYXQgc3BlYyBpcyB3cm9uZyAoM0dQUCBUUy4gMjkuMDYxPykuDQo+IA0KPiBCZWNhdXNlLCBp
biBwcmFjdGljZSBzb21lIG9wZXJhdG9yIG9uIHNvbWUgQVBOIHB1dHMgYSBHVUEgKG5vdCBhbiBM
TEEpDQo+IG9uIGl0cyByb3V0ZXIncyBpbnRlcmZhY2UgdG93YXJkcyB0aGUgVUUuICBJdCB1c2Vz
IHRoYXQgR1VBIGluIHRoZSBzcmMNCj4gb2YgdGhlIFJBIHNlbnQgdG8gdGhlIFVFLiAgUGFja2V0
IGR1bXAgYXZhaWxhYmxlIHVwb24gcmVxdWVzdC4NCj4gDQo+IEFsZXgNCj4gDQo+ID4NCj4gPj4N
Cj4gPj4gSSBkb250IHRoaW5rIHRoZXJlIGlzIGFueSBzcGVjIHRoYXQgdGVsbHMgdGhhdCB0aGUg
bmV0d29yayBNVVNUDQo+ID4+IE5PVCBhc3NpZ24gYSBHVUEgb24gaXRzIGludGVyZmFjZSB0b3dh
cmRzIHRoZSBVRS4NCj4gPg0KPiA+IFtNZWRdIFNlZSBmb3IgZXhhbXBsZSwgM0dQUCBUUy4gMjku
MDYxDQo+ID4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4+Pj4gSSBzdGlsbCBkb24ndCBzZWUgYW55
IHByaXZhY3kgY29uY2VybiBpbiBzdXBwbHlpbmcgYW4gSUlEIHRvDQo+ID4+Pj4+IGFuIFVFIHRv
IGJlIHVzZWQgZm9yIGZvcm1pbmcgaXRzIGxpbmstbG9jYWwgYWRkcmVzcy4NCj4gPj4+Pg0KPiA+
Pj4+IEVyci4uLg0KPiA+Pj4+DQo+ID4+Pj4gSXQncyBiZWNhdXNlIHRoZSBzdXBwbGllZCBJSUQg
aXMgdmVyeSBtdWNoIGxpa2UgYW4gSUVFRSBNQUMNCj4gPj4+PiA0OGJpdCBhZGRyZXNzLg0KPiA+
Pj4NCj4gPj4+IFtNZWRdIFRoaXMgaXMgYSBsaW5rLWxvY2FsIGFkZHJlc3Mgbm90IGEgR1VBLiBT
bywgbm90IHN1cmUgdG8NCj4gPj4+IHVuZGVyc3RhbmQNCj4gPj4geW91ciBwb2ludC4NCj4gPj4N
Cj4gPj4gSSBjYW4gdW5kZXJzdGFuZCB5b3VyIHBvaW50IGFib3V0IEdVQSBwcml2YWN5IHZzIExM
IHByaXZhY3kuDQo+ID4NCj4gPiBbTWVkXSBPSy4NCj4gPg0K


From nobody Wed Jul 12 05:03:52 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3E81286B2 for ; Wed, 12 Jul 2017 05:03:50 -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 rXE2zSmSBrYb for ; Wed, 12 Jul 2017 05:03: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 E2607128BC8 for ; Wed, 12 Jul 2017 05:03: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 v6CC3jmg086499; Wed, 12 Jul 2017 14:03:45 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D4D6220116A; Wed, 12 Jul 2017 14:03:45 +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 BBF61208135; Wed, 12 Jul 2017 14:03:45 +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 v6CC3j0L002185; Wed, 12 Jul 2017 14:03:45 +0200
To: Lorenzo Colitti 
Cc: "" , "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com>
Date: Wed, 12 Jul 2017 14:03:45 +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: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 12:03:50 -0000

Le 12/07/2017 à 13:43, Lorenzo Colitti a écrit :
> On Wed, Jul 12, 2017 at 8:41 PM, Alexandre Petrescu 
> >
> wrote:
> 
> Because, in practice some operator on some APN puts a GUA (not an 
> LLA) on its router's interface towards the UE.  It uses that GUA in 
> the src of the RA sent to the UE.  Packet dump available upon
> request.
> 
> 
> Just because you see it on a USB dongle does not mean the operator is
>  doing it.

I dont know what you mean precisely by USB dongle, but I dont see it on
an USB dongle.

I see it with tcpdump on a Sierra IoT module running a form of embedded
linux, gnueabi is the target of the cross compiler.  It uses /dev/ttyAT
device.

Alex


From nobody Wed Jul 12 06:19:14 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A274C13169D for ; Wed, 12 Jul 2017 06:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 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] 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 IA1TdKb_dnld for ; Wed, 12 Jul 2017 06:19: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 10B55131699 for ; Wed, 12 Jul 2017 06:19: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 v6CDJ9l1004026; Wed, 12 Jul 2017 15:19:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 58F63204ED3; Wed, 12 Jul 2017 15:19:09 +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 4B6F5201382; Wed, 12 Jul 2017 15:19:09 +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 v6CDJ9bC022848; Wed, 12 Jul 2017 15:19:09 +0200
To: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com> <787AE7BB302AE849A7480A190F8B93300A003E4C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: <48239c3c-cf5f-a2be-a6e4-d09e5bd084f5@gmail.com>
Date: Wed, 12 Jul 2017 15:19:08 +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: <787AE7BB302AE849A7480A190F8B93300A003E4C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 13:19:13 -0000

Le 12/07/2017 à 14:02, mohamed.boucadair@orange.com a écrit :
> Alex,
> 
> The key part is not to use (or not) a GUA, but ...
> 
> The GGSN shall not generate any globally unique IPv6 addresses for
> itself using the Prefix assigned to the MS in the Router
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Advertisement.

If it is not the GGSN then who does it?

The UE receives an RA with a GUA in its SRC; packet dump available upon 
request.

Alex

> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
>> Envoyé : mercredi 12 juillet 2017 13:42
>> À : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org
>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and
>> GUA
>>
>> Med,
>>
>> [...]
>>>>>>> Further, a network does not need IP-related information to
>>>>>>> identify an UE.
>>>>>>
>>>>>> I agree, so why does it want to impose an IID to the UE?
>>>>>
>>>>> [Med] This is an optimization to avoid DAD.
>>>>
>>>> Ok about LL, but how about the GUA?
>>>
>>> [Med] No problem at that front either (reading from the 3GPP spec):
>>>
>>> == Since the GGSN guarantees that the Prefix is unique, the MS does
>>> not need to perform any Duplicate Address Detection on addresses it
>>> creates. ==
>>   >
>>>
>>> If the network uses a GUA same as
>>>> the UE then there should be DAD for that GUA.
>>>
>>> [Med] Idem as above, the spec is clear:
>>>
>>> == The GGSN shall not generate any globally unique IPv6 addresses for
>>> itself using the Prefix assigned to the MS in the Router
>>> Advertisement. ==
>>
>> I think that spec is wrong (3GPP TS. 29.061?).
>>
>> Because, in practice some operator on some APN puts a GUA (not an LLA)
>> on its router's interface towards the UE.  It uses that GUA in the src
>> of the RA sent to the UE.  Packet dump available upon request.
>>
>> Alex
>>
>>>
>>>>
>>>> I dont think there is any spec that tells that the network MUST
>>>> NOT assign a GUA on its interface towards the UE.
>>>
>>> [Med] See for example, 3GPP TS. 29.061
>>>
>>>>
>>>>
>>>>
>>>>>>> I still don't see any privacy concern in supplying an IID to
>>>>>>> an UE to be used for forming its link-local address.
>>>>>>
>>>>>> Err...
>>>>>>
>>>>>> It's because the supplied IID is very much like an IEEE MAC
>>>>>> 48bit address.
>>>>>
>>>>> [Med] This is a link-local address not a GUA. So, not sure to
>>>>> understand
>>>> your point.
>>>>
>>>> I can understand your point about GUA privacy vs LL privacy.
>>>
>>> [Med] OK.
>>>


From nobody Wed Jul 12 07:58:10 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E1131453 for ; Wed, 12 Jul 2017 07:58:09 -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 NnDRJf4TQkgg for ; Wed, 12 Jul 2017 07:58:07 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 A8B70126C22 for ; Wed, 12 Jul 2017 07:58:07 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id 16so26559557qkg.2 for ; Wed, 12 Jul 2017 07:58:07 -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=xvfvZwZmjjKfhENvjfvOqCkBrIHQ8qfKTMWxgodEHko=; b=Egchv2tCjKQ0SpvMbaDjtkhM/o9Ehnk7W9cR4JdN11ga3CNx7arPMYQvyX7TiTN1f2 QQFcIKpwtRKMLgZNTP+YlIo9sX9BHYa5rWTF70iPunlIAjDzLlJeKZkMClbuI7+hkjhQ hDzII5E89nUHAfikFowhx07Qnz8p2Ylm8dpn7mlZoodauZYrMTqM2fY7PjWGGwa8brPm zg8uDUyORVtceC5RXEt+Wq06Yp/Y2btbkC/7nZKZlz39Rxol6B0ftsc6YXyWH5IKwiqy XkimPp38Wp85nUyaiByqZUNkF6Z4j2WWy6ELUin/YhqHWYtAskZ+NRak5o7V+NiXQ2ig MkfA==
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=xvfvZwZmjjKfhENvjfvOqCkBrIHQ8qfKTMWxgodEHko=; b=tLpPl1bgjC1n7MEo0gpFc2qAzZhROChoYlLyeQpofbh0z1FIFo3q/INBFCKMJkOjTH hhXQdsNKiVZmqry/wT7Cy0CGHky/i7rCef3QQj+6/XGtbMo3nK3DK+yxhniO9Xw0lDu1 OKpU3QWvLHrOB4Yj4ROCHsPMkm9d63fonqR4JeRxJmyR5n2RHd21a8mDzy8Qtryxza7k 3WKbzIc2ZeeIg4qw98Zr3jiBzxSlz4kfx9XEM/pvw6z2gMMDQb4Cnoy10vyhAtbQbwTg vLfAc48o4wMEnDVl9uztqLkdKtCQJfJmZ+cP6PpUTHAsGS2JUUVrVU78JXxawBVXcjsI jQcQ==
X-Gm-Message-State: AIVw113pQAPsjRC6X8N36OnsMxnthsk4v8TYdARA0+oT6+rzVhCRjHpx 5UTK7Kd/LwNxZGBL/3bxQYzpyLy2uQ==
X-Received: by 10.55.72.81 with SMTP id v78mr6398318qka.133.1499871486794; Wed, 12 Jul 2017 07:58:06 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.44 with HTTP; Wed, 12 Jul 2017 07:58:06 -0700 (PDT)
In-Reply-To: <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Wed, 12 Jul 2017 07:58:06 -0700
X-Google-Sender-Auth: B7qh8Jb8tO4CYiBoTXd4H_jHBUQ
Message-ID: 
To: Alexandre Petrescu 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 14:58:09 -0000

At Wed, 12 Jul 2017 13:41:39 +0200,
Alexandre Petrescu  wrote:

> > == The GGSN shall not generate any globally unique IPv6 addresses for
> > itself using the Prefix assigned to the MS in the Router
> > Advertisement. ==
>
> I think that spec is wrong (3GPP TS. 29.061?).
>
> Because, in practice some operator on some APN puts a GUA (not an LLA)
> on its router's interface towards the UE.  It uses that GUA in the src
> of the RA sent to the UE.  Packet dump available upon request.

I have no expertise in the 3GPP spec, but if I understand the above
correctly it's broken even more fundamentally: the source address
of an RA MUST be a link-local address.

4.2.  Router Advertisement Message Format
[...]
      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.
(from RFC4861)

If you really see an RA with a non-LL source address, a textual
snippet of the packet dump will certainly be interesting.

--
JINMEI, Tatuya


From nobody Wed Jul 12 08:00:14 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24D71319B7 for ; Wed, 12 Jul 2017 08: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 JNQhx0sie5nu for ; Wed, 12 Jul 2017 08:00:11 -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 68851131952 for ; Wed, 12 Jul 2017 08:00:11 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id g40so16019289uaa.3 for ; Wed, 12 Jul 2017 08: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=WoozcLE/Ctpc8mlVQUPdg7u1+XpQ9tMt8eLgCZiSaI8=; b=diPa2tNWksH8DE1LUhgKukMPbwFT5Uj+bGxOsNx/JtaQ63aMVoeykZrB8x2VURbmcd VMCghoWMgtuE1i211giS3NHZKioUm2H+5sUlZbebQCVkOfPTpZwkvEwUaC+zzUtgWx78 hRF9/ifhNlQYV+dqhf6ZOBxK/4NdJcbvICARFPC6EEB48F8peli/TKgQidErE7IbDVDK urOj6jHbZqej5PPZ5RO4D7HnOw+o3P8IL2fKIeJUE2IpFxuAMVZzQV3ie1P2HEBvGbWz akisusfDiog1AO7pTwm2A1wtIAzvtwPFJ4X51LvkHCptl/vOjTloErE42GUrBJ/2f4FQ k0vQ==
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=WoozcLE/Ctpc8mlVQUPdg7u1+XpQ9tMt8eLgCZiSaI8=; b=WBeps5/aKCe62URPKTUt8qdRDSNmEHGN5JGjrlu3rOZUzqKksTaxyvpKc+EF7kKvij Y/OHwo2cnnAZE6B7Pj7qgsUHMNOjKkVTDiNYP6UIFZwLy/B0wPtTQ4DzNeva2Ic8GG90 05owa74KQXMXTP3h10EPFmBNvGCIzldLk8g0/uDsakjjs/Urz2G6ns8z2iLoCDGsIfJG tDyfhST1gWaX1HmTpXLp5LMPLL2ip22EA440GzZwOpywChXUDm+k0vu2Pt/CH1IdPAPb BHHi0lHgRLeEgeBMfcKarbs6VyN3a4UvKyKveQ2iQnOIaLFrdoGg5+6iXby/0mwWS1ig oUag==
X-Gm-Message-State: AIVw113Rps6ZjXGlTwJsomPtZYEYwSCjJGSUCBjMUZd1Buc3/foDUQiA SFKZBhg87o1yo+/V/iZ6oGz3kVAA24nvWpY=
X-Received: by 10.176.2.84 with SMTP id 78mr3339641uas.80.1499871610095; Wed, 12 Jul 2017 08:00:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.48.129 with HTTP; Wed, 12 Jul 2017 07:59:49 -0700 (PDT)
In-Reply-To: <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com>
From: Lorenzo Colitti 
Date: Wed, 12 Jul 2017 23:59:49 +0900
Message-ID: 
To: Alexandre Petrescu 
Cc: "" , "v6ops@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11376f0087d3ac05542012c8"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 15:00:13 -0000

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

On Wed, Jul 12, 2017 at 9:03 PM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> Just because you see it on a USB dongle does not mean the operator is
>>  doing it.
>>
>
> I dont know what you mean precisely by USB dongle, but I dont see it on
> an USB dongle.
>

Sorry, let me reword: "just because you see it on your device does not mean
the operator is doing it".

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


On W=
ed, Jul 12, 2017 at 9:03 PM, Alexandre Petrescu <alexandre.petr=
escu@gmail.com> wrote:
Just because you see it on a US=
B dongle does not mean the operator is

=C2=A0doing it.





I dont know what you mean precisely by USB dongle, but I dont see it on

an USB dongle.

Sorry, let me reword: &q=
uot;just because you see it on your device does not mean the operator is do=
ing it".


--001a11376f0087d3ac05542012c8--


From nobody Wed Jul 12 08:15:57 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE1130A94 for ; Wed, 12 Jul 2017 08:15:56 -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 wWNWFy_KDgA8 for ; Wed, 12 Jul 2017 08:15:54 -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 8EFDA12EAF0 for ; Wed, 12 Jul 2017 08:15:54 -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 v6CFFqO7166315; Wed, 12 Jul 2017 17:15:52 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8BB2C2084FF; Wed, 12 Jul 2017 17:15:52 +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 7FC022084FD; Wed, 12 Jul 2017 17:15:52 +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 v6CFFqh6018980; Wed, 12 Jul 2017 17:15:52 +0200
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Cc: mohamed.boucadair@orange.com, "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com>
Date: Wed, 12 Jul 2017 17:15:52 +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: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 15:15:56 -0000

Le 12/07/2017 à 16:58, 神明達哉 a écrit :
> At Wed, 12 Jul 2017 13:41:39 +0200,
> Alexandre Petrescu  wrote:
> 
>>> == The GGSN shall not generate any globally unique IPv6 addresses for
>>> itself using the Prefix assigned to the MS in the Router
>>> Advertisement. ==
>>
>> I think that spec is wrong (3GPP TS. 29.061?).
>>
>> Because, in practice some operator on some APN puts a GUA (not an LLA)
>> on its router's interface towards the UE.  It uses that GUA in the src
>> of the RA sent to the UE.  Packet dump available upon request.
> 
> I have no expertise in the 3GPP spec, but if I understand the above
> correctly it's broken even more fundamentally: the source address
> of an RA MUST be a link-local address.
> 
> 4.2.  Router Advertisement Message Format
> [...]
>        Source Address
>                       MUST be the link-local address assigned to the
>                       interface from which this message is sent.
> (from RFC4861)
> 
> If you really see an RA with a non-LL source address, a textual
> snippet of the packet dump will certainly be interesting.

A textual snippet may include addresses that are considered private. 
But I will send you privately the snippet.

Alex

> 
> --
> JINMEI, Tatuya
> 


From nobody Wed Jul 12 09:54:01 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74A13173A for ; Wed, 12 Jul 2017 09:53:59 -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 A6oTidtqbK1w for ; Wed, 12 Jul 2017 09:53:58 -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 2644B131738 for ; Wed, 12 Jul 2017 09:53:58 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id i2so17464652qta.3 for ; Wed, 12 Jul 2017 09:53:58 -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=aG87hk5oWcHSm8CnFefsbn8FpNkJaCPxjme2R3RvjE4=; b=cLD+MYRFESSxMuD0g6Mu6JwY/QjG0XLhofvNxblV4rUeLI5u1/aBB0g2OWnRgHzqHM JUzvSWSPYZd9kOHuImCUzJ7zjt9H6p+X8fmcwHb++3/97vK48TifONwC3iXDqN85DADt T3vv8rrlSDccgMjZE0YLfyPLXRLs3wpKuzZ4WaL0yTEts27cHK3Ukex+hMONR/Va/c4h E99hne28Rp6Avrmnt0EXlszvUdFugR5oePpQBCggEH8D/+Mha5/5pzmyvBck0Yo/xQu0 sYhGWpmwEKI8bUGatKnNCJ4tUrufjMHAibjbZOGOewZrWQL/lB1B5tdZodtIJxat65/H qGgA==
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=aG87hk5oWcHSm8CnFefsbn8FpNkJaCPxjme2R3RvjE4=; b=Dabli22ZKxmRVFkXEj1qfxJR0NC1mRVimxtEll7r3U7zqgE592A8GxgaFPKTzWHa0o 65RT3jah4+SjNpykQfvQUtQRKn7ihYhcHe3zGlSZnmvoJwZux7EmI4Or9Wu5HFYz9LsE ZakXk7M6Q33FbNz9Hs6dOHVnaY59tS12wMo0Uw+V/KZoLp/SuGgsU2Qppq2i4ZPtrEbP 2J/cKZT2i3sj+JnyMIuxArLp3mZWl0Xu+I4qKSxc3vCT9Lb4nSkHz+EacJiza4XkCjOK PWEkWmITF9Nvi2SGHoRIA9WtEewT+5LJDPmaB7gXF2IqR/a3Q9H+Q3xriP1z2dR1+G4Y dreQ==
X-Gm-Message-State: AIVw112XkIYA5zPHQBlgjyF+N9VViuW9S2jqphLYGUNAU2T0Spinwxj1 qchIhA/K8FKPZRNlxx1MZWOgkg/cRw==
X-Received: by 10.200.46.100 with SMTP id s33mr8263093qta.48.1499878437189; Wed, 12 Jul 2017 09:53:57 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.44 with HTTP; Wed, 12 Jul 2017 09:53:56 -0700 (PDT)
In-Reply-To: <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Wed, 12 Jul 2017 09:53:56 -0700
X-Google-Sender-Auth: QHCmshQhRqTflfhKVbxOzHilSUU
Message-ID: 
To: Alexandre Petrescu 
Cc: "v6ops@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jul 2017 16:53:59 -0000

At Wed, 12 Jul 2017 17:15:52 +0200,
Alexandre Petrescu  wrote:

> > If you really see an RA with a non-LL source address, a textual
> > snippet of the packet dump will certainly be interesting.
>
> A textual snippet may include addresses that are considered private.
> But I will send you privately the snippet.

You could mask the sensitive part of it, but, anyway, I actually see
RAs sent from a global address.  I don't know why it behaves that way,
but it's no secret that there are broken implementations so it's not
surprising.  Since the implementation is this broken I don't see any
point in discussing this particular case here - that is, no one here
will be able to answer why a broken implementation is broken or why an
operator uses that broken implementation.  You'll just need to talk to
that operator.

--
JINMEI, Tatuya


From nobody Wed Jul 12 22:17:48 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CAC12EA95 for ; Wed, 12 Jul 2017 22:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Rb3AHXxt0AVW for ; Wed, 12 Jul 2017 22:17:45 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E63129B33 for ; Wed, 12 Jul 2017 22:17:45 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 72AE960752; Thu, 13 Jul 2017 07:17:43 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 57A4C1800A6; Thu, 13 Jul 2017 07:17:43 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0352.000; Thu, 13 Jul 2017 07:17:42 +0200
From: 
To: =?utf-8?B?56We5piO6YGU5ZOJ?= , Alexandre Petrescu 
CC: "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
Thread-Index: AQHS+yHDqDR6wtIT8E68vsezjpTnM6JQRxsAgADvfjA=
Date: Thu, 13 Jul 2017 05:17:42 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A0044C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Jul 2017 05:17:47 -0000

RGVhciBKaW5tZWksIA0KDQpJIGZ1bGx5IGFncmVlIHRoYXQgdGhlcmUgaXMgbm8gcG9pbnQgdG8g
ZGlzY3VzcyBhIGJyb2tlbiBpbXBsZW1lbnRhdGlvbi4gDQoNCkFsZXggc2VlbXMgdG8gdXNlIGEg
VEUvTVMgc3BsaXQgbW9kZS4gU28gdGhlIGFkZHJlc3NlcyBoZSBpcyBzZWVpbmcgYXJlIG5vdCBj
b21pbmcgZnJvbSB0aGUgbmV0d29yay4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdl
IGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm
Lm9yZ10gRGUgbGEgcGFydCBkZSA/Pz8/DQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTIganVpbGxl
dCAyMDE3IDE4OjU0DQo+IMOAwqA6IEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiBDY8KgOiB2Nm9wc0Bp
ZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBSRkM2NDU5ICJJUHY2IGluIDNHUFAiIC0g
dGhlIElJRCBpbiB0aGUgTEwgYWRkcmVzcyBhbmQNCj4gR1VBDQo+IA0KPiBBdCBXZWQsIDEyIEp1
bCAyMDE3IDE3OjE1OjUyICswMjAwLA0KPiBBbGV4YW5kcmUgUGV0cmVzY3UgPGFsZXhhbmRyZS5w
ZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gPiA+IElmIHlvdSByZWFsbHkgc2VlIGFu
IFJBIHdpdGggYSBub24tTEwgc291cmNlIGFkZHJlc3MsIGEgdGV4dHVhbA0KPiA+ID4gc25pcHBl
dCBvZiB0aGUgcGFja2V0IGR1bXAgd2lsbCBjZXJ0YWlubHkgYmUgaW50ZXJlc3RpbmcuDQo+ID4N
Cj4gPiBBIHRleHR1YWwgc25pcHBldCBtYXkgaW5jbHVkZSBhZGRyZXNzZXMgdGhhdCBhcmUgY29u
c2lkZXJlZCBwcml2YXRlLg0KPiA+IEJ1dCBJIHdpbGwgc2VuZCB5b3UgcHJpdmF0ZWx5IHRoZSBz
bmlwcGV0Lg0KPiANCj4gWW91IGNvdWxkIG1hc2sgdGhlIHNlbnNpdGl2ZSBwYXJ0IG9mIGl0LCBi
dXQsIGFueXdheSwgSSBhY3R1YWxseSBzZWUNCj4gUkFzIHNlbnQgZnJvbSBhIGdsb2JhbCBhZGRy
ZXNzLiAgSSBkb24ndCBrbm93IHdoeSBpdCBiZWhhdmVzIHRoYXQgd2F5LA0KPiBidXQgaXQncyBu
byBzZWNyZXQgdGhhdCB0aGVyZSBhcmUgYnJva2VuIGltcGxlbWVudGF0aW9ucyBzbyBpdCdzIG5v
dA0KPiBzdXJwcmlzaW5nLiAgU2luY2UgdGhlIGltcGxlbWVudGF0aW9uIGlzIHRoaXMgYnJva2Vu
IEkgZG9uJ3Qgc2VlIGFueQ0KPiBwb2ludCBpbiBkaXNjdXNzaW5nIHRoaXMgcGFydGljdWxhciBj
YXNlIGhlcmUgLSB0aGF0IGlzLCBubyBvbmUgaGVyZQ0KPiB3aWxsIGJlIGFibGUgdG8gYW5zd2Vy
IHdoeSBhIGJyb2tlbiBpbXBsZW1lbnRhdGlvbiBpcyBicm9rZW4gb3Igd2h5IGFuDQo+IG9wZXJh
dG9yIHVzZXMgdGhhdCBicm9rZW4gaW1wbGVtZW50YXRpb24uICBZb3UnbGwganVzdCBuZWVkIHRv
IHRhbGsgdG8NCj4gdGhhdCBvcGVyYXRvci4NCj4gDQo+IC0tDQo+IEpJTk1FSSwgVGF0dXlhDQo+
IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2
Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K


From nobody Thu Jul 13 02:40:44 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28221131895 for ; Thu, 13 Jul 2017 02:40:42 -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 Pmxhy7tgGGq6 for ; Thu, 13 Jul 2017 02:40:40 -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 655F0131892 for ; Thu, 13 Jul 2017 02:40:40 -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 v6D9ecOp047531; Thu, 13 Jul 2017 11:40:38 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B268D203E29; Thu, 13 Jul 2017 11:40:38 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A2CEE203A6F; Thu, 13 Jul 2017 11:40:38 +0200 (CEST)
Received: from [132.166.84.227] ([132.166.84.227]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6D9ebu0029773; Thu, 13 Jul 2017 11:40:38 +0200
To: mohamed.boucadair@orange.com
Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com>  <787AE7BB302AE849A7480A190F8B93300A0044C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: <8a632768-41b1-a7f2-e30e-65313b89ba1c@gmail.com>
Date: Thu, 13 Jul 2017 11:40:37 +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: <787AE7BB302AE849A7480A190F8B93300A0044C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Jul 2017 09:40:42 -0000

As for the RAs with GUA in src:

I may check the modemDaemon of Sierra Legato to see whether it is that 
generates these RAs with GUA in src, but I really doubt.

Why do you think these RAs dont come from the network?

Alex

Le 13/07/2017 à 07:17, mohamed.boucadair@orange.com a écrit :
> Dear Jinmei,
> 
> I fully agree that there is no point to discuss a broken implementation.
> 
> Alex seems to use a TE/MS split mode. So the addresses he is seeing are not coming from the network.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de ????
>> Envoyé : mercredi 12 juillet 2017 18:54
>> À : Alexandre Petrescu
>> Cc : v6ops@ietf.org
>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and
>> GUA
>>
>> At Wed, 12 Jul 2017 17:15:52 +0200,
>> Alexandre Petrescu  wrote:
>>
>>>> If you really see an RA with a non-LL source address, a textual
>>>> snippet of the packet dump will certainly be interesting.
>>>
>>> A textual snippet may include addresses that are considered private.
>>> But I will send you privately the snippet.
>>
>> You could mask the sensitive part of it, but, anyway, I actually see
>> RAs sent from a global address.  I don't know why it behaves that way,
>> but it's no secret that there are broken implementations so it's not
>> surprising.  Since the implementation is this broken I don't see any
>> point in discussing this particular case here - that is, no one here
>> will be able to answer why a broken implementation is broken or why an
>> operator uses that broken implementation.  You'll just need to talk to
>> that operator.
>>
>> --
>> JINMEI, Tatuya
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Jul 13 02:43:31 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A46131897 for ; Thu, 13 Jul 2017 02:43:30 -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 IiCDt_DDhe1d for ; Thu, 13 Jul 2017 02:43:28 -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 3DC31131895 for ; Thu, 13 Jul 2017 02:43:28 -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 v6D9hQJA012331; Thu, 13 Jul 2017 11:43:26 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8A9AE203BF1; Thu, 13 Jul 2017 11:43:26 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7A763203A78; Thu, 13 Jul 2017 11:43:26 +0200 (CEST)
Received: from [132.166.84.227] ([132.166.84.227]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6D9hPrJ032154; Thu, 13 Jul 2017 11:43:25 +0200
To: mohamed.boucadair@orange.com, =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Cc: "v6ops@ietf.org" 
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com>  <787AE7BB302AE849A7480A190F8B93300A0044C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Alexandre Petrescu 
Message-ID: <7efc2597-ad20-d15b-ccc1-b7fd0d97b68b@gmail.com>
Date: Thu, 13 Jul 2017 11:43:25 +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: <787AE7BB302AE849A7480A190F8B93300A0044C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - TE/MS split mode?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Jul 2017 09:43:30 -0000

What is a TE/MS split mode?

Alex

Le 13/07/2017 à 07:17, mohamed.boucadair@orange.com a écrit :
> Dear Jinmei,
> 
> I fully agree that there is no point to discuss a broken implementation.
> 
> Alex seems to use a TE/MS split mode. So the addresses he is seeing are not coming from the network.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de ????
>> Envoyé : mercredi 12 juillet 2017 18:54
>> À : Alexandre Petrescu
>> Cc : v6ops@ietf.org
>> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and
>> GUA
>>
>> At Wed, 12 Jul 2017 17:15:52 +0200,
>> Alexandre Petrescu  wrote:
>>
>>>> If you really see an RA with a non-LL source address, a textual
>>>> snippet of the packet dump will certainly be interesting.
>>>
>>> A textual snippet may include addresses that are considered private.
>>> But I will send you privately the snippet.
>>
>> You could mask the sensitive part of it, but, anyway, I actually see
>> RAs sent from a global address.  I don't know why it behaves that way,
>> but it's no secret that there are broken implementations so it's not
>> surprising.  Since the implementation is this broken I don't see any
>> point in discussing this particular case here - that is, no one here
>> will be able to answer why a broken implementation is broken or why an
>> operator uses that broken implementation.  You'll just need to talk to
>> that operator.
>>
>> --
>> JINMEI, Tatuya
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Jul 13 04:33:02 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6B2126D73 for ; Thu, 13 Jul 2017 04:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MKUTKzL5sO0Z for ; Thu, 13 Jul 2017 04:33:01 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3960F12ECCB for ; Thu, 13 Jul 2017 04:32:59 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id C9DECA04B6; Thu, 13 Jul 2017 13:32:57 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 9FE071A008F; Thu, 13 Jul 2017 13:32:57 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0352.000; Thu, 13 Jul 2017 13:32:57 +0200
From: 
To: Alexandre Petrescu , =?utf-8?B?56We5piO6YGU5ZOJ?= 
CC: "v6ops@ietf.org" 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - TE/MS split mode?
Thread-Index: AQHS+7x70awen34woU+GrnWOaIskkaJRn2aQ
Date: Thu, 13 Jul 2017 11:32:56 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A006E6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <00d03635-4b5d-f4df-d3c2-1e7d69653bc9@gmail.com>  <787AE7BB302AE849A7480A190F8B93300A0044C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7efc2597-ad20-d15b-ccc1-b7fd0d97b68b@gmail.com>
In-Reply-To: <7efc2597-ad20-d15b-ccc1-b7fd0d97b68b@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - TE/MS split mode?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Jul 2017 11:33:02 -0000

UmUtLA0KDQpJIG1lYW50IFRFL01ULiANCg0KSSBjYW4gZGlyZWN0IHlvdSB0byAzR1BQIHNwZWNz
LCBidXQgdGhlIGtleSBwb2ludCBpcyBuaWNlbHkgc3VtbWFyaXplZCBoZXJlOiANCmh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDY2I3NlY3Rpb24tMi40IA0KDQpDaGVlcnMsDQpNZWQN
Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQWxleGFuZHJlIFBldHJl
c2N1IFttYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBq
ZXVkaSAxMyBqdWlsbGV0IDIwMTcgMTE6NDMNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1U
L09MTjsg56We5piO6YGU5ZOJDQo+IENjwqA6IHY2b3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJl
OiBbdjZvcHNdIFJGQzY0NTkgIklQdjYgaW4gM0dQUCIgLSBURS9NUyBzcGxpdCBtb2RlPw0KPiAN
Cj4gV2hhdCBpcyBhIFRFL01TIHNwbGl0IG1vZGU/DQo+IA0KPiBBbGV4DQo+IA0KPiBMZSAxMy8w
Ny8yMDE3IMOgIDA3OjE3LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIGEgw6ljcml0IDoN
Cj4gPiBEZWFyIEppbm1laSwNCj4gPg0KPiA+IEkgZnVsbHkgYWdyZWUgdGhhdCB0aGVyZSBpcyBu
byBwb2ludCB0byBkaXNjdXNzIGEgYnJva2VuIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4gQWxl
eCBzZWVtcyB0byB1c2UgYSBURS9NUyBzcGxpdCBtb2RlLiBTbyB0aGUgYWRkcmVzc2VzIGhlIGlz
IHNlZWluZyBhcmUNCj4gbm90IGNvbWluZyBmcm9tIHRoZSBuZXR3b3JrLg0KPiA+DQo+ID4gQ2hl
ZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+
PiBEZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk
ZSA/Pz8/DQo+ID4+IEVudm95w6kgOiBtZXJjcmVkaSAxMiBqdWlsbGV0IDIwMTcgMTg6NTQNCj4g
Pj4gw4AgOiBBbGV4YW5kcmUgUGV0cmVzY3UNCj4gPj4gQ2MgOiB2Nm9wc0BpZXRmLm9yZw0KPiA+
PiBPYmpldCA6IFJlOiBbdjZvcHNdIFJGQzY0NTkgIklQdjYgaW4gM0dQUCIgLSB0aGUgSUlEIGlu
IHRoZSBMTCBhZGRyZXNzDQo+IGFuZA0KPiA+PiBHVUENCj4gPj4NCj4gPj4gQXQgV2VkLCAxMiBK
dWwgMjAxNyAxNzoxNTo1MiArMDIwMCwNCj4gPj4gQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5k
cmUucGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4+PiBJZiB5b3UgcmVhbGx5
IHNlZSBhbiBSQSB3aXRoIGEgbm9uLUxMIHNvdXJjZSBhZGRyZXNzLCBhIHRleHR1YWwNCj4gPj4+
PiBzbmlwcGV0IG9mIHRoZSBwYWNrZXQgZHVtcCB3aWxsIGNlcnRhaW5seSBiZSBpbnRlcmVzdGlu
Zy4NCj4gPj4+DQo+ID4+PiBBIHRleHR1YWwgc25pcHBldCBtYXkgaW5jbHVkZSBhZGRyZXNzZXMg
dGhhdCBhcmUgY29uc2lkZXJlZCBwcml2YXRlLg0KPiA+Pj4gQnV0IEkgd2lsbCBzZW5kIHlvdSBw
cml2YXRlbHkgdGhlIHNuaXBwZXQuDQo+ID4+DQo+ID4+IFlvdSBjb3VsZCBtYXNrIHRoZSBzZW5z
aXRpdmUgcGFydCBvZiBpdCwgYnV0LCBhbnl3YXksIEkgYWN0dWFsbHkgc2VlDQo+ID4+IFJBcyBz
ZW50IGZyb20gYSBnbG9iYWwgYWRkcmVzcy4gIEkgZG9uJ3Qga25vdyB3aHkgaXQgYmVoYXZlcyB0
aGF0IHdheSwNCj4gPj4gYnV0IGl0J3Mgbm8gc2VjcmV0IHRoYXQgdGhlcmUgYXJlIGJyb2tlbiBp
bXBsZW1lbnRhdGlvbnMgc28gaXQncyBub3QNCj4gPj4gc3VycHJpc2luZy4gIFNpbmNlIHRoZSBp
bXBsZW1lbnRhdGlvbiBpcyB0aGlzIGJyb2tlbiBJIGRvbid0IHNlZSBhbnkNCj4gPj4gcG9pbnQg
aW4gZGlzY3Vzc2luZyB0aGlzIHBhcnRpY3VsYXIgY2FzZSBoZXJlIC0gdGhhdCBpcywgbm8gb25l
IGhlcmUNCj4gPj4gd2lsbCBiZSBhYmxlIHRvIGFuc3dlciB3aHkgYSBicm9rZW4gaW1wbGVtZW50
YXRpb24gaXMgYnJva2VuIG9yIHdoeSBhbg0KPiA+PiBvcGVyYXRvciB1c2VzIHRoYXQgYnJva2Vu
IGltcGxlbWVudGF0aW9uLiAgWW91J2xsIGp1c3QgbmVlZCB0byB0YWxrIHRvDQo+ID4+IHRoYXQg
b3BlcmF0b3IuDQo+ID4+DQo+ID4+IC0tDQo+ID4+IEpJTk1FSSwgVGF0dXlhDQo+ID4+DQo+ID4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHY2
b3BzIG1haWxpbmcgbGlzdA0KPiA+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo=


From nobody Fri Jul 14 03:33:46 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1906131B21 for ; Fri, 14 Jul 2017 03:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.101
X-Spam-Level: 
X-Spam-Status: No, score=-7.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhEJMzW2jJOH for ; Fri, 14 Jul 2017 03:33:43 -0700 (PDT)
Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 7117A131B24 for ; Fri, 14 Jul 2017 03:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1500028422; x=1531564422; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C2g59kX2r4AXePlOHTA+dye5oxWEU5NYvdegwKb65aA=; b=0t0db79OJtyFbTBAgk5V/C9OB8kSgTbZhNlJ69qiCJfDxwrrftgWPkrZ LxbBy4rS3koilV6l9tx4AWayQt0nLl28w7+wKbZsqlbquFkHiBtH6wKI/ q69rkvrcu0z5fTzFYs0leBud57al7kwqKknpPztytBsGQokuTaVfcsfZC 6NJ9tJE34ky+MqVy4GRYzT1Jjjj7PuJeiQIwbjvWouAewwv36NC/7xtZU u9xXGyJH/TIbJ+wO0nkqKBIfNKgop/onG3lWFBFQnsCg9cW9fOD1Dgx4p Fkv9KpbGZoxrJgmmAMLmWEwFQ//0+O6pBELJ5+BdMPv+dKbbSVr/ICHc9 A==;
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2017 12:33:40 +0200
X-IronPort-AV: E=Sophos;i="5.40,358,1496095200"; d="scan'208";a="1354541446"
Received: from he199743.emea1.cds.t-internal.com ([10.169.119.51]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 14 Jul 2017 12:33:23 +0200
Received: from HE199744.EMEA1.cds.t-internal.com (10.169.119.52) by HE199743.emea1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Jul 2017 12:33:04 +0200
Received: from HE199744.EMEA1.cds.t-internal.com ([fe80::3435:eb51:d048:836d]) by HE199744.emea1.cds.t-internal.com ([fe80::3435:eb51:d048:836d%26]) with mapi id 15.00.1263.000; Fri, 14 Jul 2017 12:33:04 +0200
From: 
To: 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
Thread-Index: AQHS+wPtmFRdIBFLB06xmR8ahfsFoKJP8KaAgAAFnYCAAyt2oA==
Date: Fri, 14 Jul 2017 10:33:04 +0000
Message-ID: <2ff7a4128d1d424f84c35ddcd3eec0fe@HE199744.emea1.cds.t-internal.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com>
In-Reply-To: <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.171.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Jul 2017 10:33:45 -0000

U2VlIGJlbG93IHdpdGggW0hNXQ0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0K
Vm9uOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9u
IEFsZXhhbmRyZSBQZXRyZXNjdQ0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAxMi4gSnVsaSAyMDE3IDE0
OjA0DQpBbjogTG9yZW56byBDb2xpdHRpDQpDYzogdjZvcHNAaWV0Zi5vcmcNCkJldHJlZmY6IFJl
OiBbdjZvcHNdIFJGQzY0NTkgIklQdjYgaW4gM0dQUCIgLSB0aGUgSUlEIGluIHRoZSBMTCBhZGRy
ZXNzIGFuZCBHVUENCg0KDQpJIHNlZSBpdCB3aXRoIHRjcGR1bXAgb24gYSBTaWVycmEgSW9UIG1v
ZHVsZSBydW5uaW5nIGEgZm9ybSBvZiBlbWJlZGRlZA0KbGludXgsIGdudWVhYmkgaXMgdGhlIHRh
cmdldCBvZiB0aGUgY3Jvc3MgY29tcGlsZXIuICBJdCB1c2VzIC9kZXYvdHR5QVQNCmRldmljZS4N
CltITV0gV1dBTiBNb2RlbSBDaGlwc2V0cyBwZXJmb3JtIHNvbWUga2luZCBvZiB0cmFuc2xhdGlv
biBvZiBwYWNrZXRzLCBlc3BlY2lhbGx5IElDTVB2NiBwYWNrZXRzLCBiZXR3ZWVuIHRoZSBpbnRl
cmZhY2UgdG8gdGhlIGNvbXB1dGVyIGFuZCB0aGUgaW50ZXJmYWNlIHRvd2FyZHMgdGhlIHByb3Zp
ZGVyIG5ldHdvcmsuIFRoZSByZWFzb24gaXMgdGhhdCB0aGUgY29tcHV0ZXIgd2FudHMgdG8gc2Vl
IGFuIEV0aGVybmV0IGJyb2FkY2FzdCBpbnRlcmZhY2UsIGJ1dCB0aGUgcHJvdmlkZXIgaW50ZXJm
YWNlIGlzIHBvaW50LXRvLXBvaW50LiBGb3IgZXhhbXBsZSwgdGhlIGNvbXB1dGVyIG5lZWRzIE5l
aWdoYm9yIERpc2NvdmVyeSBidXQgdGhpcyBpcyBub3QgYXZhaWxhYmxlIG9uIHRoZSBwcm92aWRl
ciBpbnRlcmZhY2UuIFRoZSBwcm92aWRlcidzIG5ldHdvcmsgZGV2aWNlIGRvZXNuJ3QgaGF2ZSBh
IE1BQyBhZGRyZXNzIGVpdGhlciwgc28gdGhlIG1vZGVtIGNoaXBzZXQgZW11bGF0ZXMgdGhpcyBt
aXNzaW5nIE1BQyB0byB0aGUgY29tcHV0ZXIuDQoNClNvIHdoYXQgeW91IGNhcHR1cmUgb24gV1dB
TjAgKG9yIGhvd2V2ZXIgeW91ciBjb21wdXRlciBpbnRlcmZhY2UgaXMgbmFtZWQpIGlzIG5vdCB3
aGF0IGFjdHVhbGx5IGdvZXMgb3ZlciB0aGUgYWlyLg0KDQpIb2xnZXINCg==


From nobody Fri Jul 14 12:02:30 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48215131548 for ; Fri, 14 Jul 2017 12:02:29 -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 tBiSWw_oIcgh for ; Fri, 14 Jul 2017 12:02:27 -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 0DDD8129BA4 for ; Fri, 14 Jul 2017 12:02:26 -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 v6EJ2PsE021006 for ; Fri, 14 Jul 2017 21:02:25 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 018DA203425 for ; Fri, 14 Jul 2017 21:02:25 +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 EC2DA20339B for ; Fri, 14 Jul 2017 21:02:24 +0200 (CEST)
Received: from [132.166.84.71] ([132.166.84.71]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6EJ2NDR007577 for ; Fri, 14 Jul 2017 21:02:24 +0200
To: v6ops@ietf.org
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com> <2ff7a4128d1d424f84c35ddcd3eec0fe@HE199744.emea1.cds.t-internal.com>
From: Alexandre Petrescu 
Message-ID: 
Date: Fri, 14 Jul 2017 21:02:23 +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: <2ff7a4128d1d424f84c35ddcd3eec0fe@HE199744.emea1.cds.t-internal.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Jul 2017 19:02:29 -0000

Le 14/07/2017 à 12:33, holger.metschulat@telekom.de a écrit :
> See below with [HM] -----Ursprüngliche Nachricht----- Von: v6ops 
> [mailto:v6ops-bounces@ietf.org] Im Auftrag von Alexandre Petrescu 
> Gesendet: Mittwoch, 12. Juli 2017 14:04 An: Lorenzo Colitti Cc: 
> v6ops@ietf.org Betreff: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID 
> in the LL address and GUA
> 
> 
> I see it with tcpdump on a Sierra IoT module running a form of 
> embedded linux, gnueabi is the target of the cross compiler.  It
> uses /dev/ttyAT device.

> [HM] WWAN Modem Chipsets perform some kind of translation of packets,

This seems like a generalisation.  I do not understand what do you mean 
by WWAN Modem Chipsets - can you give an example of a WWAN Modem Chipset?

In my particular case there is no separated Modem Chipset from an 
Application Chipset, or App Processor vs. Broadband Processor, or 
something like that that one can find in many smartphones.  Or like 
Host-IMP distinciton of early RFCs.

In my case it is an IoT device.  It is called an "integrated module" and 
it runs linux.  It is from Sierra, format CF3, series WP8.

There is only one module running both linux and the cellular interface.

> especially ICMPv6 packets, between the interface to the computer and
> the interface towards the provider network. The reason is that the
> computer wants to see an Ethernet broadcast interface, but the
> provider interface is point-to-point. For example, the computer needs
> Neighbor Discovery but this is not available on the provider
> interface. The provider's network device doesn't have a MAC address
> either, so the modem chipset emulates this missing MAC to the
> computer.

Do you think it is a linux kernel module that performs that emulation, 
or is it completely another OS (like ThreadX)?

That emulation must be standardised.

> So what you capture on WWAN0 (or however your computer interface is 
> named) is not what actually goes over the air.

If you think that something else goes over the air, can you tell me how, 
or what capturing tool, did you find out that there is something else 
over the air?

My operator asks me the same thing - what goes over the air - and I dont 
know what to answer.

Alex


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


From nobody Sun Jul 16 21:22:56 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD861316C2; Sun, 16 Jul 2017 11:29:05 -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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZZ26WHmvCHp; Sun, 16 Jul 2017 11:29:03 -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 40F3A12702E; Sun, 16 Jul 2017 11:29:03 -0700 (PDT)
X-AuditID: 60721c4c-4576e9a000004e62-cc-596bb06c3ee5
Received: from VAADCEX13.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 26.3F.20066.C60BB695; Sun, 16 Jul 2017 14:29:00 -0400 (EDT)
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX13.cable.comcast.com (147.191.102.80) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 16 Jul 2017 14:28:58 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Sun, 16 Jul 2017 14:28:58 -0400
From: "Brzozowski, John" 
To: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
CC: Randy Bush , Alissa Cooper , Jim Martin , Jari Arkko , Suresh Krishnan , Russ Housley 
Thread-Topic: Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/mFjyacM1/hfIEykN3ouQq0Z3w==
Date: Sun, 16 Jul 2017 18:28:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.252]
Content-Type: text/plain; charset="utf-8"
Content-ID: <81B121D76221E340A120022E53A6DCE2@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf0wTZxjed3elB/LN46DtRwVib8NkxCFsk3TuR/xDhmYucf8s6RYDRznb o9eW3bUI+5H0H5cFtsQsCxvV+IOAE+JAiPiDsOlqIwNDHJuuOhc3B1F0y2ZcxBgd2/f1rnDd X33ved73eZ737eVYmn+Y62TlUERSQ6Ii5OQxDdoW99PK0YCn6upezn1jeD/jvjX9F+U+e2iU cvePn7a6z5/7it5o2dzb+4DaBt7Me7FJUuRWSV33ckOe/5+JL5iWn8vb7h2essTAr092gFwW cc+h2eFHVAfIY3nuBIUuje1m9IczAB1PPQL6wyRA1wfvATKSw9WgY99ctXYAli3iNHRzlic9 NHcFoLm+LgvpKeQ2ofHUDaD3bEH/XqogcBFXiYbnO9MtDFeORj45ZyU1xO13982n5QFnR/en jlCkpjkH+mluP6Un5VDv+AVar23o1uxiWseGNX+808/o+Fo0nZoDel2FRvu+NnAXWtwzxJA4 NPcUGhpbp8tvQBND3Va9dqFPO68bcQrQZPecMepAZ5MnLbtBcdyUKL6sFDcpxU1KcZPSAWAZ AGWtotjkDfrD0UjVM5VesVGRKr3hoFfUIuR3BJB/WC3ZehLc7dqcABwLhHw40xXw8BaxVWsP JkCApQQbnMnB0OON4aZ2v6j569WoImlCEWx4tdnDwyW4MaoEBCdcM4ibC5fQkLRTU6QIfqWE MthDhBxLnBbVWmSvHI5q9VFVSQDE0lh2w2e4CTaJ7e9Ialg3S4BVLCM44JpT2JHziREpIEkt kpphd7KsgOC+ITxYoEo+qW2HrEQyNJ4bJJk4M5MOWwrdSdnD282EKa8LvkBop5n+f2SKzU0A H5uPc79N7KHWIgY12WdYF8LQWzhyfgZN2xbDYdLKZ0CTZSl8w4ope4bKtpsCnYCNf/5ggWKP Pfz2PsUzoXBIcjrgQno/MuSPhpYWd9rh5OsNHn6liSABnCXwI4LbTPhyBudqOE/YYhObHSPz YbgNvPiNKYS7yDb5+LOxvDcP+0ikFQaYXhvBvQQrMDDT1iXQQ7a2GUy22218Xgqf94NmPzlv RIyYz2sJ+Ml5DdQ472ME5DNg1nnDRMWeobKdnDFw/onuNvuBYG1tf+z96prRX5rl+V3rK0ro 9ReuuLQ9B8Xfr/lWhy729LjurMh5L3ni4kJxPV8wvVC7MlYnf/h82UxqoOZ729RLQl3qj+nG HT+oW1d9/Irt2uWk+vf4tptfbjo68Odva5/t/666bvviodjs8dKy7fCylrTBkYmN5e++dmpM YDS/WF1Bq5r4H+QKnxGOBQAA
Archived-At: 
X-Mailman-Approved-At: Sun, 16 Jul 2017 21:22:54 -0700
Subject: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Jul 2017 18:29:05 -0000

Rm9sa3MsDQoNCkFwb2xvZ2llcyBpbiBhZHZhbmNlIGZvciB0aGUgZ3JhdHVpdG91cyBjcm9zcyBw
b3N0aW5nICh2Nm9wcywgaWV0ZiwgaXB2Niwgc3Vuc2V0NCwgc29mdHdpcmVzKS4gIEkgaG9wZSwg
dG8geW91IGFsbCwgdGhpcyBpcyB3b3J0aCB0aGUgYWRkZWQgZW1haWwuDQoNClRoZSBkcmFmdCBi
ZWxvdyB3YXMgd3JpdHRlbiB0byBwcm92aWRlIHRoZSBuZWNlc3NhcnkgZG9jdW1lbnRhdGlvbiB0
byBlbmFibGUgdGhlIElFVEYgKHRoZSBOT0MsIHBhcnRpY2lwYW50cywgZXRjLikgdG8gbWlncmF0
ZSB0byBhbiBJUHY2IG9ubHkgcHJpbWFyeSBuZXR3b3JrIGNvbm5lY3Rpb24gKFdpLUZpIGFuZCB3
aXJlZCkgdGhhdCB1dGlsaXplcyBOQVQ2NCtETlM2NCB0byBhY2Nlc3MgSVB2NCBvbmx5IGNvbnRl
bnQuICBUaGUgcmVxdWVzdCBmb3IgSUVURiA5OSBoYXMgYmVlbiB0byBoYXZlIHRoZSBwcmltYXJ5
IOKAnGlldGbigJ0gU1NJRCBhZGhlcmUgdG8gd2hhdCBpcyBkb2N1bWVudGVkIGluIHRoZSBJLUQg
YmVsb3cuICBJIHRydXN0IHRoZSBtb3RpdmF0aW9uIGlzIHVuZGVyc3Rvb2QuICBUaGlzIG1lYW5z
IHRoYXQgdGhlIG1haW4g4oCcaWV0ZuKAnSBTU0lEIHdvdWxkIGJlIHN3aXRjaGVkIHRvIGJlIElQ
djYgb25seSB3aXRoIE5BVDY0K0ROUzY0IChhdCBsYXllciAzKSBwZXIgdGhlIEktRCBiZWxvdy4g
IEdpdmVuIHRoZSB0aGF0IElFVEY5OSBpcyB1cG9uIHVzLCB0aGlzIG1heSBvciBtYXkgbm90IGJl
IGVudGlyZWx5IHBvc3NpYmxlLg0KDQpBdCB0aGlzIHN0YWdlLCB0aGUgaW5mcmFzdHJ1Y3R1cmUg
cHJlcGFyYXRpb25zIGZvciBJRVRGIDk5IHNob3VsZCBiZSBpbiBwbGFjZSB0byBlbnN1cmUgdGhh
dCB0aGUgSUVURiBoYXMgdGhlIG5lY2Vzc2FyeSBoYXJkd2FyZSBmb3IgcmVkdW5kYW5jeSBhbmQg
cGVyZm9ybWFuY2UuDQoNClNvLCB3ZSBhcmUgYWxsIHNlZWtpbmcgeW91ciBpbnB1dC4gIEdpdmVu
IHRoZSBhYm92ZSwgd2hhdCB3b3VsZCBhbGwgeW91IHN1Z2dlc3QgaXMgdG9sZXJhYmxlIGZvciBJ
RVRGOTkgYXMgaXQgcGVydGFpbnMgdG8gdGhlIEktRCBiZWxvdz8NCg0K4oCiIElQdjYgb25seSBw
ZXIgdGhlIEktRCBmb3IgdGhlIGJhbGFuY2Ugb2YgSUVURiB3ZWVrPw0K4oCiIElQdjYgb25seSBw
ZXIgdGhlIEktRCBmb3Igb25lIG9yIG1vcmUgZGF5cyB0aGlzIHdlZWs/DQrigKIgSVB2NiBvbmx5
IHBlciB0aGUgSS1EIGZvciB0aGUgcGxlbmFyeT8NCuKAoiBJUHY2IG9ubHkgcGVyIHRoZSBJLUQg
Zm9yIHRoZSBuZXh0IElFVEYgbWVldGluZz8NCg0KUGxlYXNlIHNlbmQgdXMgeW91ciBmZWVkYmFj
ay4NCg0KUmVnYXJkcywNCg0KSm9obg0KKzEtNDg0LTk2Mi0wMDYwDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPg0KRGF0ZTogU2F0dXJkYXksIEp1bHkgMSwgMjAxNyBhdCAwMzowNA0K
VG86IE1hcmN1cyBLZWFuZSA8bWFyY3VzLmtlYW5lQG1pY3Jvc29mdC5jb20+LCBKZW4gTGlua292
YSA8ZnVycnlAZ29vZ2xlLmNvbT4sIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29t
PiwgSm9obiBCcnpvem93c2tpIDxKb2huX0Jyem96b3dza2lAQ2FibGUuQ29tY2FzdC5jb20+LCBF
cmlrIEtsaW5lIDxla0Bnb29nbGUuY29tPiwgSm9obiBCcnpvem93c2tpIDxKb2huX0Jyem96b3dz
a2lAQ2FibGUuQ29tY2FzdC5jb20+LCBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppQGFwcGxlLmNv
bT4sIFN0dWFydCBDaGVzaGlyZSA8Y2hlc2hpcmVAYXBwbGUuY29tPiwgSmVuIExpbmtvdmEgPGZ1
cnJ5QGdvb2dsZS5jb20+LCBQYXVsIFNhYWIgPHBzQGZiLmNvbT4sIERhdmlkIFNjaGluYXppIDxk
c2NoaW5hemlAYXBwbGUuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv
ciBkcmFmdC1qam1iLXY2b3BzLWlldGYtaXB2Ni1vbmx5LWluY3JlbWVudGFsLTAwLnR4dA0KDQog
ICAgDQogICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpqbWItdjZvcHMtaWV0Zi1pcHY2
LW9ubHktaW5jcmVtZW50YWwtMDAudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p
dHRlZCBieSBKb2huIEphc29uIEJyem96b3dza2kgYW5kIHBvc3RlZCB0byB0aGUNCiAgICBJRVRG
IHJlcG9zaXRvcnkuDQogICAgDQogICAgTmFtZToJCWRyYWZ0LWpqbWItdjZvcHMtaWV0Zi1pcHY2
LW9ubHktaW5jcmVtZW50YWwNCiAgICBSZXZpc2lvbjoJMDANCiAgICBUaXRsZToJCUluY3JlbWVu
dGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdpLUZpIGZvciBJRVRGIE1lZXRpbmdzDQogICAg
RG9jdW1lbnQgZGF0ZToJMjAxNy0wNi0zMA0KICAgIEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz
aW9uDQogICAgUGFnZXM6CQkxNQ0KICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamptYi12Nm9wcy1pZXRmLWlwdjYtb25seS1pbmNy
ZW1lbnRhbC0wMC50eHQNCiAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtamptYi12Nm9wcy1pZXRmLWlwdjYtb25seS1pbmNyZW1lbnRhbC8N
CiAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpq
bWItdjZvcHMtaWV0Zi1pcHY2LW9ubHktaW5jcmVtZW50YWwtMDANCiAgICBIdG1saXplZDogICAg
ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1qam1iLXY2b3Bz
LWlldGYtaXB2Ni1vbmx5LWluY3JlbWVudGFsLTAwDQogICAgDQogICAgDQogICAgQWJzdHJhY3Q6
DQogICAgICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0byBwcm92aWRlIGEgYmx1
ZXByaW50IGFuZCBndWlkYW5jZQ0KICAgICAgIGZvciBkZXBsb3lpbmcgSVB2Ni1vbmx5IFdpLUZp
IGF0IElFVEYgbWVldGluZ3MuICBUaGlzIGRvY3VtZW50DQogICAgICAgb3V0bGluZXMgaW5mcmFz
dHJ1Y3R1cmUgYW5kIG9wZXJhdGlvbmFsIGd1aWRhbmNlIHRoYXQgb3BlcmF0b3JzDQogICAgICAg
c2hvdWxkIGNvbnNpZGVyIHdoZW4gZGVwbG95aW5nIElQdjYtb25seSBuZXR3b3JrcyB1c2luZyBO
QVQ2NCBhbmQNCiAgICAgICBETlM2NCB0byBzdXBwb3J0IGNvbW11bmljYXRpb24gdG8gbGVnYWN5
IElQdjQtb25seSBzZXJ2aWNlcy4NCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv
ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1s
aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQog
ICAgDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICANCiAgICANCg0K


From nobody Sun Jul 16 22:25:58 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2811270B4 for ; Sun, 16 Jul 2017 22:25:57 -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 hFYgX64Q3dpg for ; Sun, 16 Jul 2017 22:25:54 -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 59FEE1252BA for ; Sun, 16 Jul 2017 22:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500269152; x=1500873952; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=0zcQ0MDxcT1nNBGh6NV+nmsyIDLX5DD7XGBLY9JCwfo=; b=Bz/ l2WZPmMr08DFANu/6jbISRVTmlorxqEIsDKE1PQ/rhJwSFYWs5ksRCcHH83+G3yG 2YmPzu35WpAZ5SrP5g/ccWc7310VTwqNVk7se1oXf8D3CQugMxcVHgT8hvTuLovS BqEwwolj9oiqW3jOOelhylDkTrkuYKTy027TKWbc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=hF3No12nvg3hOnyWFrlQagdOkOGRInCnNT8D9/nnpf+9DjOt1cjY9hrBw4H+ FLQrcaV5j/3x7b2e0bv9uPBicNxpb0W/N/hQCuDE+ej/Y1J76aOcn2j7U 83ODYEWm9qiE/nP2NG+rHG6P6p56O6Klu/uvfqxxITdmuU4e3bL/2s=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 07:25:52 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 07:25:51 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005477964.msg for ; Mon, 17 Jul 2017 07:25:50 +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:170717:md50005477964::T3M8uJkZa5Gp8LBI:00007E0K
X-MDRemoteIP: 31.133.186.43
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 07:24:24 +0200
From: JORDI PALET MARTINEZ 
To: 
CC: Jim Martin , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
Message-ID: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 05:25:57 -0000

In my opinion such kind of experiment should be only done once we approve t=
he document as RFC, note before, so by the next IETF meeting (hopefully).

We like it or not, this is not a valid option, unless we make sure that if =
some participants have troubles, the alternative SSIDs have other 2.4 and 5=
 GHz radios available. Is that the case?

The unfortunate reason this doesn=E2=80=99t work is that, still there are M=
ANY apps that use literals or old APIs, that don=E2=80=99t work with NAT64.

As I explained before, if the goal is to detect and test them, this can be =
done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the default SSI=
D, and then having an automatic logging of what apps/destination IPs), are =
using the CLAT.

Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are also=
 fine.

The result is the same as you=E2=80=99re proposing but non-intrusive and wi=
th the advantage of an automated logging of the failures.

The way you=E2=80=99re proposing, will mean that many folks may switch to a=
lternative SSID, or simply don't report those failures, so at the end you d=
on=E2=80=99t have any results of how much is not working, etc.

Regards,
Jordi
=20

-----Mensaje original-----
De: v6ops  en nombre de "Brzozowski, John" 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 6:23
Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
CC: Jim Martin , Alissa Cooper , Russ =
Housley , Randy Bush , Suresh Krishnan=
 
Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Folks,
   =20
    Apologies in advance for the gratuitous cross posting (v6ops, ietf, ipv=
6, sunset4, softwires).  I hope, to you all, this is worth the added email.
   =20
    The draft below was written to provide the necessary documentation to e=
nable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only pri=
mary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to acce=
ss IPv4 only content.  The request for IETF 99 has been to have the primary=
 =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I-D below.=
  I trust the motivation is understood.  This means that the main =E2=80=9C=
ietf=E2=80=9D SSID would be switched to be IPv6 only with NAT64+DNS64 (at l=
ayer 3) per the I-D below.  Given the that IETF99 is upon us, this may or m=
ay not be entirely possible.
   =20
    At this stage, the infrastructure preparations for IETF 99 should be in=
 place to ensure that the IETF has the necessary hardware for redundancy an=
d performance.
   =20
    So, we are all seeking your input.  Given the above, what would all you=
 suggest is tolerable for IETF99 as it pertains to the I-D below?
   =20
    =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
    =E2=80=A2 IPv6 only per the I-D for one or more days this week?
    =E2=80=A2 IPv6 only per the I-D for the plenary?
    =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
   =20
    Please send us your feedback.
   =20
    Regards,
   =20
    John
    +1-484-962-0060
   =20
    -----Original Message-----
    From: "internet-drafts@ietf.org" 
    Date: Saturday, July 1, 2017 at 03:04
    To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski , David Schinazi , Stuart =
Cheshire , Jen Linkova , Paul Saab , David Schinazi 
    Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-only-i=
ncremental-00.txt
   =20
       =20
        A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-incremental-0=
0.txt
        has been successfully submitted by John Jason Brzozowski and posted=
 to the
        IETF repository.
       =20
        Name:		draft-jjmb-v6ops-ietf-ipv6-only-incremental
        Revision:	00
        Title:		Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
        Document date:	2017-06-30
        Group:		Individual Submission
        Pages:		15
        URL:            https://www.ietf.org/internet-drafts/draft-jjmb-v6o=
ps-ietf-ipv6-only-incremental-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6ops-i=
etf-ipv6-only-incremental/
        Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ietf-i=
pv6-only-incremental-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjmb-v6=
ops-ietf-ipv6-only-incremental-00
       =20
       =20
        Abstract:
           The purpose of this document is to provide a blueprint and guida=
nce
           for deploying IPv6-only Wi-Fi at IETF meetings.  This document
           outlines infrastructure and operational guidance that operators
           should consider when deploying IPv6-only networks using NAT64 an=
d
           DNS64 to support communication to legacy IPv4-only services.
       =20
                                                                           =
              =20
       =20
       =20
        Please note that it may take a couple of minutes from the time of s=
ubmission
        until the htmlized version and diff are available at tools.ietf.org=
.
       =20
        The IETF Secretariat
       =20
       =20
       =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =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 Sun Jul 16 22:33:36 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC212EE45 for ; Sun, 16 Jul 2017 22:33:35 -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, 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=fugue-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 AU7yVZu9V7kr for ; Sun, 16 Jul 2017 22:33:31 -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 1D63912ECC3 for ; Sun, 16 Jul 2017 22:33:31 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id 123so751878pgj.1 for ; Sun, 16 Jul 2017 22:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7gVTvD5t5CgbHu4t7EDoDncngmfdcAoAyAMljAL2/U0=; b=Q62mcBRywWOlww9vaUtnQJyTDKX4PI3J9KcM60nPFVQJyXM3alVzSW1M/fLNRSlnrg O/3919jwo61DCXc7rLRdCSOH8tMcVsAz1Dmj4JkDxm5XZcmn+se6EgmGqEEpojwjGndd t9wsGku3nObfmz/3rrnqcx9/yAcBhjzZNwfZJpfaZ+tdvkg/3UByhRcJCAVUSbP9vtU7 aCni0lYEZDe//Egg4JW+hzFN4gJFWGeeOCtvw01v0xQ43/F82Etb214iygHb+9E7UO3l 6Rs0VqVQKjdb8eXgzIVYxwuEZAwj6WNPc7T0aqQdBm90zgAVj4VG3NZ3P4DzvV9DpfFR Q/fQ==
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=7gVTvD5t5CgbHu4t7EDoDncngmfdcAoAyAMljAL2/U0=; b=Ye+Csw9FszfAHEGyeovRWKojJma+RKsBYkoudtY45KEvGoeU7hyW/nqIV46WZ7AA1/ C3uG1PIOEJaOF+ksD7bgKhgHp+1mtY98OeWD40cUROVo8LcWaqg/FQzN/LvhsHEMYH1k n5WfrkCKTzYcbswClGhslVvCEhwMtSJb55XR/UaYf+Kfvt6mcNAP7uJGKpA2ux1ZdzKy tNoG0Twdo+5fNuzJaGczstR32slsnX+QTzKqxnHw0RpbsyfPbdyV28xfyz9G/zqMuDuh JDkujcids9Yd+u2c4modrm8u1b7Y7e0BEqar8lD+jdvgUpzo2d/0antoAGc6Ib0iQYDm cG6Q==
X-Gm-Message-State: AIVw112SgrqOh0PanQyXOOOSHa2uZsFTFKif6Q5LPqdrbq3/q1RnhqPi 2+B9c5OixclyZl8fLF90mEmJCM48GAEy
X-Received: by 10.84.132.39 with SMTP id 36mr28620168ple.237.1500269610590; Sun, 16 Jul 2017 22:33:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 22:33:30 -0700 (PDT)
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 22:33:30 -0700 (PDT)
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
From: Ted Lemon 
Date: Mon, 17 Jul 2017 07:33:30 +0200
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: Alissa Cooper , Suresh Krishnan , v6ops@ietf.org,  Jim Martin , Randy Bush , Russ Housley 
Content-Type: multipart/alternative; boundary="94eb2c12f71434ef0705547cbd34"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 05:33:35 -0000

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

Fwiw, I have found and fixed lots of problems as a result of using the
ietf-nat64 network. It is probably still try that some participants would
have trouble on that network, so there should be a legacy network for them.
But the default should be nat64. Dogfooding is really important. If you
have broken apps, feeling a little pain is a great way to motivate
complaining about it to the vendor.

On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ" 
wrote:

> In my opinion such kind of experiment should be only done once we approve
> the document as RFC, note before, so by the next IETF meeting (hopefully)=
.
>
> We like it or not, this is not a valid option, unless we make sure that i=
f
> some participants have troubles, the alternative SSIDs have other 2.4 and=
 5
> GHz radios available. Is that the case?
>
> The unfortunate reason this doesn=E2=80=99t work is that, still there are=
 MANY
> apps that use literals or old APIs, that don=E2=80=99t work with NAT64.
>
> As I explained before, if the goal is to detect and test them, this can b=
e
> done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the default S=
SID, and then
> having an automatic logging of what apps/destination IPs), are using the
> CLAT.
>
> Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are
> also fine.
>
> The result is the same as you=E2=80=99re proposing but non-intrusive and =
with the
> advantage of an automated logging of the failures.
>
> The way you=E2=80=99re proposing, will mean that many folks may switch to
> alternative SSID, or simply don't report those failures, so at the end yo=
u
> don=E2=80=99t have any results of how much is not working, etc.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: v6ops  en nombre de "Brzozowski, John" <
> John_Brzozowski@comcast.com>
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 6:23
> Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" <
> draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org>
> CC: Jim Martin , Alissa Cooper ,
> Russ Housley , Randy Bush , Suresh
> Krishnan 
> Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetin=
gs
>
>     Folks,
>
>     Apologies in advance for the gratuitous cross posting (v6ops, ietf,
> ipv6, sunset4, softwires).  I hope, to you all, this is worth the added
> email.
>
>     The draft below was written to provide the necessary documentation to
> enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only
> primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to
> access IPv4 only content.  The request for IETF 99 has been to have the
> primary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I=
-D below.  I trust
> the motivation is understood.  This means that the main =E2=80=9Cietf=E2=
=80=9D SSID would
> be switched to be IPv6 only with NAT64+DNS64 (at layer 3) per the I-D
> below.  Given the that IETF99 is upon us, this may or may not be entirely
> possible.
>
>     At this stage, the infrastructure preparations for IETF 99 should be
> in place to ensure that the IETF has the necessary hardware for redundanc=
y
> and performance.
>
>     So, we are all seeking your input.  Given the above, what would all
> you suggest is tolerable for IETF99 as it pertains to the I-D below?
>
>     =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
>     =E2=80=A2 IPv6 only per the I-D for one or more days this week?
>     =E2=80=A2 IPv6 only per the I-D for the plenary?
>     =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
>
>     Please send us your feedback.
>
>     Regards,
>
>     John
>     +1-484-962-0060
>
>     -----Original Message-----
>     From: "internet-drafts@ietf.org" 
>     Date: Saturday, July 1, 2017 at 03:04
>     To: Marcus Keane , Jen Linkova <
> furry@google.com>, Lorenzo Colitti , John Brzozowski =
<
> John_Brzozowski@Cable.Comcast.com>, Erik Kline , John
> Brzozowski , David Schinazi <
> dschinazi@apple.com>, Stuart Cheshire , Jen Linkova <
> furry@google.com>, Paul Saab , David Schinazi <
> dschinazi@apple.com>
>     Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-
> only-incremental-00.txt
>
>
>         A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-
> only-incremental-00.txt
>         has been successfully submitted by John Jason Brzozowski and
> posted to the
>         IETF repository.
>
>         Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
>         Revision:       00
>         Title:          Incremental Deployment of IPv6-only Wi-Fi for IET=
F
> Meetings
>         Document date:  2017-06-30
>         Group:          Individual Submission
>         Pages:          15
>         URL:            https://www.ietf.org/internet-
> drafts/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
>         Status:         https://datatracker.ietf.org/
> doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/
>         Htmlized:       https://tools.ietf.org/html/
> draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
>         Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
>
>
>         Abstract:
>            The purpose of this document is to provide a blueprint and
> guidance
>            for deploying IPv6-only Wi-Fi at IETF meetings.  This document
>            outlines infrastructure and operational guidance that operator=
s
>            should consider when deploying IPv6-only networks using NAT64
> and
>            DNS64 to support communication to legacy IPv4-only services.
>
>
>
>
>         Please note that it may take a couple of minutes from the time of
> submission
>         until the htmlized version and diff are available at
> tools.ietf.org.
>
>         The IETF Secretariat
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> **********************************************
> 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
> confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Fwiw, I have found and fixed lots of problems as a result=
 of using the ietf-nat64 network. It is probably still try that some partic=
ipants would have trouble on that network, so there should be a legacy netw=
ork for them. But the default should be nat64. Dogfooding is really importa=
nt. If you have broken apps, feeling a little pain is a great way to motiva=
te complaining about it to the vendor.=C2=A0

On Jul 17, 2017 7:26 AM, "JORDI PALET=
 MARTINEZ" <jordi.pal=
et@consulintel.es> wrote:
In my opinion such kind of experiment should be only done onc=
e we approve the document as RFC, note before, so by the next IETF meeting =
(hopefully).



We like it or not, this is not a valid option, unless we make sure that if =
some participants have troubles, the alternative SSIDs have other 2.4 and 5=
 GHz radios available. Is that the case?



The unfortunate reason this doesn=E2=80=99t work is that, still there are M=
ANY apps that use literals or old APIs, that don=E2=80=99t work with NAT64.=




As I explained before, if the goal is to detect and test them, this can be =
done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the default SSI=
D, and then having an automatic logging of what apps/destination IPs), are =
using the CLAT.



Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are also=
 fine.



The result is the same as you=E2=80=99re proposing but non-intrusive and wi=
th the advantage of an automated logging of the failures.



The way you=E2=80=99re proposing, will mean that many folks may switch to a=
lternative SSID, or simply don't report those failures, so at the end y=
ou don=E2=80=99t have any results of how much is not working, etc.



Regards,

Jordi





-----Mensaje original-----

De: v6ops <v6ops-bounces@ietf.=
org> en nombre de "Brzozowski, John" <John_Brzozowski@comcast.com>

Responder a: <John_Brzozo=
wski@comcast.com>

Fecha: lunes, 17 de julio de 2017, 6:23

Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org"=
; <draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org>

CC: Jim Martin <jim@daedelus.com=
>, Alissa Cooper <alissa@cooperw=
.in>, Russ Housley <housl=
ey@vigilsec.com>, Randy Bush <ra=
ndy@psg.com>, Suresh Krishnan <suresh.krishnan@gmail.com>

Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings=




=C2=A0 =C2=A0 Folks,



=C2=A0 =C2=A0 Apologies in advance for the gratuitous cross posting (v6ops,=
 ietf, ipv6, sunset4, softwires).=C2=A0 I hope, to you all, this is worth t=
he added email.



=C2=A0 =C2=A0 The draft below was written to provide the necessary document=
ation to enable the IETF (the NOC, participants, etc.) to migrate to an IPv=
6 only primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS=
64 to access IPv4 only content.=C2=A0 The request for IETF 99 has been to h=
ave the primary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in=
 the I-D below.=C2=A0 I trust the motivation is understood.=C2=A0 This mean=
s that the main =E2=80=9Cietf=E2=80=9D SSID would be switched to be IPv6 on=
ly with NAT64+DNS64 (at layer 3) per the I-D below.=C2=A0 Given the that IE=
TF99 is upon us, this may or may not be entirely possible.



=C2=A0 =C2=A0 At this stage, the infrastructure preparations for IETF 99 sh=
ould be in place to ensure that the IETF has the necessary hardware for red=
undancy and performance.



=C2=A0 =C2=A0 So, we are all seeking your input.=C2=A0 Given the above, wha=
t would all you suggest is tolerable for IETF99 as it pertains to the I-D b=
elow?



=C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?=


=C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for one or more days this wee=
k?

=C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for the plenary?

=C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?


=C2=A0 =C2=A0 Please send us your feedback.



=C2=A0 =C2=A0 Regards,



=C2=A0 =C2=A0 John

=C2=A0 =C2=A0 +1-484-962-0060



=C2=A0 =C2=A0 -----Original Message-----

=C2=A0 =C2=A0 From: "inter=
net-drafts@ietf.org" <internet-drafts@ietf.org>

=C2=A0 =C2=A0 Date: Saturday, July 1, 2017 at 03:04

=C2=A0 =C2=A0 To: Marcus Keane <marcus.keane@microsoft.com>, Jen Linkova <furry@google.com>, Lorenzo Colitti <lorenzo@google.com>, John Brzozowski <=
;John_Brzozowski@Cable=
.Comcast.com>, Erik Kline <=
ek@google.com>, John Brzozowski <John_Brzozowski@Cable.Comcast.com>, David =
Schinazi <dschinazi@apple.com=
>, Stuart Cheshire <cheshire@ap=
ple.com>, Jen Linkova <furry@=
google.com>, Paul Saab <ps@fb.com>, David Schinazi <dschinazi@=
apple.com>

=C2=A0 =C2=A0 Subject: New Version Notification for draft-jjmb-v6ops-ietf-i=
pv6-only-incremental-00.txt





=C2=A0 =C2=A0 =C2=A0 =C2=A0 A new version of I-D, draft-jjmb-v6ops-ietf-ipv=
6-only-incremental-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 has been successfully submitted by John Jason B=
rzozowski and posted to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF repository.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d=
raft-jjmb-v6ops-ietf-ipv6-only-incremental

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Increm=
ental Deployment of IPv6-only Wi-Fi for IETF Meetings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Document date:=C2=A0 2017-06-30

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi=
dual Submission

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
a href=3D"https://www.ietf.org/internet-drafts/draft-jjmb-v6ops-ietf-ipv6-o=
nly-incremental-00.txt" rel=3D"noreferrer" target=3D"_blank">https://www.ie=
tf.org/internet-drafts/draft-jjmb-v6ops-ietf-ipv6-only-incrementa=
l-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/=
doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draf=
t-jjmb-v6ops-ietf-ipv6-only-incremental-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.or=
g/doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00





=C2=A0 =C2=A0 =C2=A0 =C2=A0 Abstract:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The purpose of this document is to=
 provide a blueprint and guidance

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for deploying IPv6-only Wi-Fi at I=
ETF meetings.=C2=A0 This document

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0outlines infrastructure and operat=
ional guidance that operators

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should consider when deploying IPv=
6-only networks using NAT64 and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DNS64 to support communication to =
legacy IPv4-only services.









=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please note that it may take a couple of minute=
s from the time of submission

=C2=A0 =C2=A0 =C2=A0 =C2=A0 until the htmlized version and diff are availab=
le at tools.ietf.org.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 The IETF Secretariat









=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 v6ops mailing list

=C2=A0 =C2=A0 v6ops@ietf.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/v6ops









**********************************************

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.







_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--94eb2c12f71434ef0705547cbd34--


From nobody Sun Jul 16 22:41:18 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B05129B2E for ; Sun, 16 Jul 2017 22:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 SG7MRQXUBK7p for ; Sun, 16 Jul 2017 22:41:13 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9935F127735 for ; Sun, 16 Jul 2017 22:41:13 -0700 (PDT)
Received: from dhcp-8c46.meeting.ietf.org ([IPv6:2001:67c:370:128:74fb:850e:6664:172d]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v6H5f0AT079078 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 17 Jul 2017 05:41:02 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:128:74fb:850e:6664:172d] claimed to be dhcp-8c46.meeting.ietf.org
To: JORDI PALET MARTINEZ , v6ops@ietf.org
Cc: Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
From: joel jaeggli 
Message-ID: <9014511d-81d1-0e89-c00a-866e42ff2fdf@bogus.com>
Date: Mon, 17 Jul 2017 07:41:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0
MIME-Version: 1.0
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6s2S6ign0MEubD7apT7j5sMwwjth4Ajug"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 05:41:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6s2S6ign0MEubD7apT7j5sMwwjth4Ajug
Content-Type: multipart/mixed; boundary="n9vXuofaxQrql4ni5ebmguRqgtsqbcAxX";
 protected-headers="v1"
From: joel jaeggli 
To: JORDI PALET MARTINEZ , v6ops@ietf.org
Cc: Jim Martin , Russ Housley ,
 Suresh Krishnan ,
 Alissa Cooper , Randy Bush 
Message-ID: <9014511d-81d1-0e89-c00a-866e42ff2fdf@bogus.com>
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
 Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>

--n9vXuofaxQrql4ni5ebmguRqgtsqbcAxX
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 7/17/17 07:24, JORDI PALET MARTINEZ wrote:
> In my opinion such kind of experiment should be only done once we appro=
ve the document as RFC, note before, so by the next IETF meeting (hopeful=
ly).
>=20
> We like it or not, this is not a valid option, unless we make sure that=
 if some participants have troubles, the alternative SSIDs have other 2.4=
 and 5 GHz radios available. Is that the case?

That's not a serious consideration. the RF properties of the ssid are
indepedantly controlled by the access points themselves. All IETF ssids
are provided by the same sets of APs/Radios

> The unfortunate reason this doesn=E2=80=99t work is that, still there a=
re MANY apps that use literals or old APIs, that don=E2=80=99t work with =
NAT64.
>=20
> As I explained before, if the goal is to detect and test them, this can=
 be done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the defau=
lt SSID, and then having an automatic logging of what apps/destination IP=
s), are using the CLAT.
>=20
> Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are =
also fine.
>=20
> The result is the same as you=E2=80=99re proposing but non-intrusive an=
d with the advantage of an automated logging of the failures.
>=20
> The way you=E2=80=99re proposing, will mean that many folks may switch =
to alternative SSID, or simply don't report those failures, so at the end=
 you don=E2=80=99t have any results of how much is not working, etc.
>=20
> Regards,
> Jordi
> =20
>=20
> -----Mensaje original-----
> De: v6ops  en nombre de "Brzozowski, John" 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 6:23
> Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
> CC: Jim Martin , Alissa Cooper , R=
uss Housley , Randy Bush , Suresh Kr=
ishnan 
> Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings
>=20
>     Folks,
>    =20
>     Apologies in advance for the gratuitous cross posting (v6ops, ietf,=
 ipv6, sunset4, softwires).  I hope, to you all, this is worth the added =
email.
>    =20
>     The draft below was written to provide the necessary documentation =
to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 on=
ly primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64=
 to access IPv4 only content.  The request for IETF 99 has been to have t=
he primary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in th=
e I-D below.  I trust the motivation is understood.  This means that the =
main =E2=80=9Cietf=E2=80=9D SSID would be switched to be IPv6 only with N=
AT64+DNS64 (at layer 3) per the I-D below.  Given the that IETF99 is upon=
 us, this may or may not be entirely possible.
>    =20
>     At this stage, the infrastructure preparations for IETF 99 should b=
e in place to ensure that the IETF has the necessary hardware for redunda=
ncy and performance.
>    =20
>     So, we are all seeking your input.  Given the above, what would all=
 you suggest is tolerable for IETF99 as it pertains to the I-D below?
>    =20
>     =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
>     =E2=80=A2 IPv6 only per the I-D for one or more days this week?
>     =E2=80=A2 IPv6 only per the I-D for the plenary?
>     =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
>    =20
>     Please send us your feedback.
>    =20
>     Regards,
>    =20
>     John
>     +1-484-962-0060
>    =20
>     -----Original Message-----
>     From: "internet-drafts@ietf.org" 
>     Date: Saturday, July 1, 2017 at 03:04
>     To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski=
 , David Schinazi , Stuart Cheshire , Jen Linkova , =
Paul Saab , David Schinazi 
>     Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-on=
ly-incremental-00.txt
>    =20
>        =20
>         A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-increment=
al-00.txt
>         has been successfully submitted by John Jason Brzozowski and po=
sted to the
>         IETF repository.
>        =20
>         Name:		draft-jjmb-v6ops-ietf-ipv6-only-incremental
>         Revision:	00
>         Title:		Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings
>         Document date:	2017-06-30
>         Group:		Individual Submission
>         Pages:		15
>         URL:            https://www.ietf.org/internet-drafts/draft-jjmb=
-v6ops-ietf-ipv6-only-incremental-00.txt
>         Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6o=
ps-ietf-ipv6-only-incremental/
>         Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ie=
tf-ipv6-only-incremental-00
>         Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjm=
b-v6ops-ietf-ipv6-only-incremental-00
>        =20
>        =20
>         Abstract:
>            The purpose of this document is to provide a blueprint and g=
uidance
>            for deploying IPv6-only Wi-Fi at IETF meetings.  This docume=
nt
>            outlines infrastructure and operational guidance that operat=
ors
>            should consider when deploying IPv6-only networks using NAT6=
4 and
>            DNS64 to support communication to legacy IPv4-only services.=

>        =20
>                                                                        =
                  =20
>        =20
>        =20
>         Please note that it may take a couple of minutes from the time =
of submission
>         until the htmlized version and diff are available at tools.ietf=
=2Eorg.
>        =20
>         The IETF Secretariat
>        =20
>        =20
>        =20
>    =20
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>    =20
>=20
>=20
>=20
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>=20
> This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that=
 any disclosure, copying, distribution or use of the contents of this inf=
ormation, including attached files, is prohibited.
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20



--n9vXuofaxQrql4ni5ebmguRqgtsqbcAxX--

--6s2S6ign0MEubD7apT7j5sMwwjth4Ajug
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAllsTewACgkQ8AA1q7Z/VrIe8ACfahyDljrAUle6GXkLZ6V+Ggk3
T0cAn0kPdoI1SbjB67tp4kmPpeQsxEGq
=kX+x
-----END PGP SIGNATURE-----

--6s2S6ign0MEubD7apT7j5sMwwjth4Ajug--


From nobody Sun Jul 16 22:44:26 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5236012EC10 for ; Sun, 16 Jul 2017 22:44:24 -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 Xi9IbZNdMkr0 for ; Sun, 16 Jul 2017 22:44:22 -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 E9F1412ECC3 for ; Sun, 16 Jul 2017 22:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500270259; x=1500875059; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=3rqs7X40sQhqHsG96CU3zmSWE gYYDpdcNmmI7Ef0USM=; b=qSfblpez076cpmciERTCDZrW5tL/4OkGJvTdsXR1l jE6vFM0vSLYWsETDN8ONqolAS7FCSlYSz+gunLLZbPcXqt91OO+MWXeo1kATozDc W2x3SyDXTm2768cNSW32L67LSiXIoTQC7s02H8BsBboHHzHo+ivV7oMg6CSO/gNz No=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lebFH9RHDXKB9R+QvsNG3gIBAJzhUn9//PCrCZjuSawj32RmpcmwOTYxj7f+ c2w9JZdqz2iex5mZCNr5Tml/NMpmIlumNeaIqmdI5/EQtG4J1MYnOpPU5 f+SxRwzvjxPAEmUIAvMktaer/a2xHpDnk/huABDrYDh+SIs04qLg4Y=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 07:44:19 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 07:44:18 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005477980.msg for ; Mon, 17 Jul 2017 07:44:13 +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:170717:md50005477980::HmSM5iTOmtYipE7w:00000frP
X-MDRemoteIP: 31.133.186.43
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 07:44:07 +0200
From: JORDI PALET MARTINEZ 
To: 
CC: Alissa Cooper , Suresh Krishnan , , Jim Martin , Randy Bush , Russ Housley 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 05:44:24 -0000

What I=E2=80=99m saying is that using CLAT, you also have dogfooding, but n=
o disturbing any participants and allowing then to keep doing the work. Som=
e of us get paid only if we finish our work on time!

I always understood that the IETF network is not for experiments. If we all=
ow this, it means we are changing our policy from now on?

I recall previous occasions where it was clearly said that if an experiment=
 is going to affect other participants, it can=E2=80=99t be done.

As said, do the same with CLAT so participants aren=E2=80=99t affected and =
at least wait until the document is an RFC.

I=E2=80=99m pro-IPv6, I=E2=80=99m sure nobody doubts that, but work is firs=
t, rules as well.

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 7:33
Para: JORDI PALET MARTINEZ 
CC: Alissa Cooper , Suresh Krishnan , , Jim Martin , Randy Bush , Russ Housley 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    Fwiw, I have found and fixed lots of problems as a result of using the =
ietf-nat64 network. It is probably still try that some participants would h=
ave trouble on that network, so there should be a legacy network for them. =
But the default should be nat64. Dogfooding is really important. If you hav=
e broken apps, feeling a little pain is a great way to motivate complaining=
 about it to the vendor.=20
   =20
    On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ"  wrote:
   =20
    In my opinion such kind of experiment should be only done once we appro=
ve the document as RFC, note before, so by the next IETF meeting (hopefully=
).
   =20
    We like it or not, this is not a valid option, unless we make sure that=
 if some participants have troubles, the alternative SSIDs have other 2.4 a=
nd 5 GHz radios available. Is that the case?
   =20
    The unfortunate reason this doesn=E2=80=99t work is that, still there a=
re MANY apps that use literals or old APIs, that don=E2=80=99t work with NA=
T64.
   =20
    As I explained before, if the goal is to detect and test them, this can=
 be done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the default=
 SSID, and then having an automatic logging of what apps/destination IPs), =
are using the CLAT.
   =20
    Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are =
also fine.
   =20
    The result is the same as you=E2=80=99re proposing but non-intrusive an=
d with the advantage of an automated logging of the failures.
   =20
    The way you=E2=80=99re proposing, will mean that many folks may switch =
to alternative SSID, or simply don't report those failures, so at the end y=
ou don=E2=80=99t have any results of how much is not working, etc.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De: v6ops  en nombre de "Brzozowski, John" 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 6:23
    Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
    CC: Jim Martin , Alissa Cooper , R=
uss Housley , Randy Bush , Suresh Kris=
hnan 
    Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings
   =20
        Folks,
   =20
        Apologies in advance for the gratuitous cross posting (v6ops, ietf,=
 ipv6, sunset4, softwires).  I hope, to you all, this is worth the added em=
ail.
   =20
        The draft below was written to provide the necessary documentation =
to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only=
 primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to =
access IPv4 only content.  The request for IETF 99 has been to have the pri=
mary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I-D be=
low.  I trust the motivation is understood.  This means that the main =E2=
=80=9Cietf=E2=80=9D SSID would be switched to be IPv6 only with NAT64+DNS64=
 (at layer 3) per the I-D below.  Given the that IETF99 is upon us, this ma=
y or may not be entirely possible.
   =20
        At this stage, the infrastructure preparations for IETF 99 should b=
e in place to ensure that the IETF has the necessary hardware for redundanc=
y and performance.
   =20
        So, we are all seeking your input.  Given the above, what would all=
 you suggest is tolerable for IETF99 as it pertains to the I-D below?
   =20
        =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
        =E2=80=A2 IPv6 only per the I-D for one or more days this week?
        =E2=80=A2 IPv6 only per the I-D for the plenary?
        =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
   =20
        Please send us your feedback.
   =20
        Regards,
   =20
        John
        +1-484-962-0060
   =20
        -----Original Message-----
        From: "internet-drafts@ietf.org" 
        Date: Saturday, July 1, 2017 at 03:04
        To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski , David Schinazi , Stu=
art Cheshire , Jen Linkova , Paul Saa=
b , David Schinazi 
        Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-on=
ly-incremental-00.txt
   =20
   =20
            A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-increment=
al-00.txt
            has been successfully submitted by John Jason Brzozowski and po=
sted to the
            IETF repository.
   =20
            Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
            Revision:       00
            Title:          Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
            Document date:  2017-06-30
            Group:          Individual Submission
            Pages:          15
            URL:            https://www.ietf.org/internet-drafts/draft-jjmb=
-v6ops-ietf-ipv6-only-incremental-00.txt
            Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6o=
ps-ietf-ipv6-only-incremental/
            Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ie=
tf-ipv6-only-incremental-00
            Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjm=
b-v6ops-ietf-ipv6-only-incremental-00
   =20
   =20
            Abstract:
               The purpose of this document is to provide a blueprint and g=
uidance
               for deploying IPv6-only Wi-Fi at IETF meetings.  This docume=
nt
               outlines infrastructure and operational guidance that operat=
ors
               should consider when deploying IPv6-only networks using NAT6=
4 and
               DNS64 to support communication to legacy IPv4-only services.
   =20
   =20
   =20
   =20
            Please note that it may take a couple of minutes from the time =
of submission
            until the htmlized version and diff are available at tools.ietf=
.org .
   =20
            The IETF Secretariat
   =20
   =20
   =20
   =20
        _______________________________________________
        v6ops mailing list
        v6ops@ietf.org
        https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or use of the contents of this informati=
on, including attached files, is prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =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 Sun Jul 16 22:44:33 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31412EC10 for ; Sun, 16 Jul 2017 22:44: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=unavailable 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 2rjDXn30sHNi for ; Sun, 16 Jul 2017 22:44:22 -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 E6F6212EC0D for ; Sun, 16 Jul 2017 22:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500270259; x=1500875059; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=3rqs7X40sQhqHsG96CU3zmSWE gYYDpdcNmmI7Ef0USM=; b=qSfblpez076cpmciERTCDZrW5tL/4OkGJvTdsXR1l jE6vFM0vSLYWsETDN8ONqolAS7FCSlYSz+gunLLZbPcXqt91OO+MWXeo1kATozDc W2x3SyDXTm2768cNSW32L67LSiXIoTQC7s02H8BsBboHHzHo+ivV7oMg6CSO/gNz No=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lebFH9RHDXKB9R+QvsNG3gIBAJzhUn9//PCrCZjuSawj32RmpcmwOTYxj7f+ c2w9JZdqz2iex5mZCNr5Tml/NMpmIlumNeaIqmdI5/EQtG4J1MYnOpPU5 f+SxRwzvjxPAEmUIAvMktaer/a2xHpDnk/huABDrYDh+SIs04qLg4Y=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 07:44:19 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 07:44:18 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005477980.msg for ; Mon, 17 Jul 2017 07:44:13 +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:170717:md50005477980::VwDi632CNRruNehd:00002EEy
X-MDRemoteIP: 31.133.186.43
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 07:44:07 +0200
From: JORDI PALET MARTINEZ 
To: 
CC: Alissa Cooper , Suresh Krishnan , , Jim Martin , Randy Bush , Russ Housley 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 05:44:25 -0000

What I=E2=80=99m saying is that using CLAT, you also have dogfooding, but n=
o disturbing any participants and allowing then to keep doing the work. Som=
e of us get paid only if we finish our work on time!

I always understood that the IETF network is not for experiments. If we all=
ow this, it means we are changing our policy from now on?

I recall previous occasions where it was clearly said that if an experiment=
 is going to affect other participants, it can=E2=80=99t be done.

As said, do the same with CLAT so participants aren=E2=80=99t affected and =
at least wait until the document is an RFC.

I=E2=80=99m pro-IPv6, I=E2=80=99m sure nobody doubts that, but work is firs=
t, rules as well.

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 7:33
Para: JORDI PALET MARTINEZ 
CC: Alissa Cooper , Suresh Krishnan , , Jim Martin , Randy Bush , Russ Housley 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    Fwiw, I have found and fixed lots of problems as a result of using the =
ietf-nat64 network. It is probably still try that some participants would h=
ave trouble on that network, so there should be a legacy network for them. =
But the default should be nat64. Dogfooding is really important. If you hav=
e broken apps, feeling a little pain is a great way to motivate complaining=
 about it to the vendor.=20
   =20
    On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ"  wrote:
   =20
    In my opinion such kind of experiment should be only done once we appro=
ve the document as RFC, note before, so by the next IETF meeting (hopefully=
).
   =20
    We like it or not, this is not a valid option, unless we make sure that=
 if some participants have troubles, the alternative SSIDs have other 2.4 a=
nd 5 GHz radios available. Is that the case?
   =20
    The unfortunate reason this doesn=E2=80=99t work is that, still there a=
re MANY apps that use literals or old APIs, that don=E2=80=99t work with NA=
T64.
   =20
    As I explained before, if the goal is to detect and test them, this can=
 be done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the default=
 SSID, and then having an automatic logging of what apps/destination IPs), =
are using the CLAT.
   =20
    Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are =
also fine.
   =20
    The result is the same as you=E2=80=99re proposing but non-intrusive an=
d with the advantage of an automated logging of the failures.
   =20
    The way you=E2=80=99re proposing, will mean that many folks may switch =
to alternative SSID, or simply don't report those failures, so at the end y=
ou don=E2=80=99t have any results of how much is not working, etc.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De: v6ops  en nombre de "Brzozowski, John" 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 6:23
    Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
    CC: Jim Martin , Alissa Cooper , R=
uss Housley , Randy Bush , Suresh Kris=
hnan 
    Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings
   =20
        Folks,
   =20
        Apologies in advance for the gratuitous cross posting (v6ops, ietf,=
 ipv6, sunset4, softwires).  I hope, to you all, this is worth the added em=
ail.
   =20
        The draft below was written to provide the necessary documentation =
to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only=
 primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to =
access IPv4 only content.  The request for IETF 99 has been to have the pri=
mary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I-D be=
low.  I trust the motivation is understood.  This means that the main =E2=
=80=9Cietf=E2=80=9D SSID would be switched to be IPv6 only with NAT64+DNS64=
 (at layer 3) per the I-D below.  Given the that IETF99 is upon us, this ma=
y or may not be entirely possible.
   =20
        At this stage, the infrastructure preparations for IETF 99 should b=
e in place to ensure that the IETF has the necessary hardware for redundanc=
y and performance.
   =20
        So, we are all seeking your input.  Given the above, what would all=
 you suggest is tolerable for IETF99 as it pertains to the I-D below?
   =20
        =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
        =E2=80=A2 IPv6 only per the I-D for one or more days this week?
        =E2=80=A2 IPv6 only per the I-D for the plenary?
        =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
   =20
        Please send us your feedback.
   =20
        Regards,
   =20
        John
        +1-484-962-0060
   =20
        -----Original Message-----
        From: "internet-drafts@ietf.org" 
        Date: Saturday, July 1, 2017 at 03:04
        To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski , David Schinazi , Stu=
art Cheshire , Jen Linkova , Paul Saa=
b , David Schinazi 
        Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-on=
ly-incremental-00.txt
   =20
   =20
            A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-increment=
al-00.txt
            has been successfully submitted by John Jason Brzozowski and po=
sted to the
            IETF repository.
   =20
            Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
            Revision:       00
            Title:          Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
            Document date:  2017-06-30
            Group:          Individual Submission
            Pages:          15
            URL:            https://www.ietf.org/internet-drafts/draft-jjmb=
-v6ops-ietf-ipv6-only-incremental-00.txt
            Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6o=
ps-ietf-ipv6-only-incremental/
            Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ie=
tf-ipv6-only-incremental-00
            Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjm=
b-v6ops-ietf-ipv6-only-incremental-00
   =20
   =20
            Abstract:
               The purpose of this document is to provide a blueprint and g=
uidance
               for deploying IPv6-only Wi-Fi at IETF meetings.  This docume=
nt
               outlines infrastructure and operational guidance that operat=
ors
               should consider when deploying IPv6-only networks using NAT6=
4 and
               DNS64 to support communication to legacy IPv4-only services.
   =20
   =20
   =20
   =20
            Please note that it may take a couple of minutes from the time =
of submission
            until the htmlized version and diff are available at tools.ietf=
.org .
   =20
            The IETF Secretariat
   =20
   =20
   =20
   =20
        _______________________________________________
        v6ops mailing list
        v6ops@ietf.org
        https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or use of the contents of this informati=
on, including attached files, is prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =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 Sun Jul 16 22:59:27 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0539B129562 for ; Sun, 16 Jul 2017 22:59:27 -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, 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=fugue-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 nw3URG330tv6 for ; Sun, 16 Jul 2017 22:59:24 -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 8B21B126C3D for ; Sun, 16 Jul 2017 22:59:24 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id q86so71284692pfl.3 for ; Sun, 16 Jul 2017 22:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j39BAF78iYbbmWYVZUD8qlGshYtDEGZegHG88T33KQE=; b=r59ho5zw7fyS2N2nKtdtFYnivPjC87tGAHdaDopHZSi9ZTGlJUO2SZEcmGcqfkyA6R +sE7fiMhXpFur71XEvMYeYxftUTTL5QVTOF828ma9KDKhs134MRUXkJVOxmFcgS0h3yR q//VJFyIXTishRQFfwKvNu/dSE/TWo3TI7+ZfQGlLbHg+6GzyNqWz0cZLZTOT1V3bfcC zV7CJGktapvjD1Ix9Q2TpZx44oNVvc7fe22US+ALT/kgHCrIqk+S9hCDELHgIuB0BR/l xn2ECGwuNeGBTJWc8QgAVMFJ0nNuLYviZ5Sah28GXScq6FBbBHKgk5NtVZFP1jP7YZHj bFUA==
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=j39BAF78iYbbmWYVZUD8qlGshYtDEGZegHG88T33KQE=; b=mfy2/CvDSb18vFvG8r/wVguvQSqTEN6bRAguI0ydx77ozm7Ce16w06+OMEZomHaA1z Rtfg0McupQKFqDDFiKXOXE4UILpIrmSWgr5nBajftR5/USgjS3kveVKULEjLr161N6Sv sJXaRUpZH3NaK99GCqDjLH41c9Ra4CKqCQ209ebjyfFr1JdnpZ1avOMUV6K+dlZm4KXI CJD6nOGNhoy9z1eUXDSS6LRLp5FmGEyzphR7WFodnAj0GWr+NgR3SXD10QQnI1VRqll3 aD1Xzyof/4jigDmEPV8wx8NPbrLN2giU9DGmTUSoQjFuwPVmSCyz815rsZFRyTnWQFSl rhQw==
X-Gm-Message-State: AIVw110gNibJyp4JtVXK9VbYtAMckNZ9y80QaQ8rsXyJyTDkltnHgZ1e bvhOTwb0dPgGSGvNtpRZfyfaYOAKoOaB
X-Received: by 10.98.42.4 with SMTP id q4mr17663884pfq.143.1500271164070; Sun, 16 Jul 2017 22:59:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 22:58:43 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  
From: Ted Lemon 
Date: Mon, 17 Jul 2017 07:58:43 +0200
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Randy Bush , Alissa Cooper ,  Russ Housley , Jim Martin ,  Suresh Krishnan 
Content-Type: multipart/alternative; boundary="001a1145cd5ecd340605547d19e1"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 05:59:27 -0000

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

"No disturbing the participants" means we aren't dogfooding.   That's what
dogfooding means: you try to use the dog food.  If it's not nutritious,
then you go back to the cat food, but you start with the dog food.   Even
if you are only dogfooding for ten minutes before you run into a problem
that requires you to switch to the legacy network, that's a win, at least
if you report the problem.

On Mon, Jul 17, 2017 at 7:44 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> What I=E2=80=99m saying is that using CLAT, you also have dogfooding, but=
 no
> disturbing any participants and allowing then to keep doing the work. Som=
e
> of us get paid only if we finish our work on time!
>
> I always understood that the IETF network is not for experiments. If we
> allow this, it means we are changing our policy from now on?
>
> I recall previous occasions where it was clearly said that if an
> experiment is going to affect other participants, it can=E2=80=99t be don=
e.
>
> As said, do the same with CLAT so participants aren=E2=80=99t affected an=
d at
> least wait until the document is an RFC.
>
> I=E2=80=99m pro-IPv6, I=E2=80=99m sure nobody doubts that, but work is fi=
rst, rules as
> well.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: Ted Lemon 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 7:33
> Para: JORDI PALET MARTINEZ 
> CC: Alissa Cooper , Suresh Krishnan <
> suresh.krishnan@gmail.com>, , Jim Martin ,
> Randy Bush , Russ Housley 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
>
>     Fwiw, I have found and fixed lots of problems as a result of using th=
e
> ietf-nat64 network. It is probably still try that some participants would
> have trouble on that network, so there should be a legacy network for the=
m.
> But the default should be nat64. Dogfooding is really important. If you
> have broken apps, feeling a little pain is a great way to motivate
> complaining about it to the vendor.
>
>     On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ" <
> jordi.palet@consulintel.es> wrote:
>
>     In my opinion such kind of experiment should be only done once we
> approve the document as RFC, note before, so by the next IETF meeting
> (hopefully).
>
>     We like it or not, this is not a valid option, unless we make sure
> that if some participants have troubles, the alternative SSIDs have other
> 2.4 and 5 GHz radios available. Is that the case?
>
>     The unfortunate reason this doesn=E2=80=99t work is that, still there=
 are MANY
> apps that use literals or old APIs, that don=E2=80=99t work with NAT64.
>
>     As I explained before, if the goal is to detect and test them, this
> can be done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the de=
fault SSID, and
> then having an automatic logging of what apps/destination IPs), are using
> the CLAT.
>
>     Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) ar=
e
> also fine.
>
>     The result is the same as you=E2=80=99re proposing but non-intrusive =
and with
> the advantage of an automated logging of the failures.
>
>     The way you=E2=80=99re proposing, will mean that many folks may switc=
h to
> alternative SSID, or simply don't report those failures, so at the end yo=
u
> don=E2=80=99t have any results of how much is not working, etc.
>
>     Regards,
>     Jordi
>
>
>     -----Mensaje original-----
>     De: v6ops  en nombre de "Brzozowski, John" <
> John_Brzozowski@comcast.com>
>     Responder a: 
>     Fecha: lunes, 17 de julio de 2017, 6:23
>     Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" <
> draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org>
>     CC: Jim Martin , Alissa Cooper ,
> Russ Housley , Randy Bush , Suresh
> Krishnan 
>     Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
>
>         Folks,
>
>         Apologies in advance for the gratuitous cross posting (v6ops,
> ietf, ipv6, sunset4, softwires).  I hope, to you all, this is worth the
> added email.
>
>         The draft below was written to provide the necessary documentatio=
n
> to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 on=
ly
> primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to
> access IPv4 only content.  The request for IETF 99 has been to have the
> primary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I=
-D below.  I trust
> the motivation is understood.  This means that the main =E2=80=9Cietf=E2=
=80=9D SSID would
> be switched to be IPv6 only with NAT64+DNS64 (at layer 3) per the I-D
> below.  Given the that IETF99 is upon us, this may or may not be entirely
> possible.
>
>         At this stage, the infrastructure preparations for IETF 99 should
> be in place to ensure that the IETF has the necessary hardware for
> redundancy and performance.
>
>         So, we are all seeking your input.  Given the above, what would
> all you suggest is tolerable for IETF99 as it pertains to the I-D below?
>
>         =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
>         =E2=80=A2 IPv6 only per the I-D for one or more days this week?
>         =E2=80=A2 IPv6 only per the I-D for the plenary?
>         =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
>
>         Please send us your feedback.
>
>         Regards,
>
>         John
>         +1-484-962-0060
>
>         -----Original Message-----
>         From: "internet-drafts@ietf.org" 
>         Date: Saturday, July 1, 2017 at 03:04
>         To: Marcus Keane , Jen Linkova <
> furry@google.com>, Lorenzo Colitti , John Brzozowski =
<
> John_Brzozowski@Cable.Comcast.com>, Erik Kline , John
> Brzozowski , David Schinazi <
> dschinazi@apple.com>, Stuart Cheshire , Jen Linkova <
> furry@google.com>, Paul Saab , David Schinazi <
> dschinazi@apple.com>
>         Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-
> only-incremental-00.txt
>
>
>             A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-
> only-incremental-00.txt
>             has been successfully submitted by John Jason Brzozowski and
> posted to the
>             IETF repository.
>
>             Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
>             Revision:       00
>             Title:          Incremental Deployment of IPv6-only Wi-Fi for
> IETF Meetings
>             Document date:  2017-06-30
>             Group:          Individual Submission
>             Pages:          15
>             URL:            https://www.ietf.org/internet-
> drafts/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
>             Status:         https://datatracker.ietf.org/
> doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/
>             Htmlized:       https://tools.ietf.org/html/
> draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
>             Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
>
>
>             Abstract:
>                The purpose of this document is to provide a blueprint and
> guidance
>                for deploying IPv6-only Wi-Fi at IETF meetings.  This
> document
>                outlines infrastructure and operational guidance that
> operators
>                should consider when deploying IPv6-only networks using
> NAT64 and
>                DNS64 to support communication to legacy IPv4-only service=
s.
>
>
>
>
>             Please note that it may take a couple of minutes from the tim=
e
> of submission
>             until the htmlized version and diff are available at
> tools.ietf.org .
>
>             The IETF Secretariat
>
>
>
>
>         _______________________________________________
>         v6ops mailing list
>         v6ops@ietf.org
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>     **********************************************
>     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 confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
>
>
>
> **********************************************
> 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
> confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


"No disturbing the participants" means we aren&#=
39;t dogfooding. =C2=A0 That's what dogfooding means: you try to use th=
e dog food.=C2=A0 If it's not nutritious, then you go back to the cat f=
ood, but you start with the dog food. =C2=A0 Even if you are only dogfoodin=
g for ten minutes before you run into a problem that requires you to switch=
 to the legacy network, that's a win, at least if you report the proble=
m.

On Mon, J=
ul 17, 2017 at 7:44 AM, JORDI PALET MARTINEZ <jordi.palet@consul=
intel.es> wrote:
What I=
=E2=80=99m saying is that using CLAT, you also have dogfooding, but no dist=
urbing any participants and allowing then to keep doing the work. Some of u=
s get paid only if we finish our work on time!



I always understood that the IETF network is not for experiments. If we all=
ow this, it means we are changing our policy from now on?



I recall previous occasions where it was clearly said that if an experiment=
 is going to affect other participants, it can=E2=80=99t be done.



As said, do the same with CLAT so participants aren=E2=80=99t affected and =
at least wait until the document is an RFC.



I=E2=80=99m pro-IPv6, I=E2=80=99m sure nobody doubts that, but work is firs=
t, rules as well.



Regards,

Jordi





-----Mensaje original-----

De: Ted Lemon <mellon@fugue.com&=
gt;

Responder a: <mellon@fugue.com&g=
t;

Fecha: lunes, 17 de julio de 2017, 7:33

Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

CC: Alissa Cooper <alissa@cooperw.i=
n>, Suresh Krishnan <suresh.krishnan@gmail.com>, <v=
6ops@ietf.org>, Jim Martin <j=
im@daedelus.com>, Randy Bush <ra=
ndy@psg.com>, Russ Housley <housley@vigilsec.com>

Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings




=C2=A0 =C2=A0 Fwiw, I have found and fixed lots of problems as a result of =
using the ietf-nat64 network. It is probably still try that some participan=
ts would have trouble on that network, so there should be a legacy network =
for them. But the default should be nat64. Dogfooding is really important. =
If you have broken apps, feeling a little pain is a great way to motivate c=
omplaining about it to the vendor.



=C2=A0 =C2=A0 On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ" <=
;jordi.palet@consulintel.es> wrote:



=C2=A0 =C2=A0 In my opinion such kind of experiment should be only done onc=
e we approve the document as RFC, note before, so by the next IETF meeting =
(hopefully).



=C2=A0 =C2=A0 We like it or not, this is not a valid option, unless we make=
 sure that if some participants have troubles, the alternative SSIDs have o=
ther 2.4 and 5 GHz radios available. Is that the case?



=C2=A0 =C2=A0 The unfortunate reason this doesn=E2=80=99t work is that, sti=
ll there are MANY apps that use literals or old APIs, that don=E2=80=99t wo=
rk with NAT64.



=C2=A0 =C2=A0 As I explained before, if the goal is to detect and test them=
, this can be done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in t=
he default SSID, and then having an automatic logging of what apps/destinat=
ion IPs), are using the CLAT.



=C2=A0 =C2=A0 Those using IPv6 are fine, those using just the PLAT (NAT64+D=
NS64) are also fine.



=C2=A0 =C2=A0 The result is the same as you=E2=80=99re proposing but non-in=
trusive and with the advantage of an automated logging of the failures.



=C2=A0 =C2=A0 The way you=E2=80=99re proposing, will mean that many folks m=
ay switch to alternative SSID, or simply don't report those failures, s=
o at the end you don=E2=80=99t have any results of how much is not working,=
 etc.



=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Jordi





=C2=A0 =C2=A0 -----Mensaje original-----

=C2=A0 =C2=A0 De: v6ops <v6ops=
-bounces@ietf.org> en nombre de "Brzozowski, John" <John_Brzozowski@comcast.com=
>

=C2=A0 =C2=A0 Responder a: <John_Brzozowski@comcast.com>

=C2=A0 =C2=A0 Fecha: lunes, 17 de julio de 2017, 6:23

=C2=A0 =C2=A0 Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@iet=
f.org" <draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org<=
/a>>

=C2=A0 =C2=A0 CC: Jim Martin <jim@da=
edelus.com>, Alissa Cooper <=
alissa@cooperw.in>, Russ Housley <housley@vigilsec.com>, Randy Bush <randy@psg.com>, Suresh Krishnan <suresh.krishnan@gmail.com>

=C2=A0 =C2=A0 Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for=
 IETF Meetings



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Folks,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Apologies in advance for the gratuitous cross p=
osting (v6ops, ietf, ipv6, sunset4, softwires).=C2=A0 I hope, to you all, t=
his is worth the added email.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 The draft below was written to provide the nece=
ssary documentation to enable the IETF (the NOC, participants, etc.) to mig=
rate to an IPv6 only primary network connection (Wi-Fi and wired) that util=
izes NAT64+DNS64 to access IPv4 only content.=C2=A0 The request for IETF 99=
 has been to have the primary =E2=80=9Cietf=E2=80=9D SSID adhere to what is=
 documented in the I-D below.=C2=A0 I trust the motivation is understood.=
=C2=A0 This means that the main =E2=80=9Cietf=E2=80=9D SSID would be switch=
ed to be IPv6 only with NAT64+DNS64 (at layer 3) per the I-D below.=C2=A0 G=
iven the that IETF99 is upon us, this may or may not be entirely possible.<=
br>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 At this stage, the infrastructure preparations =
for IETF 99 should be in place to ensure that the IETF has the necessary ha=
rdware for redundancy and performance.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, we are all seeking your input.=C2=A0 Given =
the above, what would all you suggest is tolerable for IETF99 as it pertain=
s to the I-D below?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for the balance=
 of IETF week?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for one or more=
 days this week?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for the plenary=
?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 IPv6 only per the I-D for the next IE=
TF meeting?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please send us your feedback.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 John

=C2=A0 =C2=A0 =C2=A0 =C2=A0 +1-484-962-0060



=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date: Saturday, July 1, 2017 at 03:04

=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Marcus Keane <marcus.keane@microsoft.com>, Jen Linkova <furry@google.com>, Lorenzo Colitti =
<lorenzo@google.com>, John =
Brzozowski <John_Br=
zozowski@Cable.Comcast.com>, Erik Kline <ek@google.com>, John Brzozowski <John_Brzozowski@Cable.Comcast.com>, David Schinazi <dschinazi=
@apple.com>, Stuart Cheshire <cheshire@apple.com>, Jen Linkova <furry@google.com>, Paul Saab <ps@fb.com>, David Schinazi <dschinazi@apple.com>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: New Version Notification for draft-jjm=
b-v6ops-ietf-ipv6-only-incremental-00.txt





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A new version of I-D, draft-jjmb-=
v6ops-ietf-ipv6-only-incremental-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has been successfully submitted b=
y John Jason Brzozowski and posted to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF repository.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0draft-jjmb-v6ops-ietf-ipv6-only-incremental

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Revision:=C2=A0 =C2=A0 =C2=A0 =C2=
=A000

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Document date:=C2=A0 2017-06-30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 Individual Submission

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 15

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-jjmb-v6ops-ietf-ipv6-=
only-incremental-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0https://datat=
racker.ietf.org/doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/<=
/a>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=
=A0https://tools.ietf.org/=
html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=
=A0https://datat=
racker.ietf.org/doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremen=
tal-00





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Abstract:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The purpose of this =
document is to provide a blueprint and guidance

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for deploying IPv6-o=
nly Wi-Fi at IETF meetings.=C2=A0 This document

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0outlines infrastruct=
ure and operational guidance that operators

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should consider when=
 deploying IPv6-only networks using NAT64 and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DNS64 to support com=
munication to legacy IPv4-only services.









=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please note that it may take a co=
uple of minutes from the time of submission


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 until the htmlized ve=
rsion and diff are available at tools.ietf.org <http://tools.ietf.org>=
;.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The IETF Secretariat









=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________=
_____

=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops mailing list

=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops@ietf.or=
g

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/=
listinfo/v6ops









=C2=A0 =C2=A0 **********************************************

=C2=A0 =C2=A0 IPv4 is over

=C2=A0 =C2=A0 Are you ready for the new Internet ?

=C2=A0 =C2=A0 http://www.consulintel.es

=C2=A0 =C2=A0 The IPv6 Company



=C2=A0 =C2=A0 This electronic message contains information which may be pri=
vileged or confidential. The information is intended to be for the use of t=
he individual(s) named above. If you are not the intended recipient be awar=
e that any disclosure, copying, distribution or use of the contents of this=
 information, including attached files, is prohibited.







=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 v6ops mailing list

=C2=A0 =C2=A0 v6ops@ietf.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/v6ops

















**********************************************

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.







_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--001a1145cd5ecd340605547d19e1--


From nobody Sun Jul 16 23:14:20 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68F12ECF0 for ; Sun, 16 Jul 2017 23:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neo-co-tz.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 K96isS8FJlv6 for ; Sun, 16 Jul 2017 23:14:16 -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 A87F712EC0D for ; Sun, 16 Jul 2017 23:14:15 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id a10so6098363wrd.0 for ; Sun, 16 Jul 2017 23:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XQIjX8j7DtUuHH3fPIaulmNNeiFbH4eZj4+TzTQGrVo=; b=c+xEGUCpOvIbp4OVd0kFPz4FPgSUmU3OjxoURuZlR8VHRgpKHmKci0d8dN9eG9e5X+ JYJMhflhTeXeaWqMOcTmDfwy2Y4FTUGcsSXg/npIP4WGuaIVttMzyIA+TXBxCpJARhsX bCuST0CErwvq6rDMID/h+Jfp4eF+CD/FnlSiVltsFNHEkIOhbyQPusBHp0rWhJxEPVj2 JHckka5H1dbdeHt2JZUmewN3Sn3AvyPsBO3ITgdsCkJyIrtK+XfoHOw5MKLeXQCirMQF 1P1MRCrMt6t7n0krbwGDcWR+zxqUhE/tNYpT1mIyUNFYpHkbHM7hDSrN8ZqVebgeb3+r RIBg==
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=XQIjX8j7DtUuHH3fPIaulmNNeiFbH4eZj4+TzTQGrVo=; b=J8tqLR1peQK+SDRN9AQEr6laLhfqC0K59gldTMeVh2gEwK+BePEKqZZuS+vwr25pgc C5L78lboS11K/GifwkNc71V+noRXHx15Lkkf3CBkCbBmGA1KH6keg1/HVnjEmBlG+PDw ZIzm6Z0cG1APezWD64LToQz45XOZvHkzOFQP1A/5xBL6F6/nWIPp+SbARxwcRGAUWyG9 QKEGtPjDJfVB8uwZ2ihim8Ifi4ObXu15XVL7LcNvXrePb7rkfkBypFI8bawusVEOh+Pn PBfXGTwHVnQswhrDxxO5oTjWoBYZLAMP3JPBef2tsBqKSBn1OdUV+CoH64224A3sN8TT ZioQ==
X-Gm-Message-State: AIVw113emBSuidrIaEIZ9i4RiZ10+fljmTaAZGCJUG7DIJf8DCfLOSjH dpza8twCtAVS7yg3RpCtm3hGPGf2mfVr
X-Received: by 10.223.162.208 with SMTP id t16mr11796384wra.151.1500272054185;  Sun, 16 Jul 2017 23:14:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.206.4 with HTTP; Sun, 16 Jul 2017 23:14:13 -0700 (PDT)
X-Originating-IP: [197.250.99.209]
Received: by 10.28.206.4 with HTTP; Sun, 16 Jul 2017 23:14:13 -0700 (PDT)
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
From: Noah 
Date: Mon, 17 Jul 2017 09:14:13 +0300
Message-ID: 
To: jordi.palet@consulintel.es
Cc: Alissa Cooper , Suresh Krishnan , v6ops@ietf.org,  Jim Martin , Randy Bush , Russ Housley 
Content-Type: multipart/alternative; boundary="f403045ea352db447105547d4eb1"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 06:14:19 -0000

--f403045ea352db447105547d4eb1
Content-Type: text/plain; charset="UTF-8"

On 17 Jul 2017 8:26 a.m., "JORDI PALET MARTINEZ" 
wrote:

In my opinion such kind of experiment should be only done once we approve
the document as RFC, note before, so by the next IETF meeting (hopefully).


Hi Jordi

Why not, this would be very interesting considering the times.

Perhaps we can try for 1 or 2 days for experiental purpose as need not to
wait for final RFC and the outcome could also feed the current draft as is.
Who knows.

+1 for below option if possible.

-  IPv6 only per the I-D for one or more days this week?

Cheers
Noah

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




On 17 Jul 2017 8:26 a.m., "JORDI PALET MARTINEZ"=
; <jordi.palet@consulintel=
.es> wrote:
In my o=
pinion such kind of experiment should be only done once we approve the docu=
ment as RFC, note before, so by the next IETF meeting (hopefully).

Hi Jordi<=
/div>

Why not, this would be v=
ery interesting considering the times.=C2=A0

Perhaps we can try for 1 or 2 days for experiental pur=
pose as need not to wait for final RFC and the outcome could also feed the =
current draft as is. Who knows.

+1 for below option if possible. =C2=A0
- =C2=A0IPv6 only per the I-D for one or more days this week?

Cheers
Noah

=




--f403045ea352db447105547d4eb1--


From nobody Sun Jul 16 23:27:58 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85D412ECF0 for ; Sun, 16 Jul 2017 23:27:56 -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 RCQJwiSAYLzr for ; Sun, 16 Jul 2017 23:27:54 -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 08D7B131562 for ; Sun, 16 Jul 2017 23:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500272870; x=1500877670; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=9uUwczod+1/TXiVY7nyFiETEA 1Y3VxEIdBEJtIA7iyA=; b=rEvQIm+8JgYF7KHBIr3R9+bnvfa6Zdygfnw/7dHwu 2ntpNMZ9m5p/nKo008x12EfMZsS0WLAxnrfJKJFPztCP4Q9U/ZIfrQM3vHhlrPSG WekC1Ghc5NJy1EwVUNTsK1ceqb8V+/ACSrIkoIDaCEqlrc54DrGC8kJnJqqo4iNR qw=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=k3BV+0YuPF+nlkoK2xd6jdQJVY5a8Xi/FgEI/vvL8ioOVjnoECM/kH3ky1oh ox8XKqwXThhGMUf+FvjsULpVARe18gcoZwT4l6x0BsQOMcelhRlNYbkik n78tR++LEsLw3ixaM2ClW3lW1fXLpDAHNypNNNsAvWH/Y1kYij6S4s=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:27:50 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:27:49 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478024.msg for ; Mon, 17 Jul 2017 08:27:47 +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:170717:md50005478024::CREkwcIe1jTCLYfZ:00000VXA
X-MDRemoteIP: 31.133.186.43
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 08:27:45 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Alissa Cooper , Russ Housley , Jim Martin , Suresh Krishnan 
Message-ID: <7AEAF016-007D-4A31-A03E-551008E3F7FA@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>   
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 06:27:57 -0000

Not disturbing means allowing them to work transparently, and this is the t=
arget of our network. There is no reason to force =E2=80=9Cbreaking=E2=80=
=9D something if the target is to measure something that can be done in ano=
ther way, right?

As said:
1) If we allow and ID to be experimented in our network (which is against o=
ur own rules), then it means that if somebody else tomorrow decides to writ=
e down another ID, he has the same right to ask for being experimented at t=
he default SSID.
2) The way I=E2=80=99m suggesting provides even better results for analysis=
. I agree that is good to understand what apps will fail to survive the NAT=
64.
3) CLAT is also our own dogfood.

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 7:59
Para: JORDI PALET MARTINEZ 
CC: IPv6 Ops WG , Randy Bush , Alissa Cooper=
 , Russ Housley , Jim Martin , Suresh Krishnan 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    "No disturbing the participants" means we aren't dogfooding.   That's w=
hat dogfooding means: you try to use the dog food.  If it's not nutritious,=
 then you go back to the cat food, but you start with the dog food.   Even =
if you are only dogfooding for ten minutes before you run into a problem th=
at requires you to switch to the legacy network, that's a win, at least if =
you report the problem.
   =20
    On Mon, Jul 17, 2017 at 7:44 AM, JORDI PALET MARTINEZ  wrote:
   =20
    What I=E2=80=99m saying is that using CLAT, you also have dogfooding, b=
ut no disturbing any participants and allowing then to keep doing the work.=
 Some of us get paid only if we finish our work on time!
   =20
    I always understood that the IETF network is not for experiments. If we=
 allow this, it means we are changing our policy from now on?
   =20
    I recall previous occasions where it was clearly said that if an experi=
ment is going to affect other participants, it can=E2=80=99t be done.
   =20
    As said, do the same with CLAT so participants aren=E2=80=99t affected =
and at least wait until the document is an RFC.
   =20
    I=E2=80=99m pro-IPv6, I=E2=80=99m sure nobody doubts that, but work is =
first, rules as well.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De: Ted Lemon 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 7:33
    Para: JORDI PALET MARTINEZ 
    CC: Alissa Cooper , Suresh Krishnan , , Jim Martin , Randy Bush , Russ Housley 
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
   =20
        Fwiw, I have found and fixed lots of problems as a result of using =
the ietf-nat64 network. It is probably still try that some participants wou=
ld have trouble on that network, so there should be a legacy network for th=
em. But the default should be nat64. Dogfooding is really important. If you=
 have broken apps, feeling a little pain is a great way to motivate complai=
ning about it to the vendor.
   =20
        On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ"  wrote:
   =20
        In my opinion such kind of experiment should be only done once we a=
pprove the document as RFC, note before, so by the next IETF meeting (hopef=
ully).
   =20
        We like it or not, this is not a valid option, unless we make sure =
that if some participants have troubles, the alternative SSIDs have other 2=
.4 and 5 GHz radios available. Is that the case?
   =20
        The unfortunate reason this doesn=E2=80=99t work is that, still the=
re are MANY apps that use literals or old APIs, that don=E2=80=99t work wit=
h NAT64.
   =20
        As I explained before, if the goal is to detect and test them, this=
 can be done by using a =E2=80=9CCLAT=E2=80=9D network (464XLAT) in the def=
ault SSID, and then having an automatic logging of what apps/destination IP=
s), are using the CLAT.
   =20
        Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) =
are also fine.
   =20
        The result is the same as you=E2=80=99re proposing but non-intrusiv=
e and with the advantage of an automated logging of the failures.
   =20
        The way you=E2=80=99re proposing, will mean that many folks may swi=
tch to alternative SSID, or simply don't report those failures, so at the e=
nd you don=E2=80=99t have any results of how much is not working, etc.
   =20
        Regards,
        Jordi
   =20
   =20
        -----Mensaje original-----
        De: v6ops  en nombre de "Brzozowski, John" =

        Responder a: 
        Fecha: lunes, 17 de julio de 2017, 6:23
        Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
        CC: Jim Martin , Alissa Cooper , Russ Housley , Randy Bush , Suresh =
Krishnan 
        Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
   =20
            Folks,
   =20
            Apologies in advance for the gratuitous cross posting (v6ops, i=
etf, ipv6, sunset4, softwires).  I hope, to you all, this is worth the adde=
d email.
   =20
            The draft below was written to provide the necessary documentat=
ion to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 =
only primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64=
 to access IPv4 only content.  The request for IETF 99 has been to have the=
 primary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I-=
D below.  I trust the motivation is understood.  This means that the main =
=E2=80=9Cietf=E2=80=9D SSID would be switched to be IPv6 only with NAT64+DN=
S64 (at layer 3) per the I-D below.  Given the that IETF99 is upon us, this=
 may or may not be entirely possible.
   =20
            At this stage, the infrastructure preparations for IETF 99 shou=
ld be in place to ensure that the IETF has the necessary hardware for redun=
dancy and performance.
   =20
            So, we are all seeking your input.  Given the above, what would=
 all you suggest is tolerable for IETF99 as it pertains to the I-D below?
   =20
            =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
            =E2=80=A2 IPv6 only per the I-D for one or more days this week?
            =E2=80=A2 IPv6 only per the I-D for the plenary?
            =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
   =20
            Please send us your feedback.
   =20
            Regards,
   =20
            John
            +1-484-962-0060
   =20
            -----Original Message-----
            From: "internet-drafts@ietf.org" 
            Date: Saturday, July 1, 2017 at 03:04
            To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski=
 , David Schinazi ,=
 Stuart Cheshire , Jen Linkova , Paul=
 Saab , David Schinazi 
            Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv=
6-only-incremental-00.txt
   =20
   =20
                A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-incre=
mental-00.txt
                has been successfully submitted by John Jason Brzozowski an=
d posted to the
                IETF repository.
   =20
                Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
                Revision:       00
                Title:          Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
                Document date:  2017-06-30
                Group:          Individual Submission
                Pages:          15
                URL:            https://www.ietf.org/internet-drafts/draft-=
jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
                Status:         https://datatracker.ietf.org/doc/draft-jjmb=
-v6ops-ietf-ipv6-only-incremental/
                Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6op=
s-ietf-ipv6-only-incremental-00
                Htmlized:       https://datatracker.ietf.org/doc/html/draft=
-jjmb-v6ops-ietf-ipv6-only-incremental-00
   =20
   =20
                Abstract:
                   The purpose of this document is to provide a blueprint a=
nd guidance
                   for deploying IPv6-only Wi-Fi at IETF meetings.  This do=
cument
                   outlines infrastructure and operational guidance that op=
erators
                   should consider when deploying IPv6-only networks using =
NAT64 and
                   DNS64 to support communication to legacy IPv4-only servi=
ces.
   =20
   =20
   =20
   =20
                Please note that it may take a couple of minutes from the t=
ime of submission
   =20
   =20
                until the htmlized version and diff are available at tools.=
ietf.org  .
   =20
                The IETF Secretariat
   =20
   =20
   =20
   =20
            _______________________________________________
            v6ops mailing list
            v6ops@ietf.org
            https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
        **********************************************
        IPv4 is over
        Are you ready for the new Internet ?
        http://www.consulintel.es
        The IPv6 Company
   =20
        This electronic message contains information which may be privilege=
d or confidential. The information is intended to be for the use of the ind=
ividual(s) named above. If you are not the intended recipient be aware that=
 any disclosure, copying, distribution or use of the contents of this infor=
mation, including attached files, is prohibited.
   =20
   =20
   =20
        _______________________________________________
        v6ops mailing list
        v6ops@ietf.org
        https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or use of the contents of this informati=
on, including attached files, is prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =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 Sun Jul 16 23:32:17 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BF9130154 for ; Sun, 16 Jul 2017 23:32:15 -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 K3ZyM-giqwRV for ; Sun, 16 Jul 2017 23:32:14 -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 E788612ECF0 for ; Sun, 16 Jul 2017 23:32:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500273131; x=1500877931; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=nogJYKFMBFj2aAXVZee0yWXUd mCZa19BxSbm/wRHCI8=; b=PgTG4tys8cVymn1YvsGin1N+9RmV2yaHIP1J+zgON D82B0VsbS3W1D4gY4oqhEx2ozmElXsQDVeRfrITaRQVajlNoqAvILZEfaNgllExl vYE5qEFv/rtS8KYE1SdzIelCFjNoms7MTQTuEQn6W05Aev9GlhTuSoZsXvLGA014 30=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=edsEf+qXfnin3dAasmOByiz1bBs7t6peTrsNj8NRwucGINwjniHnTZKbqmH9 gidcWBWjBSjz7LdVQ9YqHpoYH1k/xOA7yBHHqnEloPYcs8ZVm9fSFTXFN r364W7uWt9KzVEbMeoVoWhgsbbbF6lJbumHySCmtolwK1yxplPvyIk=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:32:11 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:32:10 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478028.msg for ; Mon, 17 Jul 2017 08:32:09 +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:170717:md50005478028::1KntRwpPCUAWle9S:00001CcS
X-MDRemoteIP: 31.133.186.43
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 08:32:06 +0200
From: JORDI PALET MARTINEZ 
To: 
CC: Alissa Cooper , Suresh Krishnan , Jim Martin , Randy Bush , Russ Housley 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 06:32:16 -0000

NAT64 has been tested already in many networks, it just works but ONLY if y=
our app isn=E2=80=99t using literals or old libraries, etc. So the only =E2=
=80=9Cnew=E2=80=9D thing we can learn from this experiment is what apps bre=
ak because that. The way I=E2=80=99m suggesting (464XLAT) has been also tes=
ted in many networks, and actually is globally deployed in almost every cel=
lular network that provides IPv6. The results we can get using this instead=
 of only NAT64, is that those apps that break will be automatically logged.

If we just do NAT64, do you expect the users that have a break to =E2=80=9C=
report=E2=80=9D manually what is broken for them. May be 10% will do. With =
CLAT, we collect automatically 100%.

Which one do you think is more advantageous?

Also, note that the IETF network has always been described as a non-place f=
or experiments.

Regards,
Jordi
=20

-----Mensaje original-----
De: Noah 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 8:14
Para: 
CC: Alissa Cooper , Suresh Krishnan , , Jim Martin , Randy Bush , Russ Housley 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

   =20
   =20
    On 17 Jul 2017 8:26 a.m., "JORDI PALET MARTINEZ"  wrote:
   =20
    In my opinion such kind of experiment should be only done once we appro=
ve the document as RFC, note before, so by the next IETF meeting (hopefully=
).
   =20
   =20
   =20
   =20
   =20
    Hi Jordi
   =20
    Why not, this would be very interesting considering the times.=20
   =20
    Perhaps we can try for 1 or 2 days for experiental purpose as need not =
to wait for final RFC and the outcome could also feed the current draft as =
is. Who knows.
   =20
    +1 for below option if possible. =20
   =20
    -  IPv6 only per the I-D for one or more days this week?
   =20
   =20
    Cheers
    Noah
   =20
   =20
   =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 Sun Jul 16 23:48:47 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C30120726 for ; Sun, 16 Jul 2017 23:48: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, 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=fugue-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 Y1lf9Y0WY54q for ; Sun, 16 Jul 2017 23:48:44 -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 2B38B1315FE for ; Sun, 16 Jul 2017 23:48:44 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id v190so16615329pgv.2 for ; Sun, 16 Jul 2017 23:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HPn9Y5dApy5bOiLF72ZlOJTqBJoBfgSHuvst/eBvYC0=; b=cBK/nVHl3vdx3IpcBIz6Qal9DPurWlv2ZLj+BKDKfoIc4XccjV7y4tUDkyNO1oVx92 R+bFagfa6tar2FYgwJeATeCES7W1KETBmSBUyUD/QM7xgPFdG8zCJhMQRAOTlwYA2K2R plha/x/hhRshGcJZX0OStP73mUV51JrOAgfzmT/9DWWbO9dX3OLDvESVlRj35n0T6ib4 nR8eawxRJcbSh2MZqQCIrNAg9tPy9RFOah0JiF9xrbq6IkPvwv8y6Xm8NzyXkBo24fFT axafI8SpmnVNjH0Z/Zc221N/KgIamAGLIIhMmP+a099O9Gf1iZ1/1uhAUeiH8cUX7Cla wBXA==
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=HPn9Y5dApy5bOiLF72ZlOJTqBJoBfgSHuvst/eBvYC0=; b=S+EIvkCLCq42cRounoNN0LP6Ub3PgviNsoOmzGq1qnVCW0XcDe0lamxHEBMTS9mL1a LD0hAfBDTfY7afZuG6nwiCw67t/xy2WXkpAZl4x9su0+8OTDrQQwXgZSHdwmM3pIxl9C u7m13fJSEtRpF632f+lTO5Chy2dQWM+IovvVpFqdbvv5VFrutmhz9FB3lp/U4t6ARqvn C0/ngRdmApKy4bfqyOIwO3/8nPfApJZ6rfkRRLg0ny4ILDCOAKfaUu60nB1eAa5rfU/1 f+EEx8yvNYs7oIP9EOwwLggGHl+ZSvqyFvlKtomx9FxtApi0U9agZyB7n0YYqtVRCxIc 3y9w==
X-Gm-Message-State: AIVw110eQnvCHm/DmNZlGnmvTNMH2x6ZF0V97ufwEphmD6tryZYD8V4+ M5WXQTfMLml2DJ7DL5A9fVFg1RCzmb+r
X-Received: by 10.84.132.39 with SMTP id 36mr28858420ple.237.1500274123770; Sun, 16 Jul 2017 23:48:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 23:48:03 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  
From: Ted Lemon 
Date: Mon, 17 Jul 2017 08:48:03 +0200
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh Krishnan , Russ Housley , Alissa Cooper 
Content-Type: multipart/alternative; boundary="94eb2c12f714369ea205547dca98"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 06:48:46 -0000

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

I don't actually know what the goal of the IETF network is other than to
provide connectivity.   Because of the vicissitudes of hotel topology, it
is often the case that IETF participants experience issues with the network
at least once or twice per IETF despite the best efforts (and they are
quite exceptional) of the NOC team.   I do not really see what the damage
is that you are hoping to protect against here.   Users who don't read the
NOC announcement?   No sympathy.   Sorry.

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


I don't actually know what =
the goal of the IETF network is other than to provide connectivity. =C2=A0 =
Because of the vicissitudes of hotel topology, it is often the case that IE=
TF participants experience issues with the network at least once or twice p=
er IETF despite the best efforts (and they are quite exceptional) of the NO=
C team. =C2=A0 I do not really see what the damage is that you are hoping t=
o protect against here. =C2=A0 Users who don't read the NOC announcemen=
t? =C2=A0 No sympathy. =C2=A0 Sorry.


--94eb2c12f714369ea205547dca98--


From nobody Sun Jul 16 23:51:40 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A121315FE for ; Sun, 16 Jul 2017 23:51:37 -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 mHHpQrKXPEgl for ; Sun, 16 Jul 2017 23:51:36 -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 48472120726 for ; Sun, 16 Jul 2017 23:51:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500274293; x=1500879093; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=YSXlhL5L5R7kXgWJRqGYSxWnP XJWNtW+tbtmLkhOP8E=; b=WOwI0//ghnNZf9hgOw4PVlkuur5f5pdJsJXFGUMrP sCF2D203I9htKkiPrgXU/xprZf6Yyw161SiV5teykWOR6QpT3r51DKgHLJxDoVPh N5WogZUlJ8Tq4g5tpJWR43lUfCVaG/EcYwLxXbGoZkB4O2ABPDk0RbOAOpUp4Upx tY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=niode9c5t1J1JGn2hZRYFAY5iTwdG+lftQ2iK0MZ4Fjx03tEKCzuj31MoNBN 0UMlbMa8bkdrixXhHAtjRGtXPlkFwxH6fcEa3zQLscXEQGVzVfbymzw7G Ir+rYLRxh2utOPCLVPcxsfsiyU1ivdDR4i4y1eOEh1TW0U+VRBq3pw=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:51:33 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 08:51:32 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478042.msg for ; Mon, 17 Jul 2017 08:51:31 +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:170717:md50005478042::Ejqcq/u7gADohRij:0000GTpp
X-MDRemoteIP: 31.133.186.43
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 08:51:29 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Randy Bush , Suresh Krishnan , Russ Housley , Alissa Cooper 
Message-ID: <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>   
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 06:51:38 -0000

So we agree to change the rules so that we use this network for every ID th=
at want to experiment with it? Otherwise we discriminate among different au=
thors =E2=80=A6

I think is a really bad precedent.

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 8:48
Para: JORDI PALET MARTINEZ 
CC: IPv6 Ops WG , Jim Martin , Randy Bush=
 , Suresh Krishnan , Russ Housley=
 , Alissa Cooper 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    I don't actually know what the goal of the IETF network is other than t=
o provide connectivity.   Because of the vicissitudes of hotel topology, it=
 is often the case that IETF participants experience issues with the networ=
k at least once or twice per IETF despite the best efforts (and they are qu=
ite exceptional) of the NOC team.   I do not really see what the damage is =
that you are hoping to protect against here.   Users who don't read the NOC=
 announcement?   No sympathy.   Sorry.
   =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 Sun Jul 16 23:53:58 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDF6131675 for ; Sun, 16 Jul 2017 23:53:56 -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, 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=fugue-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 O056SbBkvHFf for ; Sun, 16 Jul 2017 23:53:54 -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 244A11315FE for ; Sun, 16 Jul 2017 23:53:54 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id u5so12273358pgq.3 for ; Sun, 16 Jul 2017 23:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VniFOava8NjEYw1Bw6Ce+H6MqF5azUG6EjaLoa/4Xyw=; b=YV9wjQvawwaBjeYH6+Pd+qTv6PoXC02SilgkrpwAuzPrA1bOj8MbWdicokw7JZJ08X 3g/fUFof0pX9LxNm1pKH3MpVbXwPv+Lp4J9ePk2mD/QcBunzhZunOkGmYZdiO1q+W8Ry mOoZDzpaHwmLlP9pjqSigczSK07EblQC5aIwzp+oiTUoH0XO229C4oV19q0WmevdYJZs F+/FoDQkHeqpPzfsHSQQXlXJoIJniApI8Ob1unq/E9XFcFCmpckaPaVpCqyzwbuMfjde am7ZBxFEhurrUF2IrhJAgJgN+QxOVGxxGfyljqr8MM8I1kNbs4XmBHjJA5jo8DNOER5F St/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=VniFOava8NjEYw1Bw6Ce+H6MqF5azUG6EjaLoa/4Xyw=; b=mI4eaNPkh9SjFDBarP02ZzD7z/s9fA+9rSxWP+1tVR6E7/guxuPMVGMU2rfMycL5/e qmMP/OqliSaaIwVRRIvzJ2GrjrYNxmR4Ot8CIaOIi4xIUEhxjf5DilP7piWV5EA8BomD /F3v8NfMd/ZWUIjwPoNYN68QTzcSny36CU/9uhIGLZ4rdN6eC9QbMuD5wF+VSfRgwtwz CRBqz2kLYJcqr7cmfsDH0OpP9teTQBBk1K9XBb0bOuQr5FJG8TMDc8c2jUqXZKcHkiNO u3O4C+SubvjTlqGiBlq7p5TEFYe7V+QWZvM5XsRsHjGAZwEfoOczI8jLE/TsRQfYd2DK vkhQ==
X-Gm-Message-State: AIVw110EYVD6Ps91Z+cYkgV9LwjWTaTh6ArjAl21rYq0wIQsiUOlvrDN /T10e6iUOiLjkZflXEVtUesO8EiMgQ/7
X-Received: by 10.98.193.68 with SMTP id i65mr3109780pfg.142.1500274433660; Sun, 16 Jul 2017 23:53:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sun, 16 Jul 2017 23:53:13 -0700 (PDT)
In-Reply-To: <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>
From: Ted Lemon 
Date: Mon, 17 Jul 2017 08:53:13 +0200
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh Krishnan , Russ Housley , Alissa Cooper 
Content-Type: multipart/alternative; boundary="94eb2c184720b1198a05547ddcc3"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 06:53:56 -0000

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

I don't think this is a social justice issue.   Does the IETF think that
IPv6 works, or not?   If we think it works, and we have been working for
what, 20 years, to make it work, and we have designed all this great
transition tech, then why on earth would we not want to use it?   This
isn't "one draft."   This is roughly half the work of the IETF for the past
two decades.

On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> So we agree to change the rules so that we use this network for every ID
> that want to experiment with it? Otherwise we discriminate among differen=
t
> authors =E2=80=A6
>
> I think is a really bad precedent.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: Ted Lemon 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 8:48
> Para: JORDI PALET MARTINEZ 
> CC: IPv6 Ops WG , Jim Martin , Randy
> Bush , Suresh Krishnan , Russ
> Housley , Alissa Cooper 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
>
>     I don't actually know what the goal of the IETF network is other than
> to provide connectivity.   Because of the vicissitudes of hotel topology,
> it is often the case that IETF participants experience issues with the
> network at least once or twice per IETF despite the best efforts (and the=
y
> are quite exceptional) of the NOC team.   I do not really see what the
> damage is that you are hoping to protect against here.   Users who don't
> read the NOC announcement?   No sympathy.   Sorry.
>
>
>
>
>
> **********************************************
> 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
> confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


I don't think this is a social justice issue. =C2=A0 D=
oes the IETF think that IPv6 works, or not? =C2=A0 If we think it works, an=
d we have been working for what, 20 years, to make it work, and we have des=
igned all this great transition tech, then why on earth would we not want t=
o use it? =C2=A0 This isn't "one draft." =C2=A0 This is rough=
ly half the work of the IETF for the past two decades.

On Mon, Jul 17, 2017 at 8:51 AM,=
 JORDI PALET MARTINEZ <jordi.palet@consulintel.es> =
wrote:
So we agree to change the rules so=
 that we use this network for every ID that want to experiment with it? Oth=
erwise we discriminate among different authors =E2=80=A6



I think is a really bad precedent.



Regards,

Jordi





-----Mensaje original-----

De: Ted Lemon <mell=
on@fugue.com>

Responder a: <mellon@fugue.com&g=
t;

Fecha: lunes, 17 de julio de 2017, 8:48

Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

CC: IPv6 Ops WG <v6ops@ietf.org=
>, Jim Martin <jim@daedelus.c=
om>, Randy Bush <randy@psg.com>, Suresh Krishnan <su=
resh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>

Asunto: Re: [v6ops] Incremental Deployment of IPv=
6-only Wi-Fi for IETF Meetings



=C2=A0 =C2=A0 I don't actually know wh=
at the goal of the IETF network is other than to provide connectivity.=C2=
=A0 =C2=A0Because of the vicissitudes of hotel topology, it is often the ca=
se that IETF participants experience issues with the network at least once =
or twice per IETF despite the best efforts (and they are quite exceptional)=
 of the NOC team.=C2=A0 =C2=A0I do not really see what the damage is that y=
ou are hoping to protect against here.=C2=A0 =C2=A0Users who don't read=
 the NOC announcement?=C2=A0 =C2=A0No sympathy.=C2=A0 =C2=A0Sorry.












****************************=
******************

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.







_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--94eb2c184720b1198a05547ddcc3--


From nobody Mon Jul 17 00:01:50 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C49130154 for ; Mon, 17 Jul 2017 00:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neo-co-tz.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 uAZWOyIxzeNA for ; Mon, 17 Jul 2017 00:01:47 -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 976FF120726 for ; Mon, 17 Jul 2017 00:01:46 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id a10so6594700wrd.0 for ; Mon, 17 Jul 2017 00:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WOIibcMqux91wfCo7lZCbbnWghK80C1UxDO4t1ahiS8=; b=guxAOQCAZJZQXhA5k6ZPMRN5BapIkhzer1cNP207ILXdHeYdw8i55CDegQwsZGxr/E XR9QvzTrtvJ6Xrsw/76FqjcLXh2XkfBxaLckb5aRk4w9jPWt9MVNd8Td+mzA4iHd+60Q 1TcEatm5Cb9V7nZv/ppgfDVbkQxg8LCqWRgDGRbjKOUy4mLjsBMhmoyQ3TTUSbaArBz+ XjbI8Mt1vTlxDmydcLmIUBaJ7iZJA83mwHnFafLNib4qHwvlGQRRtEMB2VaHlSKoRM4E MsMmH+UXlm0a9Nepfn+dSPk/FVSxM9tly7gr8apD71of9EP1ddsrWd+h0D+RhAFS/DG+ 37XQ==
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=WOIibcMqux91wfCo7lZCbbnWghK80C1UxDO4t1ahiS8=; b=W95BbOMjMxUMx1piY5Wxdn+aOCQZ9BQMY4PNBSvnPxdiamGpXV4xC11yS9yn+Zzj8C +HiojksIDWD5lokCQXULgepoiM4/vxhlxOaoaBUe/rlmCiYodFOEcsJ/A+XUcQwlmxnC 7yw3KbRzlikK9ahAJ78WzNC9J+9BzGJUEsKAFSJwYVK8tjLHdMwd1DuE3Sj05ht8+JkJ qdgPUVngO/O69/EPXGUz889PP+3+iFue8hmY1GVKGcX56g4LJ0yLJ9rPGHftzN1UFXyO JQDA7w1S6tC7rIEw1odQKmLLbrehSadzs+pFgCHDM+v6LZhLJDzfHZtbYQ1I9I2ruc5H 1eNA==
X-Gm-Message-State: AIVw113FeIMaYMCNk6kNiFBgtOAPkX5F+KHxDaGdAC4PpeDlC/SzNFay aCzYQqNF9dn0FBaFb4Xaw0aIcYijJqF/
X-Received: by 10.223.144.39 with SMTP id h36mr12047736wrh.114.1500274905088;  Mon, 17 Jul 2017 00:01:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.206.4 with HTTP; Mon, 17 Jul 2017 00:01:44 -0700 (PDT)
X-Originating-IP: [197.250.99.209]
Received: by 10.28.206.4 with HTTP; Mon, 17 Jul 2017 00:01:44 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es> 
From: Noah 
Date: Mon, 17 Jul 2017 10:01:44 +0300
Message-ID: 
To: Ted Lemon 
Cc: Alissa Cooper , Suresh Krishnan ,  JORDI PALET MARTINEZ , Jim Martin ,  IPv6 Ops WG , Russ Housley , Randy Bush 
Content-Type: multipart/alternative; boundary="001a114c4e04c89c5605547df841"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 07:01:49 -0000

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

FWIW and to cater for all, would a fallback dual stack SSID work for the
status quo while this 2nd v6 SSID is also experimented upon which is a
great idea considering this is IETF.

Noah

On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:

> I don't think this is a social justice issue.   Does the IETF think that
> IPv6 works, or not?   If we think it works, and we have been working for
> what, 20 years, to make it work, and we have designed all this great
> transition tech, then why on earth would we not want to use it?   This
> isn't "one draft."   This is roughly half the work of the IETF for the pa=
st
> two decades.
>
> On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <
> jordi.palet@consulintel.es> wrote:
>
>> So we agree to change the rules so that we use this network for every ID
>> that want to experiment with it? Otherwise we discriminate among differe=
nt
>> authors =E2=80=A6
>>
>> I think is a really bad precedent.
>>
>> Regards,
>> Jordi
>>
>>
>> -----Mensaje original-----
>> De: Ted Lemon 
>> Responder a: 
>> Fecha: lunes, 17 de julio de 2017, 8:48
>> Para: JORDI PALET MARTINEZ 
>> CC: IPv6 Ops WG , Jim Martin , Randy
>> Bush , Suresh Krishnan , Russ
>> Housley , Alissa Cooper 
>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
>> Meetings
>>
>>     I don't actually know what the goal of the IETF network is other tha=
n
>> to provide connectivity.   Because of the vicissitudes of hotel topology=
,
>> it is often the case that IETF participants experience issues with the
>> network at least once or twice per IETF despite the best efforts (and th=
ey
>> are quite exceptional) of the NOC team.   I do not really see what the
>> damage is that you are hoping to protect against here.   Users who don't
>> read the NOC announcement?   No sympathy.   Sorry.
>>
>>
>>
>>
>>
>> **********************************************
>> 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
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be awar=
e
>> that any disclosure, copying, distribution or use of the contents of thi=
s
>> information, including attached files, is prohibited.
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

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


FWIW and to cater for all, would a fallback dual stack SS=
ID work for the status quo while this 2nd v6 SSID is also experimented upon=
 which is a great idea considering this is IETF.

Noah

On 17 Jul 2017 9:54 a.m., "Ted Lemon" <mellon@fugue.com> wrote:
I don't thi=
nk this is a social justice issue. =C2=A0 Does the IETF think that IPv6 wor=
ks, or not? =C2=A0 If we think it works, and we have been working for what,=
 20 years, to make it work, and we have designed all this great transition =
tech, then why on earth would we not want to use it? =C2=A0 This isn't =
"one draft." =C2=A0 This is roughly half the work of the IETF for=
 the past two decades.

On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
So we agree to change the rules so that we use this network for e=
very ID that want to experiment with it? Otherwise we discriminate among di=
fferent authors =E2=80=A6



I think is a really bad precedent.



Regards,

Jordi





-----Mensaje original-----

De: Ted Lemon <mellon@fugue.com>

Responder a: <mell=
on@fugue.com>

Fecha: lunes, 17 de julio de 2017, 8:48

Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

CC: IPv6 Ops WG <v6ops@ietf.org>, Jim Martin <jim@daedelus.com>, Randy Bush <randy@psg.com>, Suresh Krishn=
an <sures=
h.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Alissa Cooper &=
lt;alissa@cooperw.in=
>

Asunt=
o: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings<=
br>



**********************************************

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.







_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--001a114c4e04c89c5605547df841--


From nobody Mon Jul 17 00:18:00 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B88131683 for ; Mon, 17 Jul 2017 00:17:59 -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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEeuoLUg8wtD for ; Mon, 17 Jul 2017 00:17:56 -0700 (PDT)
Received: from mailout34.telekom.de (MAILOUT34.telekom.de [80.149.113.196]) (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 2620C126B7F for ; Mon, 17 Jul 2017 00:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1500275876; x=1531811876; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6EVqmGYh4uLr7+0bhjITf0lsU7zPU5yRee9/4cVRRXk=; b=BGJCTT2XVm97bJRkldvX+cG1UX7UaqHcJxXSyLGh6TKIplTpayygUtjl l7sZ0/+oTMmET9jLeLllLCOMDdu+cxSo7PNYg0E4YiGPLFPvfwxngjk2N SuIAPlQjO3eia7VwEQm1PE6+GthSecJ1+tmSwPRW1iR3hMZFCPwOXSi78 d9zmD+EmVntRhqd0v+fjfyIkNa2HMCYXMPdWY0nW9ACYkldNDzGtOkavD 60ZM1thWSN1+KCkb+uzVo2b2YbbyEfFsP7rSs87vnbzkBxsA8OVcHD1S4 52vLTEP1v7XcQeUi+0+bWszcpsA/63+DV6B1dQx1A1QNX4j37ljRSUXOP w==;
Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT31.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 09:17:53 +0200
X-IronPort-AV: E=Sophos;i="5.40,373,1496095200"; d="scan'208";a="1216849784"
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/AES256-SHA; 17 Jul 2017 09:17:53 +0200
Received: from HE199744.EMEA1.cds.t-internal.com (10.169.119.52) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 09:17:52 +0200
Received: from HE199744.EMEA1.cds.t-internal.com ([fe80::3435:eb51:d048:836d]) by HE199744.emea1.cds.t-internal.com ([fe80::3435:eb51:d048:836d%26]) with mapi id 15.00.1263.000; Mon, 17 Jul 2017 09:17:53 +0200
From: 
To: , 
Thread-Topic: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
Thread-Index: AQHS+wPtmFRdIBFLB06xmR8ahfsFoKJP8KaAgAAFnYCAAyt2oIAAbiuAgAQOpxA=
Date: Mon, 17 Jul 2017 07:17:52 +0000
Message-ID: <4f7eaf1f915a4911a428244bdf7ce497@HE199744.emea1.cds.t-internal.com>
References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com>  <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com> <2ff7a4128d1d424f84c35ddcd3eec0fe@HE199744.emea1.cds.t-internal.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.166.56]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 07:17:59 -0000

U2VlIGJlbG93IHdpdGhbSE1dDQoNCkhvbGdlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hy
aWNodC0tLS0tDQpWb246IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gSW0g
QXVmdHJhZyB2b24gQWxleGFuZHJlIFBldHJlc2N1DQpHZXNlbmRldDogRnJlaXRhZywgMTQuIEp1
bGkgMjAxNyAyMTowMg0KQW46IHY2b3BzQGlldGYub3JnDQpCZXRyZWZmOiBSZTogW3Y2b3BzXSBS
RkM2NDU5ICJJUHY2IGluIDNHUFAiIC0gdGhlIElJRCBpbiB0aGUgTEwgYWRkcmVzcyBhbmQgR1VB
DQoNCj4gW0hNXSBXV0FOIE1vZGVtIENoaXBzZXRzIHBlcmZvcm0gc29tZSBraW5kIG9mIHRyYW5z
bGF0aW9uIG9mIHBhY2tldHMsDQoNClRoaXMgc2VlbXMgbGlrZSBhIGdlbmVyYWxpc2F0aW9uLiAg
SSBkbyBub3QgdW5kZXJzdGFuZCB3aGF0IGRvIHlvdSBtZWFuIGJ5IFdXQU4gTW9kZW0gQ2hpcHNl
dHMgLSBjYW4geW91IGdpdmUgYW4gZXhhbXBsZSBvZiBhIFdXQU4gTW9kZW0gQ2hpcHNldD8NCg0K
SW4gbXkgcGFydGljdWxhciBjYXNlIHRoZXJlIGlzIG5vIHNlcGFyYXRlZCBNb2RlbSBDaGlwc2V0
IGZyb20gYW4gQXBwbGljYXRpb24gQ2hpcHNldCwgb3IgQXBwIFByb2Nlc3NvciB2cy4gQnJvYWRi
YW5kIFByb2Nlc3Nvciwgb3Igc29tZXRoaW5nIGxpa2UgdGhhdCB0aGF0IG9uZSBjYW4gZmluZCBp
biBtYW55IHNtYXJ0cGhvbmVzLiAgT3IgbGlrZSBIb3N0LUlNUCBkaXN0aW5jaXRvbiBvZiBlYXJs
eSBSRkNzLg0KDQpJbiBteSBjYXNlIGl0IGlzIGFuIElvVCBkZXZpY2UuICBJdCBpcyBjYWxsZWQg
YW4gImludGVncmF0ZWQgbW9kdWxlIiBhbmQgaXQgcnVucyBsaW51eC4gIEl0IGlzIGZyb20gU2ll
cnJhLCBmb3JtYXQgQ0YzLCBzZXJpZXMgV1A4Lg0KDQpbSE1dIExvb2sgaW50byB0aGVpciBkYXRh
c2hlZXRzLCB0aGV5IGNhbGwgaXQgIlRlbGVjb20gY29yZSIgdGhlcmUsIGFuZCBpdCBzZWVtcyB0
byBiZSBhIFF1YWxjb21tIEhleGFnb24gYmFzZWQgY2hpcHNldC4NCg0KVGhlcmUgaXMgb25seSBv
bmUgbW9kdWxlIHJ1bm5pbmcgYm90aCBsaW51eCBhbmQgdGhlIGNlbGx1bGFyIGludGVyZmFjZS4N
Cg0KW0hNXSBBbmQgdGhpcyBtb2R1bGUgaGFzIHR3byBwcm9jZXNzb3JzLCBvbmUgZm9yIHRoZSBh
cHBsaWNhdGlvbiwgYW5kIG9uZSBmb3IgdGhlIHRlbGVjb20gc2lkZSAodXN1YWxseSBjYWxsZWQg
InRoZSBtb2RlbSIpLg0KDQo+IGVzcGVjaWFsbHkgSUNNUHY2IHBhY2tldHMsIGJldHdlZW4gdGhl
IGludGVyZmFjZSB0byB0aGUgY29tcHV0ZXIgYW5kIA0KPiB0aGUgaW50ZXJmYWNlIHRvd2FyZHMg
dGhlIHByb3ZpZGVyIG5ldHdvcmsuIFRoZSByZWFzb24gaXMgdGhhdCB0aGUgDQo+IGNvbXB1dGVy
IHdhbnRzIHRvIHNlZSBhbiBFdGhlcm5ldCBicm9hZGNhc3QgaW50ZXJmYWNlLCBidXQgdGhlIA0K
PiBwcm92aWRlciBpbnRlcmZhY2UgaXMgcG9pbnQtdG8tcG9pbnQuIEZvciBleGFtcGxlLCB0aGUg
Y29tcHV0ZXIgbmVlZHMgDQo+IE5laWdoYm9yIERpc2NvdmVyeSBidXQgdGhpcyBpcyBub3QgYXZh
aWxhYmxlIG9uIHRoZSBwcm92aWRlciANCj4gaW50ZXJmYWNlLiBUaGUgcHJvdmlkZXIncyBuZXR3
b3JrIGRldmljZSBkb2Vzbid0IGhhdmUgYSBNQUMgYWRkcmVzcyANCj4gZWl0aGVyLCBzbyB0aGUg
bW9kZW0gY2hpcHNldCBlbXVsYXRlcyB0aGlzIG1pc3NpbmcgTUFDIHRvIHRoZSANCj4gY29tcHV0
ZXIuDQoNCkRvIHlvdSB0aGluayBpdCBpcyBhIGxpbnV4IGtlcm5lbCBtb2R1bGUgdGhhdCBwZXJm
b3JtcyB0aGF0IGVtdWxhdGlvbiwgb3IgaXMgaXQgY29tcGxldGVseSBhbm90aGVyIE9TIChsaWtl
IFRocmVhZFgpPw0KDQpbSE1dIE5vLCBpdCBpcyBhIHNlcGFyYXRlIHByb2Nlc3NvciAoYWN0dWFs
bHkgYSBEU1ApLg0KDQpUaGF0IGVtdWxhdGlvbiBtdXN0IGJlIHN0YW5kYXJkaXNlZC4NCg0KW0hN
XSBXZWxsLCBvYnZpb3VzbHkgbm9ib2R5IHNhdyB0aGUgbmVlZCBmb3IgaXQgdW50aWwgbm93LCBp
dCBpcyBhY3R1YWxseSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gSXQgd291bGQgYmUgYSBnb29k
IGlkZWEgaW5kZWVkIHRvIHNwZWNpZnkgdGhpcy4gTW9zdCBvZiB0aGVzZSB0cmFuc2xhdGlvbiBs
YXllcnMgZHJvcCBhbGwgREhDUHY2IHRyYWZmaWMgc28gbm8gY2hhbmNlIHRvIGdldCBQcmVmaXgg
RGVsZWdhdGlvbiB3b3JraW5nIGlmIGl0IGlzIGluaXRpYXRlZCBieSB0aGUgaG9zdC4gVGhlcmUg
aXMgYSBuZWVkIGZvciBzdWNoIHRyYW5zbGF0aW9uIG90aGVyd2lzZSBJcHY2IHdvbid0IHdvcmsu
IElwdjQgbmVpdGhlciAtIElwdjQgYWRkcmVzcyBhc3NpZ25tZW50IG9uIHRoZSBjYXJyaWVyIHNp
ZGUgZG9lcyBub3QgdXNlIERIQ1B2NCB3aGljaCB0aGUgbW9iaWxlIGhvc3QgdXN1YWxseSBzcGVh
a3MuIFRoaXMgaXMgdGhlIGRvd25zaWRlIG9mIHByZXNlbnRpbmcgYW4gRXRoZXJuZXQgaW50ZXJm
YWNlIHRvIHRoZSBPcGVyYXRpbmcgc3lzdGVtLiBUaGUgdXBzaWRlIGlzIHRoZSB0aGVyZSBpcyBu
byBuZWVkIHRvIGNoYW5nZSBPUyBzcGVjaWZpYyBoYW5kbGluZyBvZiBhIFdXQU4gaW50ZXJmYWNl
IHNpbmNlIGl0IGNhbiBiZSBoYW5kbGVkIGxpa2UgYW55IG90aGVyIEV0aGVybmV0IGludGVyZmFj
ZS4gT3RoZXJ3aXNlLCBlYWNoIE9TIHdvdWxkIGhhdmUgdG8gaW1wbGVtZW50IGFuIGludGVyZmFj
ZSBkcml2ZXIgY29tcGx5aW5nIHRvIDNHUFAncyB2aWV3IG9mIHRoZSB3aXJlbGVzcyBuZXR3b3Jr
IGNvbm5lY3Rpdml0eS4NCg0KPiBTbyB3aGF0IHlvdSBjYXB0dXJlIG9uIFdXQU4wIChvciBob3dl
dmVyIHlvdXIgY29tcHV0ZXIgaW50ZXJmYWNlIGlzDQo+IG5hbWVkKSBpcyBub3Qgd2hhdCBhY3R1
YWxseSBnb2VzIG92ZXIgdGhlIGFpci4NCg0KSWYgeW91IHRoaW5rIHRoYXQgc29tZXRoaW5nIGVs
c2UgZ29lcyBvdmVyIHRoZSBhaXIsIGNhbiB5b3UgdGVsbCBtZSBob3csIG9yIHdoYXQgY2FwdHVy
aW5nIHRvb2wsIGRpZCB5b3UgZmluZCBvdXQgdGhhdCB0aGVyZSBpcyBzb21ldGhpbmcgZWxzZSBv
dmVyIHRoZSBhaXI/DQoNCltITV0gSSB0cmFjZWQgd2l0aGluIHRoZSBvcGVyYXRvcidzIG5ldHdv
cmssIGxvb2tpbmcgYXQgdGhlIEdUUCB0cmFmZmljIGp1c3QgaW4gZnJvbnQgb2YgdGhlIEdHU04v
UEdXLg0KDQpNeSBvcGVyYXRvciBhc2tzIG1lIHRoZSBzYW1lIHRoaW5nIC0gd2hhdCBnb2VzIG92
ZXIgdGhlIGFpciAtIGFuZCBJIGRvbnQga25vdyB3aGF0IHRvIGFuc3dlci4NCltITV0gVGVsbCB0
aGVtIHRvIHRyYWNlIHlvdXIgR1RQIHRyYWZmaWMgcmlnaHQgaW4gZnJvbnQgb2YgdGhlaXIgR0dT
Ti9QR1cgKGUuZy4gR24gaW50ZXJmYWNlKS4NCg0K


From nobody Mon Jul 17 00:32:22 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4673C131A55; Mon, 17 Jul 2017 00:32:21 -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 wPmY6NPOY4Hf; Mon, 17 Jul 2017 00:32:19 -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 A27C9131945; Mon, 17 Jul 2017 00:32:19 -0700 (PDT)
X-AuditID: 60721c4c-001ff70000004e62-7c-596c68011695
Received: from VAADCEX12.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 96.F2.20066.1086C695; Mon, 17 Jul 2017 03:32:18 -0400 (EDT)
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX12.cable.comcast.com (147.191.102.79) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 03:32:16 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 17 Jul 2017 03:32:16 -0400
From: "Brzozowski, John" 
To: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" , v6ops 
CC: Randy Bush , Alissa Cooper , Jim Martin , Jari Arkko , Suresh Krishnan , Russ Housley 
Thread-Topic: RESENDING - ncremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/s7QizrLgNNGjEaoABgh8thCCw==
Date: Mon, 17 Jul 2017 07:32:16 +0000
Message-ID: <0FF06906-9EBC-40BF-A092-93CEDE79930C@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.252]
Content-Type: text/plain; charset="utf-8"
Content-ID: <66DF5EA33B5A5742B3AF2C48DF735DB0@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA11UYWwTZRjOd3dtj7JPb9e1/VbH4o5gxEE3gZhTFP3hjxqZkYiLhR/brb2t Zbd23rVjwz9VI5oO4jS6ss5kBsucA4MSwIHAoDS44VBBHU4gbrHqOn8gsgCLuHhfr92u/ro3 z/N9z/O8T74cTbL9ZgftD4REOSBInNFM1SvP8KsJn+SuHhyx87GxfwEfneL4mekJE7/n1ICR H0+R/O9vZAg+9dkFA//1uZPkU7RrNp0hXNEb3xOuY/FrJlciMUe4jiRiRtf7Pb3ANXh11vC8 aYv5ca8o+dtEuWpDvdl3c/KiofWus/3t/ktkBEyujoIlNGLWoeuzv4EoMNMs8wWB9mf+pDDB MqcB+jy1ViNGAeociJKYMDKPoMNnrpjwXMLsBigxreBDJDMBUHpftwETFmYTih4YMmiHatHN G6PqTKuzE/1wohLDFLMCfTwymzWDzNPoy8td2RkwNnT7/AECzyRjRz+n+wgtKYMSJ74ltdmK Mr/OZ+WtquT4X59QGr4KXbicBtpcjY7sO5XDK9B870EKRyCZlejg8SpN/jH01qungTZXoPc6 p0xanGI02pPOXbWjs6khQxcojesSxReV4jqluE4prlP6EBgGQXmbIHg9Lb5gOFS9xukRGiTR 6Qm2eAQlhL+HAH4MctnGIfB3tysJGBpwRZAUJDdrENqUjpYkaKYJzgovGpvd7D0NQW+HT1B8 dXJYEhWuBBq96km4ADeEpWbOATdg1LKABsTtiiSG1NfHlcO9WMi+wClhpdXv8QfDSl1YlpIA 0aQqu+sFLOsVOnaIclAzS4L7aIqzwweObXOzTJMQEptFsVWU8+x2muYQ7G9ULxbLYpPY3uiX QnlavXenUmUYPZMNuwzyKb+btekJXd4KuB7TDj39/8gEvSQJmugiNfcvIs6ttAotir8pZ22B NbjOojyatS2Fc/gomwd1lstgrUmtyJanCu3Og05Ax/fM3SLow/+M3CZYKhAMiA473Io3Z/Al XziwsLjDBkc31bvZe3UEDuAog7swbtXhixkc98NpzJbq2MIY+X/IDPCoL8YCv8LuReofZnFv FlIYXJoDs2sj+A1+GsU5TLd1GXTjra05ptBtRq2XUOu11GTrDQkhfb1Xa7L15tBcvZdqsvXm wIJ6Y5iy5alCJ0cEDL9oPBs/F1u1JhPcVjvW+1N7f+bkcsezZMePILalPHztiZe/6+vrszvF 4NGpV4x77cUlL73e3fXHowNJ5lZk6+SZiVjlkLL2nUSkZ2xdlTGZ2vzg9dibry33zdelPwXt jR+Mr3/ybuRO0pxumLkyPDE8/BG9c0Xpu4HYjp0blz6X2F3CUYpPePghUlaE/wCeGp3juQUA AA==
Archived-At: 
Subject: [v6ops] RESENDING - ncremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 07:32:21 -0000

QXBvbG9naWVzLCBJIHVuZGVyc3RhbmQgdGhpcyBtYWlsIGRpZCBub3QgbWFrZSBpdCB0byB0aGUg
dmFyaW91cyBsaXN0cy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaG4g
QnJ6b3pvd3NraSA8Sm9obl9Ccnpvem93c2tpQENhYmxlLkNvbWNhc3QuY29tPg0KRGF0ZTogU3Vu
ZGF5LCBKdWx5IDE2LCAyMDE3IGF0IDIwOjI4DQpUbzogImRyYWZ0LWpqbWItdjZvcHMtaWV0Zi1p
cHY2LW9ubHktaW5jcmVtZW50YWxAaWV0Zi5vcmciIDxkcmFmdC1qam1iLXY2b3BzLWlldGYtaXB2
Ni1vbmx5LWluY3JlbWVudGFsQGlldGYub3JnPg0KQ2M6IFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5j
b20+LCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4sIEppbSBNYXJ0aW4gPGppbUBk
YWVkZWx1cy5jb20+LCBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4sIFN1cmVzaCBL
cmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbT4sIFJ1c3MgSG91c2xleSA8aG91c2xl
eUB2aWdpbHNlYy5jb20+DQpTdWJqZWN0OiBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IG9mIElQdjYt
b25seSBXaS1GaSBmb3IgSUVURiBNZWV0aW5ncw0KDQogICAgRm9sa3MsDQogICAgDQogICAgQXBv
bG9naWVzIGluIGFkdmFuY2UgZm9yIHRoZSBncmF0dWl0b3VzIGNyb3NzIHBvc3RpbmcgKHY2b3Bz
LCBpZXRmLCBpcHY2LCBzdW5zZXQ0LCBzb2Z0d2lyZXMpLiAgSSBob3BlLCB0byB5b3UgYWxsLCB0
aGlzIGlzIHdvcnRoIHRoZSBhZGRlZCBlbWFpbC4NCiAgICANCiAgICBUaGUgZHJhZnQgYmVsb3cg
d2FzIHdyaXR0ZW4gdG8gcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IGRvY3VtZW50YXRpb24gdG8gZW5h
YmxlIHRoZSBJRVRGICh0aGUgTk9DLCBwYXJ0aWNpcGFudHMsIGV0Yy4pIHRvIG1pZ3JhdGUgdG8g
YW4gSVB2NiBvbmx5IHByaW1hcnkgbmV0d29yayBjb25uZWN0aW9uIChXaS1GaSBhbmQgd2lyZWQp
IHRoYXQgdXRpbGl6ZXMgTkFUNjQrRE5TNjQgdG8gYWNjZXNzIElQdjQgb25seSBjb250ZW50LiAg
VGhlIHJlcXVlc3QgZm9yIElFVEYgOTkgaGFzIGJlZW4gdG8gaGF2ZSB0aGUgcHJpbWFyeSDigJxp
ZXRm4oCdIFNTSUQgYWRoZXJlIHRvIHdoYXQgaXMgZG9jdW1lbnRlZCBpbiB0aGUgSS1EIGJlbG93
LiAgSSB0cnVzdCB0aGUgbW90aXZhdGlvbiBpcyB1bmRlcnN0b29kLiAgVGhpcyBtZWFucyB0aGF0
IHRoZSBtYWluIOKAnGlldGbigJ0gU1NJRCB3b3VsZCBiZSBzd2l0Y2hlZCB0byBiZSBJUHY2IG9u
bHkgd2l0aCBOQVQ2NCtETlM2NCAoYXQgbGF5ZXIgMykgcGVyIHRoZSBJLUQgYmVsb3cuICBHaXZl
biB0aGUgdGhhdCBJRVRGOTkgaXMgdXBvbiB1cywgdGhpcyBtYXkgb3IgbWF5IG5vdCBiZSBlbnRp
cmVseSBwb3NzaWJsZS4NCiAgICANCiAgICBBdCB0aGlzIHN0YWdlLCB0aGUgaW5mcmFzdHJ1Y3R1
cmUgcHJlcGFyYXRpb25zIGZvciBJRVRGIDk5IHNob3VsZCBiZSBpbiBwbGFjZSB0byBlbnN1cmUg
dGhhdCB0aGUgSUVURiBoYXMgdGhlIG5lY2Vzc2FyeSBoYXJkd2FyZSBmb3IgcmVkdW5kYW5jeSBh
bmQgcGVyZm9ybWFuY2UuDQogICAgDQogICAgU28sIHdlIGFyZSBhbGwgc2Vla2luZyB5b3VyIGlu
cHV0LiAgR2l2ZW4gdGhlIGFib3ZlLCB3aGF0IHdvdWxkIGFsbCB5b3Ugc3VnZ2VzdCBpcyB0b2xl
cmFibGUgZm9yIElFVEY5OSBhcyBpdCBwZXJ0YWlucyB0byB0aGUgSS1EIGJlbG93Pw0KICAgIA0K
ICAgIOKAoiBJUHY2IG9ubHkgcGVyIHRoZSBJLUQgZm9yIHRoZSBiYWxhbmNlIG9mIElFVEYgd2Vl
az8NCiAgICDigKIgSVB2NiBvbmx5IHBlciB0aGUgSS1EIGZvciBvbmUgb3IgbW9yZSBkYXlzIHRo
aXMgd2Vlaz8NCiAgICDigKIgSVB2NiBvbmx5IHBlciB0aGUgSS1EIGZvciB0aGUgcGxlbmFyeT8N
CiAgICDigKIgSVB2NiBvbmx5IHBlciB0aGUgSS1EIGZvciB0aGUgbmV4dCBJRVRGIG1lZXRpbmc/
DQogICAgDQogICAgUGxlYXNlIHNlbmQgdXMgeW91ciBmZWVkYmFjay4NCiAgICANCiAgICBSZWdh
cmRzLA0KICAgIA0KICAgIEpvaG4NCiAgICArMS00ODQtOTYyLTAwNjANCiAgICANCiAgICAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQogICAgRGF0ZTogU2F0dXJkYXksIEp1bHkg
MSwgMjAxNyBhdCAwMzowNA0KICAgIFRvOiBNYXJjdXMgS2VhbmUgPG1hcmN1cy5rZWFuZUBtaWNy
b3NvZnQuY29tPiwgSmVuIExpbmtvdmEgPGZ1cnJ5QGdvb2dsZS5jb20+LCBMb3JlbnpvIENvbGl0
dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4sIEpvaG4gQnJ6b3pvd3NraSA8Sm9obl9Ccnpvem93c2tp
QENhYmxlLkNvbWNhc3QuY29tPiwgRXJpayBLbGluZSA8ZWtAZ29vZ2xlLmNvbT4sIEpvaG4gQnJ6
b3pvd3NraSA8Sm9obl9Ccnpvem93c2tpQENhYmxlLkNvbWNhc3QuY29tPiwgRGF2aWQgU2NoaW5h
emkgPGRzY2hpbmF6aUBhcHBsZS5jb20+LCBTdHVhcnQgQ2hlc2hpcmUgPGNoZXNoaXJlQGFwcGxl
LmNvbT4sIEplbiBMaW5rb3ZhIDxmdXJyeUBnb29nbGUuY29tPiwgUGF1bCBTYWFiIDxwc0BmYi5j
b20+LCBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppQGFwcGxlLmNvbT4NCiAgICBTdWJqZWN0OiBO
ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpqbWItdjZvcHMtaWV0Zi1pcHY2LW9u
bHktaW5jcmVtZW50YWwtMDAudHh0DQogICAgDQogICAgICAgIA0KICAgICAgICBBIG5ldyB2ZXJz
aW9uIG9mIEktRCwgZHJhZnQtamptYi12Nm9wcy1pZXRmLWlwdjYtb25seS1pbmNyZW1lbnRhbC0w
MC50eHQNCiAgICAgICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIEph
c29uIEJyem96b3dza2kgYW5kIHBvc3RlZCB0byB0aGUNCiAgICAgICAgSUVURiByZXBvc2l0b3J5
Lg0KICAgICAgICANCiAgICAgICAgTmFtZToJCWRyYWZ0LWpqbWItdjZvcHMtaWV0Zi1pcHY2LW9u
bHktaW5jcmVtZW50YWwNCiAgICAgICAgUmV2aXNpb246CTAwDQogICAgICAgIFRpdGxlOgkJSW5j
cmVtZW50YWwgRGVwbG95bWVudCBvZiBJUHY2LW9ubHkgV2ktRmkgZm9yIElFVEYgTWVldGluZ3MN
CiAgICAgICAgRG9jdW1lbnQgZGF0ZToJMjAxNy0wNi0zMA0KICAgICAgICBHcm91cDoJCUluZGl2
aWR1YWwgU3VibWlzc2lvbg0KICAgICAgICBQYWdlczoJCTE1DQogICAgICAgIFVSTDogICAgICAg
ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamptYi12Nm9w
cy1pZXRmLWlwdjYtb25seS1pbmNyZW1lbnRhbC0wMC50eHQNCiAgICAgICAgU3RhdHVzOiAgICAg
ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpqbWItdjZvcHMtaWV0
Zi1pcHY2LW9ubHktaW5jcmVtZW50YWwvDQogICAgICAgIEh0bWxpemVkOiAgICAgICBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamptYi12Nm9wcy1pZXRmLWlwdjYtb25seS1pbmNy
ZW1lbnRhbC0wMA0KICAgICAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1qam1iLXY2b3BzLWlldGYtaXB2Ni1vbmx5LWluY3JlbWVu
dGFsLTAwDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgQWJzdHJhY3Q6DQogICAgICAgICAg
IFRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gcHJvdmlkZSBhIGJsdWVwcmludCBh
bmQgZ3VpZGFuY2UNCiAgICAgICAgICAgZm9yIGRlcGxveWluZyBJUHY2LW9ubHkgV2ktRmkgYXQg
SUVURiBtZWV0aW5ncy4gIFRoaXMgZG9jdW1lbnQNCiAgICAgICAgICAgb3V0bGluZXMgaW5mcmFz
dHJ1Y3R1cmUgYW5kIG9wZXJhdGlvbmFsIGd1aWRhbmNlIHRoYXQgb3BlcmF0b3JzDQogICAgICAg
ICAgIHNob3VsZCBjb25zaWRlciB3aGVuIGRlcGxveWluZyBJUHY2LW9ubHkgbmV0d29ya3MgdXNp
bmcgTkFUNjQgYW5kDQogICAgICAgICAgIEROUzY0IHRvIHN1cHBvcnQgY29tbXVuaWNhdGlvbiB0
byBsZWdhY3kgSVB2NC1vbmx5IHNlcnZpY2VzLg0KICAgICAgICANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIFBsZWFzZSBub3Rl
IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1
Ym1pc3Npb24NCiAgICAgICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl
IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICAgICAgDQogICAgICAgIFRoZSBJRVRG
IFNlY3JldGFyaWF0DQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQoN
Cg==


From nobody Mon Jul 17 01:14:04 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EC413179D for ; Mon, 17 Jul 2017 01:14: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, HTML_MESSAGE=0.001, 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 9qtAIdrAZmwB for ; Mon, 17 Jul 2017 01:13:59 -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 0C45E131798 for ; Mon, 17 Jul 2017 01:13:58 -0700 (PDT)
X-AuditID: 60721c4b-733ff70000000a8e-fc-596c71c4a938
Received: from VAADCEX11.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 A6.F0.02702.4C17C695; Mon, 17 Jul 2017 04:13:57 -0400 (EDT)
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX11.cable.comcast.com (147.191.102.78) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 04:13:55 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 17 Jul 2017 04:13:55 -0400
From: "Brzozowski, John" 
To: Noah , Ted Lemon 
CC: Randy Bush , IPv6 Ops WG , Alissa Cooper , Russ Housley , Jim Martin , Suresh Krishnan 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/tSiyacM1/hfIEykN3ouQq0Z3w==
Date: Mon, 17 Jul 2017 08:13:55 +0000
Message-ID: <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.253]
Content-Type: multipart/alternative; boundary="_000_0FAF1E05DA4B47BF95F77EFCD1BED9B0cablecomcastcom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA11UfUwbZRzOe9ePo+N1t4O2L5WhNHGZ0zEwZjb4sbmQWGPQTRa10wSOcqMd pa13LQOdERcrpCxxH+Bct8WFMfcRlAVQQIVAV8mYIwIa9iGLY+ICROfIJgjq8N67Kxz+8/Z3 z/P7/Z7nnr45imRuGiyU2xvgeC/rseoMmgLhedvab9/0ODKvH8myHbz4L7BNjl/R24ZjpO23 xhhh290V1thuhiYIW+xsv9b2XW8nuZGy3x2bIOzhqR8I++6BT/X2jsg1vb2hYZawTx4bBPa6 Q4eB/czIXe1mapvhqSLO4y7j+HXPFBhcVbF9wH/9Q1B+vqVRVwmmakAYJFCIfhz9+uXPujAw UAzdRqBb1R2k/NAN0MjVP7XyQx9Ac51NOjyio9ej1p6f9LhOpp9Ac03dBG4i6R8Baq+fJzCR RL+MZi4OauWmPNT2wR1lIANNt9yTtDX0Q2j/1+MaXEM6B+3trCVktX4S/VM9IKkl0FvQcPSy tAjQJjRzoVESIGkzujr2CSG/BI0avvmelGsjmvjlntRvFMWGb5/WyPijqP/SmPLSmeiLE10K no66bp8SZylxZzEKv8/LflagvkNjSosZnYu1a/eClIhKObI4EVFNyPDDqOmrdXJ3OqqtGdXL 9WoUOnJUqbNR57k5oO45BqgzIK2MZYucpS5fMJCZleFkCz1chtNX6mSFAP5tBvjq8KkvtIPP Z5+LApoC1kR4Mt/jYLRsmVBRGgUlFGE1wkFdiYO5r9BXVOFiBVc+H/RwgjUZ5njETrgAFwY9 JVYLfNYvokkLqJfbKXi4gHhXrWmwHi8yL3BCUPC7nW5fUMgP8p4oQBQprt2Th9cWsRVvcbxP FouC+ymN1QxXdexwMHQxG+BKOM7P8XF2J0VZETyFlVfwXDFXvt3tCcRpce6vR0SGVjOS2ZXQ FnM7GJOaUPlNh09i2qKm/2+ZoBKioJhKFH2/48O+BT9bKriLFekkmFAqoolxVJJNgSHslImD KsmV8BW9GJEpTi2VuwCOAiry8ew0QTVLZ+vf52cIKiqdvfhkNF6fl7OY4VasQOM1rqB3IQqL CfZtKXAwy1UEtmRJhXswblThi64sD8JxzKao2KXG4t+gSeAU71ASbMbqieIXajEJBtZhcJkC SkEgWC39ZQqmyiEVOnAORoVZqjYpBk6IgSflSoEH2IA68JFcKXAFVQIfypUCV8AlgR/ElClO LVWyVILQvh2Zf4S3ze/v2fDaKKo6kb06m37R6N7+wEe9yf6sVzdMk8dr6t4wv9T62bub3o7k s85dLXdGO+dG+GW186uymbT6G0PHl79+o+eS29H4e9/6yltTVzafzgu9t5E4axioeqyhrcaw tXyNdf7w5acrTm46AEztBTNrh67V7goxIao7kGPVCC42aw3JC+x/G+jKMvkFAAA=
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:14:01 -0000

--_000_0FAF1E05DA4B47BF95F77EFCD1BED9B0cablecomcastcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWdyZWUgd2l0aCBOb2FoIGFuZCBUZWQuDQoNCk5vdGUgdGhlIEktRCBleHBsaWNpdGx5IGRvY3Vt
ZW50cyB0aGF0IGEgZmFsbGJhY2ssIGR1YWwgc3RhY2sgU1NJRCBtdXN0IHJlbWFpbiBhdmFpbGFi
bGUgYXMgTm9haCBtZW50aW9ucyBiZWxvdy4NCg0KSSBmYWlsIHRvIHNlZSBob3cgZG9pbmcgdGhp
cyB3aWxsIGhhcm0gb3IgZGlzY3JpbWluYXRlLg0KDQpXZSBkbyBuZWVkIHRvIGVhdCBvdXIgb3du
IGRvZ2Zvb2QsIG90aGVyd2lzZSB3ZSBhcmUgaHlwb2NyaXRlcy4NCg0KSm9obg0KKzEtNDg0LTk2
Mi0wMDYwDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg
b2YgTm9haCA8bm9haEBuZW8uY28udHo+DQpEYXRlOiBNb25kYXksIEp1bHkgMTcsIDIwMTcgYXQg
MDk6MDENClRvOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogUmFuZHkgQnVzaCA8
cmFuZHlAcHNnLmNvbT4sIHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4sIEFsaXNzYSBDb29wZXIgPGFs
aXNzYUBjb29wZXJ3LmluPiwgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT4sIEpp
bSBNYXJ0aW4gPGppbUBkYWVkZWx1cy5jb20+LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlz
aG5hbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3lt
ZW50IG9mIElQdjYtb25seSBXaS1GaSBmb3IgSUVURiBNZWV0aW5ncw0KDQpGV0lXIGFuZCB0byBj
YXRlciBmb3IgYWxsLCB3b3VsZCBhIGZhbGxiYWNrIGR1YWwgc3RhY2sgU1NJRCB3b3JrIGZvciB0
aGUgc3RhdHVzIHF1byB3aGlsZSB0aGlzIDJuZCB2NiBTU0lEIGlzIGFsc28gZXhwZXJpbWVudGVk
IHVwb24gd2hpY2ggaXMgYSBncmVhdCBpZGVhIGNvbnNpZGVyaW5nIHRoaXMgaXMgSUVURi4NCg0K
Tm9haA0KDQpPbiAxNyBKdWwgMjAxNyA5OjU0IGEubS4sICJUZWQgTGVtb24iIDxtZWxsb25AZnVn
dWUuY29tPG1haWx0bzptZWxsb25AZnVndWUuY29tPj4gd3JvdGU6DQpJIGRvbid0IHRoaW5rIHRo
aXMgaXMgYSBzb2NpYWwganVzdGljZSBpc3N1ZS4gICBEb2VzIHRoZSBJRVRGIHRoaW5rIHRoYXQg
SVB2NiB3b3Jrcywgb3Igbm90PyAgIElmIHdlIHRoaW5rIGl0IHdvcmtzLCBhbmQgd2UgaGF2ZSBi
ZWVuIHdvcmtpbmcgZm9yIHdoYXQsIDIwIHllYXJzLCB0byBtYWtlIGl0IHdvcmssIGFuZCB3ZSBo
YXZlIGRlc2lnbmVkIGFsbCB0aGlzIGdyZWF0IHRyYW5zaXRpb24gdGVjaCwgdGhlbiB3aHkgb24g
ZWFydGggd291bGQgd2Ugbm90IHdhbnQgdG8gdXNlIGl0PyAgIFRoaXMgaXNuJ3QgIm9uZSBkcmFm
dC4iICAgVGhpcyBpcyByb3VnaGx5IGhhbGYgdGhlIHdvcmsgb2YgdGhlIElFVEYgZm9yIHRoZSBw
YXN0IHR3byBkZWNhZGVzLg0KDQpPbiBNb24sIEp1bCAxNywgMjAxNyBhdCA4OjUxIEFNLCBKT1JE
SSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM8bWFpbHRvOmpvcmRp
LnBhbGV0QGNvbnN1bGludGVsLmVzPj4gd3JvdGU6DQpTbyB3ZSBhZ3JlZSB0byBjaGFuZ2UgdGhl
IHJ1bGVzIHNvIHRoYXQgd2UgdXNlIHRoaXMgbmV0d29yayBmb3IgZXZlcnkgSUQgdGhhdCB3YW50
IHRvIGV4cGVyaW1lbnQgd2l0aCBpdD8gT3RoZXJ3aXNlIHdlIGRpc2NyaW1pbmF0ZSBhbW9uZyBk
aWZmZXJlbnQgYXV0aG9ycyDigKYNCg0KSSB0aGluayBpcyBhIHJlYWxseSBiYWQgcHJlY2VkZW50
Lg0KDQpSZWdhcmRzLA0KSm9yZGkNCg0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6
IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+DQpS
ZXNwb25kZXIgYTogPG1lbGxvbkBmdWd1ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+Pg0K
RmVjaGE6IGx1bmVzLCAxNyBkZSBqdWxpbyBkZSAyMDE3LCA4OjQ4DQpQYXJhOiBKT1JESSBQQUxF
VCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM8bWFpbHRvOmpvcmRpLnBhbGV0
QGNvbnN1bGludGVsLmVzPj4NCkNDOiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRv
OnY2b3BzQGlldGYub3JnPj4sIEppbSBNYXJ0aW4gPGppbUBkYWVkZWx1cy5jb208bWFpbHRvOmpp
bUBkYWVkZWx1cy5jb20+PiwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNvbTxtYWlsdG86cmFuZHlA
cHNnLmNvbT4+LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb208bWFp
bHRvOnN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+PiwgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZp
Z2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+PiwgQWxpc3NhIENvb3BlciA8
YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4NCkFzdW50bzogUmU6
IFt2Nm9wc10gSW5jcmVtZW50YWwgRGVwbG95bWVudCBvZiBJUHY2LW9ubHkgV2ktRmkgZm9yIElF
VEYgTWVldGluZ3MNCg0KICAgIEkgZG9uJ3QgYWN0dWFsbHkga25vdyB3aGF0IHRoZSBnb2FsIG9m
IHRoZSBJRVRGIG5ldHdvcmsgaXMgb3RoZXIgdGhhbiB0byBwcm92aWRlIGNvbm5lY3Rpdml0eS4g
ICBCZWNhdXNlIG9mIHRoZSB2aWNpc3NpdHVkZXMgb2YgaG90ZWwgdG9wb2xvZ3ksIGl0IGlzIG9m
dGVuIHRoZSBjYXNlIHRoYXQgSUVURiBwYXJ0aWNpcGFudHMgZXhwZXJpZW5jZSBpc3N1ZXMgd2l0
aCB0aGUgbmV0d29yayBhdCBsZWFzdCBvbmNlIG9yIHR3aWNlIHBlciBJRVRGIGRlc3BpdGUgdGhl
IGJlc3QgZWZmb3J0cyAoYW5kIHRoZXkgYXJlIHF1aXRlIGV4Y2VwdGlvbmFsKSBvZiB0aGUgTk9D
IHRlYW0uICAgSSBkbyBub3QgcmVhbGx5IHNlZSB3aGF0IHRoZSBkYW1hZ2UgaXMgdGhhdCB5b3Ug
YXJlIGhvcGluZyB0byBwcm90ZWN0IGFnYWluc3QgaGVyZS4gICBVc2VycyB3aG8gZG9uJ3QgcmVh
ZCB0aGUgTk9DIGFubm91bmNlbWVudD8gICBObyBzeW1wYXRoeS4gICBTb3JyeS4NCg0KDQoNCg0K
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBv
dmVyDQpBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cuY29u
c3VsaW50ZWwuZXMNClRoZSBJUHY2IENvbXBhbnkNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2Ug
Y29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50
aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhl
IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0
aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5n
IGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNA
aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0
bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
djZvcHMNCg==

--_000_0FAF1E05DA4B47BF95F77EFCD1BED9B0cablecomcastcom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBNaW5jaG8i
Ow0KCXBhbm9zZS0xOjIgMiA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUgMCAwIDAgMCAwIDAg
MDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ubS01NjA3MTA4Njc3NDc1ODAwNTI1
aW0NCgl7bXNvLXN0eWxlLW5hbWU6bV8tNTYwNzEwODY3NzQ3NTgwMDUyNWltO30NCnNwYW4uRW1h
aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkFncmVlIHdpdGgg
Tm9haCBhbmQgVGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+
Tm90ZSB0aGUgSS1EIGV4cGxpY2l0bHkgZG9jdW1lbnRzIHRoYXQgYSBmYWxsYmFjaywgZHVhbCBz
dGFjayBTU0lEIG11c3QgcmVtYWluIGF2YWlsYWJsZSBhcyBOb2FoIG1lbnRpb25zIGJlbG93Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+SSBmYWlsIHRvIHNlZSBo
b3cgZG9pbmcgdGhpcyB3aWxsIGhhcm0gb3IgZGlzY3JpbWluYXRlLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+V2UgZG8gbmVlZCB0byBlYXQgb3VyIG93biBkb2dm
b29kLCBvdGhlcndpc2Ugd2UgYXJlIGh5cG9jcml0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2hu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MS00ODQt
OTYyLTAwNjA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPnY2b3BzICZsdDt2
Nm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTm9haCAmbHQ7bm9haEBuZW8u
Y28udHomZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSnVseSAxNywgMjAxNyBhdCAwOTow
MTxicj4NCjxiPlRvOiA8L2I+VGVkIExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0Ozxicj4N
CjxiPkNjOiA8L2I+UmFuZHkgQnVzaCAmbHQ7cmFuZHlAcHNnLmNvbSZndDssIHY2b3BzICZsdDt2
Nm9wc0BpZXRmLm9yZyZndDssIEFsaXNzYSBDb29wZXIgJmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0
OywgUnVzcyBIb3VzbGV5ICZsdDtob3VzbGV5QHZpZ2lsc2VjLmNvbSZndDssIEppbSBNYXJ0aW4g
Jmx0O2ppbUBkYWVkZWx1cy5jb20mZ3Q7LCBTdXJlc2ggS3Jpc2huYW4gJmx0O3N1cmVzaC5rcmlz
aG5hbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbdjZvcHNdIEluY3Jl
bWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdpLUZpIGZvciBJRVRGIE1lZXRpbmdzPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkZXSVcg
YW5kIHRvIGNhdGVyIGZvciBhbGwsIHdvdWxkIGEgZmFsbGJhY2sgZHVhbCBzdGFjayBTU0lEIHdv
cmsgZm9yIHRoZSBzdGF0dXMgcXVvIHdoaWxlIHRoaXMgMm5kIHY2IFNTSUQgaXMgYWxzbyBleHBl
cmltZW50ZWQgdXBvbiB3aGljaCBpcyBhIGdyZWF0IGlkZWEgY29uc2lkZXJpbmcgdGhpcyBpcyBJ
RVRGLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk5vYWg8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiAxNyBKdWwgMjAxNyA5
OjU0IGEubS4sICZxdW90O1RlZCBMZW1vbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxv
bkBmdWd1ZS5jb20iPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIHNvY2lhbCBqdXN0aWNlIGlzc3Vl
LiAmbmJzcDsgRG9lcyB0aGUgSUVURiB0aGluayB0aGF0IElQdjYgd29ya3MsIG9yIG5vdD8gJm5i
c3A7IElmIHdlIHRoaW5rIGl0IHdvcmtzLCBhbmQgd2UgaGF2ZSBiZWVuIHdvcmtpbmcgZm9yIHdo
YXQsIDIwIHllYXJzLCB0byBtYWtlIGl0IHdvcmssIGFuZCB3ZSBoYXZlIGRlc2lnbmVkIGFsbCB0
aGlzIGdyZWF0DQogdHJhbnNpdGlvbiB0ZWNoLCB0aGVuIHdoeSBvbiBlYXJ0aCB3b3VsZCB3ZSBu
b3Qgd2FudCB0byB1c2UgaXQ/ICZuYnNwOyBUaGlzIGlzbid0ICZxdW90O29uZSBkcmFmdC4mcXVv
dDsgJm5ic3A7IFRoaXMgaXMgcm91Z2hseSBoYWxmIHRoZSB3b3JrIG9mIHRoZSBJRVRGIGZvciB0
aGUgcGFzdCB0d28gZGVjYWRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+T24gTW9uLCBKdWwgMTcsIDIwMTcgYXQgODo1MSBBTSwgSk9SREkgUEFMRVQgTUFSVElORVog
Jmx0OzxhIGhyZWY9Im1haWx0bzpqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcyIgdGFyZ2V0PSJf
YmxhbmsiPmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJn
aW4tbGVmdDouNWluIj4NClNvIHdlIGFncmVlIHRvIGNoYW5nZSB0aGUgcnVsZXMgc28gdGhhdCB3
ZSB1c2UgdGhpcyBuZXR3b3JrIGZvciBldmVyeSBJRCB0aGF0IHdhbnQgdG8gZXhwZXJpbWVudCB3
aXRoIGl0PyBPdGhlcndpc2Ugd2UgZGlzY3JpbWluYXRlIGFtb25nIGRpZmZlcmVudCBhdXRob3Jz
IOKApjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpQTWluZ0xpVSI+PGJyPg0KPGJyPg0KPC9zcGFu
PkkgdGhpbmsgaXMgYSByZWFsbHkgYmFkIHByZWNlZGVudC48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6UE1pbmdMaVUiPjxicj4NCjxicj4NCjwvc3Bhbj5SZWdhcmRzLDxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpQTWluZ0xpVSI+PGJyPg0KPC9zcGFuPkpvcmRpPHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OlBNaW5nTGlVIj48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+LS0tLS1NZW5zYWplIG9yaWdp
bmFsLS0tLS08c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6UE1pbmdMaVUiPjxicj4NCjwvc3Bhbj5E
ZTogVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0Ozxicj4NClJlc3BvbmRlciBhOiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tZWxsb25A
ZnVndWUuY29tPC9hPiZndDs8YnI+DQpGZWNoYTogbHVuZXMsIDE3IGRlIGp1bGlvIGRlIDIwMTcs
IDg6NDg8YnI+DQpQYXJhOiBKT1JESSBQQUxFVCBNQVJUSU5FWiAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzIiB0YXJnZXQ9Il9ibGFuayI+am9yZGkucGFsZXRA
Y29uc3VsaW50ZWwuZXM8L2E+Jmd0Ozxicj4NCkNDOiBJUHY2IE9wcyBXRyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+
Jmd0OywgSmltIE1hcnRpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbUBkYWVkZWx1cy5jb20iIHRh
cmdldD0iX2JsYW5rIj5qaW1AZGFlZGVsdXMuY29tPC9hPiZndDssIFJhbmR5IEJ1c2ggJmx0Ozxh
IGhyZWY9Im1haWx0bzpyYW5keUBwc2cuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmFuZHlAcHNnLmNv
bTwvYT4mZ3Q7LCBTdXJlc2gNCiBLcmlzaG5hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cmVzaC5r
cmlzaG5hbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdXJlc2gua3Jpc2huYW5AZ21haWwu
Y29tPC9hPiZndDssIFJ1c3MgSG91c2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlAdmln
aWxzZWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+aG91c2xleUB2aWdpbHNlYy5jb208L2E+Jmd0Oywg
QWxpc3NhIENvb3BlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIiB0YXJn
ZXQ9Il9ibGFuayI+YWxpc3NhQGNvb3BlcncuaW48L2E+Jmd0Ozxicj4NCjxzcGFuIGNsYXNzPSJt
LTU2MDcxMDg2Nzc0NzU4MDA1MjVpbSI+QXN1bnRvOiBSZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBE
ZXBsb3ltZW50IG9mIElQdjYtb25seSBXaS1GaSBmb3IgSUVURiBNZWV0aW5nczwvc3Bhbj48YnI+
DQo8YnI+DQo8c3BhbiBjbGFzcz0ibS01NjA3MTA4Njc3NDc1ODAwNTI1aW0iPiZuYnNwOyAmbmJz
cDsgSSBkb24ndCBhY3R1YWxseSBrbm93IHdoYXQgdGhlIGdvYWwgb2YgdGhlIElFVEYgbmV0d29y
ayBpcyBvdGhlciB0aGFuIHRvIHByb3ZpZGUgY29ubmVjdGl2aXR5LiZuYnNwOyAmbmJzcDtCZWNh
dXNlIG9mIHRoZSB2aWNpc3NpdHVkZXMgb2YgaG90ZWwgdG9wb2xvZ3ksIGl0IGlzIG9mdGVuIHRo
ZSBjYXNlIHRoYXQgSUVURiBwYXJ0aWNpcGFudHMgZXhwZXJpZW5jZSBpc3N1ZXMgd2l0aCB0aGUN
CiBuZXR3b3JrIGF0IGxlYXN0IG9uY2Ugb3IgdHdpY2UgcGVyIElFVEYgZGVzcGl0ZSB0aGUgYmVz
dCBlZmZvcnRzIChhbmQgdGhleSBhcmUgcXVpdGUgZXhjZXB0aW9uYWwpIG9mIHRoZSBOT0MgdGVh
bS4mbmJzcDsgJm5ic3A7SSBkbyBub3QgcmVhbGx5IHNlZSB3aGF0IHRoZSBkYW1hZ2UgaXMgdGhh
dCB5b3UgYXJlIGhvcGluZyB0byBwcm90ZWN0IGFnYWluc3QgaGVyZS4mbmJzcDsgJm5ic3A7VXNl
cnMgd2hvIGRvbid0IHJlYWQgdGhlIE5PQyBhbm5vdW5jZW1lbnQ/Jm5ic3A7ICZuYnNwO05vIHN5
bXBhdGh5LiZuYnNwOw0KICZuYnNwO1NvcnJ5Ljwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKio8YnI+DQpJUHY0IGlzIG92ZXI8YnI+DQpBcmUgeW91IHJlYWR5IGZv
ciB0aGUgbmV3IEludGVybmV0ID88YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmNvbnN1bGludGVs
LmVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5jb25zdWxpbnRlbC5lczwvYT48YnI+DQpU
aGUgSVB2NiBDb21wYW55PGJyPg0KPGJyPg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFp
bnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBU
aGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2
aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll
bnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9y
DQogdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0
YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWls
aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_0FAF1E05DA4B47BF95F77EFCD1BED9B0cablecomcastcom_--


From nobody Mon Jul 17 01:16:19 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8461317A1 for ; Mon, 17 Jul 2017 01:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M46TzZggbrQ for ; Mon, 17 Jul 2017 01:16:16 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CA0131798 for ; Mon, 17 Jul 2017 01:16:16 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A74BE41B75 for ; Mon, 17 Jul 2017 10:16:14 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E965C41B72; Mon, 17 Jul 2017 10:16:13 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id DA18A1F2B6; Mon, 17 Jul 2017 10:16:13 +0200 (CEST)
Date: Mon, 17 Jul 2017 10:16:13 +0200
From: Gert Doering 
To: "Brzozowski, John" 
Cc: Noah , Ted Lemon , Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
Message-ID: <20170717081613.GH45648@Space.Net>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:16:18 -0000

Hi,

On Mon, Jul 17, 2017 at 08:13:55AM +0000, Brzozowski, John wrote:
> We do need to eat our own dogfood, otherwise we are hypocrites.

This.

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

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


From nobody Mon Jul 17 01:18:03 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28FA131945 for ; Mon, 17 Jul 2017 01:18: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, 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 MQ2Lb_9j82IA for ; Mon, 17 Jul 2017 01:18:00 -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 DF7F1131798 for ; Mon, 17 Jul 2017 01:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500279471; x=1500884271; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=ygJ1JtMfexKdiI570kxL4/eST blnDVPzkIM2IZlt5TA=; b=t6w3DXNkxwWbKbMB4Q5h+deQMbk1/UgJKmtm/JoI+ wYlXe9RF/8VN6sokufhzTEgiSieRxYG+xk2lZVG5/GVYALkA6vXEuqHitw4QLTeU U8dLKE5qew+RNxWfF+Y132qCNTg+IAoay7KcYC/JsvVR1wXiJqOH+vJrk/R7eCVH xQ=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=AXwanPRVwgk4sVRNjR9BQF1D4UW/LS9wBQe/1yV6mvRjUPHvqPHzzBTRfkWA SzEwhxUo1TgouLVVr/OuEYcgA7urOCihoLoPHfjuXxbqs02uJD8writEu 9pay4di4GkP4Yo056qiACIeL/bN+5VnUwLt2ghDvTHHGr9bzMTVVxE=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:17:51 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:17:50 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478167.msg for ; Mon, 17 Jul 2017 10:17:49 +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:170717:md50005478167::hMQSBl66XNipac5+:00006e/C
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:17:45 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
Message-ID: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com>
In-Reply-To: <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:18:02 -0000

However, we have different ways for doing the same, and we should go for th=
e one that has less impact and it is more realistic.

In the real world, you will not disable IPv4 in the LANs of end-users or en=
terprise customers (at least not now, may be in 3-5 years from now). This i=
s what IETF need to test now. IPv6 only with IPv4 as a service (which is 46=
4XLAT).

Again, and I=E2=80=99m for-IPv6, but being realistic, not considering sci-f=
i of turning down IPv4 in our customer networks (now).

Regards,
Jordi
=20

-----Mensaje original-----
De: v6ops  en nombre de "Brzozowski, John" 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:14
Para: Noah , Ted Lemon 
CC: Jim Martin , IPv6 Ops WG , Alissa Coo=
per , Russ Housley , Randy Bush , Suresh Krishnan 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    Agree with Noah and Ted.
    =20
    Note the I-D explicitly documents that a fallback, dual stack SSID must=
 remain available as Noah mentions below.
    =20
    I fail to see how doing this will harm or discriminate.
    =20
    We do need to eat our own dogfood, otherwise we are hypocrites.
    =20
    John
   =20
    +1-484-962-0060
    =20
    From:
    v6ops  on behalf of Noah 
    Date: Monday, July 17, 2017 at 09:01
    To: Ted Lemon 
    Cc: Randy Bush , v6ops , Alissa Cooper <=
alissa@cooperw.in>, Russ Housley , Jim Martin , Suresh Krishnan 
    Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF=
 Meetings
   =20
    =20
   =20
    FWIW and to cater for all, would a fallback dual stack SSID work for th=
e status quo while this 2nd v6 SSID is also experimented upon which is a gr=
eat idea considering this is IETF.
   =20
    =20
   =20
    Noah
   =20
   =20
    =20
    On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
   =20
    I don't think this is a social justice issue.   Does the IETF think tha=
t IPv6 works, or not?   If we think it works, and we have been working for =
what, 20 years, to make it work, and we have designed all this great
     transition tech, then why on earth would we not want to use it?   This=
 isn't "one draft."   This is roughly half the work of the IETF for the pas=
t two decades.
   =20
    =20
    On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
   =20
    So we agree to change the rules so that we use this network for every I=
D that want to experiment with it? Otherwise we discriminate among differen=
t authors =E2=80=A6
   =20
    I think is a really bad precedent.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De: Ted Lemon 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 8:48
    Para: JORDI PALET MARTINEZ 
    CC: IPv6 Ops WG , Jim Martin , Randy =
Bush , Suresh
     Krishnan , Russ Housley , Alissa Cooper 
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
   =20
        I don't actually know what the goal of the IETF network is other th=
an to provide connectivity.   Because of the vicissitudes of hotel topology=
, it is often the case that IETF participants experience issues with the
     network at least once or twice per IETF despite the best efforts (and =
they are quite exceptional) of the NOC team.   I do not really see what the=
 damage is that you are hoping to protect against here.   Users who don't r=
ead the NOC announcement?   No sympathy.=20
      Sorry.
   =20
   =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or
     use of the contents of this information, including attached files, is =
prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
    =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =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 Mon Jul 17 01:22:22 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961D51317A1 for ; Mon, 17 Jul 2017 01:22:21 -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 vGfY5fSgCIjs for ; Mon, 17 Jul 2017 01:22:20 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 2D513131798 for ; Mon, 17 Jul 2017 01:22:20 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id p204so21643460wmg.1 for ; Mon, 17 Jul 2017 01:22:20 -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=9C8TRmtVRXGchV/N40TWmFWyiDBePkOFqG43HMMjIzU=; b=dtkwRjqHP1sGK+XzJS5UEp7jGb4h34Xx7sPn5mgLnVMKFfh9O/D2Vbpc4/LJmnRi8h PtyG4IzUM5F3iBpfkKBGz6Tnw7lRIjtIOsugZl42KSZ2D9VLHw3i4FwQYYEP+egLs/wC 3NYhy6iNPlxkz/DpDPAyJrFXVV3c02Qz4RwMo+YMN+YmASRSB7nTc4ZW89HDpomdY3Cd byWGtlBvMADDqda4SgqvF2HO5lOcSgDX3gQKCZYAVedczKCr7XSPPy+6IXnz7v9Fntyn QQw2LMb65o/g8S0FtabhAkYEhobjW/TLB0ut/WJwxSEaBxhphLXd7TjRzTdcIwZiLmDq G/IA==
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=9C8TRmtVRXGchV/N40TWmFWyiDBePkOFqG43HMMjIzU=; b=JHmmUcGKLY9RwKVE2fauNxbYZ1KV//mmn5m9CO2I7F+ifi+/85WW9brfFmJ0GTcnHz cPn6QsZUunR6SfHf3NL7c41QbrQ3rYWX4U3FXuQTvSKKQo+Zg+5PQMS5ZptxCSNO0wqx Du9po5Jq07IoTAOgE4GykhTxifTahJUvHg0HUjsU/MxnfmDJFf2gI9Oi9ZlC6dJjj+SG IqQPeaqe4ekwksJGiIUkijFCi8Nc6xnR1m4Vy+jvw+Bhgz3FISCy1wbnnoInGYTcGvRQ PUk22vuSe/2f3pfFNCrmy4u9uL/lQ5v8YQJF9CckkfizoYAf/TCLHlxwUhYuHQK43hIh yBBQ==
X-Gm-Message-State: AIVw111sJysBft4Cjn4/KmGDhrKcCbb4cIOcYaYcYzHUn5XwG0QCkxlD pmlVw+fLAeUatumJvGM=
X-Received: by 10.28.140.143 with SMTP id o137mr3833750wmd.47.1500279738791; Mon, 17 Jul 2017 01:22:18 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:e1ca:e28:5032:6def? ([2001:67c:1232:144:e1ca:e28:5032:6def]) by smtp.gmail.com with ESMTPSA id 24sm17433664wrw.0.2017.07.17.01.22.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 01:22:18 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\))
From: Fred Baker 
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
Date: Mon, 17 Jul 2017 10:22:13 +0200
Cc: IPv6 Ops WG , Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2967DA6E-D74C-4356-8193-74A6D1EA771E@gmail.com>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
To: JORDI PALET MARTINEZ 
X-Mailer: Apple Mail (2.3439)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:22:21 -0000

> On Jul 17, 2017, at 10:17 AM, JORDI PALET MARTINEZ =
 wrote:
>=20
> In the real world, you will not disable IPv4 in the LANs of end-users =
or enterprise customers (at least not now, may be in 3-5 years from =
now). This is what IETF need to test now. IPv6 only with IPv4 as a =
service (which is 464XLAT).

In the real world, there are networks that are doing this now.=20=


From nobody Mon Jul 17 01:30:52 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F601131A88 for ; Mon, 17 Jul 2017 01:30:50 -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, 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 luYohhReJr3L for ; Mon, 17 Jul 2017 01:30:48 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 F1146131798 for ; Mon, 17 Jul 2017 01:30:47 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id z62so39416885ioi.3 for ; Mon, 17 Jul 2017 01:30:47 -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=mcLi89MwCkwunuuEMK0UnQwT6P/j8wDm5OEl1h3FAho=; b=P8PBW0OpmOjp1eHjFMa5TzkbJK7DylQ9RfTYgbtaKSu/PN67iBkejPn2LJMGxwc7uj 2YtNCOuFkzO7FRWb7KttHN9NovcHoFL5KnSQgeE6BLP8JC6ttQ2r1zkBgpuM/SCxJ3Yw W4dHov1dZdMNXjZwMQq/Yd/Ngmt3YMyJuFp41klLFhXbJci/DlfysZZiWWzbUezV4zzN LXCw4PmcczJvC9L27Qc8E5moAvuSLmIEuLOwYsEKl4aj598u1eaGqOKgvXOEo5BErhXj +Q0pEI6n7YQ2hHM5Tw2YLKC71UU+ByrZD7FY7NxcxO8zEO0HEqG8TjwC7/571ZVj35iV ieag==
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=mcLi89MwCkwunuuEMK0UnQwT6P/j8wDm5OEl1h3FAho=; b=p2Bd0vQz3KyFpluVDm0JgAoYYLk8DS1eTXd5EMbiRsSjxwGuHvWe5NWjkUPG0mNaTn gcuhaQ8xC6yzFwuWxpUQi65XzpjyX2HlJPSTQqSWw+4zabDTB3mkyPV9IuhY+oeGaaqS 6MpLpoXVZHaaH6k243VVVh3siLwaIlw55bX9VO8Ai9mA6QwXNugWo47AIe7T8/6YwYu1 VgDcJC+OHLUWdq8sy9YcWQtLN//GKLu2J8oMmCUMP+U5n4UldPZ4n/1fgRpJG/Hyik5a aUK1MBNzFC5no0PrTqWF3KCbZK1hGEsQ9WPk9EER/yqZIVVQwwe2x+3phdiLZbdpQSsn L1qA==
X-Gm-Message-State: AIVw112ldPvkaABU0F3pQINGmm9IUF0IWV7LfdJAg1ldOidcdIUMnKnz uZJ/tyhkByCWtDP7RRcZM3UH2NxsaQ==
X-Received: by 10.107.137.161 with SMTP id t33mr18086639ioi.181.1500280247311;  Mon, 17 Jul 2017 01:30:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 01:30:26 -0700 (PDT)
In-Reply-To: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>
From: Jen Linkova 
Date: Mon, 17 Jul 2017 18:30:26 +1000
Message-ID: 
To: Jordi Palet Martinez 
Cc: "v6ops@ietf.org" , Jim Martin ,  Russ Housley , Suresh Krishnan ,  Alissa Cooper , Randy Bush 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:30:50 -0000

On Mon, Jul 17, 2017 at 3:24 PM, JORDI PALET MARTINEZ
 wrote:
> In my opinion such kind of experiment should be only done once we approve=
 the document as RFC, note before, so by the next IETF meeting (hopefully).

I'm not sure I understand the logic here.
The I-D is documenting the operational experience and actually I
believe it would make more sense to run the experiment *before*
finalizing the text/publish it as RFC to avoid the situation when  we
publish an RFC on smth we have not even done yet.

> We like it or not, this is not a valid option, unless we make sure that i=
f some participants have troubles, the alternative SSIDs have other 2.4 and=
 5 GHz radios available. Is that the case?

I believe the draft clearly states the the fallback option needs to be
available.

> The way you=E2=80=99re proposing, will mean that many folks may switch to=
 alternative SSID, or simply don't report those failures, so at the end you=
 don=E2=80=99t have any results of how much is not working, etc.

Actually if the fallback dual-stack network requires an explicit
configuration on the client side (as the draft recommends) to avoid
users connecting to it accidentally, the number of clients falling
back to the dual stack SSID is very good data point to demonstrate
what % of users are experiencing issues.

> De: v6ops  en nombre de "Brzozowski, John" 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 6:23
> Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
> CC: Jim Martin , Alissa Cooper , Rus=
s Housley , Randy Bush , Suresh Krishn=
an 
> Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetin=
gs
>
>     Folks,
>
>     Apologies in advance for the gratuitous cross posting (v6ops, ietf, i=
pv6, sunset4, softwires).  I hope, to you all, this is worth the added emai=
l.
>
>     The draft below was written to provide the necessary documentation to=
 enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only p=
rimary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to ac=
cess IPv4 only content.  The request for IETF 99 has been to have the prima=
ry =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I-D belo=
w.  I trust the motivation is understood.  This means that the main =E2=80=
=9Cietf=E2=80=9D SSID would be switched to be IPv6 only with NAT64+DNS64 (a=
t layer 3) per the I-D below.  Given the that IETF99 is upon us, this may o=
r may not be entirely possible.
>
>     At this stage, the infrastructure preparations for IETF 99 should be =
in place to ensure that the IETF has the necessary hardware for redundancy =
and performance.
>
>     So, we are all seeking your input.  Given the above, what would all y=
ou suggest is tolerable for IETF99 as it pertains to the I-D below?
>
>     =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
>     =E2=80=A2 IPv6 only per the I-D for one or more days this week?
>     =E2=80=A2 IPv6 only per the I-D for the plenary?
>     =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
>
>     Please send us your feedback.
>
>     Regards,
>
>     John
>     +1-484-962-0060
>
>     -----Original Message-----
>     From: "internet-drafts@ietf.org" 
>     Date: Saturday, July 1, 2017 at 03:04
>     To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski , David Schinazi , Stuar=
t Cheshire , Jen Linkova , Paul Saab =
, David Schinazi 
>     Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-only=
-incremental-00.txt
>
>
>         A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-incremental=
-00.txt
>         has been successfully submitted by John Jason Brzozowski and post=
ed to the
>         IETF repository.
>
>         Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
>         Revision:       00
>         Title:          Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
>         Document date:  2017-06-30
>         Group:          Individual Submission
>         Pages:          15
>         URL:            https://www.ietf.org/internet-drafts/draft-jjmb-v=
6ops-ietf-ipv6-only-incremental-00.txt
>         Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6ops=
-ietf-ipv6-only-incremental/
>         Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ietf=
-ipv6-only-incremental-00
>         Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjmb-=
v6ops-ietf-ipv6-only-incremental-00
>
>
>         Abstract:
>            The purpose of this document is to provide a blueprint and gui=
dance
>            for deploying IPv6-only Wi-Fi at IETF meetings.  This document
>            outlines infrastructure and operational guidance that operator=
s
>            should consider when deploying IPv6-only networks using NAT64 =
and
>            DNS64 to support communication to legacy IPv4-only services.
>
>
>
>
>         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.o=
rg.
>
>         The IETF Secretariat
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> **********************************************
> 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 c=
onfidential. The information is intended to be for the use of the individua=
l(s) named above. If you are not the intended recipient be aware that any d=
isclosure, copying, distribution or use of the contents of this information=
, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--=20
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 01:31:22 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E02F131A8D for ; Mon, 17 Jul 2017 01:31: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, 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=fugue-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 u0s1X_vendzN for ; Mon, 17 Jul 2017 01:31:18 -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 9D3D0131798 for ; Mon, 17 Jul 2017 01:31:17 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id u5so13541605pgq.3 for ; Mon, 17 Jul 2017 01:31:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a1P3PlRxvrGdOFqboDs8QkeXLOFsqbnSumr4M5iZHYw=; b=ck/SzO4RKfLTESOp44INfVNIDiLW0zoXaFE79imna6YmJCyf1DWa6cfdfjWwl92o68 npKT7WulairOEJbIH/5zZf9PRP5F2TbwVCP4DNzKfz9giwGsCSiFp6AeqsH/6gQMFHJm 5LgxZPxZzSX8KgOg8KxgqA27jGt6eCXdcVmINzgI5UPIqYv8jm8iXTHMd0bFmzVkpLL3 LQNhFufFiY5KICYFd+D6Y0p2W6FSE76kiv4BLFDq8W/NCVcIDDX7VlSnv/osa3gbAgKH 22xgpT0Ak26k5X4UasysGnBV+wY4hieQG+x5KH/WRAr7BkNxbj/ID6YleXb0jw2k83kJ 6LIQ==
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=a1P3PlRxvrGdOFqboDs8QkeXLOFsqbnSumr4M5iZHYw=; b=Yvac5d2Xzc2nGviYSgk5dS/JNeOb2i8YmR8sTKki/7G5qzVLXPD1y5nyHfLZxcbGo8 8o38d0s8aZHZdOdUqumRvIh+raG25Wmm4WabddCmrOpP4j5v1ItUrxuMny6dYSZVs8x2 fUORf34yNOwQ4DQ2Fctn7/UkAD76/iu9U60OwvuDOOwxcfLmpicrRn1/8fV+T3v0CYo4 gXlb6frBhWitkQGSHNtjOOSITqPrugCZ9Po9fdRClVIdn9TAcHIpq2a9dEeg67/bsE50 mfHLs8lQZb9UVWpYBtSrsYgoMfgHX2mlBkoGM39bvjUBm8b1YkclvZcs451O2ACHv6YG Wffw==
X-Gm-Message-State: AIVw110O3Ooni0YKknpdywJiokmodaeCcaayXTSKhlZj+SrmPu4dcVkF 695XTFqgakR+Tb38+UOQaRY6os28YQLO
X-Received: by 10.84.231.16 with SMTP id f16mr29363814plk.131.1500280275769; Mon, 17 Jul 2017 01:31:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 01:30:35 -0700 (PDT)
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
From: Ted Lemon 
Date: Mon, 17 Jul 2017 10:30:35 +0200
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Jim Martin ,  Russ Housley , Suresh Krishnan ,  Alissa Cooper , Randy Bush 
Content-Type: multipart/alternative; boundary="f40304360182e6b82405547f3882"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:31:21 -0000

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

Have you ever actually used the ietf-nat64 network?   What problems did you
have?   I ask because I use it at every IETF, and I never have any
problems.   So the degree of fear that you are exhibiting about having it
be the default is really surprising to me.   This is really not a big deal,
except in the sense that it's a big deal that the IETF still isn't
dogfooding at meetings twenty years later.

On Mon, Jul 17, 2017 at 10:17 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> However, we have different ways for doing the same, and we should go for
> the one that has less impact and it is more realistic.
>
> In the real world, you will not disable IPv4 in the LANs of end-users or
> enterprise customers (at least not now, may be in 3-5 years from now). Th=
is
> is what IETF need to test now. IPv6 only with IPv4 as a service (which is
> 464XLAT).
>
> Again, and I=E2=80=99m for-IPv6, but being realistic, not considering sci=
-fi of
> turning down IPv4 in our customer networks (now).
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: v6ops  en nombre de "Brzozowski, John" <
> John_Brzozowski@comcast.com>
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 10:14
> Para: Noah , Ted Lemon 
> CC: Jim Martin , IPv6 Ops WG , Alissa
> Cooper , Russ Housley , Randy
> Bush , Suresh Krishnan 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
>
>     Agree with Noah and Ted.
>
>     Note the I-D explicitly documents that a fallback, dual stack SSID
> must remain available as Noah mentions below.
>
>     I fail to see how doing this will harm or discriminate.
>
>     We do need to eat our own dogfood, otherwise we are hypocrites.
>
>     John
>
>     +1-484-962-0060
>
>     From:
>     v6ops  on behalf of Noah 
>     Date: Monday, July 17, 2017 at 09:01
>     To: Ted Lemon 
>     Cc: Randy Bush , v6ops , Alissa Cooper
> , Russ Housley , Jim Martin <
> jim@daedelus.com>, Suresh Krishnan 
>     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for
> IETF Meetings
>
>
>
>     FWIW and to cater for all, would a fallback dual stack SSID work for
> the status quo while this 2nd v6 SSID is also experimented upon which is =
a
> great idea considering this is IETF.
>
>
>
>     Noah
>
>
>
>     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>
>     I don't think this is a social justice issue.   Does the IETF think
> that IPv6 works, or not?   If we think it works, and we have been working
> for what, 20 years, to make it work, and we have designed all this great
>      transition tech, then why on earth would we not want to use it?
>  This isn't "one draft."   This is roughly half the work of the IETF for
> the past two decades.
>
>
>     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <
> jordi.palet@consulintel.es> wrote:
>
>     So we agree to change the rules so that we use this network for every
> ID that want to experiment with it? Otherwise we discriminate among
> different authors =E2=80=A6
>
>     I think is a really bad precedent.
>
>     Regards,
>     Jordi
>
>
>     -----Mensaje original-----
>     De: Ted Lemon 
>     Responder a: 
>     Fecha: lunes, 17 de julio de 2017, 8:48
>     Para: JORDI PALET MARTINEZ 
>     CC: IPv6 Ops WG , Jim Martin ,
> Randy Bush , Suresh
>      Krishnan , Russ Housley <
> housley@vigilsec.com>, Alissa Cooper 
>     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F
> Meetings
>
>         I don't actually know what the goal of the IETF network is other
> than to provide connectivity.   Because of the vicissitudes of hotel
> topology, it is often the case that IETF participants experience issues
> with the
>      network at least once or twice per IETF despite the best efforts (an=
d
> they are quite exceptional) of the NOC team.   I do not really see what t=
he
> damage is that you are hoping to protect against here.   Users who don't
> read the NOC announcement?   No sympathy.
>       Sorry.
>
>
>
>
>
>     **********************************************
>     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 confidential. 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 disclosure, copying, distribution or
>      use of the contents of this information, including attached files, i=
s
> prohibited.
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> **********************************************
> 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
> confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Have you ever actually used the ietf-nat64 network? =C2=A0=
 What problems did you have? =C2=A0 I ask because I use it at every IETF, a=
nd I never have any problems. =C2=A0 So the degree of fear that you are exh=
ibiting about having it be the default is really surprising to me. =C2=A0 T=
his is really not a big deal, except in the sense that it's a big deal =
that the IETF still isn't dogfooding at meetings twenty years later.

On Mon, Jul 17=
, 2017 at 10:17 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel=
.es> wrote:
However, we hav=
e different ways for doing the same, and we should go for the one that has =
less impact and it is more realistic.



In the real world, you will not disable IPv4 in the LANs of end-users or en=
terprise customers (at least not now, may be in 3-5 years from now). This i=
s what IETF need to test now. IPv6 only with IPv4 as a service (which is 46=
4XLAT).



Again, and I=E2=80=99m for-IPv6, but being realistic, not considering sci-f=
i of turning down IPv4 in our customer networks (now).



Regards,

Jordi





-----Mensaje original-----

De: v6ops <v6=
ops-bounces@ietf.org> en nombre de "Brzozowski, John" <=
John_Brzozowski@comcast.com<=
/a>>

Responder a: <John_Brzozo=
wski@comcast.com>

Fecha: lunes, 17 de julio de 2017, 10:14

Para: Noah <noah@neo.co.tz>, Te=
d Lemon <mellon@fugue.com>
CC: Jim Martin <jim@daedelus.com=
>, IPv6 Ops WG <v6ops@ietf.org&=
gt;, Alissa Cooper <alissa@cooperw.=
in>, Russ Housley <housle=
y@vigilsec.com>, Randy Bush <ran=
dy@psg.com>, Suresh Krishnan <suresh.krishnan@gmail.com>


Asunto: Re: [v6ops] Incremental Dep=
loyment of IPv6-only Wi-Fi for IETF Meetings



=C2=A0 =C2=A0 Agree with Noah and Ted.



=C2=A0 =C2=A0 Note the I-D explicitly documents that a fallback, dual stack=
 SSID must remain available as Noah mentions below.



=C2=A0 =C2=A0 I fail to see how doing this will harm or discriminate.



=C2=A0 =C2=A0 We do need to eat our own dogfood, otherwise we are hypocrite=
s.



=C2=A0 =C2=A0 John



=C2=A0 =C2=A0 +1-4=
84-962-0060



=C2=A0 =C2=A0 From:

=C2=A0 =C2=A0 v6ops <v6ops-bou=
nces@ietf.org> on behalf of Noah <noah@neo.co.tz>

=C2=A0 =C2=A0 Date: Monday, July 17, 2017 at 09:01

=C2=A0 =C2=A0 To: Ted Lemon <mellon@=
fugue.com>

=C2=A0 =C2=A0 Cc: Randy Bush <randy@psg=
.com>, v6ops <v6ops@ietf.org>, Alissa Cooper <alissa@cooper=
w.in>, Russ Housley <hous=
ley@vigilsec.com>, Jim Martin <jim@daedelus.com>, Suresh Krishnan <suresh.krishnan@gmail.com>

=C2=A0 =C2=A0 Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-F=
i for IETF Meetings







=C2=A0 =C2=A0 FWIW and to cater for all, would a fallback dual stack SSID w=
ork for the status quo while this 2nd v6 SSID is also experimented upon whi=
ch is a great idea considering this is IETF.







=C2=A0 =C2=A0 Noah







=C2=A0 =C2=A0 On 17 Jul 2017 9:54 a.m., "Ted Lemon" <mellon@fugue.com> wrote:



=C2=A0 =C2=A0 I don't think this is a social justice issue.=C2=A0 =C2=
=A0Does the IETF think that IPv6 works, or not?=C2=A0 =C2=A0If we think it =
works, and we have been working for what, 20 years, to make it work, and we=
 have designed all this great

=C2=A0 =C2=A0 =C2=A0transition tech, then why on earth would we not want to=
 use it?=C2=A0 =C2=A0This isn't "one draft."=C2=A0 =C2=A0This=
 is roughly half the work of the IETF for the past two decades.





=C2=A0 =C2=A0 On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es&g=
t; wrote:



=C2=A0 =C2=A0 So we agree to change the rules so that we use this network f=
or every ID that want to experiment with it? Otherwise we discriminate amon=
g different authors =E2=80=A6



=C2=A0 =C2=A0 I think is a really bad precedent.



=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Jordi





=C2=A0 =C2=A0 -----Mensaje original-----

=C2=A0 =C2=A0 De: Ted Lemon <mellon@=
fugue.com>

=C2=A0 =C2=A0 Responder a: <mellon@f=
ugue.com>

=C2=A0 =C2=A0 Fecha: lunes, 17 de julio de 2017, 8:48

=C2=A0 =C2=A0 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

=C2=A0 =C2=A0 CC: IPv6 Ops WG <v6ops@i=
etf.org>, Jim Martin <jim@dae=
delus.com>, Randy Bush <randy@ps=
g.com>, Suresh

=C2=A0 =C2=A0 =C2=A0Krishnan <suresh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>

=C2=A0 =C2=A0 Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi=
 for IETF Meetings



=C2=A0 =C2=A0 =C2=A0 =C2=A0 I don't actually know what the goal of the =
IETF network is other than to provide connectivity.=C2=A0 =C2=A0Because of =
the vicissitudes of hotel topology, it is often the case that IETF particip=
ants experience issues with the

=C2=A0 =C2=A0 =C2=A0network at least once or twice per IETF despite the bes=
t efforts (and they are quite exceptional) of the NOC team.=C2=A0 =C2=A0I d=
o not really see what the damage is that you are hoping to protect against =
here.=C2=A0 =C2=A0Users who don't read the NOC announcement?=C2=A0 =C2=
=A0No sympathy.

=C2=A0 =C2=A0 =C2=A0 Sorry.











=C2=A0 =C2=A0 **********************************************

=C2=A0 =C2=A0 IPv4 is over

=C2=A0 =C2=A0 Are you ready for the new Internet ?

=C2=A0 =C2=A0 http://www.consulintel.es

=C2=A0 =C2=A0 The IPv6 Company



=C2=A0 =C2=A0 This electronic message contains information which may be pri=
vileged or confidential. The information is intended to be for the use of t=
he individual(s) named above. If you are not the intended recipient be awar=
e that any disclosure, copying, distribution or

=C2=A0 =C2=A0 =C2=A0use of the contents of this information, including atta=
ched files, is prohibited.







=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 v6ops mailing list

=C2=A0 =C2=A0 v6ops@ietf.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/v6ops

















=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 v6ops mailing list

=C2=A0 =C2=A0 v6ops@ietf.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/v6ops















=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 v6ops mailing list

=C2=A0 =C2=A0 v6ops@ietf.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/v6ops









**********************************************

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.







_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--f40304360182e6b82405547f3882--


From nobody Mon Jul 17 01:32:58 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FBC131771 for ; Mon, 17 Jul 2017 01:32: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 FKkXMCDsUwdT for ; Mon, 17 Jul 2017 01:32:55 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C63131798 for ; Mon, 17 Jul 2017 01:32:55 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id q86so73072284pfl.3 for ; Mon, 17 Jul 2017 01:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w7CIgr8EMWO1kEQFZxb9Z71s9iAXA0vrmbDlz7MTrhM=; b=0n/9EOQfYLdRHV4Kyz2GMz9fmYvvk7A64pLx8FXxYPrUewFnrAkTM4r5aEMHEhe9GO ROApcXyZFmFeQ5trBHelD8yMS8FwGd8ErqMXXCzJK42X9s+RaFFfnA9VmrEfEPmWnYDN XciLHRxVguVVgCPYZIIRcgM2eEmGf4jDiZLe8UDnhwmrg0sZRKlgcWoQYFTxN41G8wCf DqTerjeO4TdQ4e9Ll9ASaSIRz1ew9EuitE7JP8clmH8ZJwEhVv9mYJ1MPZKeFfHmAf5s +ch4ZFa+8tJVaqEbIgOLfDmgUcD/F7mipdzWUYnJElkXO+p0Ep7OxFG/EXrYuQ6AOqwH 3BeA==
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=w7CIgr8EMWO1kEQFZxb9Z71s9iAXA0vrmbDlz7MTrhM=; b=JLoHjCa0F/+M0K0YMP/3KXNSVdodxoObAbHnhUXynUmErmVkeK6qZOL2l2PtamZNKW 7hIpD/eJvkNxR7wveUisn6SAyTesNmtbvEywjal9G/H06boYhKCCMuMbagZaQxPLbiwn rxSMuP97A5PdVa4PIYjtUzzwptlv6K+edna4TJkCvd5Wq2ztMhcr99qrUFgonsIm5Ldt hWzR/5LWdRWnnUmoSQKMvwSe55QK+nGL1nz0duIgXEDh6CC7pIX7OATieFgnAz6u3IF3 Y3j3gk/VU0zQaq/5jDM/wDnWJia1N4zxx/HUhHgt6Wxv9XpP2iid5XnqYhK21YB7Aiv7 ZlCg==
X-Gm-Message-State: AIVw112UYFDqm34PsnaVTlUSLHHD3uaQZbckxTMpHwEADbojyzAJ8zOm oU8LICIUF1o8ghcL5igkj0XyqODWvqNY
X-Received: by 10.84.211.2 with SMTP id b2mr2655056pli.294.1500280375041; Mon, 17 Jul 2017 01:32:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 01:32:14 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> 
From: Ted Lemon 
Date: Mon, 17 Jul 2017 10:32:14 +0200
Message-ID: 
To: Jen Linkova 
Cc: Jordi Palet Martinez , Randy Bush ,  "v6ops@ietf.org" , Russ Housley , Alissa Cooper ,  Jim Martin , Suresh Krishnan 
Content-Type: multipart/alternative; boundary="94eb2c0932b4d176f805547f3e13"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:32:57 -0000

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

On Mon, Jul 17, 2017 at 10:30 AM, Jen Linkova  wrote:

> Actually if the fallback dual-stack network requires an explicit
> configuration on the client side (as the draft recommends) to avoid
> users connecting to it accidentally, the number of clients falling
> back to the dual stack SSID is very good data point to demonstrate
> what % of users are experiencing issues.


Yes!

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


On M=
on, Jul 17, 2017 at 10:30 AM, Jen Linkova <furry13@gmail.com> wrote:
Actually if the fallback dual-st=
ack network requires an explicit

configuration on the client side (as the draft recommends) to avoid

users connecting to it accidentally, the number of clients falling

back to the dual stack SSID is very good data point to demonstrate

what % of users are experiencing issues.

Ye=
s!=C2=A0


--94eb2c0932b4d176f805547f3e13--


From nobody Mon Jul 17 01:34:15 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA432131AFC for ; Mon, 17 Jul 2017 01:34: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, 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 E4rVJLootlK5 for ; Mon, 17 Jul 2017 01:34:07 -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 7773B131B01 for ; Mon, 17 Jul 2017 01:33:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500280423; x=1500885223; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=w8iK4sygNwX31nUer/2YY9P5u YiOtRgyCczJzzKX+h0=; b=QBrhQJyvfniTbArFRkSJQi7AxB7f5IPu2zKjBMP8D Viygbk5c9JgMFMGoUUjcXYPyDE3IQ+TCKjmmik0zcKdNLONe03GbWQ66b6ZPhXUG WVsGUsPZ4GEIcTk4ALABoVF0+GLs//3kFczc42EmnAnCKpXr7So7ecbGSvHrZqPq kY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=bKYwfwctlJk0QGokpiAY/oWzFb/wKWFkNLLGjG6ppRZ/lz8ya4Oj8cOKXqtp lbZNAbZRNCKhQnYeTc4KKM7wRmMpdVQ2+Sw7W2OOQQ1SWWyM3QBITt5el V/y4usNOCtndOr2ZYlXpd0CInL0BN7xRFkeOmzJSRSvcgxiMAXec/8=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:33:43 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:33:41 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478191.msg for ; Mon, 17 Jul 2017 10:33:38 +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:170717:md50005478191::Zgl1/UY0O8onOR8R:00003Mkh
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:33:35 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <2967DA6E-D74C-4356-8193-74A6D1EA771E@gmail.com>
In-Reply-To: <2967DA6E-D74C-4356-8193-74A6D1EA771E@gmail.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:34:10 -0000

May be, but it means that customers with use old apps with literals, go and=
 complain to their operators, and probably switch to another operator. I do=
n=E2=80=99t think this is a good advice to operators or enterprise network =
admins to deploy IPv6-only in their LANs.

I fully agree about IPv6-only in the WAN and IPv4 as a service in the LANs.

Regards,
Jordi
=20

-----Mensaje original-----
De: Fred Baker 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:22
Para: JORDI PALET MARTINEZ 
CC: IPv6 Ops WG , Jim Martin , Russ Housl=
ey , Suresh Krishnan , Ali=
ssa Cooper , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

   =20
   =20
    > On Jul 17, 2017, at 10:17 AM, JORDI PALET MARTINEZ  wrote:
    >=20
    > In the real world, you will not disable IPv4 in the LANs of end-users=
 or enterprise customers (at least not now, may be in 3-5 years from now). =
This is what IETF need to test now. IPv6 only with IPv4 as a service (which=
 is 464XLAT).
   =20
    In the real world, there are networks that are doing this now.=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 Mon Jul 17 01:34:51 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E870131771 for ; Mon, 17 Jul 2017 01:34:50 -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, 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 og3_ZI56A8Kt for ; Mon, 17 Jul 2017 01:34:49 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB43131AD7 for ; Mon, 17 Jul 2017 01:34:37 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id z62so6957884ioi.0 for ; Mon, 17 Jul 2017 01:34:37 -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=+GRlVSNkyGaPhwlpgNtziIyZlQ0jP2YDYJAT4bFtmEc=; b=EYD5lRRYvhrNLxvJl0J9mFETX55t3LreEYWrc9ZbzQLK/qDyo0K7OMdWR5v/JK26nI nCZYnz5DdRNNuA9Amss158Is6mHE+TH2cuNHC21+BkYNJx3E/dnjrPeeH1vqfW4nPLmC /fvDepwfTTRzsvvxhgdE1tpsCkhMxAP0OM/LUqxN/RT4jqq40STRWl3j++uApSqn2vAL B/H7rzr07y9i22zFTulQ+cwiaeICFOmNZdVg/fDtu3Y0TA6ZWEYmcI4ufx50T+Clol1R h4tXw8x2u3IYE0MIgArOfjIOQm9AOcZ5kX//6d5cc6bh/yDumgh+6FyD5D9xaxBzK0Rv b8Cw==
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=+GRlVSNkyGaPhwlpgNtziIyZlQ0jP2YDYJAT4bFtmEc=; b=Y+QkcOZXuKL5SyhueeWAOOgKvfMu2IggbCXI4lX9DiBDGm1tFmaUUJYUhXg4NikQhF TMbgsm4UK3gEsdVnsDMcPB6QPT64Z0LCNPNwLpjtISte20xGZfeiy6TUWXZeH8raE7IO VSyw1Shf5ClwC/pVEpD7ICuRnBbmHhGMNJnYO2JvirG10TiaLNQiJAmX6IVNX5shfbJF Cs9UVejKSVq72rHUs08Vhx6dhe5015DYakx68gyMjj7aaDU0SaIWRJw/NlCeZ9vwTcgU 2uSokfyQ3jGHPiNKHzEjfK2alj1jyAtNsWy0jrfShxL86NNzB7EvZvwWRwxWuDgab2Q5 iGJw==
X-Gm-Message-State: AIVw113DEU05CAlN+TK6JCMqkT/9akCr8oHHpdhJUNCbzUKNDVXhTkk4 z8Zbt7lMYrnpRO6BVlS2qu5Z1wWW1w==
X-Received: by 10.107.174.26 with SMTP id x26mr6988349ioe.24.1500280476865; Mon, 17 Jul 2017 01:34:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 01:34:15 -0700 (PDT)
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
From: Jen Linkova 
Date: Mon, 17 Jul 2017 18:34:15 +1000
Message-ID: 
To: Jordi Palet Martinez 
Cc: IPv6 Ops WG , Jim Martin ,  Russ Housley , Suresh Krishnan ,  Alissa Cooper , Randy Bush 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:34:51 -0000

On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
 wrote:
> In the real world, you will not disable IPv4 in the LANs of end-users or =
enterprise customers (at least not now, may be in 3-5 years from now).

I disagree with this statement. There are networks doing this. Right
here right now.

> -----Mensaje original-----
> De: v6ops  en nombre de "Brzozowski, John" 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 10:14
> Para: Noah , Ted Lemon 
> CC: Jim Martin , IPv6 Ops WG , Alissa C=
ooper , Russ Housley , Randy Bush =
, Suresh Krishnan 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Me=
etings
>
>     Agree with Noah and Ted.
>
>     Note the I-D explicitly documents that a fallback, dual stack SSID mu=
st remain available as Noah mentions below.
>
>     I fail to see how doing this will harm or discriminate.
>
>     We do need to eat our own dogfood, otherwise we are hypocrites.
>
>     John
>
>     +1-484-962-0060
>
>     From:
>     v6ops  on behalf of Noah 
>     Date: Monday, July 17, 2017 at 09:01
>     To: Ted Lemon 
>     Cc: Randy Bush , v6ops , Alissa Cooper=
 , Russ Housley , Jim Martin , Suresh Krishnan 
>     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IE=
TF Meetings
>
>
>
>     FWIW and to cater for all, would a fallback dual stack SSID work for =
the status quo while this 2nd v6 SSID is also experimented upon which is a =
great idea considering this is IETF.
>
>
>
>     Noah
>
>
>
>     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>
>     I don't think this is a social justice issue.   Does the IETF think t=
hat IPv6 works, or not?   If we think it works, and we have been working fo=
r what, 20 years, to make it work, and we have designed all this great
>      transition tech, then why on earth would we not want to use it?   Th=
is isn't "one draft."   This is roughly half the work of the IETF for the p=
ast two decades.
>
>
>     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
>
>     So we agree to change the rules so that we use this network for every=
 ID that want to experiment with it? Otherwise we discriminate among differ=
ent authors =E2=80=A6
>
>     I think is a really bad precedent.
>
>     Regards,
>     Jordi
>
>
>     -----Mensaje original-----
>     De: Ted Lemon 
>     Responder a: 
>     Fecha: lunes, 17 de julio de 2017, 8:48
>     Para: JORDI PALET MARTINEZ 
>     CC: IPv6 Ops WG , Jim Martin , Rand=
y Bush , Suresh
>      Krishnan , Russ Housley , Alissa Cooper 
>     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
>
>         I don't actually know what the goal of the IETF network is other =
than to provide connectivity.   Because of the vicissitudes of hotel topolo=
gy, it is often the case that IETF participants experience issues with the
>      network at least once or twice per IETF despite the best efforts (an=
d they are quite exceptional) of the NOC team.   I do not really see what t=
he damage is that you are hoping to protect against here.   Users who don't=
 read the NOC announcement?   No sympathy.
>       Sorry.
>
>
>
>
>
>     **********************************************
>     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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or
>      use of the contents of this information, including attached files, i=
s prohibited.
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> **********************************************
> 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 c=
onfidential. The information is intended to be for the use of the individua=
l(s) named above. If you are not the intended recipient be aware that any d=
isclosure, copying, distribution or use of the contents of this information=
, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--=20
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 01:35:25 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A250131AFC for ; Mon, 17 Jul 2017 01: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, 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 090kdoMlwpWm for ; Mon, 17 Jul 2017 01:35:21 -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 8D3DB13179D for ; Mon, 17 Jul 2017 01:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500280518; x=1500885318; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=dMeLF7kaccQlR5b1O9V6RLtve DGidCXYhJWVkgG7spI=; b=b7R6dBkGMHaRibsENmNGIHBjk1tDr7fP9eLOZ+/Un /4dPnyopk1j9qYZji2w/6nPkQfEK8e0LLInsfSmxhyKoL4Hw7TqEF7rjxZVFaSjf Y21fbFKTMYLZrXOk6lmdBhPWvHNpMN0xftbWlu4m4wBiKrKHlP+l0h7KtTm2Adlu p8=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Rw/PGrDOAYra/uXX6gyBBsH4jChNoV0LbcYsfalak9vLZAhfF02ey/hj5Tjt jP26p/JtP0oWVVJlWZbb4un8WbcGW+dhKGAepSuIMv4DaLez36KSLa7a7 AcnbBeYSkejFVNAgNtpSR7lH1j4bPKIBUN2Qt42UB0TnQZbhBqNItc=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:35:18 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:35:16 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478195.msg for ; Mon, 17 Jul 2017 10:35:15 +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:170717:md50005478195::hQRxyuNVGioQu93c:000007fK
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:35:12 +0200
From: JORDI PALET MARTINEZ 
To: "v6ops@ietf.org" 
CC: Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Message-ID: <5C41328B-0B14-4605-813C-4BEADF6F53A7@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:35:23 -0000

We may need to clarify the goal here:

Is just to experiment this ? Then it has been widely done, no doubt.

Or it is to measure what apps fail? Then CLAT is a better way, as you can m=
easure/log it automatically.
=20
Regards,
Jordi
=20

-----Mensaje original-----
De: Jen Linkova 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:30
Para: Jordi Palet Martinez 
CC: "v6ops@ietf.org" , Jim Martin , Russ =
Housley , Suresh Krishnan =
, Alissa Cooper , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Mon, Jul 17, 2017 at 3:24 PM, JORDI PALET MARTINEZ
     wrote:
    > In my opinion such kind of experiment should be only done once we app=
rove the document as RFC, note before, so by the next IETF meeting (hopeful=
ly).
   =20
    I'm not sure I understand the logic here.
    The I-D is documenting the operational experience and actually I
    believe it would make more sense to run the experiment *before*
    finalizing the text/publish it as RFC to avoid the situation when  we
    publish an RFC on smth we have not even done yet.
   =20
    > We like it or not, this is not a valid option, unless we make sure th=
at if some participants have troubles, the alternative SSIDs have other 2.4=
 and 5 GHz radios available. Is that the case?
   =20
    I believe the draft clearly states the the fallback option needs to be
    available.
   =20
    > The way you=E2=80=99re proposing, will mean that many folks may switc=
h to alternative SSID, or simply don't report those failures, so at the end=
 you don=E2=80=99t have any results of how much is not working, etc.
   =20
    Actually if the fallback dual-stack network requires an explicit
    configuration on the client side (as the draft recommends) to avoid
    users connecting to it accidentally, the number of clients falling
    back to the dual stack SSID is very good data point to demonstrate
    what % of users are experiencing issues.
   =20
    > De: v6ops  en nombre de "Brzozowski, John" 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 6:23
    > Para: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" 
    > CC: Jim Martin , Alissa Cooper ,=
 Russ Housley , Randy Bush , Suresh Kr=
ishnan 
    > Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Me=
etings
    >
    >     Folks,
    >
    >     Apologies in advance for the gratuitous cross posting (v6ops, iet=
f, ipv6, sunset4, softwires).  I hope, to you all, this is worth the added =
email.
    >
    >     The draft below was written to provide the necessary documentatio=
n to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 on=
ly primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 t=
o access IPv4 only content.  The request for IETF 99 has been to have the p=
rimary =E2=80=9Cietf=E2=80=9D SSID adhere to what is documented in the I-D =
below.  I trust the motivation is understood.  This means that the main =E2=
=80=9Cietf=E2=80=9D SSID would be switched to be IPv6 only with NAT64+DNS64=
 (at layer 3) per the I-D below.  Given the that IETF99 is upon us, this ma=
y or may not be entirely possible.
    >
    >     At this stage, the infrastructure preparations for IETF 99 should=
 be in place to ensure that the IETF has the necessary hardware for redunda=
ncy and performance.
    >
    >     So, we are all seeking your input.  Given the above, what would a=
ll you suggest is tolerable for IETF99 as it pertains to the I-D below?
    >
    >     =E2=80=A2 IPv6 only per the I-D for the balance of IETF week?
    >     =E2=80=A2 IPv6 only per the I-D for one or more days this week?
    >     =E2=80=A2 IPv6 only per the I-D for the plenary?
    >     =E2=80=A2 IPv6 only per the I-D for the next IETF meeting?
    >
    >     Please send us your feedback.
    >
    >     Regards,
    >
    >     John
    >     +1-484-962-0060
    >
    >     -----Original Message-----
    >     From: "internet-drafts@ietf.org" 
    >     Date: Saturday, July 1, 2017 at 03:04
    >     To: Marcus Keane , Jen Linkova , Lorenzo Colitti , John Brzozowski , Erik Kline , John Brzozowski <=
John_Brzozowski@Cable.Comcast.com>, David Schinazi , S=
tuart Cheshire , Jen Linkova , Paul S=
aab , David Schinazi 
    >     Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-=
only-incremental-00.txt
    >
    >
    >         A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-increme=
ntal-00.txt
    >         has been successfully submitted by John Jason Brzozowski and =
posted to the
    >         IETF repository.
    >
    >         Name:           draft-jjmb-v6ops-ietf-ipv6-only-incremental
    >         Revision:       00
    >         Title:          Incremental Deployment of IPv6-only Wi-Fi for=
 IETF Meetings
    >         Document date:  2017-06-30
    >         Group:          Individual Submission
    >         Pages:          15
    >         URL:            https://www.ietf.org/internet-drafts/draft-jj=
mb-v6ops-ietf-ipv6-only-incremental-00.txt
    >         Status:         https://datatracker.ietf.org/doc/draft-jjmb-v=
6ops-ietf-ipv6-only-incremental/
    >         Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-=
ietf-ipv6-only-incremental-00
    >         Htmlized:       https://datatracker.ietf.org/doc/html/draft-j=
jmb-v6ops-ietf-ipv6-only-incremental-00
    >
    >
    >         Abstract:
    >            The purpose of this document is to provide a blueprint and=
 guidance
    >            for deploying IPv6-only Wi-Fi at IETF meetings.  This docu=
ment
    >            outlines infrastructure and operational guidance that oper=
ators
    >            should consider when deploying IPv6-only networks using NA=
T64 and
    >            DNS64 to support communication to legacy IPv4-only service=
s.
    >
    >
    >
    >
    >         Please note that it may take a couple of minutes from the tim=
e of submission
    >         until the htmlized version and diff are available at tools.ie=
tf.org.
    >
    >         The IETF Secretariat
    >
    >
    >
    >
    >     _______________________________________________
    >     v6ops mailing list
    >     v6ops@ietf.org
    >     https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >
    > **********************************************
    > 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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --=20
    SY, Jen Linkova aka Furry
   =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 Mon Jul 17 01:36:38 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC5913179D for ; Mon, 17 Jul 2017 01:36:37 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 TeyGXKtRGXbf for ; Mon, 17 Jul 2017 01:36:34 -0700 (PDT)
Received: from relay.vweb.co.za (relay.vweb.co.za [IPv6:2001:43f8:790:61::200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DB0131771 for ; Mon, 17 Jul 2017 01:36:33 -0700 (PDT)
Received: from [165.255.159.95] (port=52526 helo=mjelap.posix.co.za) by relay.vweb.co.za with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1dX1W1-0002T9-30 for v6ops@ietf.org; Mon, 17 Jul 2017 10:36:29 +0200
Reply-To: mje@posix.co.za
To: v6ops@ietf.org
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
From: Mark Elkins 
Organization: Posix Systems
Message-ID: 
Date: Mon, 17 Jul 2017 10:35:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:36:37 -0000

For what its worth, we've had successful IPv6 only days in past AfriNIC
meetings (using NAT64+DNS64). I also personally ran IPv6 only at a
SAFNOG (Southern African NOG) in Swaziland with no ill effects (I broke
dhcp on my Laptop and just had to once configured the IPv6 Nameservers
by hand).

I'm personally advocating having future "IPv6 only" AfriNIC meetings
though this may end up being just for a single day.


On 17/07/2017 10:17, JORDI PALET MARTINEZ wrote:
> However, we have different ways for doing the same, and we should go for the one that has less impact and it is more realistic.
>
> In the real world, you will not disable IPv4 in the LANs of end-users or enterprise customers (at least not now, may be in 3-5 years from now). This is what IETF need to test now. IPv6 only with IPv4 as a service (which is 464XLAT).
>
> Again, and I’m for-IPv6, but being realistic, not considering sci-fi of turning down IPv4 in our customer networks (now).
>
> Regards,
> Jordi
>  
>
> -----Mensaje original-----
> De: v6ops  en nombre de "Brzozowski, John" 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 10:14
> Para: Noah , Ted Lemon 
> CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>
>     Agree with Noah and Ted.
>      
>     Note the I-D explicitly documents that a fallback, dual stack SSID must remain available as Noah mentions below.
>      
>     I fail to see how doing this will harm or discriminate.
>      
>     We do need to eat our own dogfood, otherwise we are hypocrites.
>      
>     John
>     
>     +1-484-962-0060
>      
>     From:
>     v6ops  on behalf of Noah 
>     Date: Monday, July 17, 2017 at 09:01
>     To: Ted Lemon 
>     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley , Jim Martin , Suresh Krishnan 
>     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>     
>      
>     
>     FWIW and to cater for all, would a fallback dual stack SSID work for the status quo while this 2nd v6 SSID is also experimented upon which is a great idea considering this is IETF.
>     
>      
>     
>     Noah
>     
>     
>      
>     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>     
>     I don't think this is a social justice issue.   Does the IETF think that IPv6 works, or not?   If we think it works, and we have been working for what, 20 years, to make it work, and we have designed all this great
>      transition tech, then why on earth would we not want to use it?   This isn't "one draft."   This is roughly half the work of the IETF for the past two decades.
>     
>      
>     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
>     
>     So we agree to change the rules so that we use this network for every ID that want to experiment with it? Otherwise we discriminate among different authors …
>     
>     I think is a really bad precedent.
>     
>     Regards,
>     Jordi
>     
>     
>     -----Mensaje original-----
>     De: Ted Lemon 
>     Responder a: 
>     Fecha: lunes, 17 de julio de 2017, 8:48
>     Para: JORDI PALET MARTINEZ 
>     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
>      Krishnan , Russ Housley , Alissa Cooper 
>     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>     
>         I don't actually know what the goal of the IETF network is other than to provide connectivity.   Because of the vicissitudes of hotel topology, it is often the case that IETF participants experience issues with the
>      network at least once or twice per IETF despite the best efforts (and they are quite exceptional) of the NOC team.   I do not really see what the damage is that you are hoping to protect against here.   Users who don't read the NOC announcement?   No sympathy. 
>       Sorry.
>     
>     
>     
>     
>     
>     **********************************************
>     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 confidential. 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 disclosure, copying, distribution or
>      use of the contents of this information, including attached files, is prohibited.
>     
>     
>     
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>     
>     
>     
>     
>     
>      
>     
>     
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>     
>     
>     
>     
>     
>     
>     
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>     
>
>
>
> **********************************************
> 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 confidential. 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 disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje@posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za


From nobody Mon Jul 17 01:37:27 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6D5131AA6 for ; Mon, 17 Jul 2017 01:37:24 -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 I4GmvfPicLI2 for ; Mon, 17 Jul 2017 01:37:22 -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 E2173131A8C for ; Mon, 17 Jul 2017 01:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500280638; x=1500885438; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=RKM+mHndjZX4NJUbEk7XsNy/W bfVjXFMWz+ZkU8beS4=; b=a+vVZhNZNL/T0yFGSwv5I2/zYrWNRPYIXeJzz5+qE lSAjLMtt4MvLRb4xYuNF6esvUbJN2sXEkU1GrqH/NFHJdockLhdIMcoLfwhWHS7z bfvfe36o9Z8MauWyClFCaBtt5T1RmzD5AIQM1SgJCmkaMEgibvZYx6Ou4bhPj2ZT io=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=fF4nUS12rL+lhp2nkggd49OQrmIsban0WCQXBSKelz6dTf9RE4iz0w26Dlo0 2PMlLp5iPuCOfyR46Cbz1WFoFE9M7b8F82Lm5faBmwcBwvTER9jp0RyoN Z1nFZWnclsnMdcJMsiJc2hmv+326fGbDxmE6xY6tWab2PUTYEd0O60=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:37:18 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:37:15 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478200.msg for ; Mon, 17 Jul 2017 10:37:11 +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:170717:md50005478200::L3UkaT1AjYJjKl0F:0000CcTV
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:37:03 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:37:25 -0000

Tell your bank, your university, your library, etc., to try that.

I now that some networks (mainly related to IETF work, vendors, etc.), are =
doing that, but not in a general market.

Regards,
Jordi
=20

-----Mensaje original-----
De: Jen Linkova 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:34
Para: Jordi Palet Martinez 
CC: IPv6 Ops WG , Jim Martin , Russ Housl=
ey , Suresh Krishnan , Ali=
ssa Cooper , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
     wrote:
    > In the real world, you will not disable IPv4 in the LANs of end-users=
 or enterprise customers (at least not now, may be in 3-5 years from now).
   =20
    I disagree with this statement. There are networks doing this. Right
    here right now.
   =20
    > -----Mensaje original-----
    > De: v6ops  en nombre de "Brzozowski, John" 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 10:14
    > Para: Noah , Ted Lemon 
    > CC: Jim Martin , IPv6 Ops WG , Alis=
sa Cooper , Russ Housley , Randy B=
ush , Suresh Krishnan 
    > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
    >
    >     Agree with Noah and Ted.
    >
    >     Note the I-D explicitly documents that a fallback, dual stack SSI=
D must remain available as Noah mentions below.
    >
    >     I fail to see how doing this will harm or discriminate.
    >
    >     We do need to eat our own dogfood, otherwise we are hypocrites.
    >
    >     John
    >
    >     +1-484-962-0060
    >
    >     From:
    >     v6ops  on behalf of Noah 
    >     Date: Monday, July 17, 2017 at 09:01
    >     To: Ted Lemon 
    >     Cc: Randy Bush , v6ops , Alissa Co=
oper , Russ Housley , Jim Martin <=
jim@daedelus.com>, Suresh Krishnan 
    >     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi fo=
r IETF Meetings
    >
    >
    >
    >     FWIW and to cater for all, would a fallback dual stack SSID work =
for the status quo while this 2nd v6 SSID is also experimented upon which i=
s a great idea considering this is IETF.
    >
    >
    >
    >     Noah
    >
    >
    >
    >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
    >
    >     I don't think this is a social justice issue.   Does the IETF thi=
nk that IPv6 works, or not?   If we think it works, and we have been workin=
g for what, 20 years, to make it work, and we have designed all this great
    >      transition tech, then why on earth would we not want to use it? =
  This isn't "one draft."   This is roughly half the work of the IETF for t=
he past two decades.
    >
    >
    >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
    >
    >     So we agree to change the rules so that we use this network for e=
very ID that want to experiment with it? Otherwise we discriminate among di=
fferent authors =E2=80=A6
    >
    >     I think is a really bad precedent.
    >
    >     Regards,
    >     Jordi
    >
    >
    >     -----Mensaje original-----
    >     De: Ted Lemon 
    >     Responder a: 
    >     Fecha: lunes, 17 de julio de 2017, 8:48
    >     Para: JORDI PALET MARTINEZ 
    >     CC: IPv6 Ops WG , Jim Martin , =
Randy Bush , Suresh
    >      Krishnan , Russ Housley , Alissa Cooper 
    >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for=
 IETF Meetings
    >
    >         I don't actually know what the goal of the IETF network is ot=
her than to provide connectivity.   Because of the vicissitudes of hotel to=
pology, it is often the case that IETF participants experience issues with =
the
    >      network at least once or twice per IETF despite the best efforts=
 (and they are quite exceptional) of the NOC team.   I do not really see wh=
at the damage is that you are hoping to protect against here.   Users who d=
on't read the NOC announcement?   No sympathy.
    >       Sorry.
    >
    >
    >
    >
    >
    >     **********************************************
    >     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 privile=
ged or confidential. The information is intended to be for the use of the i=
ndividual(s) named above. If you are not the intended recipient be aware th=
at any disclosure, copying, distribution or
    >      use of the contents of this information, including attached file=
s, is prohibited.
    >
    >
    >
    >     _______________________________________________
    >     v6ops mailing list
    >     v6ops@ietf.org
    >     https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >
    >
    >
    >
    >
    >     _______________________________________________
    >     v6ops mailing list
    >     v6ops@ietf.org
    >     https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >
    >
    >
    >
    >     _______________________________________________
    >     v6ops mailing list
    >     v6ops@ietf.org
    >     https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >
    > **********************************************
    > 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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --=20
    SY, Jen Linkova aka Furry
   =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 Mon Jul 17 01:38:57 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975CB131A8E for ; Mon, 17 Jul 2017 01:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Level: 
X-Spam-Status: No, score=-7.1 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_MSPIKE_H2=-2.8, 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=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plzR6d_y-Bn2 for ; Mon, 17 Jul 2017 01:38:52 -0700 (PDT)
Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.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 1F48A131A8C for ; Mon, 17 Jul 2017 01:38:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500280730; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5zqk1DPI4OQl+dMcii7PX9gs5LMUGtMJGNhVsDM+4a0=; b=o6+evhuWnbjWRpNr/KGTsgrsbHJdP2DthIMiBFg9dN4zxooH8K82B9W/O5KBZOej dX8Q8jbmFhdW15A/XdKtSxNvHXk65FxViMpDiT3smjcwL5GaF92ciLsDqt/E4D4q ATwqyyxPrjADekQElWJgIqEyiXgRzxy4dd8ERB6dsS0NMTZXnQq3O+Um4hmzUYiH RfNMzIsHzoQfVRzr7ncTsd7coebJ0siEeh092cDb6Pt4xMip16lU+wvEbS4UYYfb Nz6CxDNd4SDnoAcpgr1Cec32B47yNID9SP/yiZvkKNdg7KDV3m+RtJ+IryWQ212n 7JGIEmd3BFYTXN1CElDIhw==;
Received: from relay2.euro.apple.com ( [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id DA.61.07437.A977C695; Mon, 17 Jul 2017 09:38:50 +0100 (BST)
X-AuditID: 1148940d-ed6789c000001d0d-c5-596c779a951f
Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id F9.ED.07255.9977C695; Mon, 17 Jul 2017 09:38:50 +0100 (BST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_aNOS3eQ+R/wrsguqQWjYsw)"
Received: from [IPv6:2001:67c:370:1998:6184:6dda:119f:1f89] (nat64-aa.meeting.ietf.org [31.130.238.170]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OT800B8K80N0K40@phonehome3.euro.apple.com>; Mon, 17 Jul 2017 09:38:49 +0100 (IST)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: 
Date: Mon, 17 Jul 2017 10:38:45 +0200
In-reply-to: 
Cc: Jordi Palet Martinez , Randy Bush , IPv6 Ops WG , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
To: Jen Linkova 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> 
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUi6GTOozurPCfS4MVbVovpZ/4yWlza2cZk 8erFTXaLa0eYLf4e/8xs8az1JZPFkQ1nWS1OH9vL7MDhsW5/gMeXJy+ZPLo+Xmby2DnrLrvH kiU/mTymzpzN6LHqzhfWAPYoLpuU1JzMstQifbsEroyLe4+xFHx/wFgx+9Iv9gbGC4cZuxg5 OSQETCS+LLnL3MXIxSEksIhJ4v3Wo0AOB1hi4n9HiPghRol/n9awgTTwCghK/Jh8jwXEZhYI k/g0fzMziC0kcJRJom1LPogtLCAt0XXhLivIHDYBLYkDa4wgWm0kTu/8yQpREiCx5eoBdpAS FgFViaPHmEDCnALBEt+nbGMDWcss0Mkk8XRnM9idIgLKEsvvXYG6s51V4kDXWnaIB2Qlbs2+ BJaQEPjOJvGl4RHjBEahWUhunYXk1llAC5kF1CWmTMmFCGtLPHl3gRXCVpNY+HsRE7L4Aka2 VYziuYmZObqZecZ6qaVF+XqJBQU5qXrJ+bmbGEER6DGFdwfj9YOGhxgFOBiVeHhl2LwjhVgT y4orc4HhxsGsJMLbE5wTKcSbklhZlVqUH19UmpNafIhRmoNFSZzXpFQ+UkggPbEkNTs1tSC1 CCbLxMEp1cDY1FrqFcy+MXpnY8Of/OCQoEklKu49b9LDs7ced1//01BMMGqy8I2LaQZhuz0i 9ZyzdBUMna3P7dqa3aR0bMbSmrUfVrptrZqmX1b9iCWKwYdD3GbCjLuxsRuCpwv5hM+IebB6 ur/RskkB267PWSVT+NtdWbbGOUcrPWvCov1rmCz4BEperlJiKc5INNRiLipOBACgSL7ivAIA AA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42IR9GgN1p1VnhNp8L7AYvqZv4wWl3a2MVm8 enGT3eLaEWaLv8c/M1s8a33JZHFkw1lWi9PH9jI7cHis2x/g8eXJSyaPro+XmTx2zrrL7rFk yU8mj6kzZzN6rLrzhTWAPYrLJiU1J7MstUjfLoEr4+LeYywF3x8wVsy+9Iu9gfHCYcYuRg4O CQETiYn/HbsYuTiEBA4xSvz7tIati5GTg1dAUOLH5HssIDazQJjEp/mbmUFsIYGjTBJtW/JB bGEBaYmuC3dZQeawCWhJHFhjBNFqI3F6509WiJIAiS1XD7CDlLAIqEocPcYEEuYUCJb4PmUb G8haZoFOJomnO5sZQRIiAsoSy+9dYYa4p51V4kDXWnaQhISArMSt2ZeYJzDyz0Jy3iwk580C 2sEsoC4xZUouRFhb4sm7C6wQtprEwt+LmJDFFzCyrWIULUrNSaw00kstLcrXSywoyEnVS87P 3cQIihcnc54djK8OGh5iFOBgVOLhtUvIiRRiTSwrrswFBhQHs5IIb08wUIg3JbGyKrUoP76o NCe1+BCjNAeLkjhvwcOISCGB9MSS1OzU1ILUIpgsEwenVAPjskJ7gQM3bJMNv95p6/h4L+b0 NcMzc34zLDyZUpBt1ielmL/brFJtydt0IZ2wD4eDNAwXKWUs3OtoIjld8Upk9YEoniucofnH b7oZnc3JO8b2f+GdSmmp6jTX38ndzY7L9Up0d5x6MbPAyiZXukm1oM+NOc7VcuaZSMYm96dV p6vrPm05LaDEUpyRaKjFXFScCAAAXBwdkwIAAA==
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:38:55 -0000

--Boundary_(ID_aNOS3eQ+R/wrsguqQWjYsw)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable


> On Jul 17, 2017, at 10:34, Jen Linkova  wrote:
>=20
> On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
> > =
wrote:
>> In the real world, you will not disable IPv4 in the LANs of end-users =
or enterprise customers (at least not now, may be in 3-5 years from =
now).
>=20
> I disagree with this statement. There are networks doing this. Right
> here right now.

A major US carrier is doing this today on iPhone without any CLAT.
It works, and they don't even have a fallback.
What we're proposing here is allowing networking experts to test
the feasibility of IPv6 only. =46rom my experience most issues are
extremely minor and it often only takes small fixes to work. But
you need to be aware of the issue ti go fix it.

Using a CLAT here would not allow us to learn what works or not
because going through NAT64 is not a failure.

Thanks,
David Schinazi


>> -----Mensaje original-----
>> De: v6ops  en nombre de "Brzozowski, John" =

>> Responder a: 
>> Fecha: lunes, 17 de julio de 2017, 10:14
>> Para: Noah , Ted Lemon 
>> CC: Jim Martin , IPv6 Ops WG , =
Alissa Cooper , Russ Housley , =
Randy Bush , Suresh Krishnan 
>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
>>=20
>>    Agree with Noah and Ted.
>>=20
>>    Note the I-D explicitly documents that a fallback, dual stack SSID =
must remain available as Noah mentions below.
>>=20
>>    I fail to see how doing this will harm or discriminate.
>>=20
>>    We do need to eat our own dogfood, otherwise we are hypocrites.
>>=20
>>    John
>>=20
>>    +1-484-962-0060
>>=20
>>    From:
>>    v6ops  on behalf of Noah 
>>    Date: Monday, July 17, 2017 at 09:01
>>    To: Ted Lemon 
>>    Cc: Randy Bush , v6ops , Alissa =
Cooper , Russ Housley , Jim =
Martin , Suresh Krishnan 
>>    Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
>>=20
>>=20
>>=20
>>    FWIW and to cater for all, would a fallback dual stack SSID work =
for the status quo while this 2nd v6 SSID is also experimented upon =
which is a great idea considering this is IETF.
>>=20
>>=20
>>=20
>>    Noah
>>=20
>>=20
>>=20
>>    On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>>=20
>>    I don't think this is a social justice issue.   Does the IETF =
think that IPv6 works, or not?   If we think it works, and we have been =
working for what, 20 years, to make it work, and we have designed all =
this great
>>     transition tech, then why on earth would we not want to use it?   =
This isn't "one draft."   This is roughly half the work of the IETF for =
the past two decades.
>>=20
>>=20
>>    On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ =
 wrote:
>>=20
>>    So we agree to change the rules so that we use this network for =
every ID that want to experiment with it? Otherwise we discriminate =
among different authors =E2=80=A6
>>=20
>>    I think is a really bad precedent.
>>=20
>>    Regards,
>>    Jordi
>>=20
>>=20
>>    -----Mensaje original-----
>>    De: Ted Lemon 
>>    Responder a: 
>>    Fecha: lunes, 17 de julio de 2017, 8:48
>>    Para: JORDI PALET MARTINEZ 
>>    CC: IPv6 Ops WG , Jim Martin , =
Randy Bush , Suresh
>>     Krishnan , Russ Housley =
, Alissa Cooper 
>>    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
>>=20
>>        I don't actually know what the goal of the IETF network is =
other than to provide connectivity.   Because of the vicissitudes of =
hotel topology, it is often the case that IETF participants experience =
issues with the
>>     network at least once or twice per IETF despite the best efforts =
(and they are quite exceptional) of the NOC team.   I do not really see =
what the damage is that you are hoping to protect against here.   Users =
who don't read the NOC announcement?   No sympathy.
>>      Sorry.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    **********************************************
>>    IPv4 is over
>>    Are you ready for the new Internet ?
>>    http://www.consulintel.es
>>    The IPv6 Company
>>=20
>>    This electronic message contains information which may be =
privileged or confidential. 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 disclosure, copying, distribution or
>>     use of the contents of this information, including attached =
files, is prohibited.
>>=20
>>=20
>>=20
>>    _______________________________________________
>>    v6ops mailing list
>>    v6ops@ietf.org
>>    https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>    _______________________________________________
>>    v6ops mailing list
>>    v6ops@ietf.org
>>    https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>    _______________________________________________
>>    v6ops mailing list
>>    v6ops@ietf.org
>>    https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>>=20
>>=20
>>=20
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.consulintel.es
>> The IPv6 Company
>>=20
>> This electronic message contains information which may be privileged =
or confidential. 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 disclosure, copying, distribution or use of the contents =
of this information, including attached files, is prohibited.
>>=20
>>=20
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
>=20
> --=20
> SY, Jen Linkova aka Furry
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org 
> https://www.ietf.org/mailman/listinfo/v6ops =


--Boundary_(ID_aNOS3eQ+R/wrsguqQWjYsw)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable


On Jul 17, 2017, at 10:34, Jen Linkova <furry13@gmail.com> =
wrote:

On Mon, Jul 17, 2017 at 6:17 PM, =
JORDI PALET MARTINEZ
<jordi.palet@consulintel.es> wrote:
In the real world, you will =
not disable IPv4 in the LANs of end-users or enterprise customers (at =
least not now, may be in 3-5 years from now).

I disagree with this statement. There are =
networks doing this. Right
here right now.

A major US =
carrier is doing this today on iPhone without any CLAT.
It =
works, and they don't even have a fallback.
What we're =
proposing here is allowing networking experts to test
the =
feasibility of IPv6 only. =46rom my experience most issues =
are
extremely minor and it often only takes small fixes to =
work. But
you need to be aware of the issue ti go fix =
it.

Using a CLAT here would not =
allow us to learn what works or not
because going through =
NAT64 is not a failure.

Thanks,
David Schinazi


-----Mensaje =
original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de "Brzozowski, =
John" <John_Brzozowski@comcast.com>
Responder =
a: <John_Brzozowski@comcast.com>
Fecha: =
lunes, 17 de julio de 2017, 10:14
Para: Noah <noah@neo.co.tz>, Ted =
Lemon <mellon@fugue.com>
CC: Jim Martin <jim@daedelus.com>, =
IPv6 Ops WG <v6ops@ietf.org>, Alissa Cooper <alissa@cooperw.in>, =
Russ Housley <housley@vigilsec.com>, Randy Bush <randy@psg.com>, Suresh =
Krishnan <suresh.krishnan@gmail.com>
Asunto: Re: =
[v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

   Agree with Noah and Ted.

   Note the I-D explicitly =
documents that a fallback, dual stack SSID must remain available as Noah =
mentions below.

   I fail to =
see how doing this will harm or discriminate.

   We do need to eat our own dogfood, =
otherwise we are hypocrites.

   John

   +1-484-962-0060

   From:
   v6ops =
<v6ops-bounces@ietf.org> on behalf of Noah <noah@neo.co.tz>
   Date: Monday, July 17, 2017 at 09:01
   To: Ted Lemon <mellon@fugue.com>
   Cc: Randy Bush <randy@psg.com>, v6ops =
<v6ops@ietf.org>, =
Alissa Cooper <alissa@cooperw.in>, Russ Housley <housley@vigilsec.com>, Jim Martin <jim@daedelus.com>, =
Suresh Krishnan <suresh.krishnan@gmail.com>
   Subject: Re: [v6ops] Incremental Deployment =
of IPv6-only Wi-Fi for IETF Meetings



   FWIW and to cater for all, =
would a fallback dual stack SSID work for the status quo while this 2nd =
v6 SSID is also experimented upon which is a great idea considering this =
is IETF.



   Noah



   On 17 Jul 2017 9:54 a.m., =
"Ted Lemon" <mellon@fugue.com> wrote:

   I don't think this is a social justice =
issue.   Does the IETF think that IPv6 works, or not? =
  If we think it works, and we have been working for what, 20 =
years, to make it work, and we have designed all this great
    transition tech, then why on earth =
would we not want to use it?   This isn't "one draft." =
  This is roughly half the work of the IETF for the past two =
decades.


   On =
Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

   So we agree to change the rules so that we =
use this network for every ID that want to experiment with it? Otherwise =
we discriminate among different authors =E2=80=A6

   I think is a really bad precedent.

   Regards,
   Jordi


   -----Mensaje original-----
   De: Ted Lemon <mellon@fugue.com>
   Responder a: <mellon@fugue.com>
   Fecha: lunes, 17 de julio de 2017, 8:48
   Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
   CC: IPv6 Ops WG <v6ops@ietf.org>, Jim =
Martin <jim@daedelus.com>, Randy Bush <randy@psg.com>, =
Suresh
    Krishnan <suresh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>
   Asunto: Re: [v6ops] Incremental Deployment =
of IPv6-only Wi-Fi for IETF Meetings

       I don't actually =
know what the goal of the IETF network is other than to provide =
connectivity.   Because of the vicissitudes of hotel topology, =
it is often the case that IETF participants experience issues with =
the
    network at least once or twice =
per IETF despite the best efforts (and they are quite exceptional) of =
the NOC team.   I do not really see what the damage is that =
you are hoping to protect against here.   Users who don't read =
the NOC announcement?   No sympathy.
     Sorry.





   *********************************************=
*
   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 confidential. 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 disclosure, copying, =
distribution or
    use of the =
contents of this information, including attached files, is =
prohibited.



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







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






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




**********************************************
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 confidential. 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 disclosure, copying, =
distribution or use of the contents of this information, including =
attached files, is prohibited.



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



-- 
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

=

--Boundary_(ID_aNOS3eQ+R/wrsguqQWjYsw)--


From nobody Mon Jul 17 01:39:17 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2B131B09 for ; Mon, 17 Jul 2017 01:39:14 -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 ACwrcU2wBLY0 for ; Mon, 17 Jul 2017 01:39:06 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 A7C88131771 for ; Mon, 17 Jul 2017 01:39:05 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id 65so1860622wmf.0 for ; Mon, 17 Jul 2017 01:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=SuWI1GZmtvkSwh4nlvKyE/Y8U8c/DMVvtwmhR4c2Tjc=; b=tzM0on8QJz1kEv6cs52gTpcoIHYlD0voy3Rte0cdLgFlCvRQ3gQMFxlJ+ZLNUCajtc wrNhS+zNgZ1wax16V4em/2jCdDD+5qJEH8Eg7OAtZXNRUisADLwmHUF2eaJRO8PTfzTB 5R+qX7SH6nZEK8b8iJ+TtTpBQhyYsSO3Q6cxF7GmLExyiSkRtb1D1qfvaexwYBsj2p8p Z8HQBBtZ0giO8Kx5QaCiEGsNspMDFmBBk+x3zqCcTVl8cq9qHFo4qVgXHWJnj7Pmduct okxiAZZK2T3hVQ9rBaPf/u4ay6NSD+JhMwkmZ7I+d8S7AkaPlHHles+RX5n9iiPmbuDR GLow==
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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SuWI1GZmtvkSwh4nlvKyE/Y8U8c/DMVvtwmhR4c2Tjc=; b=NJo2FZkX/OvQYKt49TWttwnPaagAaB9Zl7AL+zBp2ns6Bhf/8B9mUjRHw6n59AzxHB 0avj3wDwaKxcAJVYda0SIH+Mg5zabatqazqE5xmuYy6Z4Bz9odbc6zDWrxcD27FrJ5TY rO/aV8AwkRarEv6u03V9xNMOV6zZiL6NpsrTQYsMqWwEEXyHXa+lI+J/UOCASIZMmYD1 4vHUY3UyarKtk+ghZUGIasMKwyjzY+3zTo9IGm/nLYwZIzNLiH8r9Qfid4+ZmXULCIDO v7GeIor5thwh5a/RQFE2I+3PuSILRnbHugVUuLIwR1vYI3k1K1dwDKVCNBxp9lXY7Fwu 1jrQ==
X-Gm-Message-State: AIVw1104B/9mOUa12p6yjgOeTjyIzhSaoizYQg2NWiC5fCxEMwoVxAET YrIObeMjBD29SmornIg=
X-Received: by 10.28.56.198 with SMTP id f189mr3549137wma.88.1500280743928; Mon, 17 Jul 2017 01:39:03 -0700 (PDT)
Received: from CPB-TRN2.dhcp.mu.afrinic.net ([2001:43f8:90:250:edf5:82c3:462e:acb2]) by smtp.gmail.com with ESMTPSA id i136sm9495423wmf.33.2017.07.17.01.39.02 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 01:39:03 -0700 (PDT)
To: v6ops@ietf.org
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> 
From: Stephen Honlue 
Message-ID: <9a3a454b-d1fa-406c-7f39-5add5f422d16@gmail.com>
Date: Mon, 17 Jul 2017 12:38:57 +0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:39:15 -0000

My take for this is: IPv6 only per the I-D for the balance of IETF week?

We have been standardizing IPv6 for over twenty years now, it's just so
logical to preach by example.

Regards.


On 17/07/2017 12:34, Jen Linkova wrote:
> On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
>  wrote:
>> In the real world, you will not disable IPv4 in the LANs of end-users or enterprise customers (at least not now, may be in 3-5 years from now).
> I disagree with this statement. There are networks doing this. Right
> here right now.
>
>> -----Mensaje original-----
>> De: v6ops  en nombre de "Brzozowski, John" 
>> Responder a: 
>> Fecha: lunes, 17 de julio de 2017, 10:14
>> Para: Noah , Ted Lemon 
>> CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>
>>     Agree with Noah and Ted.
>>
>>     Note the I-D explicitly documents that a fallback, dual stack SSID must remain available as Noah mentions below.
>>
>>     I fail to see how doing this will harm or discriminate.
>>
>>     We do need to eat our own dogfood, otherwise we are hypocrites.
>>
>>     John
>>
>>     +1-484-962-0060
>>
>>     From:
>>     v6ops  on behalf of Noah 
>>     Date: Monday, July 17, 2017 at 09:01
>>     To: Ted Lemon 
>>     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley , Jim Martin , Suresh Krishnan 
>>     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>
>>
>>
>>     FWIW and to cater for all, would a fallback dual stack SSID work for the status quo while this 2nd v6 SSID is also experimented upon which is a great idea considering this is IETF.
>>
>>
>>
>>     Noah
>>
>>
>>
>>     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>>
>>     I don't think this is a social justice issue.   Does the IETF think that IPv6 works, or not?   If we think it works, and we have been working for what, 20 years, to make it work, and we have designed all this great
>>      transition tech, then why on earth would we not want to use it?   This isn't "one draft."   This is roughly half the work of the IETF for the past two decades.
>>
>>
>>     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
>>
>>     So we agree to change the rules so that we use this network for every ID that want to experiment with it? Otherwise we discriminate among different authors …
>>
>>     I think is a really bad precedent.
>>
>>     Regards,
>>     Jordi
>>
>>
>>     -----Mensaje original-----
>>     De: Ted Lemon 
>>     Responder a: 
>>     Fecha: lunes, 17 de julio de 2017, 8:48
>>     Para: JORDI PALET MARTINEZ 
>>     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
>>      Krishnan , Russ Housley , Alissa Cooper 
>>     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>
>>         I don't actually know what the goal of the IETF network is other than to provide connectivity.   Because of the vicissitudes of hotel topology, it is often the case that IETF participants experience issues with the
>>      network at least once or twice per IETF despite the best efforts (and they are quite exceptional) of the NOC team.   I do not really see what the damage is that you are hoping to protect against here.   Users who don't read the NOC announcement?   No sympathy.
>>       Sorry.
>>
>>
>>
>>
>>
>>     **********************************************
>>     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 confidential. 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 disclosure, copying, distribution or
>>      use of the contents of this information, including attached files, is prohibited.
>>
>>
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     v6ops@ietf.org
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     v6ops@ietf.org
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     v6ops@ietf.org
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>> **********************************************
>> 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 confidential. 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 disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>


From nobody Mon Jul 17 01:39:34 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCED131B09 for ; Mon, 17 Jul 2017 01:39: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, 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 TlHSGt7HU5_f for ; Mon, 17 Jul 2017 01:39:22 -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 A474F131B14 for ; Mon, 17 Jul 2017 01:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500280756; x=1500885556; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=XuFLxOA8TyX+DZ5116Xe6O758 G/G0VgMgG508qgJT3g=; b=MA+IogPEBpQ1/D0nbVkNXTo6vPiHcFNEopcGLVt6v dWgGidcBaDaEQso2PsL2K3enb0GwcoS8w6Tpo3zKGyaME+tojPG8L8hZwGofPLtv 5HlDJIrrsW8TJeuDpCGelx3fLgsacInyWbxVATVhnbGsS7P3Uxf3LYgqDm8Y2Y45 IY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=GKl/fBR54tdyi5YLMJ5LqbCz7Oh76EPENY7mgogSbHk3AEI1KNI0OObkGS9v ZwwC2AH98ciZ9V0gzIAox1oLQr4qHbeLXM2PvtkG1GA6yOrGxaAptBPbt eIi+PGWcARW5A20ElsqUcF9ZuQVk9YGjGRK7SQ3xlWYV5jGjXSwYeM=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:39:16 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:39:15 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478204.msg for ; Mon, 17 Jul 2017 10:39:15 +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:170717:md50005478204::c9I6CuQGQnZmeMmw:00001Xei
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:39:09 +0200
From: JORDI PALET MARTINEZ 
To: "v6ops@ietf.org" 
CC: Randy Bush , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Message-ID: <22D5BDD5-E59C-427A-8785-BBC97D522026@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:39:24 -0000

What we prefer:

1) Knowing only =E2=80=9Chow many=E2=80=9D people switch to dual-stack fall=
back?
Or
2) Knowing what apps fail to operators with NAT64, which means we could tel=
l the vendors of specific apps?

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:32
Para: Jen Linkova 
CC: Jordi Palet Martinez , Randy Bush , "v6ops@ietf.org" , Russ Housley , Alissa Cooper , Jim Martin , Sure=
sh Krishnan 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Mon, Jul 17, 2017 at 10:30 AM, Jen Linkova  wrote=
:
   =20
    Actually if the fallback dual-stack network requires an explicit
    configuration on the client side (as the draft recommends) to avoid
    users connecting to it accidentally, the number of clients falling
    back to the dual stack SSID is very good data point to demonstrate
    what % of users are experiencing issues.
   =20
   =20
    Yes!=20
   =20
   =20
   =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 Mon Jul 17 01:40:45 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D450131AFC for ; Mon, 17 Jul 2017 01:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lWa7VQbczob for ; Mon, 17 Jul 2017 01:40:42 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BD5131A8E for ; Mon, 17 Jul 2017 01:40:42 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F16DA41BF3 for ; Mon, 17 Jul 2017 10:40:40 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 687C441B72; Mon, 17 Jul 2017 10:40:40 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 598D71F430; Mon, 17 Jul 2017 10:40:40 +0200 (CEST)
Date: Mon, 17 Jul 2017 10:40:40 +0200
From: Gert Doering 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Message-ID: <20170717084040.GJ45648@Space.Net>
References:    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <2967DA6E-D74C-4356-8193-74A6D1EA771E@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:40:44 -0000

Hi,

On Mon, Jul 17, 2017 at 10:33:35AM +0200, JORDI PALET MARTINEZ wrote:
> May be, but it means that customers with use old apps with literals, 
> go and complain to their operators, and probably switch to another 
> operator. I don???t think this is a good advice to operators or 
> enterprise network admins to deploy IPv6-only in their LANs.

This is not about "operators".  It's about demonstrating to a very
particular technical body where homeworks have not been made properly yet
- so: expose breakage to those that need to fix it.

IETF attendees are not innocent virgins that need to be protected from
evil dragons.

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

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


From nobody Mon Jul 17 01:42:00 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2FE131A8E for ; Mon, 17 Jul 2017 01:41:59 -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, 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 2xwLIJ-Tc2FI for ; Mon, 17 Jul 2017 01:41:57 -0700 (PDT)
Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 39130131A8C for ; Mon, 17 Jul 2017 01:41:57 -0700 (PDT)
Received: by mail-it0-x241.google.com with SMTP id v193so17428674itc.2 for ; Mon, 17 Jul 2017 01:41:57 -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=0wcb/80W6cqc1Mdet1hED9yMLWrVQl/ukcAy9uqEDOw=; b=Qtfxr5CP5BRShgVsXdmfXZm+yVkULEuEwfcjD7X8tIdZRg102gHSnCinIWXLuYOjxD koLe8WVicYYcSe3p7OZSMjkhBElusBA4zVvCq2bNEbREWc90Apanv9kfscdSoFEJAMFK N4ArDUbddERtytqCFoUYAmio1ORu6idggz86MkOJED+qvYgvA+eLlkFebS4p6D1EVLcm tsioVNKBbcFUmmR5gtU85Qj0AHlhjPEYdAH3GRkKVsgoKfccbOQptsJvHEcHX9PfKk2m 6vPUbkKNppUr0YvipvqhKor/fInm1m/aCojs0uxgq6EDDzizBs+/j5p82gDfmVZVKbGl SrCg==
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=0wcb/80W6cqc1Mdet1hED9yMLWrVQl/ukcAy9uqEDOw=; b=uDTzcUv7gsEyAbnY8HqFWBfnfdtEFFZQvfD/jnGebaiswkfsJ2QgGJxvIBH3th3u/i thNtOUNKfIK3OKfpW223CCiXvx/VohPXQypf53dQk9lCQBXVW2UQ3DEwjJH/jz6lFnmP xiwJE8gDawNoKa6ZTjoGRGtBeSF/izuaVTM+NkIEk7TsF4PM9I1egAPTBL7jkiIa3BQP HWnKJiN4nqwIYaqcoCijE9MvB8BDAg7bo7k47YqTQmlYbhD5+t+AiIMTlKtMzhuYbtY2 kVScTxq80sDRnxsqjc4PRYljJ8MdBZdq00FGKI+kO4dXwwbWWjgfuc6UGKArR+6+B1uk 1QRA==
X-Gm-Message-State: AIVw112jFSPSmr0WphVdPDCJNgtro87IbZQS2CQxwz0JbCV7TOSAvhPZ kB6e1ULRDflIHbrZcV2KZEXwG8JeX4Jints=
X-Received: by 10.36.47.144 with SMTP id j138mr4304436itj.30.1500280916511; Mon, 17 Jul 2017 01:41:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 01:41:35 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>  
From: Jen Linkova 
Date: Mon, 17 Jul 2017 18:41:35 +1000
Message-ID: 
To: Jordi Palet Martinez 
Cc: IPv6 Ops WG , Jim Martin , Alissa Cooper ,  Suresh Krishnan , Russ Housley , Randy Bush 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:41:59 -0000

On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
 wrote:
> Tell your bank, your university, your library, etc., to try that.
>
> I now that some networks (mainly related to IETF work, vendors, etc.), ar=
e doing that, but not in a general market.

Are you saying IETF should wait until everyone else has done it and
proved it works and only then we feel safe enough to try it? ;)

> -----Mensaje original-----
> De: Jen Linkova 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 10:34
> Para: Jordi Palet Martinez 
> CC: IPv6 Ops WG , Jim Martin , Russ Hou=
sley , Suresh Krishnan , A=
lissa Cooper , Randy Bush 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Me=
etings
>
>     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
>      wrote:
>     > In the real world, you will not disable IPv4 in the LANs of end-use=
rs or enterprise customers (at least not now, may be in 3-5 years from now)=
.
>
>     I disagree with this statement. There are networks doing this. Right
>     here right now.
>
>     > -----Mensaje original-----
>     > De: v6ops  en nombre de "Brzozowski, John" =

>     > Responder a: 
>     > Fecha: lunes, 17 de julio de 2017, 10:14
>     > Para: Noah , Ted Lemon 
>     > CC: Jim Martin , IPv6 Ops WG , Al=
issa Cooper , Russ Housley , Randy=
 Bush , Suresh Krishnan 
>     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
>     >
>     >     Agree with Noah and Ted.
>     >
>     >     Note the I-D explicitly documents that a fallback, dual stack S=
SID must remain available as Noah mentions below.
>     >
>     >     I fail to see how doing this will harm or discriminate.
>     >
>     >     We do need to eat our own dogfood, otherwise we are hypocrites.
>     >
>     >     John
>     >
>     >     +1-484-962-0060
>     >
>     >     From:
>     >     v6ops  on behalf of Noah 
>     >     Date: Monday, July 17, 2017 at 09:01
>     >     To: Ted Lemon 
>     >     Cc: Randy Bush , v6ops , Alissa =
Cooper , Russ Housley , Jim Martin=
 , Suresh Krishnan 
>     >     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi =
for IETF Meetings
>     >
>     >
>     >
>     >     FWIW and to cater for all, would a fallback dual stack SSID wor=
k for the status quo while this 2nd v6 SSID is also experimented upon which=
 is a great idea considering this is IETF.
>     >
>     >
>     >
>     >     Noah
>     >
>     >
>     >
>     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>     >
>     >     I don't think this is a social justice issue.   Does the IETF t=
hink that IPv6 works, or not?   If we think it works, and we have been work=
ing for what, 20 years, to make it work, and we have designed all this grea=
t
>     >      transition tech, then why on earth would we not want to use it=
?   This isn't "one draft."   This is roughly half the work of the IETF for=
 the past two decades.
>     >
>     >
>     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
>     >
>     >     So we agree to change the rules so that we use this network for=
 every ID that want to experiment with it? Otherwise we discriminate among =
different authors =E2=80=A6
>     >
>     >     I think is a really bad precedent.
>     >
>     >     Regards,
>     >     Jordi
>     >
>     >
>     >     -----Mensaje original-----
>     >     De: Ted Lemon 
>     >     Responder a: 
>     >     Fecha: lunes, 17 de julio de 2017, 8:48
>     >     Para: JORDI PALET MARTINEZ 
>     >     CC: IPv6 Ops WG , Jim Martin =
, Randy Bush , Suresh
>     >      Krishnan , Russ Housley , Alissa Cooper 
>     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
>     >
>     >         I don't actually know what the goal of the IETF network is =
other than to provide connectivity.   Because of the vicissitudes of hotel =
topology, it is often the case that IETF participants experience issues wit=
h the
>     >      network at least once or twice per IETF despite the best effor=
ts (and they are quite exceptional) of the NOC team.   I do not really see =
what the damage is that you are hoping to protect against here.   Users who=
 don't read the NOC announcement?   No sympathy.
>     >       Sorry.
>     >
>     >
>     >
>     >
>     >
>     >     **********************************************
>     >     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 privi=
leged or confidential. 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 disclosure, copying, distribution or
>     >      use of the contents of this information, including attached fi=
les, is prohibited.
>     >
>     >
>     >
>     >     _______________________________________________
>     >     v6ops mailing list
>     >     v6ops@ietf.org
>     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >     _______________________________________________
>     >     v6ops mailing list
>     >     v6ops@ietf.org
>     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >     _______________________________________________
>     >     v6ops mailing list
>     >     v6ops@ietf.org
>     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
>     >
>     >
>     > **********************************************
>     > 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 privilege=
d or confidential. The information is intended to be for the use of the ind=
ividual(s) named above. If you are not the intended recipient be aware that=
 any disclosure, copying, distribution or use of the contents of this infor=
mation, including attached files, is prohibited.
>     >
>     >
>     >
>     > _______________________________________________
>     > v6ops mailing list
>     > v6ops@ietf.org
>     > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>     --
>     SY, Jen Linkova aka Furry
>
>
>
>
> **********************************************
> 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 c=
onfidential. The information is intended to be for the use of the individua=
l(s) named above. If you are not the intended recipient be aware that any d=
isclosure, copying, distribution or use of the contents of this information=
, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--=20
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 01:42:23 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C912D131AFC for ; Mon, 17 Jul 2017 01:42:21 -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 3vEdA-byIhex for ; Mon, 17 Jul 2017 01:42:19 -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 E8EC7131B1A for ; Mon, 17 Jul 2017 01:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500280929; x=1500885729; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=HqjGN9LlWiMyULea2XMp6viXR 0F0eTLe9d2OvGoEGOA=; b=XE0rPIZnLjzQ24ApuWWXeNZEtkpBeE31Q/2WqQFw/ ZJ/Edk+OR5c6wzqj7xlRF8SrVRS+xqrUQ8bex6W9RThUxNlNG6gvPkFB8K6aVKpK au9P4Kyrz+5u5q1Yh/HUTmojiiBGW5FUZYa8D9BOercHt5C3rZ6qlpX/zXgd72ou 9k=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=B2bw4Tp5VHcyhynK/ImaVYw6xpTB0WNOe1NBuUy2SyRU2i1UtWHUpThh3gFb obyEjuPKbyJxU/HzO+DpGoSazSiwuSUw58rgVntCz6yAWbXbwwJpJFM1n UD51BDxGWqYZI1ZCrhgh4JbzGB40xisM6zZxS1EIZGAur3fYgIdyr4=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:42:09 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:42:07 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478210.msg for ; Mon, 17 Jul 2017 10:42:05 +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:170717:md50005478210::GozKGgwGE+rQpLAI:00001Rnn
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:42:01 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>  
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:42:22 -0000

Using CLAT means we can actually KNOW and report if we like, what will be b=
roken by NAT64 without actually breaking it.

Cellular networks is a much more controlled field, I guess all app develope=
rs, because Apple mandated (and I like it very much), support for IPv6 in a=
ny app, worked out the same for Android/Windows apps, so it make sense.

Regards,
Jordi
=20

-----Mensaje original-----
De:  en nombre de David Schinazi 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:38
Para: Jen Linkova 
CC: Jordi Palet Martinez , Randy Bush , IPv6 Ops WG , Russ Housley , =
Alissa Cooper , Jim Martin , Suresh Kr=
ishnan 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

   =20
   =20
    On Jul 17, 2017, at 10:34, Jen Linkova  wrote:
   =20
    On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
     wrote:
   =20
    In the real world, you will not disable IPv4 in the LANs of end-users o=
r enterprise customers (at least not now, may be in 3-5 years from now).
   =20
   =20
   =20
    I disagree with this statement. There are networks doing this. Right
    here right now.
   =20
   =20
   =20
   =20
    A major US carrier is doing this today on iPhone without any CLAT.
    It works, and they don't even have a fallback.
    What we're proposing here is allowing networking experts to test
    the feasibility of IPv6 only. From my experience most issues are
    extremely minor and it often only takes small fixes to work. But
    you need to be aware of the issue ti go fix it.
   =20
    Using a CLAT here would not allow us to learn what works or not
    because going through NAT64 is not a failure.
   =20
    Thanks,
    David Schinazi
   =20
   =20
   =20
   =20
    -----Mensaje original-----
    De: v6ops  en nombre de "Brzozowski, John" 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 10:14
    Para: Noah , Ted Lemon 
    CC: Jim Martin , IPv6 Ops WG , Alissa=
 Cooper , Russ Housley , Randy Bus=
h , Suresh Krishnan 
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
   =20
       Agree with Noah and Ted.
   =20
       Note the I-D explicitly documents that a fallback, dual stack SSID m=
ust remain available as Noah mentions below.
   =20
       I fail to see how doing this will harm or discriminate.
   =20
       We do need to eat our own dogfood, otherwise we are hypocrites.
   =20
       John
   =20
       +1-484-962-0060
   =20
       From:
       v6ops  on behalf of Noah 
       Date: Monday, July 17, 2017 at 09:01
       To: Ted Lemon 
       Cc: Randy Bush , v6ops , Alissa Coope=
r , Russ Housley , Jim Martin , Suresh Krishnan 
       Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
   =20
   =20
   =20
       FWIW and to cater for all, would a fallback dual stack SSID work for=
 the status quo while this 2nd v6 SSID is also experimented upon which is a=
 great idea considering this is IETF.
   =20
   =20
   =20
       Noah
   =20
   =20
   =20
       On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
   =20
       I don't think this is a social justice issue.   Does the IETF think =
that IPv6 works, or not?   If we think it works, and we have been working f=
or what, 20 years, to make it work, and we have designed all this great
        transition tech, then why on earth would we not want to use it?   T=
his isn't "one draft."   This is roughly half the work of the IETF for the =
past two decades.
   =20
   =20
       On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
   =20
       So we agree to change the rules so that we use this network for ever=
y ID that want to experiment with it? Otherwise we discriminate among diffe=
rent authors =E2=80=A6
   =20
       I think is a really bad precedent.
   =20
       Regards,
       Jordi
   =20
   =20
       -----Mensaje original-----
       De: Ted Lemon 
       Responder a: 
       Fecha: lunes, 17 de julio de 2017, 8:48
       Para: JORDI PALET MARTINEZ 
       CC: IPv6 Ops WG , Jim Martin , Ran=
dy Bush , Suresh
        Krishnan , Russ Housley , Alissa Cooper 
       Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IE=
TF Meetings
   =20
           I don't actually know what the goal of the IETF network is other=
 than to provide connectivity.   Because of the vicissitudes of hotel topol=
ogy, it is often the case that IETF participants experience issues with the
        network at least once or twice per IETF despite the best efforts (a=
nd they are quite exceptional) of the NOC team.   I do not really see what =
the damage is that you are hoping to protect against here.   Users who don'=
t read the NOC announcement?   No sympathy.
         Sorry.
   =20
   =20
   =20
   =20
   =20
       **********************************************
       IPv4 is over
       Are you ready for the new Internet ?
       http://www.consulintel.es
       The IPv6 Company
   =20
       This electronic message contains information which may be privileged=
 or confidential. The information is intended to be for the use of the indi=
vidual(s) named above. If you are not the intended recipient be aware that =
any disclosure, copying, distribution or
        use of the contents of this information, including attached files, =
is prohibited.
   =20
   =20
   =20
       _______________________________________________
       v6ops mailing list
       v6ops@ietf.org
       https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =20
   =20
       _______________________________________________
       v6ops mailing list
       v6ops@ietf.org
       https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =20
       _______________________________________________
       v6ops mailing list
       v6ops@ietf.org
       https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or use of the contents of this informati=
on, including attached files, is prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
    --=20
    SY, Jen Linkova aka Furry
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =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 Mon Jul 17 01:44:40 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F238131771 for ; Mon, 17 Jul 2017 01:44:39 -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 XSjJZkZ9ug4l for ; Mon, 17 Jul 2017 01:44:37 -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 F06D2131B19 for ; Mon, 17 Jul 2017 01:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500281075; x=1500885875; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=BMEFB86n/aFM6jYtVh/DqWDwX MSlzBp+wXIZTDPGuNc=; b=fPNiWIrTtuKzOHtjK9sEyOc9j/iuf+4mpG4OluBrQ qmTVdA407ycEDFb+4Lab5pLCEBDghpka6hXIPhekjn86ETojGFdFOaxPTNT91LCI 9EmDtFjk6NwyvjgeVRYy4rdvlvb5GwTYJup0bAROTJvB5DgXRncjU0wNFVac4al8 Uk=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ZUL9rzco86evbRCE/wWawskRMwslwqnA1KEmA+TATGTCq5ZdIphKitEA1Gha LMteQl+JkLJ0fcUw9g+CXVK3Fo7mBimVYkj7QYBTyL/2r/8TmkXGFd4lD 50OidcmpSEpI1xKvZJLCRZkWN1ogNTaHNNOGYrcuf83EiwuWBrFs0o=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:44:35 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 10:44:33 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478213.msg for ; Mon, 17 Jul 2017 10:44:31 +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:170717:md50005478213::566lcJraxsRmEKYf:00001zFS
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 10:44:27 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Message-ID: <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>   
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:44:40 -0000

I=E2=80=99m saying:

1) We should not try experiments in the IETF network, it has been the rule =
for ages.
2) If we decide to change that rule, we should try what is good for the mar=
ket, not what we =E2=80=9Cwish=E2=80=9D

I wish we can turn off IPv4 for every network in the world, but this is not=
 realistic.

Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivity, is=
 feasible. This is what we need to try.

NAT64 has been tested, in fact most of the RIRs (and of course IETF), have =
already such a network from long time ago.

Saludos,
Jordi
=20

-----Mensaje original-----
De: Jen Linkova 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 10:42
Para: Jordi Palet Martinez 
CC: IPv6 Ops WG , Jim Martin , Alissa Coo=
per , Suresh Krishnan , Russ =
Housley , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
     wrote:
    > Tell your bank, your university, your library, etc., to try that.
    >
    > I now that some networks (mainly related to IETF work, vendors, etc.)=
, are doing that, but not in a general market.
   =20
    Are you saying IETF should wait until everyone else has done it and
    proved it works and only then we feel safe enough to try it? ;)
   =20
    > -----Mensaje original-----
    > De: Jen Linkova 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 10:34
    > Para: Jordi Palet Martinez 
    > CC: IPv6 Ops WG , Jim Martin , Russ=
 Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
    > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
    >
    >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
    >      wrote:
    >     > In the real world, you will not disable IPv4 in the LANs of end=
-users or enterprise customers (at least not now, may be in 3-5 years from =
now).
    >
    >     I disagree with this statement. There are networks doing this. Ri=
ght
    >     here right now.
    >
    >     > -----Mensaje original-----
    >     > De: v6ops  en nombre de "Brzozowski, Jo=
hn" 
    >     > Responder a: 
    >     > Fecha: lunes, 17 de julio de 2017, 10:14
    >     > Para: Noah , Ted Lemon 
    >     > CC: Jim Martin , IPv6 Ops WG =
, Alissa Cooper , Russ Housley , R=
andy Bush , Suresh Krishnan 
    >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
    >     >
    >     >     Agree with Noah and Ted.
    >     >
    >     >     Note the I-D explicitly documents that a fallback, dual sta=
ck SSID must remain available as Noah mentions below.
    >     >
    >     >     I fail to see how doing this will harm or discriminate.
    >     >
    >     >     We do need to eat our own dogfood, otherwise we are hypocri=
tes.
    >     >
    >     >     John
    >     >
    >     >     +1-484-962-0060
    >     >
    >     >     From:
    >     >     v6ops  on behalf of Noah 
    >     >     Date: Monday, July 17, 2017 at 09:01
    >     >     To: Ted Lemon 
    >     >     Cc: Randy Bush , v6ops , Ali=
ssa Cooper , Russ Housley , Jim Ma=
rtin , Suresh Krishnan 
    >     >     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi=
-Fi for IETF Meetings
    >     >
    >     >
    >     >
    >     >     FWIW and to cater for all, would a fallback dual stack SSID=
 work for the status quo while this 2nd v6 SSID is also experimented upon w=
hich is a great idea considering this is IETF.
    >     >
    >     >
    >     >
    >     >     Noah
    >     >
    >     >
    >     >
    >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wr=
ote:
    >     >
    >     >     I don't think this is a social justice issue.   Does the IE=
TF think that IPv6 works, or not?   If we think it works, and we have been =
working for what, 20 years, to make it work, and we have designed all this =
great
    >     >      transition tech, then why on earth would we not want to us=
e it?   This isn't "one draft."   This is roughly half the work of the IETF=
 for the past two decades.
    >     >
    >     >
    >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
    >     >
    >     >     So we agree to change the rules so that we use this network=
 for every ID that want to experiment with it? Otherwise we discriminate am=
ong different authors =E2=80=A6
    >     >
    >     >     I think is a really bad precedent.
    >     >
    >     >     Regards,
    >     >     Jordi
    >     >
    >     >
    >     >     -----Mensaje original-----
    >     >     De: Ted Lemon 
    >     >     Responder a: 
    >     >     Fecha: lunes, 17 de julio de 2017, 8:48
    >     >     Para: JORDI PALET MARTINEZ 
    >     >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
    >     >      Krishnan , Russ Housley , Alissa Cooper 
    >     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-=
Fi for IETF Meetings
    >     >
    >     >         I don't actually know what the goal of the IETF network=
 is other than to provide connectivity.   Because of the vicissitudes of ho=
tel topology, it is often the case that IETF participants experience issues=
 with the
    >     >      network at least once or twice per IETF despite the best e=
fforts (and they are quite exceptional) of the NOC team.   I do not really =
see what the damage is that you are hoping to protect against here.   Users=
 who don't read the NOC announcement?   No sympathy.
    >     >       Sorry.
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >     **********************************************
    >     >     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 p=
rivileged or confidential. The information is intended to be for the use of=
 the individual(s) named above. If you are not the intended recipient be aw=
are that any disclosure, copying, distribution or
    >     >      use of the contents of this information, including attache=
d files, is prohibited.
    >     >
    >     >
    >     >
    >     >     _______________________________________________
    >     >     v6ops mailing list
    >     >     v6ops@ietf.org
    >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >     _______________________________________________
    >     >     v6ops mailing list
    >     >     v6ops@ietf.org
    >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >     _______________________________________________
    >     >     v6ops mailing list
    >     >     v6ops@ietf.org
    >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >
    >     > **********************************************
    >     > 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 privi=
leged or confidential. 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 disclosure, copying, distribution or use of the contents of this i=
nformation, including attached files, is prohibited.
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > v6ops@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >     --
    >     SY, Jen Linkova aka Furry
    >
    >
    >
    >
    > **********************************************
    > 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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --=20
    SY, Jen Linkova aka Furry
   =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 Mon Jul 17 01:59:35 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54512EA7C for ; Mon, 17 Jul 2017 01:59:34 -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 aJRB_9KvOliw for ; Mon, 17 Jul 2017 01:59:33 -0700 (PDT)
Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE8D126E3A for ; Mon, 17 Jul 2017 01:59:32 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=50650 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dX1sH-0000wg-T6; Mon, 17 Jul 2017 10:59:29 +0200
Date: Mon, 17 Jul 2017 10:59:29 +0200
From: Tore Anderson 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Message-ID: <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 08:59:34 -0000

* JORDI PALET MARTINEZ 

> However, we have different ways for doing the same, and we should go
> for the one that has less impact and it is more realistic.
> 
> In the real world, you will not disable IPv4 in the LANs of end-users
> or enterprise customers (at least not now, may be in 3-5 years from
> now). 

Jordi,

Did you even read the draft? It is quite clear in its recommendation to
provide IPv4 Internet connectivity to be provided through a NAT64/DNS64
service. Quoting from the abstract:

   The purpose of this document is to provide a blueprint and guidance
   for deploying IPv6-only Wi-Fi at IETF meetings.  This document
   outlines infrastructure and operational guidance that operators
   should consider when deploying IPv6-only networks **using NAT64 and
   DNS64 to support communication to legacy IPv4-only services**.

(Emphasis mine.)

> This is what IETF need to test now. IPv6 only with IPv4 as a service
> (which is 464XLAT).

Precisely. The existence of NAT64/DNS64 should in turn automatically
facilitate usage of 464XLAT.

Host operating systems that implements the CLAT component of 464XLAT
(e.g., Android or recently updated Windows 10) should be able to simply
activate it. While Apple doesn't implement 464XLAT per se they have
something similar, so they should be covered too.

There is more discussion about IPv4 backwards compatibility, including
a mention of 464XLAT, in section 4.2 of the draft.

Tore


From nobody Mon Jul 17 02:06:42 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C96131771 for ; Mon, 17 Jul 2017 02:06: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, 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 SGEiOFh4qfXv for ; Mon, 17 Jul 2017 02:06:39 -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 5C23312EB5F for ; Mon, 17 Jul 2017 02:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500282397; x=1500887197; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=24I0KE9N5Ah7Tv7CV/nWUYcLG Qxc5LKC+BSNuFgBZKQ=; b=OFhnbd+aUp01m50hf1RnYY3l1zpCQ97xfkMAxgR5L QaZKXQFDNMiUWwWbGVkEkflt4q8zedfILxXOPpeC1BycnUg76C8/sCG1eFMvG2lI hVhKbRuuw9COlqGBqmM/MgzvQGHheAb9AEPFTm2wPUEtMUZHmh8RheRHFUD9Dhnq Rc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=uShTX1L8GB0gPU0qAqR1qMTSk6ljz3uifV+idKdhRRtxpsCof+bqEZhnbcyp vVimniEWUWScIun6wXEU3MdvyrhuqfDMi5C8PUitBGutHrf5zd8u3TG38 qpd5MPfyrgdBU/bfuUrjuI3KhnSSwoFAOlKZczq6Il++NsyuISJ41g=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:06:37 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:06:36 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478233.msg for ; Mon, 17 Jul 2017 11:06:34 +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:170717:md50005478233::1WyyhOHyWQTaXmNq:00002ulH
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 11:06:27 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
In-Reply-To: <20170717105929.5a6b7997@echo.ms.redpill-linpro.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 09:06:41 -0000

Yeah, I read the draft and provided inputs.

And I understand what you=E2=80=99re saying however, not all the OSs have C=
LAT by default, it doesn=E2=80=99t work for us, and even less for end-custo=
mers.

I don=E2=80=99t think Apple has anything similar, just they mandated for iO=
S (smartphones), to have all the apps with IPv6 support, but is not the sam=
e for the laptops.

The last IETF I got a /64 prefix delegated by the NOC to my computer and I =
was running a VM with a CLAT daemon. All worked fine, but it requires the N=
OC to delegate me a prefix and have the VM running, which is not practical =
for every participant. Doing the same having the CLAT in a VM in the NOC it=
self, works for all.

Regards,
Jordi
=20

-----Mensaje original-----
De: Tore Anderson 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 11:00
Para: JORDI PALET MARTINEZ 
CC: IPv6 Ops WG , Jim Martin , Russ Housl=
ey , Suresh Krishnan , Ali=
ssa Cooper , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    * JORDI PALET MARTINEZ 
   =20
    > However, we have different ways for doing the same, and we should go
    > for the one that has less impact and it is more realistic.
    >=20
    > In the real world, you will not disable IPv4 in the LANs of end-users
    > or enterprise customers (at least not now, may be in 3-5 years from
    > now).=20
   =20
    Jordi,
   =20
    Did you even read the draft? It is quite clear in its recommendation to
    provide IPv4 Internet connectivity to be provided through a NAT64/DNS64
    service. Quoting from the abstract:
   =20
       The purpose of this document is to provide a blueprint and guidance
       for deploying IPv6-only Wi-Fi at IETF meetings.  This document
       outlines infrastructure and operational guidance that operators
       should consider when deploying IPv6-only networks **using NAT64 and
       DNS64 to support communication to legacy IPv4-only services**.
   =20
    (Emphasis mine.)
   =20
    > This is what IETF need to test now. IPv6 only with IPv4 as a service
    > (which is 464XLAT).
   =20
    Precisely. The existence of NAT64/DNS64 should in turn automatically
    facilitate usage of 464XLAT.
   =20
    Host operating systems that implements the CLAT component of 464XLAT
    (e.g., Android or recently updated Windows 10) should be able to simply
    activate it. While Apple doesn't implement 464XLAT per se they have
    something similar, so they should be covered too.
   =20
    There is more discussion about IPv4 backwards compatibility, including
    a mention of 464XLAT, in section 4.2 of the draft.
   =20
    Tore
   =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 Mon Jul 17 02:07:20 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BB8131B02 for ; Mon, 17 Jul 2017 02:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.101
X-Spam-Level: 
X-Spam-Status: No, score=-7.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC-XlzzqjXlc for ; Mon, 17 Jul 2017 02:07:17 -0700 (PDT)
Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.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 2AFB7131A88 for ; Mon, 17 Jul 2017 02:07:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500282434; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kd6Dz/MjWJ/LRsg0RIYAVU3SUxgJe8lKzshWFLn2Ym8=; b=SWEnPNpNgdr1u8XzSCrRQAwRdwImvUjdjKsuGA8JWbdJXi4io6K4YvWCR/MpbjAr 1E/9uilfXNbqTcuDZw4uwym21apgHIm9MkLjJuIn5aGZQoBeNzBg3GM4jyU+7DGo SQWZJJVgrF6VAqVF7+EiZQvbOGa897WLVrywzOG8tww9UE5wNDSYZqWyM5AVFAg1 wpSz4vhI5h4UCmMmlHSsN9DNjB1kpUNClVcfudF/i8Vnwa0aYWwuCqd6lVprqMpm bgg0rnVdRxCj9cWJAYwiwhfXryGKOWc8JIt5W8+ydkY/5iswUlEwy+W+/RURd/Cy 9hXACth/PpDpD+lyD1i9aA==;
Received: from relay2.euro.apple.com ( [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id 98.32.07437.24E7C695; Mon, 17 Jul 2017 10:07:14 +0100 (BST)
X-AuditID: 1148940d-ed6789c000001d0d-bf-596c7e429dc3
Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 77.80.07255.24E7C695; Mon, 17 Jul 2017 10:07:14 +0100 (BST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [IPv6:2001:67c:370:1998:6184:6dda:119f:1f89] (nat64-aa.meeting.ietf.org [31.130.238.170]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OT800BSJ9BZ0K40@phonehome3.euro.apple.com>; Mon, 17 Jul 2017 10:07:14 +0100 (IST)
Sender: dschinazi@apple.com
From: David Schinazi 
In-reply-to: <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
Date: Mon, 17 Jul 2017 11:07:10 +0200
Cc: JORDI PALET MARTINEZ , Randy Bush , IPv6 Ops WG , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Message-id: <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com>
To: Tore Anderson 
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUi6GTOo+tUlxNp0L5MwGL6mb+MFq9e3GS3 uHaE2eLv8c/MFs9aXzJZHNlwltViy8E7jBanj+1lduDwWLc/wOPLk5dMHl0fLzN5/O2dye6x c9Zddo8lS34yeUydOZvRY9WdL6wBHFFcNimpOZllqUX6dglcGS9/b2Ip+Mxa0XrnPWsD4x2W LkZODgkBE4kNO1aydjFycQgJLGKS+PVrAjNM4ujr1SwQiUOMEjMXPGUFSfAKCEr8mHwPKMHB wSwgL3HwvCxImFlAS+L7o1ao+qNMEnNaF4INEhaQlui6cJcVwg6Q2HL1ADtILxtQw4E1RiBh TgFHiROTnoGFWQRUJd7f5wYZwyzQySTRvbAdaq2NxPHPnVDzv7NITF17EewDEaAbOk/Ogjpa VuLW7EtQ9nU2iUN3mCYwCs9CcvYshLNnITl7ASPzKkbx3MTMHN3MPGO91NKifL3EgoKcVL3k /NxNjKC48pjCu4Px+kHDQ4wCHIxKPLwybN6RQqyJZcWVucDg4WBWEuHtCc6JFOJNSaysSi3K jy8qzUktPsQozcGiJM5rUiofKSSQnliSmp2aWpBaBJNl4uCUamCstynoKVI76t01a78O29EH tZ1SS64JOpvV/IjQyhIrV7Jf7R3P1asb+WWZdZj8ghlbM05/ZVymGniCZ/OaTq+ihi0xIYcv /F6ruWXpIjHt/7xV33qeVBTHBpe2LOx4xPZAurK47ovThVCVL0WOtfen7n77/d6aOw03r8Tl n/l/LXFt74kTJz8psRRnJBpqMRcVJwIAX9b9JacCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUi6NEarOtUlxNpcO40j8X0M38ZLV69uMlu ce0Is8Xf45+ZLZ61vmSyOLLhLKvFloN3GC1OH9vL7MDhsW5/gMeXJy+ZPLo+Xmby+Ns7k91j 56y77B5Llvxk8pg6czajx6o7X1gDOKK4bFJSczLLUov07RK4Ml7+3sRS8Jm1ovXOe9YGxjss XYycHBICJhJHX68Gsrk4hAQOMUrMXPCUFSTBKyAo8WPyPaAEBwezgLzEwfOyIGFmAS2J749a oeqPMknMaV3IDJIQFpCW6LpwlxXCDpDYcvUAO0gvG1DDgTVGIGFOAUeJE5OegYVZBFQl3t/n BhnDLNDJJNG9sB1qrY3E8c+dUPO/s0hMXXsR7FARoBs6T85ihjhaVuLW7EvMExgFZiE5dRbC qbOQnLqAkXkVo2hRak5ipZFeamlRvl5iQUFOql5yfu4mRlAkOJnz7GB8ddDwEKMAB6MSD69d Qk6kEGtiWXFlLjBAOJiVRHh7goFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeQseRkQKCaQnlqRm p6YWpBbBZJk4OKUaGEPTHU1UjPyOiapH7W9xYZM8EXvDRNi9KtOLIefWBo4Ao+gFYSel1fs8 50seTXj5rmhjhzlvfYn4paUtdYkZX6Y038p7uu+l+azayw7iGuIheRWbXxhrikTu33Px1ZXj nYeWbg24sNA46cmlXO3G1N+GN28KuL1e/l1tz5FLTYUXltt+PcF3TomlOCPRUIu5qDgRALMo 8kqAAgAA
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 09:07:18 -0000

> On Jul 17, 2017, at 10:59, Tore Anderson  wrote:
> [...]
> Host operating systems that implements the CLAT component of 464XLAT
> (e.g., Android or recently updated Windows 10) should be able to simply
> activate it. While Apple doesn't implement 464XLAT per se they have
> something similar, so they should be covered too.

Indeed, section 4.2 mentions:

   Operating systems SHOULD provide simple
   ways for applications to do so or even connect to IPv4 literals in
   the absence of host names.  Possible solutions include 464XLAT
   [RFC6877], "Bump-in-the-Host" [RFC6535] and Happy Eyeballs v2 [HEv2].

Apple devices support HEv2, and this is massively deployed which
has proved that it is a viable solution.

David


From nobody Mon Jul 17 02:41:38 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9569912EBFA for ; Mon, 17 Jul 2017 02:41:36 -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 8qvb5cKNuVIg for ; Mon, 17 Jul 2017 02:41:34 -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 6CD141315FF for ; Mon, 17 Jul 2017 02:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500284489; x=1500889289; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=+78Kgd7PnftQsP2LZtUOeCWsW WmP0RZ9Ixw4Av7FBbU=; b=bG75OJHQe31ON4lv4UPKPI4Lts2k9SCqmg1Vy6U2E YOFOv3YU7r28gQ5iP+etjfkkN4hB5P82PwlR+AIbpI8d4EUI3icpT0lqbVXHRPad YJPTNspIAY+e0f6kuuxpUTWWGudXiXFrzo+dRRKdYKsxaXeGm1MADmc86W2br0ub fs=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=S6b8c8S5TfjW0MvTLt416e2CAYrMctucuiMEnzz60YQ+ADGDnfdxiLyybnN7 7TRVOg6mM6AoCtSiT8nYdqC1j9WPxEnxgE50BIZi8RVDxbsnELsGBBWEk 0yln4F29G2bLLdD4n7n+7h4aex+ElTNvOMJJjKc3aJvCJSPFN5isKM=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:41:29 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:41:27 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478284.msg for ; Mon, 17 Jul 2017 11:41:26 +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:170717:md50005478284::/C0iCxdFgex8tdwk:00004GS+
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 11:41:20 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>
In-Reply-To: <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 09:41:37 -0000

I=E2=80=99ve investigated this with OpenVPN right now using the ietf-nat64 =
SSID.

The remote OpenVPN server is IPv4-only, has a domain name (so not using lit=
erals), however, it seems the name is resolved to the IPv4-only address (ma=
ybe not using Apple Sierra OS =E2=80=93 latest version- all updated- system=
 APIs), so it fails to work with the NAT64.

I=E2=80=99m sure there are many other apps that have the same problem, it i=
s very unfortunate, I wish programmers do it right and use the systems APIs=
 (and no literals) that make it work, but this is not the case in the real =
world.

The point here is again: Manually asking the participants that get somethin=
g broken to report it, doesn=E2=80=99t work, while having an automated way =
to report what is using the CLAT is a much lower effort (actually none for =
the participants).

The result, if we do this experiment with NAT64, is that everyone requiring=
 =E2=80=9Cany=E2=80=9D app breaking with NAT64, is going to switch to the d=
ual-stack SSID, so we will not get reports for =E2=80=9Cother=E2=80=9D brok=
en apps from those participants.

Is this what we want? Or we prefer to have as many reports of broken things=
 as possible?

I guess many folks use OpenVPN, so it may be the case that many have the sa=
me problem. May be it happens the same with other VPN apps.

Regards,
Jordi
=20

-----Mensaje original-----
De:  en nombre de David Schinazi 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 11:07
Para: Tore Anderson 
CC: JORDI PALET MARTINEZ , Randy Bush , IPv6 Ops WG , Russ Housley , =
Alissa Cooper , Jim Martin , Suresh Kr=
ishnan 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

   =20
    > On Jul 17, 2017, at 10:59, Tore Anderson  wrote:
    > [...]
    > Host operating systems that implements the CLAT component of 464XLAT
    > (e.g., Android or recently updated Windows 10) should be able to simp=
ly
    > activate it. While Apple doesn't implement 464XLAT per se they have
    > something similar, so they should be covered too.
   =20
    Indeed, section 4.2 mentions:
   =20
       Operating systems SHOULD provide simple
       ways for applications to do so or even connect to IPv4 literals in
       the absence of host names.  Possible solutions include 464XLAT
       [RFC6877], "Bump-in-the-Host" [RFC6535] and Happy Eyeballs v2 [HEv2]=
.
   =20
    Apple devices support HEv2, and this is massively deployed which
    has proved that it is a viable solution.
   =20
    David
   =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 Mon Jul 17 02:48:32 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0312EBFE for ; Mon, 17 Jul 2017 02:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.101
X-Spam-Level: 
X-Spam-Status: No, score=-7.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAiDWKEGPu_q for ; Mon, 17 Jul 2017 02:48:28 -0700 (PDT)
Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.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 057FE12EB99 for ; Mon, 17 Jul 2017 02:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500284906; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VtZ/v9kglScsN5Q/FWKovLD/AMohl5ceCDwDJNWZAtA=; b=raT7nfJ7gaL/RPYrqMx/NpgeMt5zQ9ZCu+Y2xWc3BQpP2YinFJuhBbabM/URh4ax IOlF/DRq+Nz1BgUbAIgFnfsgNEZih4joP8XGnQrFhwKOQMIRINaONW/jt0YsxE8y skBu6KA94Y4lKAv2Qr/KQl7YqoEhr7gMZL8EzlQnYQquATZKdG0JRg0vZS+C6IYh KlfsWn4nLjgxknq4s+i1hSW8MBpPBfFFSXfli7HYfKxryPfTJacfZ+l4UsWl8jjA 8nAw3UqyB0Gti3tHkSTb5GEjHUCHgT2tgDTj0ZN9liMIc2akk0S3FBMVCGiSQOcB EyPOG9lSCHWdHfbGrpGtiA==;
Received: from relay1.euro.apple.com ( [17.66.55.11]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id F3.63.07437.AE78C695; Mon, 17 Jul 2017 10:48:26 +0100 (BST)
X-AuditID: 1148940d-ed6789c000001d0d-6b-596c87eac674
Received: from crk-phonehomebzp-sz04.euro.apple.com (crk-phonehomebzp-sz04.euro.apple.com [17.72.133.84]) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id C7.A8.10112.9E78C695; Mon, 17 Jul 2017 10:48:26 +0100 (BST)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [IPv6:2001:67c:370:1998:6184:6dda:119f:1f89] (nat64-aa.meeting.ietf.org [31.130.238.170]) by phonehome4.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OT800IFOB8N0900@phonehome4.euro.apple.com>; Mon, 17 Jul 2017 10:48:25 +0100 (IST)
Sender: dschinazi@apple.com
From: David Schinazi 
In-reply-to: 
Date: Mon, 17 Jul 2017 11:48:22 +0200
Cc: IPv6 Ops WG , Randy Bush , Alissa Cooper , Suresh Krishnan , Russ Housley , Jim Martin 
Content-transfer-encoding: quoted-printable
Message-id: <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@apple.com>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com> 
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRdDLn1n3VnhNpcPs9m8X0M38ZLV69uMlu ce0Is8Xf45+ZLZ61vmSyOLLhLKvF6WN7mR3YPdbtD/D48uQlk0fXx8tMHjtn3WX3WLLkJ5PH 1JmzGT1W3fnCGsAexWWTkpqTWZZapG+XwJWx4cQlxoKvHBVXJi9laWCcwN7FyMkhIWAisbJj C5DNxSEksIhJ4uvx24wwicd3T7JCJJ4xSnSuXwWW4BUQlPgx+R5LFyMHB7OAusSUKbkQNUeZ JC58fMIEUiMsIC3RdeEuK4QdILHl6gF2kHo2AS2JA2uMQExOASeJn09NQSpYBFQlDnxrYQMZ wyxwjVHi7pcdLCAJZgFtiSfvLrBCrLWRmNLQAXXoI1aJC8tesoEkRATkJO6uaIU6Wlbi1uxL zCBFEgLX2SRevmlgmsAoPAvJ3bMQ7p6FZMcCRuZVjOK5iZk5upl5xnqppUX5eokFBTmpesn5 uZsYQVHkMYV3B+P1g4aHGAU4GJV4eGXYvCOFWBPLiitzDzFKcDArifD2BOdECvGmJFZWpRbl xxeV5qQWH2KU5mBREuc1KZWPFBJITyxJzU5NLUgtgskycXBKNTC2VHdUt/E9mOl4hT3ju/Dk 2ZKLZJ/m+z20uey0afOS26sl3+TfP99/Lf7r6TWPWj9sf/kw7PKCt8vvx8w99muC0skcj0eT 3vt/dUi/lF3ieEvOvuJEvG76j717n+bHb8qa1pJYMu3+i3M7DbneS/PIf/n83avQUMhDL+7S Wu4nfI3vlpn53NpRo8RSnJFoqMVcVJwIAEnWdJOeAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUi6NEaovuqPSfSYOF5ZovpZ/4yWrx6cZPd 4toRZou/xz8zWzxrfclkcWTDWVaL08f2Mjuwe6zbH+Dx5clLJo+uj5eZPHbOusvusWTJTyaP qTNnM3qsuvOFNYA9issmJTUnsyy1SN8ugStjw4lLjAVfOSquTF7K0sA4gb2LkZNDQsBE4vHd k6xdjFwcQgLPGCU6169iBEnwCghK/Jh8j6WLkYODWUBdYsqUXIiao0wSFz4+YQKpERaQlui6 cJcVwg6Q2HL1ADtIPZuAlsSBNUYgJqeAk8TPp6YgFSwCqhIHvrWwgYxhFrjGKHH3yw4WkASz gLbEk3cXWCHW2khMaehgh9j1iFXiwrKXbCAJEQE5ibsrWhkhjpaVuDX7EvMERoFZSE6dhXDq LCRjFzAyr2IULUrNSaw01EstLcrXSywoyEnVS87P3cQICnonc+4djMd3Gx5iFOBgVOLhlW3I iRRiTSwrrsw9xCjBwawkwtsTDBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOW/AwIlJIID2xJDU7 NbUgtQgmy8TBKdXA6PDC5Mpc99rA6H3ub/fZCe5nu8Yen6N2R4lJ8oDK62AZNd2dn774/b3z 1fj0bf1V9n//vf0xc/+E8FWhpx7Ez37NFSiaF7mC5dZu9yyN/dOuH3bId3dj+XXoQuh0de+z s1njT09g4TWSXcz2ROl64JPk6kATLSVWGdUjH5WvyWy1nx8lbbqnRImlOCPRUIu5qDgRAO7s 1rt2AgAA
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 09:48:29 -0000

> On Jul 17, 2017, at 11:41, JORDI PALET MARTINEZ =
 wrote:
>=20
> I=E2=80=99ve investigated this with OpenVPN right now using the =
ietf-nat64 SSID.
>=20
> The remote OpenVPN server is IPv4-only, has a domain name (so not =
using literals), however, it seems the name is resolved to the IPv4-only =
address (maybe not using Apple Sierra OS =E2=80=93 latest version- all =
updated- system APIs), so it fails to work with the NAT64.
>=20
> I=E2=80=99m sure there are many other apps that have the same problem, =
it is very unfortunate, I wish programmers do it right and use the =
systems APIs (and no literals) that make it work, but this is not the =
case in the real world.

Should we then give up on IPv6 or try to get these fixed?

> The point here is again: Manually asking the participants that get =
something broken to report it, doesn=E2=80=99t work, while having an =
automated way to report what is using the CLAT is a much lower effort =
(actually none for the participants).

Which "automated way to report what is [broken] using the CLAT" software =
are you referring to?=


From nobody Mon Jul 17 02:53:09 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A16A129417 for ; Mon, 17 Jul 2017 02:53:08 -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 e-xtKFCARGRs for ; Mon, 17 Jul 2017 02:53:07 -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 73DA91276AF for ; Mon, 17 Jul 2017 02:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500285182; x=1500889982; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=U0YBGqvzyQhspdik/CuLqM7/m gSwvEkw4QGxW/XOBjI=; b=W1WBLIgiydYXzr05vLqJklo/jNoHCcrZaPngJ3ecq C/suyLjB9n4idvkvCzIyA8H1MGR/0nuvEqe2dsT/KXoN/GgUhPRKKvJvB724cTeg sZ1kHHKho5UMoQgda4zKGj1pZT0CWQxuITBzcxshpWfvL1T37HDUtPYSMbF6uIL2 tA=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=nBheW/No0Mfb4CVsfNYlvvGTd/VTPM4FZyTW5qF7l4D3pQ+9QrZvVAp5f55D OujKyLTNn3tqYjUSsS+BzfKmhj6r4ydPwXRitf3Z5m2L+fmIGtgGH7jO2 VRQ2zZNua21eI3ggWmPLPBrz0nKsu48AIsbpgZbV6Nx5AHJCaruKhY=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:53:02 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 11:53:01 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478297.msg for ; Mon, 17 Jul 2017 11:53:01 +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:170717:md50005478297::QWUUtBKAqBO7uZLN:00002Cyd
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 11:52:53 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Alissa Cooper , Suresh Krishnan , Russ Housley , Jim Martin 
Message-ID: <4DDD221A-B9AA-4F47-9B15-DD58CEBE6584@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@apple.com>
In-Reply-To: <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@apple.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 09:53:08 -0000

Definitively get them fixed, and towards that we need to identify them. We =
want to identify them =E2=80=9Cmanually=E2=80=9D or =E2=80=9Cautomatically=
=E2=80=9D? I think automatically will work much better. Manually means peop=
le may report the first failure, then switch to the fall back network =E2=
=80=A6

CLAT can be run in a VM (for example using Jool). I=E2=80=99ve done it.

I=E2=80=99m not a software developer, but Jool provides some logging tools,=
 it is just a matter to get our hands on it.

There may be other CLAT implementations that can be used. I think Jool is v=
ery powerful, take advantage of multiple cores, etc.

Regards,
Jordi
=20

-----Mensaje original-----
De:  en nombre de David Schinazi 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 11:48
Para: 
CC: IPv6 Ops WG , Randy Bush , Alissa Cooper=
 , Suresh Krishnan , Russ Hou=
sley , Jim Martin 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

   =20
   =20
    > On Jul 17, 2017, at 11:41, JORDI PALET MARTINEZ  wrote:
    >=20
    > I=E2=80=99ve investigated this with OpenVPN right now using the ietf-=
nat64 SSID.
    >=20
    > The remote OpenVPN server is IPv4-only, has a domain name (so not usi=
ng literals), however, it seems the name is resolved to the IPv4-only addre=
ss (maybe not using Apple Sierra OS =E2=80=93 latest version- all updated- =
system APIs), so it fails to work with the NAT64.
    >=20
    > I=E2=80=99m sure there are many other apps that have the same problem=
, it is very unfortunate, I wish programmers do it right and use the system=
s APIs (and no literals) that make it work, but this is not the case in the=
 real world.
   =20
    Should we then give up on IPv6 or try to get these fixed?
   =20
    > The point here is again: Manually asking the participants that get so=
mething broken to report it, doesn=E2=80=99t work, while having an automate=
d way to report what is using the CLAT is a much lower effort (actually non=
e for the participants).
   =20
    Which "automated way to report what is [broken] using the CLAT" softwar=
e are you referring to?



**********************************************
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 Mon Jul 17 03:00:07 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6760E12EB99 for ; Mon, 17 Jul 2017 03:00:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4s1_JhRVNtY for ; Mon, 17 Jul 2017 03:00:03 -0700 (PDT)
Received: from mail-in2.euro.apple.com (mail-in.euro.apple.com [17.72.148.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 6494F1276AF for ; Mon, 17 Jul 2017 03:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500285600; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g7Cxey5SM2G4suKRqPPwuNluCD4qYOY5gDnuX8w20Aw=; b=TATX6OWP3/fk9MF4W4dBRjyg2P4xqxcbEI5Tw5coUzSY8IyWcnBn0Nc/68pCRbuv HZ1r/TcCUDnYg9wCvqBqd0+yAz+x8mVmHOz6epVdkXea+4fCyvsVh2bnnB4dNq8x SrSorMJXjhNC7+rsnYMP+azugSD4zGvMrlnmyfdmqxfQEZ4Uv4gc44DCzl7LF4nS HTvansDy9oHcNeaGCxrxphghWckv+dVHPXOMffJT++KcJ0GWNDQZH27AqYPCiege oK0ew553NVe0cOBfOblSgLfvAyiOzUyswUOx69fpqY4payOM4neuKbF2xh7xBRUT MpynpmJTRQmCc2qnOAl2WQ==;
Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 34.A0.06273.0AA8C695; Mon, 17 Jul 2017 11:00:00 +0100 (BST)
X-AuditID: 1148940c-1926f9c000001881-90-596c8aa0f4c5
Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 97.55.07255.0AA8C695; Mon, 17 Jul 2017 11:00:00 +0100 (BST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_o9TmgTeKI/Z3WO/oWHOgPA)"
Received: from [17.235.222.136] (unknown [17.235.222.136]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OT800BSABRY0K50@phonehome3.euro.apple.com>; Mon, 17 Jul 2017 11:00:00 +0100 (IST)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: <5CA17A3A-5F25-4C26-BF08-3A9C117CE333@apple.com>
Date: Mon, 17 Jul 2017 11:59:56 +0200
In-reply-to: <4DDD221A-B9AA-4F47-9B15-DD58CEBE6584@consulintel.es>
Cc: IPv6 Ops WG , Randy Bush , Russ Housley , Suresh Krishnan , Alissa Cooper , Jim Martin 
To: jordi.palet@consulintel.es
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@apple.com> <4DDD221A-B9AA-4F47-9B15-DD58CEBE6584@consulintel.es>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUi6GTOo7ugKyfS4OU/HYvpZ/4yWrx6cZPd 4toRZou/xz8zWzxrfclkcWTDWVaL08f2Mjuwe6zbH+Dx5clLJo+uj5eZPHbOusvusWTJTyaP qTNnM3qsuvOFNYA9issmJTUnsyy1SN8ugSvjZcMWpoKFW5gqvq/5ytbA2NDP1MXIwSEhYCIx 77J9FyMXh5DAdiaJw3vns3UxcoLF70+cwgiROMQo0fbhJwtIgldAUOLH5HtgNrNAmMSn26eZ IIqmM0nca/jNDpIQFpCW6LpwlxVkA5uAlsSBNUYQvTYSZyY2M0OUBEhsuXoArJxFQFXixdHf YIs5BZwkWnrPsYLMZBa4xijx5187WEJEQE7i7opWqIvOskk0nPnOCHGqrMSt2ZeYIezXbBL/ tupPYBSaheTYWUiOnQV0E7OAusSUKbkQYW2JJ+8usELYahILfy9iQhZfwMi2ilE8NzEzRzcz z0gvtbQoXy+xoCAnVS85P3cTIyjyPKbw7GC8eNDwEKMAB6MSD29snG+kEGtiWXFlLjDgOJiV RHh7gnMihXhTEiurUovy44tKc1KLDzFKc7AoifOalMpHCgmkJ5akZqemFqQWwWSZODilGhhD ejku/8p7of+bo5Nd7atXlMup3qrrqfaqt8L8HD6LFFpOm9592itKJlAq4Lcn4539u6/EXP63 QpD5z1n1w/zXc2Iup10+oFYc/M+U85zS01oln5T0i0f0/PXlt1VX2diGLtX5fK9C/s7G5ANv ZbuYOLdsfLLcJ7x1gZpl4lEnIR+2nUrOqkosxRmJhlrMRcWJABatZzO4AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUi6NEarLugKyfSYGejpsX0M38ZLV69uMlu ce0Is8Xf45+ZLZ61vmSyOLLhLKvF6WN7mR3YPdbtD/D48uQlk0fXx8tMHjtn3WX3WLLkJ5PH 1JmzGT1W3fnCGsAexWWTkpqTWZZapG+XwJXxsmELU8HCLUwV39d8ZWtgbOhn6mLk5JAQMJG4 P3EKYxcjF4eQwCFGibYPP1lAErwCghI/Jt8Ds5kFwiQ+3T7NBFE0nUniXsNvdpCEsIC0RNeF u6xdjBwcbAJaEgfWGEH02kicmdjMDFESILHl6gGwchYBVYkXR3+zgdicAk4SLb3nWEFmMgtc Y5T4868dLCEiICdxd0Ur1EVn2SQaznxnhDhVVuLW7EvMExj5ZyE5cBaSA2cB3cEsoC4xZUou RFhb4sm7C6wQtprEwt+LmJDFFzCyrWIULUrNSaw00kstLcrXSywoyEnVS87P3cQIihYnc54d jK8OGh5iFOBgVOLhVWnMiRRiTSwrrswFBhUHs5IIb08wUIg3JbGyKrUoP76oNCe1+BCjNAeL kjhvwcOISCGB9MSS1OzU1ILUIpgsEwenVAOjpeo2T65jTrtUKnfms/FuF2FoNFm4UPfovjVH 7oscvXWl5ew/kcUzbFieJVmtMzzxly/s19/N8nP+nPiT2a1/XDh0yr+1vIJqL1lfhfgphLyz WBhcd/ilp6jQ0X0fct1abtkd11d6I2bBlSPhHz/Z1GLzm/+MD0+k3mqNlNc/car3Yf17y6/L lFiKMxINtZiLihMB4J9MDpICAAA=
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:00:05 -0000

--Boundary_(ID_o9TmgTeKI/Z3WO/oWHOgPA)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

I absolutely agree that automatic issue detection is better.
However I fail to see how you automatically go from CLAT logs to
knowing there is an issue with a specific piece of software.
This is a problem that we tried to solve in the past and there is no =
silver bullet.

As such, I think relying on IETF attendees to check whether their own =
software works has great value.

David


> On Jul 17, 2017, at 11:52, JORDI PALET MARTINEZ =
 wrote:
>=20
>=20
> Definitively get them fixed, and towards that we need to identify =
them. We want to identify them =E2=80=9Cmanually=E2=80=9D or =
=E2=80=9Cautomatically=E2=80=9D? I think automatically will work much =
better. Manually means people may report the first failure, then switch =
to the fall back network =E2=80=A6
>=20
> CLAT can be run in a VM (for example using Jool). I=E2=80=99ve done =
it.
>=20
> I=E2=80=99m not a software developer, but Jool provides some logging =
tools, it is just a matter to get our hands on it.
>=20
> There may be other CLAT implementations that can be used. I think Jool =
is very powerful, take advantage of multiple cores, etc.
>=20
> Regards,
> Jordi
>=20
>=20
> -----Mensaje original-----
> De: > en nombre de =
David Schinazi >
> Responder a: >
> Fecha: lunes, 17 de julio de 2017, 11:48
> Para: >
> CC: IPv6 Ops WG >, Randy Bush =
>, Alissa Cooper >, Suresh Krishnan >, Russ Housley >, Jim Martin >
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
>=20
>=20
>=20
>> On Jul 17, 2017, at 11:41, JORDI PALET MARTINEZ =
 wrote:
>>=20
>> I=E2=80=99ve investigated this with OpenVPN right now using the =
ietf-nat64 SSID.
>>=20
>> The remote OpenVPN server is IPv4-only, has a domain name (so not =
using literals), however, it seems the name is resolved to the IPv4-only =
address (maybe not using Apple Sierra OS =E2=80=93 latest version- all =
updated- system APIs), so it fails to work with the NAT64.
>>=20
>> I=E2=80=99m sure there are many other apps that have the same =
problem, it is very unfortunate, I wish programmers do it right and use =
the systems APIs (and no literals) that make it work, but this is not =
the case in the real world.
>=20
>    Should we then give up on IPv6 or try to get these fixed?
>=20
>> The point here is again: Manually asking the participants that get =
something broken to report it, doesn=E2=80=99t work, while having an =
automated way to report what is using the CLAT is a much lower effort =
(actually none for the participants).
>=20
>    Which "automated way to report what is [broken] using the CLAT" =
software are you referring to?
>=20
>=20
>=20
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es 
> The IPv6 Company
>=20
> This electronic message contains information which may be privileged =
or confidential. 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 disclosure, copying, distribution or use of the contents =
of this information, including attached files, is prohibited.
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org 
> https://www.ietf.org/mailman/listinfo/v6ops =


--Boundary_(ID_o9TmgTeKI/Z3WO/oWHOgPA)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

I absolutely agree that automatic issue detection is =
better.
However I fail to see how you automatically go =
from CLAT logs to
knowing there is an issue with a =
specific piece of software.
This is a problem that =
we tried to solve in the past and there is no silver bullet.

As such, I think relying =
on IETF attendees to check whether their own software works has great =
value.

David


On Jul 17, 2017, at 11:52, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:


Definitively get them fixed, and towards that we =
need to identify them. We want to identify them =E2=80=9Cmanually=E2=80=9D=
 or =E2=80=9Cautomatically=E2=80=9D? I think automatically will work =
much better. Manually means people may report the first failure, then =
switch to the fall back network =E2=80=A6

CLAT can be run in a VM (for example using =
Jool). I=E2=80=99ve done it.

I=E2=80=99m not a software developer, but Jool =
provides some logging tools, it is just a matter to get our hands on =
it.

There may be other CLAT =
implementations that can be used. I think Jool is very powerful, take =
advantage of multiple cores, etc.

Regards,
Jordi
-----Mensaje original-----
De: <dschinazi@apple.com> en nombre de David Schinazi =
<dschinazi@apple.com>
Responder a: <dschinazi@apple.com>
Fecha: lunes, 17 de julio de 2017, =
11:48
Para: <jordi.palet@consulintel.es>
CC: IPv6 Ops WG <v6ops@ietf.org>, Randy Bush <randy@psg.com>, Alissa Cooper =
<alissa@cooperw.in>, Suresh Krishnan =
<suresh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Jim Martin <jim@daedelus.com>
Asunto: Re: [v6ops] Incremental Deployment of =
IPv6-only Wi-Fi for IETF Meetings

On Jul 17, 2017, at 11:41, =
JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

I=E2=80=99ve investigated this with OpenVPN right now using =
the ietf-nat64 SSID.

The remote OpenVPN =
server is IPv4-only, has a domain name (so not using literals), however, =
it seems the name is resolved to the IPv4-only address (maybe not using =
Apple Sierra OS =E2=80=93 latest version- all updated- system APIs), so =
it fails to work with the NAT64.

I=E2=80=99m =
sure there are many other apps that have the same problem, it is very =
unfortunate, I wish programmers do it right and use the systems APIs =
(and no literals) that make it work, but this is not the case in the =
real world.

   Should we then =
give up on IPv6 or try to get these fixed?

The point here is again: =
Manually asking the participants that get something broken to report it, =
doesn=E2=80=99t work, while having an automated way to report what is =
using the CLAT is a much lower effort (actually none for the =
participants).

   Which =
"automated way to report what is [broken] using the CLAT" software are =
you referring to?


**********************************************
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 confidential. 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 disclosure, copying, distribution =
or use of the contents of this information, including attached files, is =
prohibited.


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

=

--Boundary_(ID_o9TmgTeKI/Z3WO/oWHOgPA)--


From nobody Mon Jul 17 03:02:53 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767D212EB99 for ; Mon, 17 Jul 2017 03:02:51 -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 UJjCnYgv92Eb for ; Mon, 17 Jul 2017 03:02:49 -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 EEBBA1276AF for ; Mon, 17 Jul 2017 03:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500285766; x=1500890566; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Fe6UEax7sUHtrSHlyLQPrv4nd wV/yBuQ59ZGxkVofF0=; b=c1j2zxQF6mGGzFAzMXBp8RQtED2qrEmSr+M6lzW85 bqR4ys+oCJvX9ESBCKvT5Y727su8Bv3OtENeQtlxBtoYEEreuLpqX3smY/P6dE9i QM1HPqWGWoM9J4wxoFJkXUFkV/8kAHgEq8+FG+ZR6vmjEhEttw+K8hOqPoeegtaF Og=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=P5mhBWGqvLPx37Z6oRybTkRNqWUUSSuNSmRhjqqWb8/6Qp3YSz1pm7pTbroh 32iDtP78JV/05q2kUtGp2DkgOuu952VmnJQEt8rqinMs2a25HG7Jj9b1n yA0apLV3pgxMO9gti/wdi6yu0E7qoS71M3GArRE3pGo+D5vO5vNLQ8=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 12:02:46 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 12:02:45 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478306.msg for ; Mon, 17 Jul 2017 12:02:44 +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:170717:md50005478306::oQdUVSR1PoF6/TVZ:00003jdm
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 12:02:37 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Russ Housley , Suresh Krishnan , Alissa Cooper , Jim Martin 
Message-ID: <3FEF5EC2-512C-4080-BA45-78E84585BC4F@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <38B8160E-1DFC-423E-AB9E-2CDD64BF50AD@apple.com> <4DDD221A-B9AA-4F47-9B15-DD58CEBE6584@consulintel.es> <5CA17A3A-5F25-4C26-BF08-3A9C117CE333@apple.com>
In-Reply-To: <5CA17A3A-5F25-4C26-BF08-3A9C117CE333@apple.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:02:51 -0000

Everything that goes thru the CLAT means is failing to go thru the NAT64, s=
o reporting all by default in the CLAT will make it.

The logs tell us the data that we need to identify the apps, and I think it=
 could be automated with some scripts.

Regards,
Jordi
=20

-----Mensaje original-----
De:  en nombre de David Schinazi 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 12:00
Para: 
CC: IPv6 Ops WG , Randy Bush , Russ Housley =
, Suresh Krishnan , Alissa=
 Cooper , Jim Martin 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    I absolutely agree that automatic issue detection is better.However I f=
ail to see how you automatically go from CLAT logs to
    knowing there is an issue with a specific piece of software.
    This is a problem that we tried to solve in the past and there is no si=
lver bullet.
   =20
    As such, I think relying on IETF attendees to check whether their own s=
oftware works has great value.
   =20
    David
   =20
   =20
   =20
    On Jul 17, 2017, at 11:52, JORDI PALET MARTINEZ  wrote:
   =20
   =20
    Definitively get them fixed, and towards that we need to identify them.=
 We want to identify them =E2=80=9Cmanually=E2=80=9D or =E2=80=9Cautomatica=
lly=E2=80=9D? I think automatically will work much better. Manually means p=
eople may report the first failure, then switch to the fall back network =
=E2=80=A6
   =20
    CLAT can be run in a VM (for example using Jool). I=E2=80=99ve done it.
   =20
    I=E2=80=99m not a software developer, but Jool provides some logging to=
ols, it is just a matter to get our hands on it.
   =20
    There may be other CLAT implementations that can be used. I think Jool =
is very powerful, take advantage of multiple cores, etc.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De:  en nombre de David Schinazi 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 11:48
    Para: 
    CC: IPv6 Ops WG , Randy Bush , Alissa Co=
oper , Suresh Krishnan , Russ=
 Housley , Jim Martin 
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
   =20
   =20
   =20
   =20
    On Jul 17, 2017, at 11:41, JORDI PALET MARTINEZ  wrote:
   =20
    I=E2=80=99ve investigated this with OpenVPN right now using the ietf-na=
t64 SSID.
   =20
    The remote OpenVPN server is IPv4-only, has a domain name (so not using=
 literals), however, it seems the name is resolved to the IPv4-only address=
 (maybe not using Apple Sierra OS =E2=80=93 latest version- all updated- sy=
stem APIs), so it fails to work with the NAT64.
   =20
    I=E2=80=99m sure there are many other apps that have the same problem, =
it is very unfortunate, I wish programmers do it right and use the systems =
APIs (and no literals) that make it work, but this is not the case in the r=
eal world.
   =20
   =20
   =20
       Should we then give up on IPv6 or try to get these fixed?
   =20
   =20
    The point here is again: Manually asking the participants that get some=
thing broken to report it, doesn=E2=80=99t work, while having an automated =
way to report what is using the CLAT is a much lower effort (actually none =
for the participants).
   =20
   =20
   =20
       Which "automated way to report what is [broken] using the CLAT" soft=
ware are you referring to?
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es 
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or use of the contents of this informati=
on, including attached files, is prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =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 Mon Jul 17 03:04:48 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBCD131771 for ; Mon, 17 Jul 2017 03:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xbygmsHr6CWz for ; Mon, 17 Jul 2017 03:04:38 -0700 (PDT)
Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFECC12F28A for ; Mon, 17 Jul 2017 03:04:38 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=53196 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dX2tI-00013g-VB; Mon, 17 Jul 2017 12:04:36 +0200
Date: Mon, 17 Jul 2017 12:04:36 +0200
From: Tore Anderson 
To: jordi.palet@consulintel.es
Cc: v6ops@ietf.org
Message-ID: <20170717120436.598ca19e@echo.ms.redpill-linpro.com>
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com> 
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:04:43 -0000

* JORDI PALET MARTINEZ 

> I=E2=80=99ve investigated this with OpenVPN right now using the ietf-nat64
> SSID.
>=20
> The remote OpenVPN server is IPv4-only, has a domain name (so not
> using literals), however, it seems the name is resolved to the
> IPv4-only address (maybe not using Apple Sierra OS =E2=80=93 latest versi=
on-
> all updated- system APIs), so it fails to work with the NAT64.

Which OpenVPN version is this? If you're not running v2.4.0 or newer,
try upgrading. I believe this this have improved there, cf.
https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst:

[...]

  Dualstack round-robin DNS client connect
    Instead of only using the first address of each --remote OpenVPN
    will now try all addresses (IPv6 and IPv4) of a --remote entry.

[...]

  * proto udp and proto tcp now use both IPv4 and IPv6. The new options
    proto udp4 and proto tcp4 use IPv4 only.

Tore


From nobody Mon Jul 17 03:18:34 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090C61270B4 for ; Mon, 17 Jul 2017 03:18:33 -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=neo-co-tz.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 fMj9VOoYj23V for ; Mon, 17 Jul 2017 03:18:31 -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 D6A3F1252BA for ; Mon, 17 Jul 2017 03:18:30 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id w126so71309564wme.0 for ; Mon, 17 Jul 2017 03:18:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fULRA+Lxxnh+cTwyCGKueHpoTK/pCAi7ixkHj/BQ+gI=; b=Zawh+WH+zs2DI4SHUYeSQ+V6IDzvqfRfNeT5P4bI5p06FFDkMfo3EjjvHkIZOHK4UR gT1AoZkMBEQQVkiwBWMxDitXkxf4zOCu7ayR7qkKrWcCOzhJBzKO4hOFW5n8GjTXrGTE IeqwQODqt2vBTjSQ1ZScNEMvta4AIE3lGEbNM49PNS7E4eR0foey0jE5JNvvrddWJZQq nwnSUv1651Ovh/+nWehKPeaILupWqFu7om6h0CmwSF/pop1xunBzYncJKczjxUsydVNV RvONJDLrEeoU9woso1QFQ4uXhHLmLZtJbwb/o1HMGbscV47z/opLwcihltJ/eNr61nKV FLLA==
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=fULRA+Lxxnh+cTwyCGKueHpoTK/pCAi7ixkHj/BQ+gI=; b=bHl4UxZiQpSrV3mvx1alMziYsC1Ru33O5j5gAm2IzTqP0g4vixrK4d+knaUR+RYDEx Wv2TyiS4EyRBopnut4q4/aSQtvD6kO1Jua5nOKTz+EFyTmxF0KQmwvlqWP1IVed9dniM wjbYtyf44ZvFILfEk4Bjy2wSv79s6sdll46+gd+uy51cy1UXrwBCaP+5+EUX8Gsmcfp5 Z12WWqjyCVj9R4F1TsuuCnLPKa9aFjivZtTjZrrc4nsdUvORVj4IkSlY3ZIqNO9aUAAD 2sNxBaHPdVtEblgrueqDLW7HU1ctzROKII/rU6dUN+aGhKPxIHz0YQff/2/nf8g8Hkel i8ww==
X-Gm-Message-State: AIVw110U/p0etoc7GVTMPuL4heZYk0ucoLNnSLNttHAYuNbNiYmJ1J85 DJr9A3YrvaaQS2JRUeD1/INd/sLCFlN8QqI=
X-Received: by 10.28.214.133 with SMTP id n127mr3699975wmg.16.1500286709319; Mon, 17 Jul 2017 03:18:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.206.4 with HTTP; Mon, 17 Jul 2017 03:18:27 -0700 (PDT)
X-Originating-IP: [105.28.32.9]
Received: by 10.28.206.4 with HTTP; Mon, 17 Jul 2017 03:18:27 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> 
From: Noah 
Date: Mon, 17 Jul 2017 13:18:27 +0300
Message-ID: 
To: Mark Elkins 
Cc: v6ops@ietf.org
Content-Type: multipart/alternative; boundary="001a114741945eeda3055480b8bd"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:18:33 -0000

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

On 17 Jul 2017 11:36 a.m., "Mark Elkins"  wrote:



I'm personally advocating having future "IPv6 only" AfriNIC meetings
though this may end up being just for a single day.


+1 Elkins

And perhaps the upcoming meeting in November and hence forth but will
depend on the upstream provider sponsoring the connectivity.

Let us walk the talk folks.

Noah

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




On 17 Jul 2017 11:36 a.m., "Mark Elkins" <mje@posix.co.za> wrote:




I'm personally advocating having future "IPv6 only" AfriNIC m=
eetings

though this may end up being just for a single day.

+1 Elkins

And perhaps the upcoming meeting in =
November and hence forth but will depend on the upstream provider sponsorin=
g the connectivity.

Let =
us walk the talk folks.

=
Noah


--001a114741945eeda3055480b8bd--


From nobody Mon Jul 17 03:23:23 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A64129B5B for ; Mon, 17 Jul 2017 03:23:22 -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 lvjwVrXkzNno for ; Mon, 17 Jul 2017 03:23:20 -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 555DB1252BA for ; Mon, 17 Jul 2017 03:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500286998; x=1500891798; 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=OpZ0yVn0Ugo2n3vAV4BLxg1sU x3jKBggZPNgZc1P65o=; b=D9tTnvotqgayj3ZfCuaGtDjV+HJ3lX42U2SXqySas rHOMuDjXoyfx07ooW9YH9yi2WB7tF+I92uYA43nz/IAj+BJvrTVoMDuRf+UphZAr rgvwkEV3nL4paB68n8KJfVdwo6TcNWko/0WS3epLZdQ3zlU/wTTD/RQkPYA1CPLe fM=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=axDiKM0HYmf9WClLzY60L1dHTyTNXe2X+/wz6rbRHmL9+hBN89ZSJ4SNMHWw CgIHBBWTTnJQ0+IRoMQdrjI/pvUWByHkwQcM0GhNfom+ne5nZ3qvsURMa v+13WYjsE6glvmAlKJgZ/xtT5QgmxnEGukS/zl3ySemtdf+adRSiT4=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 12:23:18 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 12:23:17 +0200
Received: from [31.133.186.43] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478338.msg for ; Mon, 17 Jul 2017 12:23:16 +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:170717:md50005478338::61JGTXftdqeRYmIL:0000BUMA
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 12:23:13 +0200
From: JORDI PALET MARTINEZ 
To: 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <20170717120436.598ca19e@echo.ms.redpill-linpro.com>
In-Reply-To: <20170717120436.598ca19e@echo.ms.redpill-linpro.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:23:22 -0000

Using latest version, both at the server and client. I will check later wha=
t specific version on both sides, but they are using >2.4.2 for sure.

Regards,
Jordi
=20

-----Mensaje original-----
De: Tore Anderson 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 12:04
Para: 
CC: 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    * JORDI PALET MARTINEZ 
   =20
    > I=E2=80=99ve investigated this with OpenVPN right now using the ietf-=
nat64
    > SSID.
    >=20
    > The remote OpenVPN server is IPv4-only, has a domain name (so not
    > using literals), however, it seems the name is resolved to the
    > IPv4-only address (maybe not using Apple Sierra OS =E2=80=93 latest v=
ersion-
    > all updated- system APIs), so it fails to work with the NAT64.
   =20
    Which OpenVPN version is this? If you're not running v2.4.0 or newer,
    try upgrading. I believe this this have improved there, cf.
    https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst:
   =20
    [...]
   =20
      Dualstack round-robin DNS client connect
        Instead of only using the first address of each --remote OpenVPN
        will now try all addresses (IPv6 and IPv4) of a --remote entry.
   =20
    [...]
   =20
      * proto udp and proto tcp now use both IPv4 and IPv6. The new options
        proto udp4 and proto tcp4 use IPv4 only.
   =20
    Tore
   =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 Mon Jul 17 03:26:57 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEA8131838 for ; Mon, 17 Jul 2017 03:26:56 -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, 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=fugue-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 y6ssej0m7AVz for ; Mon, 17 Jul 2017 03:26:54 -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 871C81317D5 for ; Mon, 17 Jul 2017 03:26:44 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id e199so13323819pfh.2 for ; Mon, 17 Jul 2017 03:26:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vl91t5ih0fA5vnLcf+H1hjRL4EzZxVkx9EHGa9UFbVk=; b=HdkPuF44YVx9ax+BOLk3nGOOpBlPA/T+ZlxQaEXg05z++X2ZHhocG2tLZAcTNp+QSa iMYufP2jLGN8dyPqpu0d8/gw2Jm069SP/G0q+0WDjdk9LVz8+6yqyWVsDuhSVVzYJzrb ZM6/U92TKt7reMDuEQ+1nsdZww6MBeqJJ7OAa61jPMRJ09EoGZTvKCHYYbUgPVBoAOPG ayyXKNbq9twdSs48g3yCKXnPszEnicZGoWFVNR3RgAn2ioOrXdHeMGghfoQa847lwqzr SLlhB7kMQkmmpBqlVcJx43rufgmfGV+uiQdIviQ50SL59FWixcMJptt+/v7l7EqdiJym sJzw==
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=Vl91t5ih0fA5vnLcf+H1hjRL4EzZxVkx9EHGa9UFbVk=; b=g2ZldZBSMe/w7iNMrSFgYT70xNd4fIAHD7PLphKciB8XjmRL9h06BsZypaUzCbDvTW o7nm0Av2q15jv2F49hnIJNuhJJuyUO3Dek4vYcfb5BKNP6HVGGjoGlgjwvvhEcntaLTL mYeTE9Ltu6fGBd72/j/IEh+wdxD9uyEi++/j58h+Li+JGXgkBfrCPaUS1J/MA/cEfwG7 P1dy2JsDRqv8XiuRl68qXwgJQqRrq50kNQ/ikeEmdoHkMi8Ozo6Xa2yrl/81dTnNan9s k9dp6O/HqzSqZrQjVqmOAP+QJG5vbaslJnWZjHTPr77symdQ//5sXHPYPpB992lv7GKQ dC5w==
X-Gm-Message-State: AIVw113qU56kmxC7MGLL0lDS5MfQ8jwu+dvaIUGEqtvXNAG3ZlVNIYMI 2iFLhNZ65CMWke7Ai6j9EOpH2AS1dk3U
X-Received: by 10.98.193.68 with SMTP id i65mr3855371pfg.142.1500287203837; Mon, 17 Jul 2017 03:26:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 03:26:03 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <20170717120436.598ca19e@echo.ms.redpill-linpro.com> 
From: Ted Lemon 
Date: Mon, 17 Jul 2017 12:26:03 +0200
Message-ID: 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="94eb2c184720d8b50c055480d526"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:26:56 -0000

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

OpenVPN requires that the client be configured to use either IPv4 or IPv6.
  If you configure the client to use IPv6, it will work just fine through
NAT64 to an IPv4 OpenVPN server.   This is an unfortunate limitation of
OpenVPN; the maintainers are aware of it, but apparently it's not a
priority to fix. :(

On Mon, Jul 17, 2017 at 12:23 PM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> Using latest version, both at the server and client. I will check later
> what specific version on both sides, but they are using >2.4.2 for sure.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: Tore Anderson 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 12:04
> Para: 
> CC: 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
>
>     * JORDI PALET MARTINEZ 
>
>     > I=E2=80=99ve investigated this with OpenVPN right now using the iet=
f-nat64
>     > SSID.
>     >
>     > The remote OpenVPN server is IPv4-only, has a domain name (so not
>     > using literals), however, it seems the name is resolved to the
>     > IPv4-only address (maybe not using Apple Sierra OS =E2=80=93 latest=
 version-
>     > all updated- system APIs), so it fails to work with the NAT64.
>
>     Which OpenVPN version is this? If you're not running v2.4.0 or newer,
>     try upgrading. I believe this this have improved there, cf.
>     https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst:
>
>     [...]
>
>       Dualstack round-robin DNS client connect
>         Instead of only using the first address of each --remote OpenVPN
>         will now try all addresses (IPv6 and IPv4) of a --remote entry.
>
>     [...]
>
>       * proto udp and proto tcp now use both IPv4 and IPv6. The new optio=
ns
>         proto udp4 and proto tcp4 use IPv4 only.
>
>     Tore
>
>
>
>
> **********************************************
> 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
> confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


OpenVPN requires that the client be configured to use eith=
er IPv4 or IPv6. =C2=A0 If you configure the client to use IPv6, it will wo=
rk just fine through NAT64 to an IPv4 OpenVPN server. =C2=A0 This is an unf=
ortunate limitation of OpenVPN; the maintainers are aware of it, but appare=
ntly it's not a priority to fix. :(
On Mon, Jul 17, 2017 at 12:23 PM, JORDI PALET M=
ARTINEZ <jordi.palet@consulintel.es> wrote:
Using latest version, both at the server and cli=
ent. I will check later what specific version on both sides, but they are u=
sing >2.4.2 for sure.



Regards,

Jordi





-----Mensaje original-----

De: Tore Anderson <tore@=
fud.no>

Responder a: <tore@fud.no>

Fecha: lunes, 17 de julio de 2017, 12:04

Para: <jordi.palet@consuli=
ntel.es>

CC: <v6ops@ietf.org>

Asunto: Re: [v6ops] Incremental Deployment of IPv=
6-only Wi-Fi for IETF Meetings



=C2=A0 =C2=A0 * JORDI PALET MARTINEZ <<=
a href=3D"mailto:jordi.palet@consulintel.es">jordi.palet@consulintel.es=
>



=C2=A0 =C2=A0 > I=E2=80=99ve investigated this with OpenVPN right now us=
ing the ietf-nat64

=C2=A0 =C2=A0 > SSID.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > The remote OpenVPN server is IPv4-only, has a domain nam=
e (so not

=C2=A0 =C2=A0 > using literals), however, it seems the name is resolved =
to the

=C2=A0 =C2=A0 > IPv4-only address (maybe not using Apple Sierra OS =E2=
=80=93 latest version-

=C2=A0 =C2=A0 > all updated- system APIs), so it fails to work with the =
NAT64.



=C2=A0 =C2=A0 Which OpenVPN version is this? If you're not running v2.4=
.0 or newer,

=C2=A0 =C2=A0 try upgrading. I believe this this have improved there, cf.
=C2=A0 =C2=A0 https://github.com/Open=
VPN/openvpn/blob/release/2.4/Changes.rst:



=C2=A0 =C2=A0 [...]



=C2=A0 =C2=A0 =C2=A0 Dualstack round-robin DNS client connect

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Instead of only using the first address of each=
 --remote OpenVPN

=C2=A0 =C2=A0 =C2=A0 =C2=A0 will now try all addresses (IPv6 and IPv4) of a=
 --remote entry.



=C2=A0 =C2=A0 [...]



=C2=A0 =C2=A0 =C2=A0 * proto udp and proto tcp now use both IPv4 and IPv6. =
The new options

=C2=A0 =C2=A0 =C2=A0 =C2=A0 proto udp4 and proto tcp4 use IPv4 only.



=C2=A0 =C2=A0 Tore









*************************************=
*********

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.








____________________________=
___________________

v6ops mailing list

v6ops@ietf.org

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





--94eb2c184720d8b50c055480d526--


From nobody Mon Jul 17 03:43:01 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B30131B06 for ; Mon, 17 Jul 2017 03:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL0HskuL8Nv1 for ; Mon, 17 Jul 2017 03:42:56 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE7A131B1A for ; Mon, 17 Jul 2017 03:42:56 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A9F7741BEC for ; Mon, 17 Jul 2017 12:42:53 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6CBF641B72; Mon, 17 Jul 2017 12:42:53 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 68B759058; Mon, 17 Jul 2017 12:42:53 +0200 (CEST)
Date: Mon, 17 Jul 2017 12:42:53 +0200
From: Gert Doering 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Randy Bush , Alissa Cooper , Suresh Krishnan , Russ Housley , Jim Martin 
Message-ID: <20170717104253.GM45648@Space.Net>
References:   <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:42:59 -0000

Hi,

On Mon, Jul 17, 2017 at 11:41:20AM +0200, JORDI PALET MARTINEZ wrote:
> I???ve investigated this with OpenVPN right now using the ietf-nat64 SSID.
> 
> The remote OpenVPN server is IPv4-only, has a domain name (so not using literals), however, it seems the name is resolved to the IPv4-only address (maybe not using Apple Sierra OS ??? latest version- all updated- system APIs), so it fails to work with the NAT64.

The openvpn client in version 2.3.x is "dual single-stacked" - it will
not ask for a v6 address unless it's told to use ipv6 (in which case it
will not ask for a v4 address).  This obviously stinks, but you need
test setups like this to find out where it stinks.

Since this was found a few years ago at a RIPE meeting in the IPv6-only
network already, OpenVPN 2.4.x has been fixed, and will now do the right
thing ("call getaddrinfo() and use all addresses returned in the order
presented by the host OS").

Please upgrade your client :-)

> I???m sure there are many other apps that have the same problem, it is very unfortunate, I wish programmers do it right and use the systems APIs (and no literals) that make it work, but this is not the case in the real world.
> 
> The point here is again: Manually asking the participants that get something broken to report it, doesn???t work, while having an automated way to report what is using the CLAT is a much lower effort (actually none for the participants).

So how would the CLAT know that it's openvpn that is broken, and what
are meeting ops supposed to do with the result?

No, the breakage must be visible on the host that has broken software
installed, otherwise people will continue to just not care.

> I guess many folks use OpenVPN, so it may be the case that many have the same problem. May be it happens the same with other VPN apps.

OpenVPN is a good example, because the problem was found due to usage of
IPv6-only networks, fixed, and now just lingers because people continue
to use old versions...

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

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


From nobody Mon Jul 17 03:44:16 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811A6131AAF for ; Mon, 17 Jul 2017 03:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHsxWri1LZF8 for ; Mon, 17 Jul 2017 03:44:13 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B44A1319B4 for ; Mon, 17 Jul 2017 03:44:13 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0AB4141B94 for ; Mon, 17 Jul 2017 12:44:12 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D677741B72; Mon, 17 Jul 2017 12:44:11 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id D351B9068; Mon, 17 Jul 2017 12:44:11 +0200 (CEST)
Date: Mon, 17 Jul 2017 12:44:11 +0200
From: Gert Doering 
To: JORDI PALET MARTINEZ 
Cc: v6ops@ietf.org
Message-ID: <20170717104411.GN45648@Space.Net>
References: <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <20170717120436.598ca19e@echo.ms.redpill-linpro.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:44:14 -0000

Hi,

On Mon, Jul 17, 2017 at 12:23:13PM +0200, JORDI PALET MARTINEZ wrote:
> Using latest version, both at the server and client. I will check later what specific version on both sides, but they are using >2.4.2 for sure.

In which case the observed behaviour would only happen if you force
the client to IPv4-only by means of "proto udp4".

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

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


From nobody Mon Jul 17 03:45:43 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB99131AAF for ; Mon, 17 Jul 2017 03:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6atY-2kimgJ for ; Mon, 17 Jul 2017 03:45:41 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CD7131B1F for ; Mon, 17 Jul 2017 03:45:40 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 175DD41B94 for ; Mon, 17 Jul 2017 12:45:39 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E4DE441B72; Mon, 17 Jul 2017 12:45:38 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id DCDDE9081; Mon, 17 Jul 2017 12:45:38 +0200 (CEST)
Date: Mon, 17 Jul 2017 12:45:38 +0200
From: Gert Doering 
To: Ted Lemon 
Cc: JORDI PALET MARTINEZ , IPv6 Ops WG 
Message-ID: <20170717104538.GO45648@Space.Net>
References:   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <20170717120436.598ca19e@echo.ms.redpill-linpro.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 10:45:42 -0000

Hi,

On Mon, Jul 17, 2017 at 12:26:03PM +0200, Ted Lemon wrote:
> OpenVPN requires that the client be configured to use either IPv4 or IPv6.
>   If you configure the client to use IPv6, it will work just fine through
> NAT64 to an IPv4 OpenVPN server.   This is an unfortunate limitation of
> OpenVPN; the maintainers are aware of it, but apparently it's not a
> priority to fix. :(

It has been fixed two years ago, and a formal release containing the
proper code has been made last December (2.4.0).

If there is anything still wrong in 2.4.x regarding dual-stack client
behaviour, I'd very much like to know.

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

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


From nobody Mon Jul 17 04:32:47 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA131318A8 for ; Mon, 17 Jul 2017 04:32: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, 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 ioy5_u3Lq1f0 for ; Mon, 17 Jul 2017 04:32:44 -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 B05781288B8 for ; Mon, 17 Jul 2017 04:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500291162; x=1500895962; 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=41Dek7i8YLdCXpP7FFZMDh9Xw CrpoxC5z8qayZOPjs4=; b=JfSzY/Odb+Nl4cqG5OXWFsXTiATnnjIrvdXQUf+7a 3025QeuTXaH6MyMHSQ4LOAs5/mR4K/SwANCiAo/0tvT5zZEiz0z+syyPePHi9DX8 fVRQyvmblJfBwqu3vhC6yTlZ5i1wroD1z4EmGeoRdSlI5qD5azE45zDlgsrCVGRa JM=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Z/+p6VDwdZI2FwVo4d42RNnMB034BhpevWHk3MRVVKm2NTbyJLl4H7MFM4u+ NvKDWnJ0142r9ncVdaP6D60CB1zX1300r6eF3T/M3B/J7fApkCgXSzZmI c/tFqNLvor3GbNwce3gTrjO+lRNq4FtwBJ4ZXspVPOflFmg7KaLk8E=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 13:32:42 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 13:32:41 +0200
Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478404.msg for ; Mon, 17 Jul 2017 13:32:39 +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:170717:md50005478404::B8q5ckFFqi1YJk7J:0000Cb1j
X-MDRemoteIP: 31.133.142.45
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 13:32:35 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
Message-ID: <1EA41531-B9F2-481B-BD59-8925DF84B49E@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <20170717120436.598ca19e@echo.ms.redpill-linpro.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 11:32:46 -0000

Responding also to Gert.

I just tried again, no need to upgrade the client or server, as both of the=
m were running the latest available versions.

As you said, it is a =E2=80=9Cstrange=E2=80=9D configuration =E2=80=9Clangu=
age=E2=80=9D. Even if you don=E2=80=99t have the server with IPv6, it needs=
 to be enabled in both sides to work thru a NAT64.

Of course, this means we =E2=80=9Cthechies=E2=80=9D find the work around wi=
th some help from others that already suffered the problem, but a regular u=
ser not. If we were running CLAT, it just works and the most important, we =
get it reported/logged automatically, which is what I=E2=80=99m insisting o=
n.

However =E2=80=A6. I=E2=80=99m still on the ietf-nat64 and Outlook (last re=
lease 15.36) for Mac refuses to send this message. I need to turn to anothe=
r SSID to keep working thru the meeting. This is what we want?

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 12:27
Para: JORDI PALET MARTINEZ 
CC: IPv6 Ops WG 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    OpenVPN requires that the client be configured to use either IPv4 or IP=
v6.   If you configure the client to use IPv6, it will work just fine throu=
gh NAT64 to an IPv4 OpenVPN server.   This is an unfortunate limitation of =
OpenVPN; the maintainers are aware of it, but apparently it's not a priorit=
y to fix. :(
   =20
    On Mon, Jul 17, 2017 at 12:23 PM, JORDI PALET MARTINEZ  wrote:
   =20
    Using latest version, both at the server and client. I will check later=
 what specific version on both sides, but they are using >2.4.2 for sure.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De: Tore Anderson 
    Responder a: 
    Fecha: lunes, 17 de julio de 2017, 12:04
    Para: 
    CC: 
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
   =20
        * JORDI PALET MARTINEZ 
   =20
        > I=E2=80=99ve investigated this with OpenVPN right now using the i=
etf-nat64
        > SSID.
        >
        > The remote OpenVPN server is IPv4-only, has a domain name (so not
        > using literals), however, it seems the name is resolved to the
        > IPv4-only address (maybe not using Apple Sierra OS =E2=80=93 late=
st version-
        > all updated- system APIs), so it fails to work with the NAT64.
   =20
        Which OpenVPN version is this? If you're not running v2.4.0 or newe=
r,
        try upgrading. I believe this this have improved there, cf.
        https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst:
   =20
        [...]
   =20
          Dualstack round-robin DNS client connect
            Instead of only using the first address of each --remote OpenVP=
N
            will now try all addresses (IPv6 and IPv4) of a --remote entry.
   =20
        [...]
   =20
          * proto udp and proto tcp now use both IPv4 and IPv6. The new opt=
ions
            proto udp4 and proto tcp4 use IPv4 only.
   =20
        Tore
   =20
   =20
   =20
   =20
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company
   =20
    This electronic message contains information which may be privileged or=
 confidential. The information is intended to be for the use of the individ=
ual(s) named above. If you are not the intended recipient be aware that any=
 disclosure, copying, distribution or use of the contents of this informati=
on, including attached files, is prohibited.
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =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 Mon Jul 17 04:37:43 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64D6129B62 for ; Mon, 17 Jul 2017 04:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQDHdsZgB5_X for ; Mon, 17 Jul 2017 04:37:39 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886F21288B8 for ; Mon, 17 Jul 2017 04:37:39 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1FA4D41B95 for ; Mon, 17 Jul 2017 13:37:38 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id EFE4041B75; Mon, 17 Jul 2017 13:37:37 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id E22B792F4; Mon, 17 Jul 2017 13:37:37 +0200 (CEST)
Date: Mon, 17 Jul 2017 13:37:37 +0200
From: Gert Doering 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG 
Message-ID: <20170717113737.GQ45648@Space.Net>
References:  <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <20170717105929.5a6b7997@echo.ms.redpill-linpro.com> <56F96ACC-E55F-4C07-94D9-C3BE511836B1@apple.com>  <20170717120436.598ca19e@echo.ms.redpill-linpro.com>   <1EA41531-B9F2-481B-BD59-8925DF84B49E@consulintel.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1EA41531-B9F2-481B-BD59-8925DF84B49E@consulintel.es>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 11:37:42 -0000

Hi,

On Mon, Jul 17, 2017 at 01:32:35PM +0200, JORDI PALET MARTINEZ wrote:
> Responding also to Gert.
> 
> I just tried again, no need to upgrade the client or server, as both of them were running the latest available versions.
> 
> As you said, it is a ???strange??? configuration ???language???. Even if you don???t have the server with IPv6, it needs to be enabled in both sides to work thru a NAT64.

Actually, no.  The server can be happily IPv4-only, but of course you
need to enable dual-stack mode on the client (which is the default, to
point this out explicitely).

If you force the client to IPv4-only "because the server is!", this is
what you'll get: something which is broken if you are in a DNS64/NAT64
network - but that's a misconfiguration, and there is no need to do so.

Same thing if you put a literal v4 address in your config - it's a 
misconfiguration, and it needs to break so people are made aware of it,
and can fix things.

(In your case it seems the VPN provider has created that config for you,
and if that provider puts "ipv4 only!" in the config, they need to be
told in no uncertain terms that this is a buggy client config - if the
DNS name resolves to v4-only, the client will automatically be v4-only,
so what)


> Of course, this means we ???thechies??? find the work around with some help from others that already suffered the problem, but a regular user not. If we were running CLAT, it just works and the most important, we get it reported/logged automatically, which is what I???m insisting on.
> 
> However ???. I???m still on the ietf-nat64 and Outlook (last release 15.36) for Mac refuses to send this message. I need to turn to another SSID to keep working thru the meeting. This is what we want?

This is what "we" *need*, otherwise it will just silently work and
nobody will ever escalate this high enough into Microsoft to fix it.

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

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


From nobody Mon Jul 17 05:29:50 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0C1131B51 for ; Mon, 17 Jul 2017 05:29:48 -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 lY5XARgNGSGA for ; Mon, 17 Jul 2017 05:29:46 -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 64D62131668 for ; Mon, 17 Jul 2017 05:29:46 -0700 (PDT)
X-AuditID: 60721c4b-719ff70000000a8e-bf-596cadb7c291
Received: from VAADCEX11.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 FC.03.02702.7BDAC695; Mon, 17 Jul 2017 08:29:44 -0400 (EDT)
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX11.cable.comcast.com (147.191.102.78) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 08:29:42 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 17 Jul 2017 08:29:42 -0400
From: "Brzozowski, John" 
To: "jordi.palet@consulintel.es" , IPv6 Ops WG 
CC: Jim Martin , Russ Housley , "Suresh Krishnan" , Alissa Cooper , Randy Bush 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/tSiyacM1/hfIEykN3ouQq0Z36JX77qAgABj3QA=
Date: Mon, 17 Jul 2017 12:29:42 +0000
Message-ID: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
In-Reply-To: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf0wbVRzPu2vpgX1yu9L2rWMEuojBTOiiaZrN4MQldswmsC3MNlngKCft KG3ttfxYTMQtIoIm/rEJdEbNAjNjA6eigJlz6xo32BbCD3FTNlnWkIHLgmGRwMR5766Fq3/1 m8/nvc/n8/305SiSGUozUG5vkAt4WY8xJU1Rwe+2PD/Y67GbRpvMlvbrq8Ayf/+WyjIVJS2r VxZJy+x7c4Qleu6G0nLt5x/JnSpr308l1kexOcLa+tcEYR0K31ZZu7qWCevxzhPA2jP9SFmi cqS9VMV53HVcoKCwIs3VcewK4Y++3vBH301lE7ha3ApSKUS/iGK37hCtII1i6AECjXTPKDHB 0BcBuvd+kUQMA9T8ySqBiRTajPov/a7CcwZ9EE2Nfw/wIZIeBGj1wbQCExp6L1q6PqaUDu1D A82L8Qvb0fC5X8QzCvoZNDnbT+IZ0rvQwJ2HpOR2UYHaRk+Jbql0EZo405WCZ0Dr0NLIWREn aT36LfY5Ie1Ao67zo6Q0a9HcvX9FYy2dj6YWTiskfCu68WsMSLMJfdd9IY7noJXPJgV9StDM Q1/9UCCN21F/c6nklIOOtd1VSTE3oOHOWPymHl2ODio/BpvCskDhdaHwulBYJhSWCX0BlD0g q45lq5y1Ll8oaNqW72QrPVy+01frZPkg/v0G4PcRyNwzCPqWX4sAmgJGNbz8qcfOKNk6vrE2 AmoowqiFYyk1dubpSl9Vo4vlXeWBkIfjjRkws004CdfgypCnxmiALWcFVLOGerl63sMFhQdp zIInsZB+jeNDvN/tdPtCfHko4IkARJGCbE4vlq1iGw9zAZ9kFgGbKIVRD3OHDtkZupoNcjUc 5+cCCbaeoowImrHzhgBXzTW86fYEE7Rwr7VTYGg5I4bdDC1Rt53RyQlZ3hy4A9MGOf3/yASV GgHVlFrI/bKYm/eztby7Om6tgR/gktQJVLTdCLeeEUAmAcosN8MylVCRLkEl242ANkCFO5b/ Jqj+x1eXCEbh9Xk5gx6+jfVofMkV8q4tbtDB4dIKO5MuI3AAQyb8EONaGb6ewZAN72N2o4xN jpH4rMwDp/BiNDAb964WPjrrezOQxeBTcVBcG8E3xD8ojsm2zoR2vLU2ziS7zQv1EkK9GptY b5ANyuudton1xtF4veM2sd44mFRvO6Z0CSrZydAEXn18hDhe3D7tsN3cc9Rc8JH6ybN+5T8T kzOuC66jK+NTW961lelsvXlHHHtfOFTomCkbW0gfGpk4XbIjNa+ne/GV5T/3O4oWlPUZ7+wy NYRzrbmFLWNfd6w8aDmlun3gid2Rv/Pg7Anz+W9nsk6W39Wmj5s0Bw5nX7pWt6/44e4v50vf Mip4F7vtOTLAs/8BeqR6LcwFAAA=
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 12:29:48 -0000

VGhlIGJlbG93IGlzIG5vdCB0cnVlLCB0aGlzIGlzIGV4YWN0bHkgd2hhdCBzb21lIG9mIHRoZSBh
dXRob3LigJlzIGluIHRoZSBkcmFmdCBhcmUgZG9pbmc6DQoNCuKAnEluIHRoZSByZWFsIHdvcmxk
LCB5b3Ugd2lsbCBub3QgZGlzYWJsZSBJUHY0IGluIHRoZSBMQU5zIG9mIGVuZC11c2VycyBvciBl
bnRlcnByaXNlIGN1c3RvbWVycyAoYXQgbGVhc3Qgbm90IG5vdywgbWF5IGJlIGluIDMtNSB5ZWFy
cyBmcm9tIG5vdyku4oCdDQoNClRoZSBJLUQgdGhhdCB3ZSB3cm90ZSBpcyBiYXNlZCBvbiByZWFs
IGRlcGxveW1lbnQgZXhwZXJpZW5jZXMsIG5vdCBmYW50YXN5IG9yIHNjaS1maS4NCg0KSm9obg0K
KzEtNDg0LTk2Mi0wMDYwDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9w
cyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpPUkRJIE1BUlRJTkVaIDxq
b3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NClJlcGx5LVRvOiBKT1JESSBNQVJUSU5FWiA8am9y
ZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+DQpEYXRlOiBNb25kYXksIEp1bHkgMTcsIDIwMTcgYXQg
MTA6MTcNClRvOiB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc+DQpDYzogSmltIE1hcnRpbiA8amltQGRh
ZWRlbHVzLmNvbT4sIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+LCBTdXJlc2gg
S3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+LCBBbGlzc2EgQ29vcGVyIDxhbGlz
c2FAY29vcGVydy5pbj4sIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20+DQpTdWJqZWN0OiBSZTog
W3Y2b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IG9mIElQdjYtb25seSBXaS1GaSBmb3IgSUVU
RiBNZWV0aW5ncw0KDQogICAgSG93ZXZlciwgd2UgaGF2ZSBkaWZmZXJlbnQgd2F5cyBmb3IgZG9p
bmcgdGhlIHNhbWUsIGFuZCB3ZSBzaG91bGQgZ28gZm9yIHRoZSBvbmUgdGhhdCBoYXMgbGVzcyBp
bXBhY3QgYW5kIGl0IGlzIG1vcmUgcmVhbGlzdGljLg0KICAgIA0KICAgIEluIHRoZSByZWFsIHdv
cmxkLCB5b3Ugd2lsbCBub3QgZGlzYWJsZSBJUHY0IGluIHRoZSBMQU5zIG9mIGVuZC11c2VycyBv
ciBlbnRlcnByaXNlIGN1c3RvbWVycyAoYXQgbGVhc3Qgbm90IG5vdywgbWF5IGJlIGluIDMtNSB5
ZWFycyBmcm9tIG5vdykuIFRoaXMgaXMgd2hhdCBJRVRGIG5lZWQgdG8gdGVzdCBub3cuIElQdjYg
b25seSB3aXRoIElQdjQgYXMgYSBzZXJ2aWNlICh3aGljaCBpcyA0NjRYTEFUKS4NCiAgICANCiAg
ICBBZ2FpbiwgYW5kIEnigJltIGZvci1JUHY2LCBidXQgYmVpbmcgcmVhbGlzdGljLCBub3QgY29u
c2lkZXJpbmcgc2NpLWZpIG9mIHR1cm5pbmcgZG93biBJUHY0IGluIG91ciBjdXN0b21lciBuZXR3
b3JrcyAobm93KS4NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIEpvcmRpDQogICAgIA0KICAgIA0K
ICAgIC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQogICAgRGU6IHY2b3BzIDx2Nm9wcy1ib3Vu
Y2VzQGlldGYub3JnPiBlbiBub21icmUgZGUgIkJyem96b3dza2ksIEpvaG4iIDxKb2huX0Jyem96
b3dza2lAY29tY2FzdC5jb20+DQogICAgUmVzcG9uZGVyIGE6IDxKb2huX0Jyem96b3dza2lAY29t
Y2FzdC5jb20+DQogICAgRmVjaGE6IGx1bmVzLCAxNyBkZSBqdWxpbyBkZSAyMDE3LCAxMDoxNA0K
ICAgIFBhcmE6IE5vYWggPG5vYWhAbmVvLmNvLnR6PiwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUu
Y29tPg0KICAgIENDOiBKaW0gTWFydGluIDxqaW1AZGFlZGVsdXMuY29tPiwgSVB2NiBPcHMgV0cg
PHY2b3BzQGlldGYub3JnPiwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+LCBSdXNz
IEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPiwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNv
bT4sIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbT4NCiAgICBBc3Vu
dG86IFJlOiBbdjZvcHNdIEluY3JlbWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdpLUZp
IGZvciBJRVRGIE1lZXRpbmdzDQogICAgDQogICAgICAgIEFncmVlIHdpdGggTm9haCBhbmQgVGVk
Lg0KICAgICAgICAgDQogICAgICAgIE5vdGUgdGhlIEktRCBleHBsaWNpdGx5IGRvY3VtZW50cyB0
aGF0IGEgZmFsbGJhY2ssIGR1YWwgc3RhY2sgU1NJRCBtdXN0IHJlbWFpbiBhdmFpbGFibGUgYXMg
Tm9haCBtZW50aW9ucyBiZWxvdy4NCiAgICAgICAgIA0KICAgICAgICBJIGZhaWwgdG8gc2VlIGhv
dyBkb2luZyB0aGlzIHdpbGwgaGFybSBvciBkaXNjcmltaW5hdGUuDQogICAgICAgICANCiAgICAg
ICAgV2UgZG8gbmVlZCB0byBlYXQgb3VyIG93biBkb2dmb29kLCBvdGhlcndpc2Ugd2UgYXJlIGh5
cG9jcml0ZXMuDQogICAgICAgICANCiAgICAgICAgSm9obg0KICAgICAgICANCiAgICAgICAgKzEt
NDg0LTk2Mi0wMDYwDQogICAgICAgICANCiAgICAgICAgRnJvbToNCiAgICAgICAgdjZvcHMgPHY2
b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBOb2FoIDxub2FoQG5lby5jby50ej4N
CiAgICAgICAgRGF0ZTogTW9uZGF5LCBKdWx5IDE3LCAyMDE3IGF0IDA5OjAxDQogICAgICAgIFRv
OiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQogICAgICAgIENjOiBSYW5keSBCdXNoIDxy
YW5keUBwc2cuY29tPiwgdjZvcHMgPHY2b3BzQGlldGYub3JnPiwgQWxpc3NhIENvb3BlciA8YWxp
c3NhQGNvb3BlcncuaW4+LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPiwgSmlt
IE1hcnRpbiA8amltQGRhZWRlbHVzLmNvbT4sIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNo
bmFuQGdtYWlsLmNvbT4NCiAgICAgICAgU3ViamVjdDogUmU6IFt2Nm9wc10gSW5jcmVtZW50YWwg
RGVwbG95bWVudCBvZiBJUHY2LW9ubHkgV2ktRmkgZm9yIElFVEYgTWVldGluZ3MNCiAgICAgICAg
DQogICAgICAgICANCiAgICAgICAgDQogICAgICAgIEZXSVcgYW5kIHRvIGNhdGVyIGZvciBhbGws
IHdvdWxkIGEgZmFsbGJhY2sgZHVhbCBzdGFjayBTU0lEIHdvcmsgZm9yIHRoZSBzdGF0dXMgcXVv
IHdoaWxlIHRoaXMgMm5kIHY2IFNTSUQgaXMgYWxzbyBleHBlcmltZW50ZWQgdXBvbiB3aGljaCBp
cyBhIGdyZWF0IGlkZWEgY29uc2lkZXJpbmcgdGhpcyBpcyBJRVRGLg0KICAgICAgICANCiAgICAg
ICAgIA0KICAgICAgICANCiAgICAgICAgTm9haA0KICAgICAgICANCiAgICAgICAgDQogICAgICAg
ICANCiAgICAgICAgT24gMTcgSnVsIDIwMTcgOTo1NCBhLm0uLCAiVGVkIExlbW9uIiA8bWVsbG9u
QGZ1Z3VlLmNvbT4gd3JvdGU6DQogICAgICAgIA0KICAgICAgICBJIGRvbid0IHRoaW5rIHRoaXMg
aXMgYSBzb2NpYWwganVzdGljZSBpc3N1ZS4gICBEb2VzIHRoZSBJRVRGIHRoaW5rIHRoYXQgSVB2
NiB3b3Jrcywgb3Igbm90PyAgIElmIHdlIHRoaW5rIGl0IHdvcmtzLCBhbmQgd2UgaGF2ZSBiZWVu
IHdvcmtpbmcgZm9yIHdoYXQsIDIwIHllYXJzLCB0byBtYWtlIGl0IHdvcmssIGFuZCB3ZSBoYXZl
IGRlc2lnbmVkIGFsbCB0aGlzIGdyZWF0DQogICAgICAgICB0cmFuc2l0aW9uIHRlY2gsIHRoZW4g
d2h5IG9uIGVhcnRoIHdvdWxkIHdlIG5vdCB3YW50IHRvIHVzZSBpdD8gICBUaGlzIGlzbid0ICJv
bmUgZHJhZnQuIiAgIFRoaXMgaXMgcm91Z2hseSBoYWxmIHRoZSB3b3JrIG9mIHRoZSBJRVRGIGZv
ciB0aGUgcGFzdCB0d28gZGVjYWRlcy4NCiAgICAgICAgDQogICAgICAgICANCiAgICAgICAgT24g
TW9uLCBKdWwgMTcsIDIwMTcgYXQgODo1MSBBTSwgSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRp
LnBhbGV0QGNvbnN1bGludGVsLmVzPiB3cm90ZToNCiAgICAgICAgDQogICAgICAgIFNvIHdlIGFn
cmVlIHRvIGNoYW5nZSB0aGUgcnVsZXMgc28gdGhhdCB3ZSB1c2UgdGhpcyBuZXR3b3JrIGZvciBl
dmVyeSBJRCB0aGF0IHdhbnQgdG8gZXhwZXJpbWVudCB3aXRoIGl0PyBPdGhlcndpc2Ugd2UgZGlz
Y3JpbWluYXRlIGFtb25nIGRpZmZlcmVudCBhdXRob3JzIOKApg0KICAgICAgICANCiAgICAgICAg
SSB0aGluayBpcyBhIHJlYWxseSBiYWQgcHJlY2VkZW50Lg0KICAgICAgICANCiAgICAgICAgUmVn
YXJkcywNCiAgICAgICAgSm9yZGkNCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICAtLS0tLU1l
bnNhamUgb3JpZ2luYWwtLS0tLQ0KICAgICAgICBEZTogVGVkIExlbW9uIDxtZWxsb25AZnVndWUu
Y29tPg0KICAgICAgICBSZXNwb25kZXIgYTogPG1lbGxvbkBmdWd1ZS5jb20+DQogICAgICAgIEZl
Y2hhOiBsdW5lcywgMTcgZGUganVsaW8gZGUgMjAxNywgODo0OA0KICAgICAgICBQYXJhOiBKT1JE
SSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+DQogICAgICAgIEND
OiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc+LCBKaW0gTWFydGluIDxqaW1AZGFlZGVsdXMu
Y29tPiwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNvbT4sIFN1cmVzaA0KICAgICAgICAgS3Jpc2hu
YW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmln
aWxzZWMuY29tPiwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+DQogICAgICAgIEFz
dW50bzogUmU6IFt2Nm9wc10gSW5jcmVtZW50YWwgRGVwbG95bWVudCBvZiBJUHY2LW9ubHkgV2kt
RmkgZm9yIElFVEYgTWVldGluZ3MNCiAgICAgICAgDQogICAgICAgICAgICBJIGRvbid0IGFjdHVh
bGx5IGtub3cgd2hhdCB0aGUgZ29hbCBvZiB0aGUgSUVURiBuZXR3b3JrIGlzIG90aGVyIHRoYW4g
dG8gcHJvdmlkZSBjb25uZWN0aXZpdHkuICAgQmVjYXVzZSBvZiB0aGUgdmljaXNzaXR1ZGVzIG9m
IGhvdGVsIHRvcG9sb2d5LCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IElFVEYgcGFydGljaXBh
bnRzIGV4cGVyaWVuY2UgaXNzdWVzIHdpdGggdGhlDQogICAgICAgICBuZXR3b3JrIGF0IGxlYXN0
IG9uY2Ugb3IgdHdpY2UgcGVyIElFVEYgZGVzcGl0ZSB0aGUgYmVzdCBlZmZvcnRzIChhbmQgdGhl
eSBhcmUgcXVpdGUgZXhjZXB0aW9uYWwpIG9mIHRoZSBOT0MgdGVhbS4gICBJIGRvIG5vdCByZWFs
bHkgc2VlIHdoYXQgdGhlIGRhbWFnZSBpcyB0aGF0IHlvdSBhcmUgaG9waW5nIHRvIHByb3RlY3Qg
YWdhaW5zdCBoZXJlLiAgIFVzZXJzIHdobyBkb24ndCByZWFkIHRoZSBOT0MgYW5ub3VuY2VtZW50
PyAgIE5vIHN5bXBhdGh5LiANCiAgICAgICAgICBTb3JyeS4NCiAgICAgICAgDQogICAgICAgIA0K
ICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICAqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgICAgIElQdjQgaXMgb3Zlcg0KICAgICAg
ICBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCiAgICAgICAgaHR0cDovL3d3
dy5jb25zdWxpbnRlbC5lcw0KICAgICAgICBUaGUgSVB2NiBDb21wYW55DQogICAgICAgIA0KICAg
ICAgICBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBt
YXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRl
bmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4g
SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBk
aXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3INCiAgICAgICAgIHVzZSBvZiB0aGUg
Y29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBp
cyBwcm9oaWJpdGVkLg0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICB2Nm9w
cyBtYWlsaW5nIGxpc3QNCiAgICAgICAgdjZvcHNAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAgICAgICANCiAgICAgICAgDQog
ICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgICANCiAgICAgICAgDQogICAgICAg
IA0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KICAgICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICAgICAgdjZvcHNAaWV0Zi5vcmcNCiAg
ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAgICAg
ICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAg
ICAgICANCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCiAgICAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgICAgIHY2b3BzQGlldGYub3Jn
DQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAg
ICAgICAgDQogICAgDQogICAgDQogICAgDQogICAgKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKg0KICAgIElQdjQgaXMgb3Zlcg0KICAgIEFyZSB5b3UgcmVhZHkg
Zm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KICAgIGh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNCiAg
ICBUaGUgSVB2NiBDb21wYW55DQogICAgDQogICAgVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29u
dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFs
LiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu
ZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp
cGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9u
IG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0
dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KICAgIA0KICAgIA0KICAgIA0KICAgIF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFp
bGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgDQoNCg==


From nobody Mon Jul 17 05:30:07 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F85F131668 for ; Mon, 17 Jul 2017 05:29: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, HTML_MESSAGE=0.001, 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 AA3uZOgww-d5 for ; Mon, 17 Jul 2017 05:29:46 -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 B2BC613188D for ; Mon, 17 Jul 2017 05:29:46 -0700 (PDT)
X-AuditID: 60721c4b-733ff70000000a8e-c0-596cadb8bfac
Received: from VAADCEX12.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 0D.03.02702.8BDAC695; Mon, 17 Jul 2017 08:29:44 -0400 (EDT)
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX12.cable.comcast.com (147.191.102.79) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 08:29:43 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 17 Jul 2017 08:29:43 -0400
From: "Brzozowski, John" 
To: Ted Lemon , JORDI PALET MARTINEZ 
CC: Randy Bush , IPv6 Ops WG , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/tSiyacM1/hfIEykN3ouQq0Z36JX77qAgAADloCAAGB1gA==
Date: Mon, 17 Jul 2017 12:29:43 +0000
Message-ID: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.254]
Content-Type: multipart/alternative; boundary="_000_BEB73854CBB342DB99DA1F508D7736C2cablecomcastcom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA11UfVAUZRzu3ftaTt5aF7h7OcHkZiRqFGEiW5OpxqzOikFtIs9/YDm2u5P7 YG7v+GiymCYysZmYBsc4oRo6a5QPg2yAplLPGxP8uABHx/hwrBuVKw1DY8DRad/dPVz6591n n+f3/p7f++w7S6romN5EOj1+zudhXWatXl3Gb2JW93e5rHnxqQJm35l7gIlfv6RjLkRUzL1f ZlTMX50RgrnaMEUwkW/PapjTJ39SPU9auo9uttyOTRGWxlujhOX9X7/WWQaCEzpLKDRHWPa2 7AeWQ+O3NZvJ7frCCs7lrOZ8a54t0zviHQe1Vd2/g9rQB1FtPegZB40giURUAYrev0JgTFN9 BOrY/VQj0Av4GEAjkQ619DIIUO+dO1pcpaXWoiPHx3QYp1JvoO7JERGrqPMADU+8iXEKtRXN nhnWSDWvo74PZ+T6DejP9gEVxmpqJbo8f0PgSRJSG9Gtpk2S1y4Nmtw7JNYkUVtQc/S06Aso A5od6iQkLyP6LfYFIZ2AQqEfoyoJp6GpP+6LvmlULrowfVAt8avQ2Ysx+cR56PsDP8t8Fpr/ /LxW6mlHwz0zYg2klqLBlphcY0QnIv2aJpAeVFgHFVuCii1B4Tgq6nF0+Ic1UkkWat5zRSfh HNTQ2ibjZ1C0aRQoa74E5CGwvJplK2xuhzfgz8vPtbHlLi7X5nXbWN6Pn70AXxxfxqv9oHvu 5TCgSGBOhidaXVZaw1bzde4wqCQJcxoc1lZa6YfLvRV1DpZ3lPoCLo43p8KMPUIlXKDLA65K swl+1CmwKQush6vhXZxfuKnm5bAdNzIuaHyAr3LanN4AXxrwucIAkSqhbVYXblvB1r3N+byS WRgsI9VmI8we2GGlKTvr5yo5rorzJdQakjQjuBY7L/Vxdq72LafLn5CFfY0tgkIpFXHYTMhE nFbaoBQU82bB9Vg2KeX/j0yQSWFgJ5OFuZ8T5+arWDfvtMvWKXA3Dik5wYq26XBVh0DSCVJh mQlLdEJEhoS02G4ItAEy+NncvwTZK65H7p6aJciwuJ7EK632eD2cyQjfwQ4UbuMIeBaiMBng 4JYyK/2IQsAjmTLgx5hPU/APpjKtgNexmq5QFw+W+APFgU24QylwBf4SycL/6UESNGQxuUQm xSAQ3CZ+MplT5JABrTiHNFlZ7BYXAieEwFOKxMD9rF8Z+HiRGLjMyoGPFImBy+SiwPdhyZCQ FjuZ6sHOJV7fuWjftVMH1j1pfCx1f3HDP+7CMf1DxHRhydPjbfZrk7VbPZQlcnX1vG4M5rSt q8m/+80rjncD2cnOle99Yr852n6x64VdN/4OlZ4rfO3F2KPB7ZbaSfDV8eLCS9PrP9244+h3 OfSyl3qaN2S7R4pv0pqSY4e38dwwc7l+oqA1c6dZzTvY/CdUPp79D/KU9ar3BQAA
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 12:29:49 -0000

--_000_BEB73854CBB342DB99DA1F508D7736C2cablecomcastcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWdyZWVkLg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0KRnJvbTogdjZvcHMgPHY2b3BzLWJv
dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+
DQpEYXRlOiBNb25kYXksIEp1bHkgMTcsIDIwMTcgYXQgMTA6MzANClRvOiBKT1JESSBNQVJUSU5F
WiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+DQpDYzogUmFuZHkgQnVzaCA8cmFuZHlAcHNn
LmNvbT4sIHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4sIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdp
bHNlYy5jb20+LCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4sIEppbSBNYXJ0aW4g
PGppbUBkYWVkZWx1cy5jb20+LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFp
bC5jb20+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IG9mIElQ
djYtb25seSBXaS1GaSBmb3IgSUVURiBNZWV0aW5ncw0KDQpIYXZlIHlvdSBldmVyIGFjdHVhbGx5
IHVzZWQgdGhlIGlldGYtbmF0NjQgbmV0d29yaz8gICBXaGF0IHByb2JsZW1zIGRpZCB5b3UgaGF2
ZT8gICBJIGFzayBiZWNhdXNlIEkgdXNlIGl0IGF0IGV2ZXJ5IElFVEYsIGFuZCBJIG5ldmVyIGhh
dmUgYW55IHByb2JsZW1zLiAgIFNvIHRoZSBkZWdyZWUgb2YgZmVhciB0aGF0IHlvdSBhcmUgZXho
aWJpdGluZyBhYm91dCBoYXZpbmcgaXQgYmUgdGhlIGRlZmF1bHQgaXMgcmVhbGx5IHN1cnByaXNp
bmcgdG8gbWUuICAgVGhpcyBpcyByZWFsbHkgbm90IGEgYmlnIGRlYWwsIGV4Y2VwdCBpbiB0aGUg
c2Vuc2UgdGhhdCBpdCdzIGEgYmlnIGRlYWwgdGhhdCB0aGUgSUVURiBzdGlsbCBpc24ndCBkb2dm
b29kaW5nIGF0IG1lZXRpbmdzIHR3ZW50eSB5ZWFycyBsYXRlci4NCg0KT24gTW9uLCBKdWwgMTcs
IDIwMTcgYXQgMTA6MTcgQU0sIEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldEBjb25z
dWxpbnRlbC5lczxtYWlsdG86am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+PiB3cm90ZToNCkhv
d2V2ZXIsIHdlIGhhdmUgZGlmZmVyZW50IHdheXMgZm9yIGRvaW5nIHRoZSBzYW1lLCBhbmQgd2Ug
c2hvdWxkIGdvIGZvciB0aGUgb25lIHRoYXQgaGFzIGxlc3MgaW1wYWN0IGFuZCBpdCBpcyBtb3Jl
IHJlYWxpc3RpYy4NCg0KSW4gdGhlIHJlYWwgd29ybGQsIHlvdSB3aWxsIG5vdCBkaXNhYmxlIElQ
djQgaW4gdGhlIExBTnMgb2YgZW5kLXVzZXJzIG9yIGVudGVycHJpc2UgY3VzdG9tZXJzIChhdCBs
ZWFzdCBub3Qgbm93LCBtYXkgYmUgaW4gMy01IHllYXJzIGZyb20gbm93KS4gVGhpcyBpcyB3aGF0
IElFVEYgbmVlZCB0byB0ZXN0IG5vdy4gSVB2NiBvbmx5IHdpdGggSVB2NCBhcyBhIHNlcnZpY2Ug
KHdoaWNoIGlzIDQ2NFhMQVQpLg0KDQpBZ2FpbiwgYW5kIEnigJltIGZvci1JUHY2LCBidXQgYmVp
bmcgcmVhbGlzdGljLCBub3QgY29uc2lkZXJpbmcgc2NpLWZpIG9mIHR1cm5pbmcgZG93biBJUHY0
IGluIG91ciBjdXN0b21lciBuZXR3b3JrcyAobm93KS4NCg0KUmVnYXJkcywNCkpvcmRpDQoNCg0K
LS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCkRlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz4+IGVuIG5vbWJyZSBkZSAiQnJ6b3pv
d3NraSwgSm9obiIgPEpvaG5fQnJ6b3pvd3NraUBjb21jYXN0LmNvbTxtYWlsdG86Sm9obl9Ccnpv
em93c2tpQGNvbWNhc3QuY29tPj4NClJlc3BvbmRlciBhOiA8Sm9obl9Ccnpvem93c2tpQGNvbWNh
c3QuY29tPG1haWx0bzpKb2huX0Jyem96b3dza2lAY29tY2FzdC5jb20+Pg0KRmVjaGE6IGx1bmVz
LCAxNyBkZSBqdWxpbyBkZSAyMDE3LCAxMDoxNA0KUGFyYTogTm9haCA8bm9haEBuZW8uY28udHo8
bWFpbHRvOm5vYWhAbmVvLmNvLnR6Pj4sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWls
dG86bWVsbG9uQGZ1Z3VlLmNvbT4+DQpDQzogSmltIE1hcnRpbiA8amltQGRhZWRlbHVzLmNvbTxt
YWlsdG86amltQGRhZWRlbHVzLmNvbT4+LCBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc8bWFp
bHRvOnY2b3BzQGlldGYub3JnPj4sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPG1h
aWx0bzphbGlzc2FAY29vcGVydy5pbj4+LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMu
Y29tPG1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4+LCBSYW5keSBCdXNoIDxyYW5keUBwc2cu
Y29tPG1haWx0bzpyYW5keUBwc2cuY29tPj4sIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNo
bmFuQGdtYWlsLmNvbTxtYWlsdG86c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbT4+DQpBc3VudG86
IFJlOiBbdjZvcHNdIEluY3JlbWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdpLUZpIGZv
ciBJRVRGIE1lZXRpbmdzDQoNCiAgICBBZ3JlZSB3aXRoIE5vYWggYW5kIFRlZC4NCg0KICAgIE5v
dGUgdGhlIEktRCBleHBsaWNpdGx5IGRvY3VtZW50cyB0aGF0IGEgZmFsbGJhY2ssIGR1YWwgc3Rh
Y2sgU1NJRCBtdXN0IHJlbWFpbiBhdmFpbGFibGUgYXMgTm9haCBtZW50aW9ucyBiZWxvdy4NCg0K
ICAgIEkgZmFpbCB0byBzZWUgaG93IGRvaW5nIHRoaXMgd2lsbCBoYXJtIG9yIGRpc2NyaW1pbmF0
ZS4NCg0KICAgIFdlIGRvIG5lZWQgdG8gZWF0IG91ciBvd24gZG9nZm9vZCwgb3RoZXJ3aXNlIHdl
IGFyZSBoeXBvY3JpdGVzLg0KDQogICAgSm9obg0KDQogICAgKzEtNDg0LTk2Mi0wMDYwPHRlbDol
MkIxLTQ4NC05NjItMDA2MD4NCg0KICAgIEZyb206DQogICAgdjZvcHMgPHY2b3BzLWJvdW5jZXNA
aWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTm9h
aCA8bm9haEBuZW8uY28udHo8bWFpbHRvOm5vYWhAbmVvLmNvLnR6Pj4NCiAgICBEYXRlOiBNb25k
YXksIEp1bHkgMTcsIDIwMTcgYXQgMDk6MDENCiAgICBUbzogVGVkIExlbW9uIDxtZWxsb25AZnVn
dWUuY29tPG1haWx0bzptZWxsb25AZnVndWUuY29tPj4NCiAgICBDYzogUmFuZHkgQnVzaCA8cmFu
ZHlAcHNnLmNvbTxtYWlsdG86cmFuZHlAcHNnLmNvbT4+LCB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc8
bWFpbHRvOnY2b3BzQGlldGYub3JnPj4sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3Lmlu
PG1haWx0bzphbGlzc2FAY29vcGVydy5pbj4+LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxz
ZWMuY29tPG1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4+LCBKaW0gTWFydGluIDxqaW1AZGFl
ZGVsdXMuY29tPG1haWx0bzpqaW1AZGFlZGVsdXMuY29tPj4sIFN1cmVzaCBLcmlzaG5hbiA8c3Vy
ZXNoLmtyaXNobmFuQGdtYWlsLmNvbTxtYWlsdG86c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbT4+
DQogICAgU3ViamVjdDogUmU6IFt2Nm9wc10gSW5jcmVtZW50YWwgRGVwbG95bWVudCBvZiBJUHY2
LW9ubHkgV2ktRmkgZm9yIElFVEYgTWVldGluZ3MNCg0KDQoNCiAgICBGV0lXIGFuZCB0byBjYXRl
ciBmb3IgYWxsLCB3b3VsZCBhIGZhbGxiYWNrIGR1YWwgc3RhY2sgU1NJRCB3b3JrIGZvciB0aGUg
c3RhdHVzIHF1byB3aGlsZSB0aGlzIDJuZCB2NiBTU0lEIGlzIGFsc28gZXhwZXJpbWVudGVkIHVw
b24gd2hpY2ggaXMgYSBncmVhdCBpZGVhIGNvbnNpZGVyaW5nIHRoaXMgaXMgSUVURi4NCg0KDQoN
CiAgICBOb2FoDQoNCg0KDQogICAgT24gMTcgSnVsIDIwMTcgOTo1NCBhLm0uLCAiVGVkIExlbW9u
IiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+IHdyb3RlOg0KDQog
ICAgSSBkb24ndCB0aGluayB0aGlzIGlzIGEgc29jaWFsIGp1c3RpY2UgaXNzdWUuICAgRG9lcyB0
aGUgSUVURiB0aGluayB0aGF0IElQdjYgd29ya3MsIG9yIG5vdD8gICBJZiB3ZSB0aGluayBpdCB3
b3JrcywgYW5kIHdlIGhhdmUgYmVlbiB3b3JraW5nIGZvciB3aGF0LCAyMCB5ZWFycywgdG8gbWFr
ZSBpdCB3b3JrLCBhbmQgd2UgaGF2ZSBkZXNpZ25lZCBhbGwgdGhpcyBncmVhdA0KICAgICB0cmFu
c2l0aW9uIHRlY2gsIHRoZW4gd2h5IG9uIGVhcnRoIHdvdWxkIHdlIG5vdCB3YW50IHRvIHVzZSBp
dD8gICBUaGlzIGlzbid0ICJvbmUgZHJhZnQuIiAgIFRoaXMgaXMgcm91Z2hseSBoYWxmIHRoZSB3
b3JrIG9mIHRoZSBJRVRGIGZvciB0aGUgcGFzdCB0d28gZGVjYWRlcy4NCg0KDQogICAgT24gTW9u
LCBKdWwgMTcsIDIwMTcgYXQgODo1MSBBTSwgSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBh
bGV0QGNvbnN1bGludGVsLmVzPG1haWx0bzpqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4+IHdy
b3RlOg0KDQogICAgU28gd2UgYWdyZWUgdG8gY2hhbmdlIHRoZSBydWxlcyBzbyB0aGF0IHdlIHVz
ZSB0aGlzIG5ldHdvcmsgZm9yIGV2ZXJ5IElEIHRoYXQgd2FudCB0byBleHBlcmltZW50IHdpdGgg
aXQ/IE90aGVyd2lzZSB3ZSBkaXNjcmltaW5hdGUgYW1vbmcgZGlmZmVyZW50IGF1dGhvcnMg4oCm
DQoNCiAgICBJIHRoaW5rIGlzIGEgcmVhbGx5IGJhZCBwcmVjZWRlbnQuDQoNCiAgICBSZWdhcmRz
LA0KICAgIEpvcmRpDQoNCg0KICAgIC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQogICAgRGU6
IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+DQog
ICAgUmVzcG9uZGVyIGE6IDxtZWxsb25AZnVndWUuY29tPG1haWx0bzptZWxsb25AZnVndWUuY29t
Pj4NCiAgICBGZWNoYTogbHVuZXMsIDE3IGRlIGp1bGlvIGRlIDIwMTcsIDg6NDgNCiAgICBQYXJh
OiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM8bWFpbHRv
OmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPj4NCiAgICBDQzogSVB2NiBPcHMgV0cgPHY2b3Bz
QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+LCBKaW0gTWFydGluIDxqaW1AZGFlZGVs
dXMuY29tPG1haWx0bzpqaW1AZGFlZGVsdXMuY29tPj4sIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5j
b208bWFpbHRvOnJhbmR5QHBzZy5jb20+PiwgU3VyZXNoDQogICAgIEtyaXNobmFuIDxzdXJlc2gu
a3Jpc2huYW5AZ21haWwuY29tPG1haWx0bzpzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPj4sIFJ1
c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMu
Y29tPj4sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPG1haWx0bzphbGlzc2FAY29v
cGVydy5pbj4+DQogICAgQXN1bnRvOiBSZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3ltZW50
IG9mIElQdjYtb25seSBXaS1GaSBmb3IgSUVURiBNZWV0aW5ncw0KDQogICAgICAgIEkgZG9uJ3Qg
YWN0dWFsbHkga25vdyB3aGF0IHRoZSBnb2FsIG9mIHRoZSBJRVRGIG5ldHdvcmsgaXMgb3RoZXIg
dGhhbiB0byBwcm92aWRlIGNvbm5lY3Rpdml0eS4gICBCZWNhdXNlIG9mIHRoZSB2aWNpc3NpdHVk
ZXMgb2YgaG90ZWwgdG9wb2xvZ3ksIGl0IGlzIG9mdGVuIHRoZSBjYXNlIHRoYXQgSUVURiBwYXJ0
aWNpcGFudHMgZXhwZXJpZW5jZSBpc3N1ZXMgd2l0aCB0aGUNCiAgICAgbmV0d29yayBhdCBsZWFz
dCBvbmNlIG9yIHR3aWNlIHBlciBJRVRGIGRlc3BpdGUgdGhlIGJlc3QgZWZmb3J0cyAoYW5kIHRo
ZXkgYXJlIHF1aXRlIGV4Y2VwdGlvbmFsKSBvZiB0aGUgTk9DIHRlYW0uICAgSSBkbyBub3QgcmVh
bGx5IHNlZSB3aGF0IHRoZSBkYW1hZ2UgaXMgdGhhdCB5b3UgYXJlIGhvcGluZyB0byBwcm90ZWN0
IGFnYWluc3QgaGVyZS4gICBVc2VycyB3aG8gZG9uJ3QgcmVhZCB0aGUgTk9DIGFubm91bmNlbWVu
dD8gICBObyBzeW1wYXRoeS4NCiAgICAgIFNvcnJ5Lg0KDQoNCg0KDQoNCiAgICAqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgSVB2NCBpcyBvdmVyDQog
ICAgQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQogICAgaHR0cDovL3d3dy5j
b25zdWxpbnRlbC5lcw0KICAgIFRoZSBJUHY2IENvbXBhbnkNCg0KICAgIFRoaXMgZWxlY3Ryb25p
YyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9y
IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUg
dXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcs
IGRpc3RyaWJ1dGlvbiBvcg0KICAgICB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3Jt
YXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCg0KDQoNCiAg
ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHY2
b3BzIG1haWxpbmcgbGlzdA0KICAgIHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y
Zz4NCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0K
DQoNCg0KDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmc8bWFpbHRv
OnY2b3BzQGlldGYub3JnPg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vdjZvcHMNCg0KDQoNCg0KDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0
Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZvciB0aGUg
bmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNClRoZSBJUHY2IENvbXBh
bnkNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2gg
bWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50
ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUu
IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkg
ZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMg
b2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJp
dGVkLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo=

--_000_BEB73854CBB342DB99DA1F508D7736C2cablecomcastcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <231DE99BF960D64C8002A96CDA17D0FF@comcast.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBNaW5jaG8i
Ow0KCXBhbm9zZS0xOjIgMiA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUgMCAwIDAgMCAwIDAg
MDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
Ow0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0K
CXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0
aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBv
cnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
Ow0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi
b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkFncmVlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpv
aG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxLTQ4
NC05NjItMDA2MDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+djZvcHMgJmx0
O3Y2b3BzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBUZWQgTGVtb24gJmx0O21l
bGxvbkBmdWd1ZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSnVseSAxNywgMjAx
NyBhdCAxMDozMDxicj4NCjxiPlRvOiA8L2I+Sk9SREkgTUFSVElORVogJmx0O2pvcmRpLnBhbGV0
QGNvbnN1bGludGVsLmVzJmd0Ozxicj4NCjxiPkNjOiA8L2I+UmFuZHkgQnVzaCAmbHQ7cmFuZHlA
cHNnLmNvbSZndDssIHY2b3BzICZsdDt2Nm9wc0BpZXRmLm9yZyZndDssIFJ1c3MgSG91c2xleSAm
bHQ7aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7LCBBbGlzc2EgQ29vcGVyICZsdDthbGlzc2FAY29v
cGVydy5pbiZndDssIEppbSBNYXJ0aW4gJmx0O2ppbUBkYWVkZWx1cy5jb20mZ3Q7LCBTdXJlc2gg
S3Jpc2huYW4gJmx0O3N1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj
dDogPC9iPlJlOiBbdjZvcHNdIEluY3JlbWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdp
LUZpIGZvciBJRVRGIE1lZXRpbmdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPkhhdmUgeW91IGV2ZXIgYWN0dWFsbHkgdXNlZCB0aGUgaWV0Zi1u
YXQ2NCBuZXR3b3JrPyAmbmJzcDsgV2hhdCBwcm9ibGVtcyBkaWQgeW91IGhhdmU/ICZuYnNwOyBJ
IGFzayBiZWNhdXNlIEkgdXNlIGl0IGF0IGV2ZXJ5IElFVEYsIGFuZCBJIG5ldmVyIGhhdmUgYW55
IHByb2JsZW1zLiAmbmJzcDsgU28gdGhlIGRlZ3JlZSBvZiBmZWFyIHRoYXQgeW91IGFyZSBleGhp
Yml0aW5nIGFib3V0IGhhdmluZw0KIGl0IGJlIHRoZSBkZWZhdWx0IGlzIHJlYWxseSBzdXJwcmlz
aW5nIHRvIG1lLiAmbmJzcDsgVGhpcyBpcyByZWFsbHkgbm90IGEgYmlnIGRlYWwsIGV4Y2VwdCBp
biB0aGUgc2Vuc2UgdGhhdCBpdCdzIGEgYmlnIGRlYWwgdGhhdCB0aGUgSUVURiBzdGlsbCBpc24n
dCBkb2dmb29kaW5nIGF0IG1lZXRpbmdzIHR3ZW50eSB5ZWFycyBsYXRlci48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gTW9uLCBKdWwgMTcsIDIwMTcgYXQgMTA6MTcg
QU0sIEpPUkRJIFBBTEVUIE1BUlRJTkVaICZsdDs8YSBocmVmPSJtYWlsdG86am9yZGkucGFsZXRA
Y29uc3VsaW50ZWwuZXMiIHRhcmdldD0iX2JsYW5rIj5qb3JkaS5wYWxldEBjb25zdWxpbnRlbC5l
czwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp
biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ib3dldmVyLCB3ZSBoYXZlIGRpZmZl
cmVudCB3YXlzIGZvciBkb2luZyB0aGUgc2FtZSwgYW5kIHdlIHNob3VsZCBnbyBmb3IgdGhlIG9u
ZSB0aGF0IGhhcyBsZXNzIGltcGFjdCBhbmQgaXQgaXMgbW9yZSByZWFsaXN0aWMuPGJyPg0KPGJy
Pg0KSW4gdGhlIHJlYWwgd29ybGQsIHlvdSB3aWxsIG5vdCBkaXNhYmxlIElQdjQgaW4gdGhlIExB
TnMgb2YgZW5kLXVzZXJzIG9yIGVudGVycHJpc2UgY3VzdG9tZXJzIChhdCBsZWFzdCBub3Qgbm93
LCBtYXkgYmUgaW4gMy01IHllYXJzIGZyb20gbm93KS4gVGhpcyBpcyB3aGF0IElFVEYgbmVlZCB0
byB0ZXN0IG5vdy4gSVB2NiBvbmx5IHdpdGggSVB2NCBhcyBhIHNlcnZpY2UgKHdoaWNoIGlzIDQ2
NFhMQVQpLjxicj4NCjxicj4NCkFnYWluLCBhbmQgSeKAmW0gZm9yLUlQdjYsIGJ1dCBiZWluZyBy
ZWFsaXN0aWMsIG5vdCBjb25zaWRlcmluZyBzY2ktZmkgb2YgdHVybmluZyBkb3duIElQdjQgaW4g
b3VyIGN1c3RvbWVyIG5ldHdvcmtzIChub3cpLjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpQTWlu
Z0xpVSI+PGJyPg0KPGJyPg0KPC9zcGFuPlJlZ2FyZHMsPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OlBNaW5nTGlVIj48YnI+DQo8L3NwYW4+Sm9yZGk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6UE1p
bmdMaVUiPjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj4tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0t
LTxicj4NCkRlOiB2Nm9wcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v
cmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBlbiBub21icmUgZGUgJnF1b3Q7QnJ6
b3pvd3NraSwgSm9obiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkpvaG5fQnJ6b3pvd3NraUBj
b21jYXN0LmNvbSI+Sm9obl9Ccnpvem93c2tpQGNvbWNhc3QuY29tPC9hPiZndDs8YnI+DQpSZXNw
b25kZXIgYTogJmx0OzxhIGhyZWY9Im1haWx0bzpKb2huX0Jyem96b3dza2lAY29tY2FzdC5jb20i
PkpvaG5fQnJ6b3pvd3NraUBjb21jYXN0LmNvbTwvYT4mZ3Q7PGJyPg0KRmVjaGE6IGx1bmVzLCAx
NyBkZSBqdWxpbyBkZSAyMDE3LCAxMDoxNDxicj4NClBhcmE6IE5vYWggJmx0OzxhIGhyZWY9Im1h
aWx0bzpub2FoQG5lby5jby50eiI+bm9haEBuZW8uY28udHo8L2E+Jmd0OywgVGVkIExlbW9uICZs
dDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSI+bWVsbG9uQGZ1Z3VlLmNvbTwvYT4m
Z3Q7PGJyPg0KQ0M6IEppbSBNYXJ0aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqaW1AZGFlZGVsdXMu
Y29tIj5qaW1AZGFlZGVsdXMuY29tPC9hPiZndDssIElQdjYgT3BzIFdHICZsdDs8YSBocmVmPSJt
YWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDssIEFsaXNzYSBDb29w
ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiI+YWxpc3NhQGNvb3Blcncu
aW48L2E+Jmd0OywgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp
bHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDssDQogUmFuZHkgQnVzaCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnJhbmR5QHBzZy5jb20iPnJhbmR5QHBzZy5jb208L2E+Jmd0OywgU3Vy
ZXNoIEtyaXNobmFuICZsdDs8YSBocmVmPSJtYWlsdG86c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNv
bSI+c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5B
c3VudG86IFJlOiBbdjZvcHNdIEluY3JlbWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdp
LUZpIGZvciBJRVRGIE1lZXRpbmdzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBBZ3JlZSB3aXRo
IE5vYWggYW5kIFRlZC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE5vdGUgdGhlIEktRCBleHBs
aWNpdGx5IGRvY3VtZW50cyB0aGF0IGEgZmFsbGJhY2ssIGR1YWwgc3RhY2sgU1NJRCBtdXN0IHJl
bWFpbiBhdmFpbGFibGUgYXMgTm9haCBtZW50aW9ucyBiZWxvdy48YnI+DQo8YnI+DQombmJzcDsg
Jm5ic3A7IEkgZmFpbCB0byBzZWUgaG93IGRvaW5nIHRoaXMgd2lsbCBoYXJtIG9yIGRpc2NyaW1p
bmF0ZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFdlIGRvIG5lZWQgdG8gZWF0IG91ciBvd24g
ZG9nZm9vZCwgb3RoZXJ3aXNlIHdlIGFyZSBoeXBvY3JpdGVzLjxicj4NCjxicj4NCiZuYnNwOyAm
bmJzcDsgSm9objxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0idGVsOiUyQjEtNDg0
LTk2Mi0wMDYwIj4mIzQzOzEtNDg0LTk2Mi0wMDYwPC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJz
cDsgRnJvbTo8YnI+DQombmJzcDsgJm5ic3A7IHY2b3BzICZsdDs8YSBocmVmPSJtYWlsdG86djZv
cHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl
aGFsZiBvZiBOb2FoICZsdDs8YSBocmVmPSJtYWlsdG86bm9haEBuZW8uY28udHoiPm5vYWhAbmVv
LmNvLnR6PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7IERhdGU6IE1vbmRheSwgSnVseSAxNywg
MjAxNyBhdCAwOTowMTxicj4NCiZuYnNwOyAmbmJzcDsgVG86IFRlZCBMZW1vbiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0Ozxicj4N
CiZuYnNwOyAmbmJzcDsgQ2M6IFJhbmR5IEJ1c2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5keUBw
c2cuY29tIj5yYW5keUBwc2cuY29tPC9hPiZndDssIHY2b3BzICZsdDs8YSBocmVmPSJtYWlsdG86
djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDssIEFsaXNzYSBDb29wZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiI+YWxpc3NhQGNvb3BlcncuaW48L2E+
Jmd0OywgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdpbHNlYy5j
b20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDssDQogSmltIE1hcnRpbiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmppbUBkYWVkZWx1cy5jb20iPmppbUBkYWVkZWx1cy5jb208L2E+Jmd0OywgU3Vy
ZXNoIEtyaXNobmFuICZsdDs8YSBocmVmPSJtYWlsdG86c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNv
bSI+c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyBT
dWJqZWN0OiBSZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IG9mIElQdjYtb25seSBX
aS1GaSBmb3IgSUVURiBNZWV0aW5nczxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJz
cDsgRldJVyBhbmQgdG8gY2F0ZXIgZm9yIGFsbCwgd291bGQgYSBmYWxsYmFjayBkdWFsIHN0YWNr
IFNTSUQgd29yayBmb3IgdGhlIHN0YXR1cyBxdW8gd2hpbGUgdGhpcyAybmQgdjYgU1NJRCBpcyBh
bHNvIGV4cGVyaW1lbnRlZCB1cG9uIHdoaWNoIGlzIGEgZ3JlYXQgaWRlYSBjb25zaWRlcmluZyB0
aGlzIGlzIElFVEYuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBOb2FoPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiAxNyBKdWwgMjAxNyA5OjU0IGEu
bS4sICZxdW90O1RlZCBMZW1vbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1
ZS5jb20iPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsg
Jm5ic3A7IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIHNvY2lhbCBqdXN0aWNlIGlzc3VlLiZuYnNw
OyAmbmJzcDtEb2VzIHRoZSBJRVRGIHRoaW5rIHRoYXQgSVB2NiB3b3Jrcywgb3Igbm90PyZuYnNw
OyAmbmJzcDtJZiB3ZSB0aGluayBpdCB3b3JrcywgYW5kIHdlIGhhdmUgYmVlbiB3b3JraW5nIGZv
ciB3aGF0LCAyMCB5ZWFycywgdG8gbWFrZSBpdCB3b3JrLCBhbmQgd2UgaGF2ZSBkZXNpZ25lZCBh
bGwgdGhpcyBncmVhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNpdGlvbiB0ZWNoLCB0
aGVuIHdoeSBvbiBlYXJ0aCB3b3VsZCB3ZSBub3Qgd2FudCB0byB1c2UgaXQ/Jm5ic3A7ICZuYnNw
O1RoaXMgaXNuJ3QgJnF1b3Q7b25lIGRyYWZ0LiZxdW90OyZuYnNwOyAmbmJzcDtUaGlzIGlzIHJv
dWdobHkgaGFsZiB0aGUgd29yayBvZiB0aGUgSUVURiBmb3IgdGhlIHBhc3QgdHdvIGRlY2FkZXMu
PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBNb24sIEp1bCAxNywgMjAxNyBhdCA4
OjUxIEFNLCBKT1JESSBQQUxFVCBNQVJUSU5FWiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmRpLnBh
bGV0QGNvbnN1bGludGVsLmVzIj5qb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lczwvYT4mZ3Q7IHdy
b3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgU28gd2UgYWdyZWUgdG8gY2hhbmdlIHRoZSBy
dWxlcyBzbyB0aGF0IHdlIHVzZSB0aGlzIG5ldHdvcmsgZm9yIGV2ZXJ5IElEIHRoYXQgd2FudCB0
byBleHBlcmltZW50IHdpdGggaXQ/IE90aGVyd2lzZSB3ZSBkaXNjcmltaW5hdGUgYW1vbmcgZGlm
ZmVyZW50IGF1dGhvcnMg4oCmPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlBNaW5nTGlVIj48YnI+
DQo8YnI+DQo8L3NwYW4+Jm5ic3A7ICZuYnNwOyBJIHRoaW5rIGlzIGEgcmVhbGx5IGJhZCBwcmVj
ZWRlbnQuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlBNaW5nTGlVIj48YnI+DQo8YnI+DQo8L3Nw
YW4+Jm5ic3A7ICZuYnNwOyBSZWdhcmRzLDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpQTWluZ0xp
VSI+PGJyPg0KPC9zcGFuPiZuYnNwOyAmbmJzcDsgSm9yZGk8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6UE1pbmdMaVUiPjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj4mbmJzcDsgJm5ic3A7IC0tLS0t
TWVuc2FqZSBvcmlnaW5hbC0tLS0tPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlBNaW5nTGlVIj48
YnI+DQo8L3NwYW4+Jm5ic3A7ICZuYnNwOyBEZTogVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWls
dG86bWVsbG9uQGZ1Z3VlLmNvbSI+bWVsbG9uQGZ1Z3VlLmNvbTwvYT4mZ3Q7PGJyPg0KJm5ic3A7
ICZuYnNwOyBSZXNwb25kZXIgYTogJmx0OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29t
Ij5tZWxsb25AZnVndWUuY29tPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7IEZlY2hhOiBsdW5l
cywgMTcgZGUganVsaW8gZGUgMjAxNywgODo0ODxicj4NCiZuYnNwOyAmbmJzcDsgUGFyYTogSk9S
REkgUEFMRVQgTUFSVElORVogJmx0OzxhIGhyZWY9Im1haWx0bzpqb3JkaS5wYWxldEBjb25zdWxp
bnRlbC5lcyI+am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM8L2E+Jmd0Ozxicj4NCiZuYnNwOyAm
bmJzcDsgQ0M6IElQdjYgT3BzIFdHICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci
PnY2b3BzQGlldGYub3JnPC9hPiZndDssIEppbSBNYXJ0aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpq
aW1AZGFlZGVsdXMuY29tIj5qaW1AZGFlZGVsdXMuY29tPC9hPiZndDssIFJhbmR5IEJ1c2ggJmx0
OzxhIGhyZWY9Im1haWx0bzpyYW5keUBwc2cuY29tIj5yYW5keUBwc2cuY29tPC9hPiZndDssIFN1
cmVzaDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7S3Jpc2huYW4gJmx0OzxhIGhyZWY9Im1haWx0
bzpzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tIj5zdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPC9h
PiZndDssIFJ1c3MgSG91c2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMu
Y29tIj5ob3VzbGV5QHZpZ2lsc2VjLmNvbTwvYT4mZ3Q7LCBBbGlzc2EgQ29vcGVyICZsdDs8YSBo
cmVmPSJtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4iPmFsaXNzYUBjb29wZXJ3LmluPC9hPiZndDs8
YnI+DQombmJzcDsgJm5ic3A7IEFzdW50bzogUmU6IFt2Nm9wc10gSW5jcmVtZW50YWwgRGVwbG95
bWVudCBvZiBJUHY2LW9ubHkgV2ktRmkgZm9yIElFVEYgTWVldGluZ3M8YnI+DQo8YnI+DQombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBkb24ndCBhY3R1YWxseSBrbm93IHdoYXQgdGhlIGdv
YWwgb2YgdGhlIElFVEYgbmV0d29yayBpcyBvdGhlciB0aGFuIHRvIHByb3ZpZGUgY29ubmVjdGl2
aXR5LiZuYnNwOyAmbmJzcDtCZWNhdXNlIG9mIHRoZSB2aWNpc3NpdHVkZXMgb2YgaG90ZWwgdG9w
b2xvZ3ksIGl0IGlzIG9mdGVuIHRoZSBjYXNlIHRoYXQgSUVURiBwYXJ0aWNpcGFudHMgZXhwZXJp
ZW5jZSBpc3N1ZXMgd2l0aCB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO25ldHdvcmsgYXQg
bGVhc3Qgb25jZSBvciB0d2ljZSBwZXIgSUVURiBkZXNwaXRlIHRoZSBiZXN0IGVmZm9ydHMgKGFu
ZCB0aGV5IGFyZSBxdWl0ZSBleGNlcHRpb25hbCkgb2YgdGhlIE5PQyB0ZWFtLiZuYnNwOyAmbmJz
cDtJIGRvIG5vdCByZWFsbHkgc2VlIHdoYXQgdGhlIGRhbWFnZSBpcyB0aGF0IHlvdSBhcmUgaG9w
aW5nIHRvIHByb3RlY3QgYWdhaW5zdCBoZXJlLiZuYnNwOyAmbmJzcDtVc2VycyB3aG8gZG9uJ3Qg
cmVhZCB0aGUgTk9DIGFubm91bmNlbWVudD8mbmJzcDsgJm5ic3A7Tm8gc3ltcGF0aHkuPGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU29ycnkuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KJm5ic3A7ICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqPGJyPg0KJm5ic3A7ICZuYnNwOyBJUHY0IGlzIG92ZXI8YnI+DQombmJzcDsgJm5i
c3A7IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPzxicj4NCiZuYnNwOyAmbmJz
cDsgPGEgaHJlZj0iaHR0cDovL3d3dy5jb25zdWxpbnRlbC5lcyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHA6Ly93d3cuY29uc3VsaW50ZWwuZXM8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgSVB2NiBD
b21wYW55PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBj
b250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRp
YWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBvZiB0aGUg
aW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl
Y2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRp
b24NCiBvcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlIG9mIHRoZSBjb250ZW50cyBvZiB0
aGlzIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQu
PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgdjZvcHMgbWFp
bGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5v
cmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJyPg0K
PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNw
OyAmbmJzcDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJt
YWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJz
cDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv
cHM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5i
c3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZuYnNwOyAmbmJzcDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNw
OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4N
CiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCklQdjQgaXMgb3Zlcjxi
cj4NCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPzxicj4NCjxhIGhyZWY9Imh0
dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmNvbnN1
bGludGVsLmVzPC9hPjxicj4NClRoZSBJUHY2IENvbXBhbnk8YnI+DQo8YnI+DQpUaGlzIGVsZWN0
cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdl
ZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3Ig
dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3Qg
dGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5
aW5nLCBkaXN0cmlidXRpb24gb3INCiB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3Jt
YXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC48YnI+DQo8YnI+
DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp
ZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BEB73854CBB342DB99DA1F508D7736C2cablecomcastcom_--


From nobody Mon Jul 17 05:30:13 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29906131B58 for ; Mon, 17 Jul 2017 05:29:51 -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 3aGKbRekQ0EG for ; Mon, 17 Jul 2017 05:29:48 -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 6DBC1131B3F for ; Mon, 17 Jul 2017 05:29:47 -0700 (PDT)
X-AuditID: 60721c4c-001ff70000004e62-d7-596cadb975ca
Received: from VAADCEX16.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 CB.55.20066.9BDAC695; Mon, 17 Jul 2017 08:29:45 -0400 (EDT)
Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX16.cable.comcast.com (147.191.102.83) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 08:29:44 -0400
Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 17 Jul 2017 08:29:44 -0400
From: "Brzozowski, John" 
To: Stephen Honlue , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/tSiyacM1/hfIEykN3ouQq0Z3w==
Date: Mon, 17 Jul 2017 12:29:44 +0000
Message-ID: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>  <9a3a454b-d1fa-406c-7f39-5add5f422d16@gmail.com>
In-Reply-To: <9a3a454b-d1fa-406c-7f39-5add5f422d16@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.115.73.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf0wbZRj2u2vpgXzu25W2HycjcokmWzaGP4KN6DJ1idVIpjOZlpiMoz3b rkdL7loY/kjmH+KEGaeZDKoyZoqTMR3RGQrRZXTEjc1FZ4hLBjMqNVm7PzSbKdmI4H13V7j6 1733PN/7Ps/7fJdjaHaxlGNCkZgoRwSJLymzNCtPuzeNfyF56y6+5XZ/cmMQuC98/x29lfKM J67aPMnkLeo5qqnsUb8ohdpFefOW5rLgmSM3qbbkM3v6B3KWvWDU0w1KGYwewn+OjFq7QRnD ojEKH57qovSX0wC//e4irb9MA5z6NWUjLSWoHp+cnFVrhqlAHvzXHw8S2I524IUfLllJXYFe wGNdN216XYvzXy8BUlvQvXjx9j9W0grRNny6d70+fsKKl2f7KHKmFD2GPzj6pnYeICdeOH9c w2nkwlcyhyndNcLJb3+k9dqBs/NLmq5D1frl72GLjm/EFy9ngF7X4W+GThl4Db49MFNCPNBo PT4xsVkvH8HZdKWuVIMP9vyuuYdoLZ7uzxidLnxmKmU9ALiEyVBidVBidVDCNChhGjQIrMdA dbsg+H2twWg8VvdArU9okcRaX7TVJygx8vwKkBuWq55NgRu9njRADODL4fhHkpe1Cu1KZ2sa hBmKd8BLJWEve1dL1N8ZFJTgLjkuiQpfAat61JNwBW6JS2Geg/uOq6h9BY2IHYokxtRPiq+G n5JBrhVOiSttIV8oGld2xWUpDTBDq2OXB8hYv9D5qihHdbE0uJux8C543/huL4sCQkwMi2Kb KBfYDobhMawnymtlMSDueSUkxQq02tfdrzLIzGhm10H3VMjLOs2EyW8NbCA0Z6b/b5liStMg wJSrvvcTeai0Ca1KKGBI2+E7JKTyAqrJVsKNIyrIFkCT5Dq406ZG5CxQxXLnQQ9gEn238hRz cvHcAsVaItGIyLng62QeIk3BeGRlcc4Jp59v9rJrTAQxwFXB/QR3mPBVD9w98BphK01ssY3C jyEHfOoXY4dnyeLl6m9jdW8WPkws3WmA2toYvqRdkIGZtq6CXrK1w2CK1XJqvJQar71Rizcm xMzxzjVq8RqoEe/PjVq8BlgU7yFCOQtUsRK3F2zo2Dpzbv7s0fomas6+lD84O1zRWT2cuZxd /vyz/NyBiYz1w8mZl+cDr53qGmVxaOoKNfHizvhvqX8/9qd+CuZ6hq4PK3DL4HWANznqryZz 6Se+DD61/b1J27b8NdB0ITu0Gz7eN9L7fsOTh4bEHWveGGu844RHGMgeo7v2NfSHp3mLEhTu 30DLivAf0N8tzY4FAAA=
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 12:29:51 -0000

VGhhbmsgeW91Lg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg
b2YgU3RlcGhlbiBIb25sdWUgPGhvbmx1ZUBnbWFpbC5jb20+DQpEYXRlOiBNb25kYXksIEp1bHkg
MTcsIDIwMTcgYXQgMTA6MzgNClRvOiB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS
ZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IG9mIElQdjYtb25seSBXaS1GaSBmb3Ig
SUVURiBNZWV0aW5ncw0KDQogICAgTXkgdGFrZSBmb3IgdGhpcyBpczogSVB2NiBvbmx5IHBlciB0
aGUgSS1EIGZvciB0aGUgYmFsYW5jZSBvZiBJRVRGIHdlZWs/DQogICAgDQogICAgV2UgaGF2ZSBi
ZWVuIHN0YW5kYXJkaXppbmcgSVB2NiBmb3Igb3ZlciB0d2VudHkgeWVhcnMgbm93LCBpdCdzIGp1
c3Qgc28NCiAgICBsb2dpY2FsIHRvIHByZWFjaCBieSBleGFtcGxlLg0KICAgIA0KICAgIFJlZ2Fy
ZHMuDQogICAgDQogICAgDQogICAgT24gMTcvMDcvMjAxNyAxMjozNCwgSmVuIExpbmtvdmEgd3Jv
dGU6DQogICAgPiBPbiBNb24sIEp1bCAxNywgMjAxNyBhdCA2OjE3IFBNLCBKT1JESSBQQUxFVCBN
QVJUSU5FWg0KICAgID4gPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiB3cm90ZToNCiAgICA+
PiBJbiB0aGUgcmVhbCB3b3JsZCwgeW91IHdpbGwgbm90IGRpc2FibGUgSVB2NCBpbiB0aGUgTEFO
cyBvZiBlbmQtdXNlcnMgb3IgZW50ZXJwcmlzZSBjdXN0b21lcnMgKGF0IGxlYXN0IG5vdCBub3cs
IG1heSBiZSBpbiAzLTUgeWVhcnMgZnJvbSBub3cpLg0KICAgID4gSSBkaXNhZ3JlZSB3aXRoIHRo
aXMgc3RhdGVtZW50LiBUaGVyZSBhcmUgbmV0d29ya3MgZG9pbmcgdGhpcy4gUmlnaHQNCiAgICA+
IGhlcmUgcmlnaHQgbm93Lg0KICAgID4NCiAgICA+PiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0t
LQ0KICAgID4+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRl
ICJCcnpvem93c2tpLCBKb2huIiA8Sm9obl9Ccnpvem93c2tpQGNvbWNhc3QuY29tPg0KICAgID4+
IFJlc3BvbmRlciBhOiA8Sm9obl9Ccnpvem93c2tpQGNvbWNhc3QuY29tPg0KICAgID4+IEZlY2hh
OiBsdW5lcywgMTcgZGUganVsaW8gZGUgMjAxNywgMTA6MTQNCiAgICA+PiBQYXJhOiBOb2FoIDxu
b2FoQG5lby5jby50ej4sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4NCiAgICA+PiBDQzog
SmltIE1hcnRpbiA8amltQGRhZWRlbHVzLmNvbT4sIElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9y
Zz4sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPiwgUnVzcyBIb3VzbGV5IDxob3Vz
bGV5QHZpZ2lsc2VjLmNvbT4sIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20+LCBTdXJlc2ggS3Jp
c2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+DQogICAgPj4gQXN1bnRvOiBSZTogW3Y2
b3BzXSBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IG9mIElQdjYtb25seSBXaS1GaSBmb3IgSUVURiBN
ZWV0aW5ncw0KICAgID4+DQogICAgPj4gICAgIEFncmVlIHdpdGggTm9haCBhbmQgVGVkLg0KICAg
ID4+DQogICAgPj4gICAgIE5vdGUgdGhlIEktRCBleHBsaWNpdGx5IGRvY3VtZW50cyB0aGF0IGEg
ZmFsbGJhY2ssIGR1YWwgc3RhY2sgU1NJRCBtdXN0IHJlbWFpbiBhdmFpbGFibGUgYXMgTm9haCBt
ZW50aW9ucyBiZWxvdy4NCiAgICA+Pg0KICAgID4+ICAgICBJIGZhaWwgdG8gc2VlIGhvdyBkb2lu
ZyB0aGlzIHdpbGwgaGFybSBvciBkaXNjcmltaW5hdGUuDQogICAgPj4NCiAgICA+PiAgICAgV2Ug
ZG8gbmVlZCB0byBlYXQgb3VyIG93biBkb2dmb29kLCBvdGhlcndpc2Ugd2UgYXJlIGh5cG9jcml0
ZXMuDQogICAgPj4NCiAgICA+PiAgICAgSm9obg0KICAgID4+DQogICAgPj4gICAgICsxLTQ4NC05
NjItMDA2MA0KICAgID4+DQogICAgPj4gICAgIEZyb206DQogICAgPj4gICAgIHY2b3BzIDx2Nm9w
cy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTm9haCA8bm9haEBuZW8uY28udHo+DQog
ICAgPj4gICAgIERhdGU6IE1vbmRheSwgSnVseSAxNywgMjAxNyBhdCAwOTowMQ0KICAgID4+ICAg
ICBUbzogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPg0KICAgID4+ICAgICBDYzogUmFuZHkg
QnVzaCA8cmFuZHlAcHNnLmNvbT4sIHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4sIEFsaXNzYSBDb29w
ZXIgPGFsaXNzYUBjb29wZXJ3LmluPiwgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNv
bT4sIEppbSBNYXJ0aW4gPGppbUBkYWVkZWx1cy5jb20+LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVz
aC5rcmlzaG5hbkBnbWFpbC5jb20+DQogICAgPj4gICAgIFN1YmplY3Q6IFJlOiBbdjZvcHNdIElu
Y3JlbWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5IFdpLUZpIGZvciBJRVRGIE1lZXRpbmdz
DQogICAgPj4NCiAgICA+Pg0KICAgID4+DQogICAgPj4gICAgIEZXSVcgYW5kIHRvIGNhdGVyIGZv
ciBhbGwsIHdvdWxkIGEgZmFsbGJhY2sgZHVhbCBzdGFjayBTU0lEIHdvcmsgZm9yIHRoZSBzdGF0
dXMgcXVvIHdoaWxlIHRoaXMgMm5kIHY2IFNTSUQgaXMgYWxzbyBleHBlcmltZW50ZWQgdXBvbiB3
aGljaCBpcyBhIGdyZWF0IGlkZWEgY29uc2lkZXJpbmcgdGhpcyBpcyBJRVRGLg0KICAgID4+DQog
ICAgPj4NCiAgICA+Pg0KICAgID4+ICAgICBOb2FoDQogICAgPj4NCiAgICA+Pg0KICAgID4+DQog
ICAgPj4gICAgIE9uIDE3IEp1bCAyMDE3IDk6NTQgYS5tLiwgIlRlZCBMZW1vbiIgPG1lbGxvbkBm
dWd1ZS5jb20+IHdyb3RlOg0KICAgID4+DQogICAgPj4gICAgIEkgZG9uJ3QgdGhpbmsgdGhpcyBp
cyBhIHNvY2lhbCBqdXN0aWNlIGlzc3VlLiAgIERvZXMgdGhlIElFVEYgdGhpbmsgdGhhdCBJUHY2
IHdvcmtzLCBvciBub3Q/ICAgSWYgd2UgdGhpbmsgaXQgd29ya3MsIGFuZCB3ZSBoYXZlIGJlZW4g
d29ya2luZyBmb3Igd2hhdCwgMjAgeWVhcnMsIHRvIG1ha2UgaXQgd29yaywgYW5kIHdlIGhhdmUg
ZGVzaWduZWQgYWxsIHRoaXMgZ3JlYXQNCiAgICA+PiAgICAgIHRyYW5zaXRpb24gdGVjaCwgdGhl
biB3aHkgb24gZWFydGggd291bGQgd2Ugbm90IHdhbnQgdG8gdXNlIGl0PyAgIFRoaXMgaXNuJ3Qg
Im9uZSBkcmFmdC4iICAgVGhpcyBpcyByb3VnaGx5IGhhbGYgdGhlIHdvcmsgb2YgdGhlIElFVEYg
Zm9yIHRoZSBwYXN0IHR3byBkZWNhZGVzLg0KICAgID4+DQogICAgPj4NCiAgICA+PiAgICAgT24g
TW9uLCBKdWwgMTcsIDIwMTcgYXQgODo1MSBBTSwgSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRp
LnBhbGV0QGNvbnN1bGludGVsLmVzPiB3cm90ZToNCiAgICA+Pg0KICAgID4+ICAgICBTbyB3ZSBh
Z3JlZSB0byBjaGFuZ2UgdGhlIHJ1bGVzIHNvIHRoYXQgd2UgdXNlIHRoaXMgbmV0d29yayBmb3Ig
ZXZlcnkgSUQgdGhhdCB3YW50IHRvIGV4cGVyaW1lbnQgd2l0aCBpdD8gT3RoZXJ3aXNlIHdlIGRp
c2NyaW1pbmF0ZSBhbW9uZyBkaWZmZXJlbnQgYXV0aG9ycyDigKYNCiAgICA+Pg0KICAgID4+ICAg
ICBJIHRoaW5rIGlzIGEgcmVhbGx5IGJhZCBwcmVjZWRlbnQuDQogICAgPj4NCiAgICA+PiAgICAg
UmVnYXJkcywNCiAgICA+PiAgICAgSm9yZGkNCiAgICA+Pg0KICAgID4+DQogICAgPj4gICAgIC0t
LS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQogICAgPj4gICAgIERlOiBUZWQgTGVtb24gPG1lbGxv
bkBmdWd1ZS5jb20+DQogICAgPj4gICAgIFJlc3BvbmRlciBhOiA8bWVsbG9uQGZ1Z3VlLmNvbT4N
CiAgICA+PiAgICAgRmVjaGE6IGx1bmVzLCAxNyBkZSBqdWxpbyBkZSAyMDE3LCA4OjQ4DQogICAg
Pj4gICAgIFBhcmE6IEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldEBjb25zdWxpbnRl
bC5lcz4NCiAgICA+PiAgICAgQ0M6IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4sIEppbSBN
YXJ0aW4gPGppbUBkYWVkZWx1cy5jb20+LCBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPiwgU3Vy
ZXNoDQogICAgPj4gICAgICBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbT4sIFJ1
c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+LCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FA
Y29vcGVydy5pbj4NCiAgICA+PiAgICAgQXN1bnRvOiBSZTogW3Y2b3BzXSBJbmNyZW1lbnRhbCBE
ZXBsb3ltZW50IG9mIElQdjYtb25seSBXaS1GaSBmb3IgSUVURiBNZWV0aW5ncw0KICAgID4+DQog
ICAgPj4gICAgICAgICBJIGRvbid0IGFjdHVhbGx5IGtub3cgd2hhdCB0aGUgZ29hbCBvZiB0aGUg
SUVURiBuZXR3b3JrIGlzIG90aGVyIHRoYW4gdG8gcHJvdmlkZSBjb25uZWN0aXZpdHkuICAgQmVj
YXVzZSBvZiB0aGUgdmljaXNzaXR1ZGVzIG9mIGhvdGVsIHRvcG9sb2d5LCBpdCBpcyBvZnRlbiB0
aGUgY2FzZSB0aGF0IElFVEYgcGFydGljaXBhbnRzIGV4cGVyaWVuY2UgaXNzdWVzIHdpdGggdGhl
DQogICAgPj4gICAgICBuZXR3b3JrIGF0IGxlYXN0IG9uY2Ugb3IgdHdpY2UgcGVyIElFVEYgZGVz
cGl0ZSB0aGUgYmVzdCBlZmZvcnRzIChhbmQgdGhleSBhcmUgcXVpdGUgZXhjZXB0aW9uYWwpIG9m
IHRoZSBOT0MgdGVhbS4gICBJIGRvIG5vdCByZWFsbHkgc2VlIHdoYXQgdGhlIGRhbWFnZSBpcyB0
aGF0IHlvdSBhcmUgaG9waW5nIHRvIHByb3RlY3QgYWdhaW5zdCBoZXJlLiAgIFVzZXJzIHdobyBk
b24ndCByZWFkIHRoZSBOT0MgYW5ub3VuY2VtZW50PyAgIE5vIHN5bXBhdGh5Lg0KICAgID4+ICAg
ICAgIFNvcnJ5Lg0KICAgID4+DQogICAgPj4NCiAgICA+Pg0KICAgID4+DQogICAgPj4NCiAgICA+
PiAgICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KICAg
ID4+ICAgICBJUHY0IGlzIG92ZXINCiAgICA+PiAgICAgQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5l
dyBJbnRlcm5ldCA/DQogICAgPj4gICAgIGh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXMNCiAgICA+
PiAgICAgVGhlIElQdjYgQ29tcGFueQ0KICAgID4+DQogICAgPj4gICAgIFRoaXMgZWxlY3Ryb25p
YyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9y
IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUg
dXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcs
IGRpc3RyaWJ1dGlvbiBvcg0KICAgID4+ICAgICAgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlz
IGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuDQog
ICAgPj4NCiAgICA+Pg0KICAgID4+DQogICAgPj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4gICAgIHY2b3BzIG1haWxpbmcgbGlzdA0K
ICAgID4+ICAgICB2Nm9wc0BpZXRmLm9yZw0KICAgID4+ICAgICBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgPj4NCiAgICA+Pg0KICAgID4+DQogICAgPj4N
CiAgICA+Pg0KICAgID4+DQogICAgPj4NCiAgICA+Pg0KICAgID4+ICAgICBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+ICAgICB2Nm9wcyBtYWls
aW5nIGxpc3QNCiAgICA+PiAgICAgdjZvcHNAaWV0Zi5vcmcNCiAgICA+PiAgICAgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAgID4+DQogICAgPj4NCiAgICA+
Pg0KICAgID4+DQogICAgPj4NCiAgICA+Pg0KICAgID4+DQogICAgPj4gICAgIF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4gICAgIHY2b3BzIG1h
aWxpbmcgbGlzdA0KICAgID4+ICAgICB2Nm9wc0BpZXRmLm9yZw0KICAgID4+ICAgICBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgPj4NCiAgICA+Pg0KICAg
ID4+DQogICAgPj4NCiAgICA+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqDQogICAgPj4gSVB2NCBpcyBvdmVyDQogICAgPj4gQXJlIHlvdSByZWFkeSBmb3Ig
dGhlIG5ldyBJbnRlcm5ldCA/DQogICAgPj4gaHR0cDovL3d3dy5jb25zdWxpbnRlbC5lcw0KICAg
ID4+IFRoZSBJUHY2IENvbXBhbnkNCiAgICA+Pg0KICAgID4+IFRoaXMgZWxlY3Ryb25pYyBtZXNz
YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZp
ZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9m
IHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k
ZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3Ry
aWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGluY2x1
ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCiAgICA+Pg0KICAgID4+DQogICAg
Pj4NCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KICAgID4+IHY2b3BzIG1haWxpbmcgbGlzdA0KICAgID4+IHY2b3BzQGlldGYub3JnDQogICAg
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAgID4NCiAg
ICA+DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCiAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICB2Nm9wc0BpZXRmLm9yZw0KICAgIGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICANCg0K


From nobody Mon Jul 17 05:42:11 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B7131839 for ; Mon, 17 Jul 2017 05:42:09 -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=neo-co-tz.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 pud8JdGrIbAx for ; Mon, 17 Jul 2017 05:42:07 -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 6C85B131473 for ; Mon, 17 Jul 2017 05:42:07 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id b134so46661084wma.0 for ; Mon, 17 Jul 2017 05:42:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I0sxcxezjUYncatRhulwg/WmdjwPkTiS/NbXATSfus0=; b=vP9Vr7EQpgZCgDhbz0Q6bLUKzBEX0eQnXytSxWqLf0/qZJDGxDddYviN/YPVz+h9/g oTnmcUI7ouUN6rSzsqTIqaYeD7TdotgSmhfzvg5FUJWDqU2vW5QWNUK8k+3nr94GdlzV 7rU8/FgvWiCICgmaok7Cww+oo68Wgsidd5q9M73lM/+IdmE49Ne51wDG3DAQZLxM7qHQ 5VahxxkWo4ZHzRMBekZBSwCk53gRomcT/XI2pG7XQbEVzgWX5q48+0nHz52L5C5mekrp 2rF45uC7h4oc/JylCV+kNYt7ddYp1PL1kZcFucjPjDvAjIOhOHOlszk84v6Waeq+OR1Z QZZQ==
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=I0sxcxezjUYncatRhulwg/WmdjwPkTiS/NbXATSfus0=; b=diNZCzU72GcmyZIEgx2xxOKReCLFqswz1EmaD+yvqQzcloP2NPAiIF8puM8fXevV2D SY6L3DyV1j/klkBAxjDmfZaKLVcfITQmLWoIMEBnV6vSKYZ11pqKE7FO445G7k7ferpO 8ZehrmiyG8A/M+qcy/ux/3o++utDng0LjLmL2blc1c7VJr8IFxGsw9Jq4rpqEjvFAqfX W5WpphsgeJIRW9FH6f1aQ/dPNa/9MhC6OyAOC+r3eKk/9TaejjNjS9rtdybwKzyyFqx/ NQJzqkvDY+F/uRpGByWktdvORqtqeaL4pqIusDnJHnAgFHPbLzafS0f3QFBhp5tH1KTT QaFg==
X-Gm-Message-State: AIVw1138iII+i+RpT4z/NlFX6U9my8NP7Z/iXXgOIBvsWhgh/TEQr25G QmSfdFUH0nTomlhr7kDqIGaCMadc1i13
X-Received: by 10.28.12.195 with SMTP id 186mr1454353wmm.5.1500295325901; Mon, 17 Jul 2017 05:42:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.206.4 with HTTP; Mon, 17 Jul 2017 05:42:04 -0700 (PDT)
X-Originating-IP: [105.28.32.9]
Received: by 10.28.206.4 with HTTP; Mon, 17 Jul 2017 05:42:04 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  
From: Noah 
Date: Mon, 17 Jul 2017 15:42:04 +0300
Message-ID: 
To: Ted Lemon 
Cc: Alissa Cooper , Suresh Krishnan ,  Jen Linkova , "v6ops@ietf.org" , Jim Martin ,  Randy Bush , Russ Housley 
Content-Type: multipart/alternative; boundary="001a114420c0f5821f055482b958"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 12:42:10 -0000

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

On Mon, Jul 17, 2017 at 10:30 AM, Jen Linkova  wrote:

> Actually if the fallback dual-stack network requires an explicit
> configuration on the client side (as the draft recommends) to avoid
> users connecting to it accidentally, the number of clients falling
> back to the dual stack SSID is very good data point to demonstrate
> what % of users are experiencing issues.


I couldnt agree more... Lets walk the talk folks.

So do we have consensus for the experiment to go on now that its pretty
much logical for folks across the board that this is good stuff?


Cheers,
Noah

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



=
On Mon, Jul 17, 2017 at 10:30 AM, Jen Linkova <furry13@gmail.com> wrote:
Actually if the fallback dua=
l-stack network requires an explicit

configuration on the client side (as the draft recommends) to avoid

users connecting to it accidentally, the number of clients falling

back to the dual stack SSID is very good data point to demonstrate

what % of users are experiencing issues.

I couldnt agree more... Lets walk the talk folks.

So do we have consensus for the experiment to=
 go on now that its pretty much logical for folks across the board that thi=
s is good stuff?


Cheers,
Noah




--001a114420c0f5821f055482b958--


From nobody Mon Jul 17 06:52:25 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1245131BB0 for ; Mon, 17 Jul 2017 06:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 zM8t1Kz4GMJO for ; Mon, 17 Jul 2017 06:52:20 -0700 (PDT)
Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by ietfa.amsl.com (Postfix) with ESMTP id ED4C4131BAA for ; Mon, 17 Jul 2017 06:52:19 -0700 (PDT)
Received: from [188.170.81.216] (account dburk@burkov.aha.ru HELO GSP.local) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 511394021 for v6ops@ietf.org; Mon, 17 Jul 2017 16:52:17 +0300
To: v6ops@ietf.org
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>   
From: Dmitry Burkov 
Message-ID: 
Date: Mon, 17 Jul 2017 16:52:18 +0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; 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-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 13:52:24 -0000

IETF did more funny things... It can do anything, of course...


On 7/17/17 11:41 AM, Jen Linkova wrote:
> On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
>  wrote:
>> Tell your bank, your university, your library, etc., to try that.
>>
>> I now that some networks (mainly related to IETF work, vendors, etc.), are doing that, but not in a general market.
> Are you saying IETF should wait until everyone else has done it and
> proved it works and only then we feel safe enough to try it? ;)
>
>> -----Mensaje original-----
>> De: Jen Linkova 
>> Responder a: 
>> Fecha: lunes, 17 de julio de 2017, 10:34
>> Para: Jordi Palet Martinez 
>> CC: IPv6 Ops WG , Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>
>>      On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
>>       wrote:
>>      > In the real world, you will not disable IPv4 in the LANs of end-users or enterprise customers (at least not now, may be in 3-5 years from now).
>>
>>      I disagree with this statement. There are networks doing this. Right
>>      here right now.
>>
>>      > -----Mensaje original-----
>>      > De: v6ops  en nombre de "Brzozowski, John" 
>>      > Responder a: 
>>      > Fecha: lunes, 17 de julio de 2017, 10:14
>>      > Para: Noah , Ted Lemon 
>>      > CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
>>      > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>      >
>>      >     Agree with Noah and Ted.
>>      >
>>      >     Note the I-D explicitly documents that a fallback, dual stack SSID must remain available as Noah mentions below.
>>      >
>>      >     I fail to see how doing this will harm or discriminate.
>>      >
>>      >     We do need to eat our own dogfood, otherwise we are hypocrites.
>>      >
>>      >     John
>>      >
>>      >     +1-484-962-0060
>>      >
>>      >     From:
>>      >     v6ops  on behalf of Noah 
>>      >     Date: Monday, July 17, 2017 at 09:01
>>      >     To: Ted Lemon 
>>      >     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley , Jim Martin , Suresh Krishnan 
>>      >     Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>      >
>>      >
>>      >
>>      >     FWIW and to cater for all, would a fallback dual stack SSID work for the status quo while this 2nd v6 SSID is also experimented upon which is a great idea considering this is IETF.
>>      >
>>      >
>>      >
>>      >     Noah
>>      >
>>      >
>>      >
>>      >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>>      >
>>      >     I don't think this is a social justice issue.   Does the IETF think that IPv6 works, or not?   If we think it works, and we have been working for what, 20 years, to make it work, and we have designed all this great
>>      >      transition tech, then why on earth would we not want to use it?   This isn't "one draft."   This is roughly half the work of the IETF for the past two decades.
>>      >
>>      >
>>      >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
>>      >
>>      >     So we agree to change the rules so that we use this network for every ID that want to experiment with it? Otherwise we discriminate among different authors …
>>      >
>>      >     I think is a really bad precedent.
>>      >
>>      >     Regards,
>>      >     Jordi
>>      >
>>      >
>>      >     -----Mensaje original-----
>>      >     De: Ted Lemon 
>>      >     Responder a: 
>>      >     Fecha: lunes, 17 de julio de 2017, 8:48
>>      >     Para: JORDI PALET MARTINEZ 
>>      >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
>>      >      Krishnan , Russ Housley , Alissa Cooper 
>>      >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
>>      >
>>      >         I don't actually know what the goal of the IETF network is other than to provide connectivity.   Because of the vicissitudes of hotel topology, it is often the case that IETF participants experience issues with the
>>      >      network at least once or twice per IETF despite the best efforts (and they are quite exceptional) of the NOC team.   I do not really see what the damage is that you are hoping to protect against here.   Users who don't read the NOC announcement?   No sympathy.
>>      >       Sorry.
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >     **********************************************
>>      >     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 confidential. 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 disclosure, copying, distribution or
>>      >      use of the contents of this information, including attached files, is prohibited.
>>      >
>>      >
>>      >
>>      >     _______________________________________________
>>      >     v6ops mailing list
>>      >     v6ops@ietf.org
>>      >     https://www.ietf.org/mailman/listinfo/v6ops
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >     _______________________________________________
>>      >     v6ops mailing list
>>      >     v6ops@ietf.org
>>      >     https://www.ietf.org/mailman/listinfo/v6ops
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >     _______________________________________________
>>      >     v6ops mailing list
>>      >     v6ops@ietf.org
>>      >     https://www.ietf.org/mailman/listinfo/v6ops
>>      >
>>      >
>>      >
>>      >
>>      > **********************************************
>>      > 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 confidential. 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 disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>>      >
>>      >
>>      >
>>      > _______________________________________________
>>      > v6ops mailing list
>>      > v6ops@ietf.org
>>      > https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>      --
>>      SY, Jen Linkova aka Furry
>>
>>
>>
>>
>> **********************************************
>> 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 confidential. 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 disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>


From nobody Mon Jul 17 07:00:39 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6E131BEB for ; Mon, 17 Jul 2017 07:00:37 -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, 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 ew5YRlcVkOoP for ; Mon, 17 Jul 2017 07:00:35 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0617131BEC for ; Mon, 17 Jul 2017 07:00:21 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id v202so50136404itb.0 for ; Mon, 17 Jul 2017 07:00: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=RAHrXVsqH/tPHv+3uUQni/z4EXwUYXCzb/gZfzEch5k=; b=kv0ghFOZQ+NeQCbN7j5k5IJd3Hlkn15RCpT1WYhbo9Sh7W9O4Wv7r3LqrIfU/N9121 MzFgGzDE7q7ABKfIeGFWqJ1/ALnESaJ8RU8zVkzqJiaXcxcNX1p9miMfJFg2mDQqZNg7 jVFZBBJQhrxZD4Lu/YL9T6hyytYED7nzMVy+sXm0yMuQrJg5jFp3KOpKnBfbnqv4LjYz CZ+RSZSF9Hfxz8Z2UJZpQ9P2dL3xTucI6dxVJNdM8wuJcWeAsOHKAZKPhXi+E8ac93bP QLBRu1nhEQ3JnUqbSgd24dtic/rP1tmBRQNQ5EI0/glBDSjNsijkZzMkoRmZl0uFYn3w ejSw==
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=RAHrXVsqH/tPHv+3uUQni/z4EXwUYXCzb/gZfzEch5k=; b=Cx50g/ZR+T5EE+OrnrUPLWLtTJxo1exAMBhoyMRPXq2F6/xEgU1P6CZom6aCpHrs4E fvAcftqhVEbgV+6AC9GiNQRRuri+/1i8wBjVN0tSomq3rry1s3rf1XOrm7vMR7qbqnkr Sv+F/kcsfrakS/b718RCUsqE/kGGT/yCgg3KCW3Ehuw5LAs0nkYagUjYn9R8KnhC4BZU AQwWXb7pTRBAu+srsNlfiDPfF7MFaObsfNEnMe5IGadnZ+vRl2po/gzq2S8ho2OC2zAs hjKmp4T96sdB8Y5KO39GxuzXqCtHp8Ac9Uxt19NZ97yKFEMXgOGIt69X8vzWMRqOFlQ/ 3jnQ==
X-Gm-Message-State: AIVw1127TISnSTV639rdxHPgcGYLntR1psbUH56N37W2If2YtN+bFxRe 2qloxf5pTzK6sqazaXOeiYjp8joDfQ==
X-Received: by 10.36.68.193 with SMTP id o184mr5507284ita.59.1500300020868; Mon, 17 Jul 2017 07:00:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 06:59:59 -0700 (PDT)
In-Reply-To: <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>
From: Jen Linkova 
Date: Mon, 17 Jul 2017 23:59:59 +1000
Message-ID: 
To: Jordi Palet Martinez 
Cc: IPv6 Ops WG , Jim Martin ,  Russ Housley , Suresh Krishnan ,  Alissa Cooper , Randy Bush 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:00:38 -0000

On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
 wrote:
> I=E2=80=99m saying:
>
> 1) We should not try experiments in the IETF network, it has been the rul=
e for ages.
> 2) If we decide to change that rule, we should try what is good for the m=
arket, not what we =E2=80=9Cwish=E2=80=9D

Could you pls elaborate on why proving that IPv6-only/NAT64 network
works (or if it does not, identifying the issues and getting them
fixed) is not good for the market? If, as you said, nobody is doing
Ipv6-only (and we have seen a number of comments stating the
opposite), wouldn't it be good for them if we prove that v6-only works
and start working on issues? If, as some people have said, there are
Ipv6-only network out >
> Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivity, =
is feasible. This is what we need to try.

>
>
> -----Mensaje original-----
> De: Jen Linkova 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 10:42
> Para: Jordi Palet Martinez 
> CC: IPv6 Ops WG , Jim Martin , Alissa C=
ooper , Suresh Krishnan , Rus=
s Housley , Randy Bush 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Me=
etings
>
>     On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
>      wrote:
>     > Tell your bank, your university, your library, etc., to try that.
>     >
>     > I now that some networks (mainly related to IETF work, vendors, etc=
.), are doing that, but not in a general market.
>
>     Are you saying IETF should wait until everyone else has done it and
>     proved it works and only then we feel safe enough to try it? ;)
>
>     > -----Mensaje original-----
>     > De: Jen Linkova 
>     > Responder a: 
>     > Fecha: lunes, 17 de julio de 2017, 10:34
>     > Para: Jordi Palet Martinez 
>     > CC: IPv6 Ops WG , Jim Martin , Ru=
ss Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
>     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
>     >
>     >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
>     >      wrote:
>     >     > In the real world, you will not disable IPv4 in the LANs of e=
nd-users or enterprise customers (at least not now, may be in 3-5 years fro=
m now).
>     >
>     >     I disagree with this statement. There are networks doing this. =
Right
>     >     here right now.
>     >
>     >     > -----Mensaje original-----
>     >     > De: v6ops  en nombre de "Brzozowski, =
John" 
>     >     > Responder a: 
>     >     > Fecha: lunes, 17 de julio de 2017, 10:14
>     >     > Para: Noah , Ted Lemon 
>     >     > CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley ,=
 Randy Bush , Suresh Krishnan 
>     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi=
 for IETF Meetings
>     >     >
>     >     >     Agree with Noah and Ted.
>     >     >
>     >     >     Note the I-D explicitly documents that a fallback, dual s=
tack SSID must remain available as Noah mentions below.
>     >     >
>     >     >     I fail to see how doing this will harm or discriminate.
>     >     >
>     >     >     We do need to eat our own dogfood, otherwise we are hypoc=
rites.
>     >     >
>     >     >     John
>     >     >
>     >     >     +1-484-962-0060
>     >     >
>     >     >     From:
>     >     >     v6ops  on behalf of Noah 
>     >     >     Date: Monday, July 17, 2017 at 09:01
>     >     >     To: Ted Lemon 
>     >     >     Cc: Randy Bush , v6ops , A=
lissa Cooper , Russ Housley , Jim =
Martin , Suresh Krishnan 
>     >     >     Subject: Re: [v6ops] Incremental Deployment of IPv6-only =
Wi-Fi for IETF Meetings
>     >     >
>     >     >
>     >     >
>     >     >     FWIW and to cater for all, would a fallback dual stack SS=
ID work for the status quo while this 2nd v6 SSID is also experimented upon=
 which is a great idea considering this is IETF.
>     >     >
>     >     >
>     >     >
>     >     >     Noah
>     >     >
>     >     >
>     >     >
>     >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  =
wrote:
>     >     >
>     >     >     I don't think this is a social justice issue.   Does the =
IETF think that IPv6 works, or not?   If we think it works, and we have bee=
n working for what, 20 years, to make it work, and we have designed all thi=
s great
>     >     >      transition tech, then why on earth would we not want to =
use it?   This isn't "one draft."   This is roughly half the work of the IE=
TF for the past two decades.
>     >     >
>     >     >
>     >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
>     >     >
>     >     >     So we agree to change the rules so that we use this netwo=
rk for every ID that want to experiment with it? Otherwise we discriminate =
among different authors =E2=80=A6
>     >     >
>     >     >     I think is a really bad precedent.
>     >     >
>     >     >     Regards,
>     >     >     Jordi
>     >     >
>     >     >
>     >     >     -----Mensaje original-----
>     >     >     De: Ted Lemon 
>     >     >     Responder a: 
>     >     >     Fecha: lunes, 17 de julio de 2017, 8:48
>     >     >     Para: JORDI PALET MARTINEZ 
>     >     >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
>     >     >      Krishnan , Russ Housley , Alissa Cooper 
>     >     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only W=
i-Fi for IETF Meetings
>     >     >
>     >     >         I don't actually know what the goal of the IETF netwo=
rk is other than to provide connectivity.   Because of the vicissitudes of =
hotel topology, it is often the case that IETF participants experience issu=
es with the
>     >     >      network at least once or twice per IETF despite the best=
 efforts (and they are quite exceptional) of the NOC team.   I do not reall=
y see what the damage is that you are hoping to protect against here.   Use=
rs who don't read the NOC announcement?   No sympathy.
>     >     >       Sorry.
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >     **********************************************
>     >     >     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 confidential. 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 disclosure, copying, distribution or
>     >     >      use of the contents of this information, including attac=
hed files, is prohibited.
>     >     >
>     >     >
>     >     >
>     >     >     _______________________________________________
>     >     >     v6ops mailing list
>     >     >     v6ops@ietf.org
>     >     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >     _______________________________________________
>     >     >     v6ops mailing list
>     >     >     v6ops@ietf.org
>     >     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >     _______________________________________________
>     >     >     v6ops mailing list
>     >     >     v6ops@ietf.org
>     >     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > **********************************************
>     >     > 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 pri=
vileged or confidential. The information is intended to be for the use of t=
he individual(s) named above. If you are not the intended recipient be awar=
e that any disclosure, copying, distribution or use of the contents of this=
 information, including attached files, is prohibited.
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > v6ops mailing list
>     >     > v6ops@ietf.org
>     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
>     >
>     >     --
>     >     SY, Jen Linkova aka Furry
>     >
>     >
>     >
>     >
>     > **********************************************
>     > 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 privilege=
d or confidential. The information is intended to be for the use of the ind=
ividual(s) named above. If you are not the intended recipient be aware that=
 any disclosure, copying, distribution or use of the contents of this infor=
mation, including attached files, is prohibited.
>     >
>     >
>     >
>     > _______________________________________________
>     > v6ops mailing list
>     > v6ops@ietf.org
>     > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>     --
>     SY, Jen Linkova aka Furry
>
>
>
>
> **********************************************
> 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 c=
onfidential. The information is intended to be for the use of the individua=
l(s) named above. If you are not the intended recipient be aware that any d=
isclosure, copying, distribution or use of the contents of this information=
, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--=20
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 07:08:56 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81DF131BE0 for ; Mon, 17 Jul 2017 07:08:52 -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, 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=fugue-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 hQSKnDLP13Ah for ; Mon, 17 Jul 2017 07:08:48 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 53231131BCC for ; Mon, 17 Jul 2017 07:08:48 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id k14so80460267pgr.0 for ; Mon, 17 Jul 2017 07:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oh82KcpARUcvxAOtkFKmn64pB9STo/Dzv4MGmXFryX4=; b=haddEBGu+tQzoAn2Gvr5+lAokdJUwnYgXVyJ99rlvsjV88vXCCBQ5sD8VLLMa9EK/p iGhr/UwLc73AwVafZlNzq2JBIRl0VTmmXOIKt5UAAsWq4qFQoXGk19GQCFjPakfYqbYL l/9e8ZtUFIWsC9b4CkjZYV00Dce6eXm+BCx9q62YtpJ6X+L6oCtgr2/J7VpSwilLd81M evgP9OcvW6fF3TPk0omn46MvBCZUmqfLEsh5U3jaFwdgSnkLWxxtgdIfDJFnpQdwizS/ fMFZ0NFk+EPxy0bT+H0QSh5eZkmeeKDHx59Q+8ijIa3Ktdxpxi1qK7IqeAXurleJexiF OGQg==
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=oh82KcpARUcvxAOtkFKmn64pB9STo/Dzv4MGmXFryX4=; b=FIppT27/6M5orPT7pF0iJ79I3sHQOFvxRsiZ49SBtNSOsm26clhabtGrPweDgtS6q7 7QJrfTewGup+BT9NSzW1JDTTwywtN87ujfDI67wwJjlYaU6vMtr79mU+KvhSm2wofNpN n63OvcJQwEcLcqpTEVQYMqBndqyyV3tiobjZvzDudWI24fWBQDJ4tEZUES5Ui7qzJT8d zILw9oWIqCAKvJ4rLJ+18x9wSOJTS1m9DJKeAiwdXVSuS0DDgZsdocipDERlEannvlHD PAWwlKM1Snb4WBymxNZGauuzhnDJbkRJ5jb6SyKXYrTuGYGZ/Z3yQo9M3FRtr0vGYJn9 pYUg==
X-Gm-Message-State: AIVw111nStlDD2Rs899XPLOE8tmkkQacQLABI/dc9ZWShLJSbESAw3T1 nh0sotj0jd9wvS0keL4+vZKezAIgAE0J
X-Received: by 10.99.62.65 with SMTP id l62mr18975887pga.220.1500300527732; Mon, 17 Jul 2017 07:08:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 07:08:07 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es> 
From: Ted Lemon 
Date: Mon, 17 Jul 2017 16:08:07 +0200
Message-ID: 
To: Jen Linkova 
Cc: Jordi Palet Martinez , Randy Bush ,  IPv6 Ops WG , Russ Housley , Alissa Cooper ,  Jim Martin , Suresh Krishnan 
Content-Type: multipart/alternative; boundary="94eb2c18ff6a031dba055483f09c"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:08:53 -0000

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

To be clear, the reason to privilege nat64 is that it gives you effectively
an IPv6-only network, with enough of a shim that most stuff that still
relies on legacy servers still works.   It is not that nat64 is the
transition technology that the market has chosen (I don't actually know
what the market has selected) but rather that it is the transition
technology that allows us to not run _any_ IPv4 on the link.

On Mon, Jul 17, 2017 at 3:59 PM, Jen Linkova  wrote:

> On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
>  wrote:
> > I=E2=80=99m saying:
> >
> > 1) We should not try experiments in the IETF network, it has been the
> rule for ages.
> > 2) If we decide to change that rule, we should try what is good for the
> market, not what we =E2=80=9Cwish=E2=80=9D
>
> Could you pls elaborate on why proving that IPv6-only/NAT64 network
> works (or if it does not, identifying the issues and getting them
> fixed) is not good for the market? If, as you said, nobody is doing
> Ipv6-only (and we have seen a number of comments stating the
> opposite), wouldn't it be good for them if we prove that v6-only works
> and start working on issues? If, as some people have said, there are
> Ipv6-only network out >
> > Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivity=
,
> is feasible. This is what we need to try.
>
> >
> >
> > -----Mensaje original-----
> > De: Jen Linkova 
> > Responder a: 
> > Fecha: lunes, 17 de julio de 2017, 10:42
> > Para: Jordi Palet Martinez 
> > CC: IPv6 Ops WG , Jim Martin , Alissa
> Cooper , Suresh Krishnan ,
> Russ Housley , Randy Bush 
> > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
> >
> >     On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
> >      wrote:
> >     > Tell your bank, your university, your library, etc., to try that.
> >     >
> >     > I now that some networks (mainly related to IETF work, vendors,
> etc.), are doing that, but not in a general market.
> >
> >     Are you saying IETF should wait until everyone else has done it and
> >     proved it works and only then we feel safe enough to try it? ;)
> >
> >     > -----Mensaje original-----
> >     > De: Jen Linkova 
> >     > Responder a: 
> >     > Fecha: lunes, 17 de julio de 2017, 10:34
> >     > Para: Jordi Palet Martinez 
> >     > CC: IPv6 Ops WG , Jim Martin ,
> Russ Housley , Suresh Krishnan <
> suresh.krishnan@gmail.com>, Alissa Cooper , Randy Bush
> 
> >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for
> IETF Meetings
> >     >
> >     >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
> >     >      wrote:
> >     >     > In the real world, you will not disable IPv4 in the LANs of
> end-users or enterprise customers (at least not now, may be in 3-5 years
> from now).
> >     >
> >     >     I disagree with this statement. There are networks doing this=
.
> Right
> >     >     here right now.
> >     >
> >     >     > -----Mensaje original-----
> >     >     > De: v6ops  en nombre de
> "Brzozowski, John" 
> >     >     > Responder a: 
> >     >     > Fecha: lunes, 17 de julio de 2017, 10:14
> >     >     > Para: Noah , Ted Lemon 
> >     >     > CC: Jim Martin , IPv6 Ops WG <
> v6ops@ietf.org>, Alissa Cooper , Russ Housley <
> housley@vigilsec.com>, Randy Bush , Suresh Krishnan <
> suresh.krishnan@gmail.com>
> >     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only
> Wi-Fi for IETF Meetings
> >     >     >
> >     >     >     Agree with Noah and Ted.
> >     >     >
> >     >     >     Note the I-D explicitly documents that a fallback, dual
> stack SSID must remain available as Noah mentions below.
> >     >     >
> >     >     >     I fail to see how doing this will harm or discriminate.
> >     >     >
> >     >     >     We do need to eat our own dogfood, otherwise we are
> hypocrites.
> >     >     >
> >     >     >     John
> >     >     >
> >     >     >     +1-484-962-0060
> >     >     >
> >     >     >     From:
> >     >     >     v6ops  on behalf of Noah <
> noah@neo.co.tz>
> >     >     >     Date: Monday, July 17, 2017 at 09:01
> >     >     >     To: Ted Lemon 
> >     >     >     Cc: Randy Bush , v6ops ,
> Alissa Cooper , Russ Housley ,
> Jim Martin , Suresh Krishnan 
> >     >     >     Subject: Re: [v6ops] Incremental Deployment of IPv6-onl=
y
> Wi-Fi for IETF Meetings
> >     >     >
> >     >     >
> >     >     >
> >     >     >     FWIW and to cater for all, would a fallback dual stack
> SSID work for the status quo while this 2nd v6 SSID is also experimented
> upon which is a great idea considering this is IETF.
> >     >     >
> >     >     >
> >     >     >
> >     >     >     Noah
> >     >     >
> >     >     >
> >     >     >
> >     >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon" 
> wrote:
> >     >     >
> >     >     >     I don't think this is a social justice issue.   Does th=
e
> IETF think that IPv6 works, or not?   If we think it works, and we have
> been working for what, 20 years, to make it work, and we have designed al=
l
> this great
> >     >     >      transition tech, then why on earth would we not want t=
o
> use it?   This isn't "one draft."   This is roughly half the work of the
> IETF for the past two decades.
> >     >     >
> >     >     >
> >     >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <
> jordi.palet@consulintel.es> wrote:
> >     >     >
> >     >     >     So we agree to change the rules so that we use this
> network for every ID that want to experiment with it? Otherwise we
> discriminate among different authors =E2=80=A6
> >     >     >
> >     >     >     I think is a really bad precedent.
> >     >     >
> >     >     >     Regards,
> >     >     >     Jordi
> >     >     >
> >     >     >
> >     >     >     -----Mensaje original-----
> >     >     >     De: Ted Lemon 
> >     >     >     Responder a: 
> >     >     >     Fecha: lunes, 17 de julio de 2017, 8:48
> >     >     >     Para: JORDI PALET MARTINEZ 
> >     >     >     CC: IPv6 Ops WG , Jim Martin <
> jim@daedelus.com>, Randy Bush , Suresh
> >     >     >      Krishnan , Russ Housley <
> housley@vigilsec.com>, Alissa Cooper 
> >     >     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-only
> Wi-Fi for IETF Meetings
> >     >     >
> >     >     >         I don't actually know what the goal of the IETF
> network is other than to provide connectivity.   Because of the
> vicissitudes of hotel topology, it is often the case that IETF participan=
ts
> experience issues with the
> >     >     >      network at least once or twice per IETF despite the
> best efforts (and they are quite exceptional) of the NOC team.   I do not
> really see what the damage is that you are hoping to protect against here=
.
>  Users who don't read the NOC announcement?   No sympathy.
> >     >     >       Sorry.
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >     **********************************************
> >     >     >     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 confidential. The information is intended to be for the
> use of the individual(s) named above. If you are not the intended recipie=
nt
> be aware that any disclosure, copying, distribution or
> >     >     >      use of the contents of this information, including
> attached files, is prohibited.
> >     >     >
> >     >     >
> >     >     >
> >     >     >     _______________________________________________
> >     >     >     v6ops mailing list
> >     >     >     v6ops@ietf.org
> >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >     _______________________________________________
> >     >     >     v6ops mailing list
> >     >     >     v6ops@ietf.org
> >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >     _______________________________________________
> >     >     >     v6ops mailing list
> >     >     >     v6ops@ietf.org
> >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > **********************************************
> >     >     > 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 confidential. The information is intended to be for the use
> of the individual(s) named above. If you are not the intended recipient b=
e
> aware that any disclosure, copying, distribution or use of the contents o=
f
> this information, including attached files, is prohibited.
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > v6ops mailing list
> >     >     > v6ops@ietf.org
> >     >     > https://www.ietf.org/mailman/listinfo/v6ops
> >     >
> >     >
> >     >
> >     >     --
> >     >     SY, Jen Linkova aka Furry
> >     >
> >     >
> >     >
> >     >
> >     > **********************************************
> >     > 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 confidential. The information is intended to be for the use
> of the individual(s) named above. If you are not the intended recipient b=
e
> aware that any disclosure, copying, distribution or use of the contents o=
f
> this information, including attached files, is prohibited.
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > v6ops mailing list
> >     > v6ops@ietf.org
> >     > https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> >     --
> >     SY, Jen Linkova aka Furry
> >
> >
> >
> >
> > **********************************************
> > 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
> confidential. 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 disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


To be clear, the reason to privilege nat64 is that it give=
s you effectively an IPv6-only network, with enough of a shim that most stu=
ff that still relies on legacy servers still works. =C2=A0 It is not that n=
at64 is the transition technology that the market has chosen (I don't a=
ctually know what the market has selected) but rather that it is the transi=
tion technology that allows us to not run _any_ IPv4 on the link.

On Mon, Jul 17, 2017 =
at 3:59 PM, Jen Linkova <furry13@gmail.com> wrote:
On Mon, Jul 17, 2017 at 6:44 PM, =
JORDI PALET MARTINEZ

<jordi.palet@consulintel.e=
s> wrote:

> I=E2=80=99m saying:

>

> 1) We should not try experiments in the IETF network, it has been the =
rule for ages.

> 2) If we decide to change that rule, we should try what is good for th=
e market, not what we =E2=80=9Cwish=E2=80=9D



Could you pls elaborate on why proving that IPv6-only/NAT64 network<=
br>
works (or if it does not, identifying the issues and getting them

fixed) is not good for the market? If, as you said, nobody is doing

Ipv6-only (and we have seen a number of comments stating the

opposite), wouldn't it be good for them if we prove that v6-only works<=
br>
and start working on issues? If, as some people have said, there are

Ipv6-only network out >

> Turning off IPv4 in the WAN, but keeping som=
e sort of IPv4 connectivity, is feasible. This is what we need to try.



>

>


> -----Mensaje original--=
---

> De: Jen Linkova <furry13@gmail=
.com>

> Responder a: <furry13@gmail.co=
m>

> Fecha: lunes, 17 de julio de 2017, 10:42

> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>

> CC: IPv6 Ops WG <v6ops@ietf.org>, Jim Martin <jim@daedelus.com=
>, Alissa Cooper <alissa@coo=
perw.in>, Suresh Krishnan <suresh.krishnan@gmail.com>, Russ Housley <housley@vigilsec.com>, Randy Bush <randy@psg.com>

> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF=
 Meetings

>

>=C2=A0 =C2=A0 =C2=A0On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTIN=
EZ

>=C2=A0 =C2=A0 =C2=A0<j=
ordi.palet@consulintel.es> wrote:

>=C2=A0 =C2=A0 =C2=A0> Tell your bank, your university, your library,=
 etc., to try that.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> I now that some networks (mainly related to IE=
TF work, vendors, etc.), are doing that, but not in a general market.

>

>=C2=A0 =C2=A0 =C2=A0Are you saying IETF should wait until everyone else=
 has done it and

>=C2=A0 =C2=A0 =C2=A0proved it works and only then we feel safe enough t=
o try it? ;)

>

>=C2=A0 =C2=A0 =C2=A0> -----Mensaje original-----

>=C2=A0 =C2=A0 =C2=A0> De: Jen Linkova <furry13@gmail.com>

>=C2=A0 =C2=A0 =C2=A0> Responder a: <furry13@gmail.com>

>=C2=A0 =C2=A0 =C2=A0> Fecha: lunes, 17 de julio de 2017, 10:34

>=C2=A0 =C2=A0 =C2=A0> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>

>=C2=A0 =C2=A0 =C2=A0> CC: IPv6 Ops WG <v6ops@ietf.org>, Jim Martin <jim@daedelus.com>, Russ Housley <housley@vigilsec.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, Al=
issa Cooper <alissa@cooperw.in&=
gt;, Randy Bush <randy@psg.com><=
br>
>=C2=A0 =C2=A0 =C2=A0> Asunto: Re: [v6ops] Incremental Deployment of =
IPv6-only Wi-Fi for IETF Meetings

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On Mon, Jul 17, 2017 at 6:1=
7 PM, JORDI PALET MARTINEZ

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<jordi.palet@consulintel.es> wrote:

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> In the real world, you=
 will not disable IPv4 in the LANs of end-users or enterprise customers (at=
 least not now, may be in 3-5 years from now).

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I disagree with this statem=
ent. There are networks doing this. Right

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0here right now.

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> -----Mensaje original-=
----

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> De: v6ops <v6ops-bounces@ietf.org> en nombre=
 de "Brzozowski, John" <John_Brzozowski@comcast.com>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Responder a: <John_Brzozowski@comcast.com&g=
t;

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Fecha: lunes, 17 de ju=
lio de 2017, 10:14

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Para: Noah <noah@neo.co.tz>, Ted Lemon <mellon@fugue.com>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> CC: Jim Martin <jim@daedelus.com>, IPv6 Ops WG <=
v6ops@ietf.org>, Alissa Cooper <=
;alissa@cooperw.in>, Russ Housl=
ey <housley@vigilsec.com>=
, Randy Bush <randy@psg.com>, Su=
resh Krishnan <suresh.krish=
nan@gmail.com>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Asunto: Re: [v6ops] In=
cremental Deployment of IPv6-only Wi-Fi for IETF Meetings

>=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=A0Agr=
ee with Noah and Ted.

>=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=A0Not=
e the I-D explicitly documents that a fallback, dual stack SSID must remain=
 available as Noah mentions below.

>=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=A0I f=
ail to see how doing this will harm or discriminate.

>=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=A0We =
do need to eat our own dogfood, otherwise we are hypocrites.

>=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=A0Joh=
n

>=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+1-484-962-0060
>=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=A0Fro=
m:

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0v6o=
ps <v6ops-bounces@ietf.org=
> on behalf of Noah <noah@neo.co.tz=
>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Dat=
e: Monday, July 17, 2017 at 09:01

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0To:=
 Ted Lemon <mellon@fugue.com>=


>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Cc:=
 Randy Bush <randy@psg.com>, v6o=
ps <v6ops@ietf.org>, Alissa Coo=
per <alissa@cooperw.in>, Rus=
s Housley <housley@vigilsec.com<=
/a>>, Jim Martin <jim@daedelus.co=
m>, Suresh Krishnan <suresh.krishnan@gmail.com>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Sub=
ject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetin=
gs

>=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=A0FWI=
W and to cater for all, would a fallback dual stack SSID work for the statu=
s quo while this 2nd v6 SSID is also experimented upon which is a great ide=
a considering this is IETF.

>=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=A0Noa=
h

>=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=A0On =
17 Jul 2017 9:54 a.m., "Ted Lemon" <mellon@fugue.com> wrote:

>=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=A0I d=
on't think this is a social justice issue.=C2=A0 =C2=A0Does the IETF th=
ink that IPv6 works, or not?=C2=A0 =C2=A0If we think it works, and we have =
been working for what, 20 years, to make it work, and we have designed all =
this great

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 tr=
ansition tech, then why on earth would we not want to use it?=C2=A0 =C2=A0T=
his isn't "one draft."=C2=A0 =C2=A0This is roughly half the w=
ork of the IETF for the past two decades.

>=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=A0On =
Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

>=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=A0So =
we agree to change the rules so that we use this network for every ID that =
want to experiment with it? Otherwise we discriminate among different autho=
rs =E2=80=A6

>=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=A0I t=
hink is a really bad precedent.

>=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=A0Reg=
ards,

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Jor=
di

>=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---=
--Mensaje original-----

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0De:=
 Ted Lemon <mellon@fugue.com>=


>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Res=
ponder a: <mellon@fugue.com><=
br>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Fec=
ha: lunes, 17 de julio de 2017, 8:48

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Par=
a: JORDI PALET MARTINEZ <j=
ordi.palet@consulintel.es>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0CC:=
 IPv6 Ops WG <v6ops@ietf.org>, =
Jim Martin <jim@daedelus.com>=
, Randy Bush <randy@psg.com>, Su=
resh

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 Kr=
ishnan <suresh.krishnan@gma=
il.com>, Russ Housley <ho=
usley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Asu=
nto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meeting=
s

>=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=A0I don't actually know what the goal of the IETF network is=
 other than to provide connectivity.=C2=A0 =C2=A0Because of the vicissitude=
s of hotel topology, it is often the case that IETF participants experience=
 issues with the

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 ne=
twork at least once or twice per IETF despite the best efforts (and they ar=
e quite exceptional) of the NOC team.=C2=A0 =C2=A0I do not really see what =
the damage is that you are hoping to protect against here.=C2=A0 =C2=A0User=
s who don't read the NOC announcement?=C2=A0 =C2=A0No sympathy.

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0Sorry.

>=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=A0IPv=
4 is over

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Are=
 you ready for the new Internet ?

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0htt=
p://www.consulintel.es

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The=
 IPv6 Company

>=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=A0Thi=
s electronic message contains information which may be privileged or confid=
ential. 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 disclo=
sure, copying, distribution or

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 us=
e of the contents of this information, including attached files, is prohibi=
ted.

>=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=A0v6o=
ps mailing list

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0v6ops@ietf.org

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/v6ops

>=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 =C2=A0 =C2=A0___=
____________________________________________

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0v6o=
ps mailing list

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0v6ops@ietf.org

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/v6ops

>=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0v6o=
ps mailing list

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0v6ops@ietf.org

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/v6ops

>=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> IPv4 is over

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Are you ready for the =
new Internet ?

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> http://www.consulintel=
.es

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> The IPv6 Company

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> This electronic messag=
e contains information which may be privileged or confidential. The informa=
tion is intended to be for the use of the individual(s) named above. If you=
 are not the intended recipient be aware that any disclosure, copying, dist=
ribution or use of the contents of this information, including attached fil=
es, is prohibited.

>=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> v6ops mailing list

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> v6ops@ietf.org

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> http=
s://www.ietf.org/mailman/listinfo/v6ops

>=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=A0SY, Jen Linkova aka Furry
>=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> IPv4 is over

>=C2=A0 =C2=A0 =C2=A0> Are you ready for the new Internet ?

>=C2=A0 =C2=A0 =C2=A0> http://www.consulintel.es

>=C2=A0 =C2=A0 =C2=A0> The IPv6 Company

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> This electronic message contains information w=
hich may be privileged or confidential. The information is intended to be f=
or the use of the individual(s) named above. If you are not the intended re=
cipient be aware that any disclosure, copying, distribution or use of the c=
ontents of this information, including attached files, is prohibited.

>=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> v6ops mailing list

>=C2=A0 =C2=A0 =C2=A0> v6ops@ietf.o=
rg

>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman=
/listinfo/v6ops

>

>

>

>=C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0SY, Jen Linkova aka Furry

>

>

>

>

> **********************************************

> 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 o=
r confidential. The information is intended to be for the use of the indivi=
dual(s) named above. If you are not the intended recipient be aware that an=
y disclosure, copying, distribution or use of the contents of this informat=
ion, including attached files, is prohibited.

>

>

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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








--

SY, Jen Linkova aka Furry



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--94eb2c18ff6a031dba055483f09c--


From nobody Mon Jul 17 07:11:02 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280112EC5D for ; Mon, 17 Jul 2017 07:11:02 -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 wgkRm1Qj73HA for ; Mon, 17 Jul 2017 07:10:59 -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 1D7E4131BDC for ; Mon, 17 Jul 2017 07:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500300655; x=1500905455; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=K5SzJidMBRl0/NMgCG8U+7apc p2L9p8pDIIhQRV0IWc=; b=M0OcZy93UeVLKSK47BZxSt2LzVSXv1nwdOZcwHd7o ZoC35Zpa2EdRZKDDdWmtzBLxP1lanBmh/uaHHo1oDe6x+CV3ewmfF1/yZ1L21fyN xjw0aFfFVb9KBP/X3yv7xaVw+tD/ZW6AsWThUBb5WgaUgxPtKgV6SAsVJQdCcSIG iI=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Wup/bo6Jtf+YYeIf8bDoZLsJGqLSbf8L12TvdEmIqmsgklgvlEK1lnm9zZNa 6IXlmec7VDjMyF5JMLOcaJBWWrL/97wErgrIL207o9CnSY+1cEHTjmjAy gUmqUP3dIKwJVNtdKqlywZtSryJbyB6zxkrIt4qx541k3WGgYFLvFE=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:10:55 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:10:51 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478544.msg for ; Mon, 17 Jul 2017 16:10:50 +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:170717:md50005478544::zf0r3wSPfgESCaBG:00000I73
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 16:10:44 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:11:02 -0000

If the end-users and enterprises are forced to switch to IPv6 only in their=
 LANs, overnight, who is going to pay for replacing IP cameras, home automa=
tion, and many other old devices, that still work, but are IPv4-only?

To make sure, IPv6-only in the WAN is not the same as IPv6-only in the WAN =
and the customers LANs.

If vendor x or z deploy IPv6-only infrastructure in their corporate network=
 that=E2=80=99s really good and I applaud for it.

If cellular operator a or b deploy IPv6-only cellular access for smartphone=
s, that's wonderful and I applaud it. It is a more controlled scenario and =
they can tell the app developers (as Apple did), to make sure that the apps=
 are IPv6 capable. However, Android and Windows smartphones in that infrast=
ructure are still using CLAT, right? Or Android/Windows have also done the =
same as Apple, making sure that all the Apps are IPv6-ready?

Now if instead of a smartphone is a LTE router, or a smartphone doing some =
kind of network sharing for providing broadband in a home that has no wired=
 connectivity, and it is IPv6-only, how come are going to work those device=
s that I mention before? Should the user throw them to the trash can? Are t=
he operators going to pay for that, or the user will prefer an operator tha=
t provides a broadband LTE router with some kind of =E2=80=9CIPv4 as a serv=
ice=E2=80=9D in the LAN even if the WAN is IPv6-only?

Regards,
Jordi
=20

-----Mensaje original-----
De: Jen Linkova 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 16:00
Para: Jordi Palet Martinez 
CC: IPv6 Ops WG , Jim Martin , Russ Housl=
ey , Suresh Krishnan , Ali=
ssa Cooper , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
     wrote:
    > I=E2=80=99m saying:
    >
    > 1) We should not try experiments in the IETF network, it has been the=
 rule for ages.
    > 2) If we decide to change that rule, we should try what is good for t=
he market, not what we =E2=80=9Cwish=E2=80=9D
   =20
    Could you pls elaborate on why proving that IPv6-only/NAT64 network
    works (or if it does not, identifying the issues and getting them
    fixed) is not good for the market? If, as you said, nobody is doing
    Ipv6-only (and we have seen a number of comments stating the
    opposite), wouldn't it be good for them if we prove that v6-only works
    and start working on issues? If, as some people have said, there are
    Ipv6-only network out >
    > Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivi=
ty, is feasible. This is what we need to try.
   =20
    >
    >
    > -----Mensaje original-----
    > De: Jen Linkova 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 10:42
    > Para: Jordi Palet Martinez 
    > CC: IPv6 Ops WG , Jim Martin , Alis=
sa Cooper , Suresh Krishnan ,=
 Russ Housley , Randy Bush 
    > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
    >
    >     On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
    >      wrote:
    >     > Tell your bank, your university, your library, etc., to try tha=
t.
    >     >
    >     > I now that some networks (mainly related to IETF work, vendors,=
 etc.), are doing that, but not in a general market.
    >
    >     Are you saying IETF should wait until everyone else has done it a=
nd
    >     proved it works and only then we feel safe enough to try it? ;)
    >
    >     > -----Mensaje original-----
    >     > De: Jen Linkova 
    >     > Responder a: 
    >     > Fecha: lunes, 17 de julio de 2017, 10:34
    >     > Para: Jordi Palet Martinez 
    >     > CC: IPv6 Ops WG , Jim Martin =
, Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
    >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
    >     >
    >     >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
    >     >      wrote:
    >     >     > In the real world, you will not disable IPv4 in the LANs =
of end-users or enterprise customers (at least not now, may be in 3-5 years=
 from now).
    >     >
    >     >     I disagree with this statement. There are networks doing th=
is. Right
    >     >     here right now.
    >     >
    >     >     > -----Mensaje original-----
    >     >     > De: v6ops  en nombre de "Brzozows=
ki, John" 
    >     >     > Responder a: 
    >     >     > Fecha: lunes, 17 de julio de 2017, 10:14
    >     >     > Para: Noah , Ted Lemon 
    >     >     > CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
    >     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only W=
i-Fi for IETF Meetings
    >     >     >
    >     >     >     Agree with Noah and Ted.
    >     >     >
    >     >     >     Note the I-D explicitly documents that a fallback, du=
al stack SSID must remain available as Noah mentions below.
    >     >     >
    >     >     >     I fail to see how doing this will harm or discriminat=
e.
    >     >     >
    >     >     >     We do need to eat our own dogfood, otherwise we are h=
ypocrites.
    >     >     >
    >     >     >     John
    >     >     >
    >     >     >     +1-484-962-0060
    >     >     >
    >     >     >     From:
    >     >     >     v6ops  on behalf of Noah 
    >     >     >     Date: Monday, July 17, 2017 at 09:01
    >     >     >     To: Ted Lemon 
    >     >     >     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley , =
Jim Martin , Suresh Krishnan 
    >     >     >     Subject: Re: [v6ops] Incremental Deployment of IPv6-o=
nly Wi-Fi for IETF Meetings
    >     >     >
    >     >     >
    >     >     >
    >     >     >     FWIW and to cater for all, would a fallback dual stac=
k SSID work for the status quo while this 2nd v6 SSID is also experimented =
upon which is a great idea considering this is IETF.
    >     >     >
    >     >     >
    >     >     >
    >     >     >     Noah
    >     >     >
    >     >     >
    >     >     >
    >     >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
    >     >     >
    >     >     >     I don't think this is a social justice issue.   Does =
the IETF think that IPv6 works, or not?   If we think it works, and we have=
 been working for what, 20 years, to make it work, and we have designed all=
 this great
    >     >     >      transition tech, then why on earth would we not want=
 to use it?   This isn't "one draft."   This is roughly half the work of th=
e IETF for the past two decades.
    >     >     >
    >     >     >
    >     >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ=
  wrote:
    >     >     >
    >     >     >     So we agree to change the rules so that we use this n=
etwork for every ID that want to experiment with it? Otherwise we discrimin=
ate among different authors =E2=80=A6
    >     >     >
    >     >     >     I think is a really bad precedent.
    >     >     >
    >     >     >     Regards,
    >     >     >     Jordi
    >     >     >
    >     >     >
    >     >     >     -----Mensaje original-----
    >     >     >     De: Ted Lemon 
    >     >     >     Responder a: 
    >     >     >     Fecha: lunes, 17 de julio de 2017, 8:48
    >     >     >     Para: JORDI PALET MARTINEZ 
    >     >     >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
    >     >     >      Krishnan , Russ Housley <=
housley@vigilsec.com>, Alissa Cooper 
    >     >     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-on=
ly Wi-Fi for IETF Meetings
    >     >     >
    >     >     >         I don't actually know what the goal of the IETF n=
etwork is other than to provide connectivity.   Because of the vicissitudes=
 of hotel topology, it is often the case that IETF participants experience =
issues with the
    >     >     >      network at least once or twice per IETF despite the =
best efforts (and they are quite exceptional) of the NOC team.   I do not r=
eally see what the damage is that you are hoping to protect against here.  =
 Users who don't read the NOC announcement?   No sympathy.
    >     >     >       Sorry.
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >     **********************************************
    >     >     >     IPv4 is over
    >     >     >     Are you ready for the new Internet ?
    >     >     >     http://www.consulintel.es
    >     >     >     The IPv6 Company
    >     >     >
    >     >     >     This electronic message contains information which ma=
y be privileged or confidential. 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 disclosure, copying, distribution or
    >     >     >      use of the contents of this information, including a=
ttached files, is prohibited.
    >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     v6ops mailing list
    >     >     >     v6ops@ietf.org
    >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     v6ops mailing list
    >     >     >     v6ops@ietf.org
    >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     v6ops mailing list
    >     >     >     v6ops@ietf.org
    >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     > **********************************************
    >     >     > 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 confidential. 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 disclosure, copying, distribution or use of the contents of =
this information, including attached files, is prohibited.
    >     >     >
    >     >     >
    >     >     >
    >     >     > _______________________________________________
    >     >     > v6ops mailing list
    >     >     > v6ops@ietf.org
    >     >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >     --
    >     >     SY, Jen Linkova aka Furry
    >     >
    >     >
    >     >
    >     >
    >     > **********************************************
    >     > 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 privi=
leged or confidential. 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 disclosure, copying, distribution or use of the contents of this i=
nformation, including attached files, is prohibited.
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > v6ops@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >     --
    >     SY, Jen Linkova aka Furry
    >
    >
    >
    >
    > **********************************************
    > 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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --=20
    SY, Jen Linkova aka Furry
   =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 Mon Jul 17 07:13:22 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC2129482 for ; Mon, 17 Jul 2017 07:13:19 -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 qIq5fVU3u-4r for ; Mon, 17 Jul 2017 07:13:17 -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 D457312EC5D for ; Mon, 17 Jul 2017 07:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500300794; x=1500905594; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=709p5sGyyaeQrDlwt94AN9Ixn dRlwzEBSsCP1LfKyoI=; b=Ri55f8TVuwVZBmKhvWl/u/EvK+rhpIsom4yVanOv0 9PaPY21xggN6uaHbaYRXMCWruaB+f3JCfNFqTTubZVCrmB0LtYb4odJL+uJCSxun FqA9JPv90suurAG3X7pkAZhHET9P/brN/cR7wX4UGlTQ9pN84L3XnNVPT549sp3H 30=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dbHRYTS8U1x0v7JanI8PDDsoY6VfLFTg3f9QNkCoh3hTVPDL/7vO0vW66ws6 0Ex3fc9gI2Qejiwh8iykMjDNiJNr0+Nw4fX0MUp8RULMrqA0WgWed2ycr lJTfI2XrsaSjKDc9jn6fk0Ga6PolLgo6MTTxosbvtNdRKkaO75FQHg=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:13:14 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:13:13 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478546.msg for ; Mon, 17 Jul 2017 16:13:11 +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:170717:md50005478546::Sb+gb8lyaSI8rKA2:00002Ruw
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 16:13:05 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Message-ID: <9CDFFE8B-DBEC-4059-8E93-44AEC304E31A@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>  
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:13:20 -0000

If we count number of devices using it, the bigger one is 464XLAT. No other=
 transition technology has reached the millions of devices connected with a=
n IPv6-only WAN but still providing IPv4 as a service (just look at cellula=
r operators in several countries, millions of users/devices).

Regards,
Jordi
=20

-----Mensaje original-----
De: Ted Lemon 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 16:09
Para: Jen Linkova 
CC: Jordi Palet Martinez , Randy Bush , IPv6 Ops WG , Russ Housley , =
Alissa Cooper , Jim Martin , Suresh Kr=
ishnan 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    To be clear, the reason to privilege nat64 is that it gives you effecti=
vely an IPv6-only network, with enough of a shim that most stuff that still=
 relies on legacy servers still works.   It is not that nat64 is the transi=
tion technology that the market has chosen (I don't actually know what the =
market has selected) but rather that it is the transition technology that a=
llows us to not run _any_ IPv4 on the link.
   =20
    On Mon, Jul 17, 2017 at 3:59 PM, Jen Linkova  wrote:
   =20
    On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
     wrote:
    > I=E2=80=99m saying:
    >
    > 1) We should not try experiments in the IETF network, it has been the=
 rule for ages.
    > 2) If we decide to change that rule, we should try what is good for t=
he market, not what we =E2=80=9Cwish=E2=80=9D
   =20
    Could you pls elaborate on why proving that IPv6-only/NAT64 network
    works (or if it does not, identifying the issues and getting them
    fixed) is not good for the market? If, as you said, nobody is doing
    Ipv6-only (and we have seen a number of comments stating the
    opposite), wouldn't it be good for them if we prove that v6-only works
    and start working on issues? If, as some people have said, there are
    Ipv6-only network out >
    > Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivi=
ty, is feasible. This is what we need to try.
   =20
    >
    >
    > -----Mensaje original-----
    > De: Jen Linkova 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 10:42
    > Para: Jordi Palet Martinez 
    > CC: IPv6 Ops WG , Jim Martin , Alis=
sa Cooper , Suresh Krishnan ,=
 Russ Housley , Randy Bush 
    > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
    >
    >     On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
    >      wrote:
    >     > Tell your bank, your university, your library, etc., to try tha=
t.
    >     >
    >     > I now that some networks (mainly related to IETF work, vendors,=
 etc.), are doing that, but not in a general market.
    >
    >     Are you saying IETF should wait until everyone else has done it a=
nd
    >     proved it works and only then we feel safe enough to try it? ;)
    >
    >     > -----Mensaje original-----
    >     > De: Jen Linkova 
    >     > Responder a: 
    >     > Fecha: lunes, 17 de julio de 2017, 10:34
    >     > Para: Jordi Palet Martinez 
    >     > CC: IPv6 Ops WG , Jim Martin =
, Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
    >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
    >     >
    >     >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
    >     >      wrote:
    >     >     > In the real world, you will not disable IPv4 in the LANs =
of end-users or enterprise customers (at least not now, may be in 3-5 years=
 from now).
    >     >
    >     >     I disagree with this statement. There are networks doing th=
is. Right
    >     >     here right now.
    >     >
    >     >     > -----Mensaje original-----
    >     >     > De: v6ops  en nombre de "Brzozows=
ki, John" 
    >     >     > Responder a: 
    >     >     > Fecha: lunes, 17 de julio de 2017, 10:14
    >     >     > Para: Noah , Ted Lemon 
    >     >     > CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
    >     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only W=
i-Fi for IETF Meetings
    >     >     >
    >     >     >     Agree with Noah and Ted.
    >     >     >
    >     >     >     Note the I-D explicitly documents that a fallback, du=
al stack SSID must remain available as Noah mentions below.
    >     >     >
    >     >     >     I fail to see how doing this will harm or discriminat=
e.
    >     >     >
    >     >     >     We do need to eat our own dogfood, otherwise we are h=
ypocrites.
    >     >     >
    >     >     >     John
    >     >     >
    >     >     >     +1-484-962-0060 
    >     >     >
    >     >     >     From:
    >     >     >     v6ops  on behalf of Noah 
    >     >     >     Date: Monday, July 17, 2017 at 09:01
    >     >     >     To: Ted Lemon 
    >     >     >     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley , =
Jim Martin , Suresh Krishnan 
    >     >     >     Subject: Re: [v6ops] Incremental Deployment of IPv6-o=
nly Wi-Fi for IETF Meetings
    >     >     >
    >     >     >
    >     >     >
    >     >     >     FWIW and to cater for all, would a fallback dual stac=
k SSID work for the status quo while this 2nd v6 SSID is also experimented =
upon which is a great idea considering this is IETF.
    >     >     >
    >     >     >
    >     >     >
    >     >     >     Noah
    >     >     >
    >     >     >
    >     >     >
    >     >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
    >     >     >
    >     >     >     I don't think this is a social justice issue.   Does =
the IETF think that IPv6 works, or not?   If we think it works, and we have=
 been working for what, 20 years, to make it work, and we have designed all=
 this great
    >     >     >      transition tech, then why on earth would we not want=
 to use it?   This isn't "one draft."   This is roughly half the work of th=
e IETF for the past two decades.
    >     >     >
    >     >     >
    >     >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ=
  wrote:
    >     >     >
    >     >     >     So we agree to change the rules so that we use this n=
etwork for every ID that want to experiment with it? Otherwise we discrimin=
ate among different authors =E2=80=A6
    >     >     >
    >     >     >     I think is a really bad precedent.
    >     >     >
    >     >     >     Regards,
    >     >     >     Jordi
    >     >     >
    >     >     >
    >     >     >     -----Mensaje original-----
    >     >     >     De: Ted Lemon 
    >     >     >     Responder a: 
    >     >     >     Fecha: lunes, 17 de julio de 2017, 8:48
    >     >     >     Para: JORDI PALET MARTINEZ 
    >     >     >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
    >     >     >      Krishnan , Russ Housley <=
housley@vigilsec.com>, Alissa Cooper 
    >     >     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-on=
ly Wi-Fi for IETF Meetings
    >     >     >
    >     >     >         I don't actually know what the goal of the IETF n=
etwork is other than to provide connectivity.   Because of the vicissitudes=
 of hotel topology, it is often the case that IETF participants experience =
issues with the
    >     >     >      network at least once or twice per IETF despite the =
best efforts (and they are quite exceptional) of the NOC team.   I do not r=
eally see what the damage is that you are hoping to protect against here.  =
 Users who don't read the NOC announcement?   No sympathy.
    >     >     >       Sorry.
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >     **********************************************
    >     >     >     IPv4 is over
    >     >     >     Are you ready for the new Internet ?
    >     >     >     http://www.consulintel.es
    >     >     >     The IPv6 Company
    >     >     >
    >     >     >     This electronic message contains information which ma=
y be privileged or confidential. 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 disclosure, copying, distribution or
    >     >     >      use of the contents of this information, including a=
ttached files, is prohibited.
    >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     v6ops mailing list
    >     >     >     v6ops@ietf.org
    >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     v6ops mailing list
    >     >     >     v6ops@ietf.org
    >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     v6ops mailing list
    >     >     >     v6ops@ietf.org
    >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     > **********************************************
    >     >     > 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 confidential. 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 disclosure, copying, distribution or use of the contents of =
this information, including attached files, is prohibited.
    >     >     >
    >     >     >
    >     >     >
    >     >     > _______________________________________________
    >     >     > v6ops mailing list
    >     >     > v6ops@ietf.org
    >     >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >     --
    >     >     SY, Jen Linkova aka Furry
    >     >
    >     >
    >     >
    >     >
    >     > **********************************************
    >     > 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 privi=
leged or confidential. 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 disclosure, copying, distribution or use of the contents of this i=
nformation, including attached files, is prohibited.
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > v6ops@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >     --
    >     SY, Jen Linkova aka Furry
    >
    >
    >
    >
    > **********************************************
    > 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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --
    SY, Jen Linkova aka Furry
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
   =20
   =20
   =20
   =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 Mon Jul 17 07:14:50 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7E0131BBA for ; Mon, 17 Jul 2017 07:14:49 -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 Z8l9DTnUm60v for ; Mon, 17 Jul 2017 07:14:47 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4093E129482 for ; Mon, 17 Jul 2017 07:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500300885; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=GmjEfRz0tEgnwVPX7d5jsRVgNnLSBhOtSys2TgPhOcs=; b=VGJ90POF3iId9Cd2ngnkJL4QGz/lcM6b/CH4GciXfuGtvzhCF3fwVo0dU11CshWcCsuemZ+DIqK/MQqaBEJ5jL8DhfV5YPxAanktUYtPpU8P8qRP0GN656WE2AhKSGkDF+PpIRKmGZIhcLHvYx/vDxnmau/27osE8lntWYbwLlw=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0241.outbound.protection.outlook.com [213.199.154.241]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-75-KiQ2alElNryKFFEJ0_3cDQ-1; Mon, 17 Jul 2017 15:14:41 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0517.eurprd07.prod.outlook.com (10.141.47.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 14:14:39 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.008; Mon, 17 Jul 2017 14:14:39 +0000
From: Tim Chown 
To: Noah 
CC: Ted Lemon , Randy Bush , "v6ops@ietf.org" , Russ Housley , Alissa Cooper , Jim Martin , Suresh Krishnan 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
Thread-Index: AQHS/r05SwldI9zBi0erX+YxO1XvLqJXsGYAgAAAgQCAAEXNAIAAGd0A
Date: Mon, 17 Jul 2017 14:14:39 +0000
Message-ID: <3283B1C1-1D6C-462E-82E0-4E9BDB63DF16@jisc.ac.uk>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>   
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:67c:370:1998:5c70:fa95:912:6170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB0517; 20:FsJyQ0gnjYjZuGaZB8GrjHuN+pbnfAnJyS+CALI2Z7gGY2pbCGpY5kCglaXWLk+A/328NYtftSuc7MJTyEVqehLHIHjDZebxAEc8JnCfZSTzpLt4ESTbpIj0XwaLA5FHXHPXbegphLcZctAGyIrjmauklIIIkVifADoMkyKbsuo=
x-ms-office365-filtering-correlation-id: 1221c5ea-1ae4-437b-1ac9-08d4cd1e29a1
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0517; 
x-ms-traffictypediagnostic: AM3PR07MB0517:
x-exchange-antispam-report-test: UriScan:(133145235818549)(236129657087228)(48057245064654)(100405760836317); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910075)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0517; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0517; 
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39840400002)(39450400003)(39400400002)(24454002)(377454003)(50986999)(6506006)(57306001)(6436002)(33656002)(82746002)(14454004)(6486002)(5660300001)(229853002)(81166006)(53546010)(74482002)(76176999)(6916009)(72206003)(2950100002)(39060400002)(36756003)(8676002)(478600001)(6116002)(38730400002)(5250100002)(6246003)(2906002)(110136004)(3660700001)(3280700002)(25786009)(50226002)(2900100001)(42882006)(8936002)(189998001)(4326008)(102836003)(53936002)(6512007)(54906002)(99286003)(93886004)(305945005)(7736002)(83716003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0517; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: 
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 14:14:39.5969 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0517
X-MC-Unique: KiQ2alElNryKFFEJ0_3cDQ-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:14:49 -0000

PiBPbiAxNyBKdWwgMjAxNywgYXQgMTM6NDIsIE5vYWggPG5vYWhAbmVvLmNvLnR6PiB3cm90ZToN
Cj4gDQo+IA0KPiBPbiBNb24sIEp1bCAxNywgMjAxNyBhdCAxMDozMCBBTSwgSmVuIExpbmtvdmEg
PGZ1cnJ5MTNAZ21haWwuY29tPiB3cm90ZToNCj4gQWN0dWFsbHkgaWYgdGhlIGZhbGxiYWNrIGR1
YWwtc3RhY2sgbmV0d29yayByZXF1aXJlcyBhbiBleHBsaWNpdA0KPiBjb25maWd1cmF0aW9uIG9u
IHRoZSBjbGllbnQgc2lkZSAoYXMgdGhlIGRyYWZ0IHJlY29tbWVuZHMpIHRvIGF2b2lkDQo+IHVz
ZXJzIGNvbm5lY3RpbmcgdG8gaXQgYWNjaWRlbnRhbGx5LCB0aGUgbnVtYmVyIG9mIGNsaWVudHMg
ZmFsbGluZw0KPiBiYWNrIHRvIHRoZSBkdWFsIHN0YWNrIFNTSUQgaXMgdmVyeSBnb29kIGRhdGEg
cG9pbnQgdG8gZGVtb25zdHJhdGUNCj4gd2hhdCAlIG9mIHVzZXJzIGFyZSBleHBlcmllbmNpbmcg
aXNzdWVzLg0KPiANCj4gSSBjb3VsZG50IGFncmVlIG1vcmUuLi4gTGV0cyB3YWxrIHRoZSB0YWxr
IGZvbGtzLg0KPiANCj4gU28gZG8gd2UgaGF2ZSBjb25zZW5zdXMgZm9yIHRoZSBleHBlcmltZW50
IHRvIGdvIG9uIG5vdyB0aGF0IGl0cyBwcmV0dHkgbXVjaCBsb2dpY2FsIGZvciBmb2xrcyBhY3Jv
c3MgdGhlIGJvYXJkIHRoYXQgdGhpcyBpcyBnb29kIHN0dWZmPw0KDQpTb3VuZHMgZ29vZCB0byBt
ZS4gSeKAmXZlIG5ldmVyIGhhZCBhIHByb2JsZW0gd2l0aCB0aGUgSUVURiBOQVQ2NCBuZXR3b3Jr
LiBJ4oCZZCBjaGFsbGVuZ2UgdGhvc2Ugd2hvIGhhdmUgY29uY2VybnMgdG8gdHJ5IGl0LiAgSXTi
gJlzIG5vdCBsaWtlIHRoZXJl4oCZcyBubyBmYWxsYmFjayBpbiBwbGFjZS4NCg0KSXTigJlzIGFs
c28gaW50ZXJlc3RpbmcgLSBidXQgSeKAmWQgbm90IG1ha2UgaXQgdGhlIGRlZmF1bHQgLSB0byB0
cnkgdGhlIElFVEYgdjZvbmx5IFNTSUQgdG8gZ2F1Z2UgdGhlIHY2IHN1cHBvcnQgZm9yIHRoZSB0
b29scyB5b3UgdXNlIG9uIGEgcmVndWxhciBiYXNpcywgaW4geW91ciBob21lIG9yIG90aGVyIDNy
ZCBwYXJ0eSBuZXR3b3Jrcy9zZXJ2aWNlcy4gIA0KDQpUaW0=


From nobody Mon Jul 17 07:15:53 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3396C131BD6 for ; Mon, 17 Jul 2017 07:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.101
X-Spam-Level: 
X-Spam-Status: No, score=-7.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1BBErA_EucR for ; Mon, 17 Jul 2017 07:15:49 -0700 (PDT)
Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.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 67952131BBA for ; Mon, 17 Jul 2017 07:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500300947; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vY/hE8rOyCYsGBnNvVqt4T5crbJAGKJ/mYsoDQUrPrQ=; b=pf+V2NOR0Fh9RjG2ntybRuUcJFk9ys9WukdkXVdwTgOYKV33R4ViypWXeAxbahrj GagXRumQ+E12bgMTMpcK8i6sl/L9qpiBJDKlVlKo6Re3T3/jq/nunmjmKvRr9HvF L97CPE4Org47tRR8Ru5EOU/hc4fZDM67wH2OOz01PGelpSdGA8ofLHraseaJn065 Jsh+lnapedW1TCsNE0LU+yZG3PJlrVghRIUL9qg1Eg+SEkQEwOuVQU1gjHhc8wJJ lfDvAlE/k3ICoQDY7ZTak5t7MOwnkokTD3OQA1KClJx7Ks+a7nF2y7/2/ZxNr65j 1CKwHRlM+45sWmI979fmgw==;
Received: from relay2.euro.apple.com ( [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id B0.B9.07437.396CC695; Mon, 17 Jul 2017 15:15:47 +0100 (BST)
X-AuditID: 1148940d-ed6789c000001d0d-5e-596cc6930b12
Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 99.F9.07255.396CC695; Mon, 17 Jul 2017 15:15:47 +0100 (BST)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [IPv6:2001:67c:370:1998:f0d2:b2f5:9408:9ad4] (nat64-b7.meeting.ietf.org [31.130.238.183]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OT800CRZNM8D200@phonehome3.euro.apple.com>; Mon, 17 Jul 2017 15:15:47 +0100 (IST)
Sender: dschinazi@apple.com
From: David Schinazi 
In-reply-to: <9CDFFE8B-DBEC-4059-8E93-44AEC304E31A@consulintel.es>
Date: Mon, 17 Jul 2017 16:15:43 +0200
Cc: IPv6 Ops WG , Randy Bush , Alissa Cooper , Suresh Krishnan , Russ Housley , Jim Martin 
Content-transfer-encoding: quoted-printable
Message-id: <45A7CDF3-9832-4944-9D77-95E17EAEDB47@apple.com>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   <9CDFFE8B-DBEC-4059-8E93-44AEC304E31A@consulintel.es>
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRdDLn0Z18LCfSYONfGYvpZ/4yWrx6cZPd 4toRZou/xz8zWzxrfclkcWTDWVaL08f2Mjuwe6zbH+Dx5clLJo+uj5eZPHbOusvusWTJTyaP qTNnM3qsuvOFNYA9issmJTUnsyy1SN8ugSvjzBqTgrVpFatnPGBtYLwR1MXIwSEhYCLxab5b FyMXh5DAIiaJB1/3s3cxcoLFH27vYYNIHGKU2LTsMytIgldAUOLH5HssIM3MAuoSU6bkQtQc ZZJo6b3CCFIjLCAt0XXhLiuEHSCx5eoBdpB6NgEtiQNrjEDCnAJOEju39LGBhFkEVCX+rTAC GcMscI1R4u6XHSwgNcwC2hJP3l2AWmsj0be0lR1iVwuHRHfHIiaQhIiAnMTdFa2MEEfLStya fYkZpEhC4DKbRMPxRuYJjMKzkNw9C+HuWUh2LGBkXsUonpuYmaObmWesl1palK+XWFCQk6qX nJ+7iREUQR5TeHcwXj9oeIhRgINRiYdXhs07Uog1say4MhcYPhzMSiK8drtzIoV4UxIrq1KL 8uOLSnNSiw8xSnOwKInzmpTKRwoJpCeWpGanphakFsFkmTg4pRoYnSdODxaX1uFoM+34o/pP x2Zz4aGCw9fWd7k7b+Cd+P3lzfvxanv6lrccYts3yZatryY6UuVDVtjUZsYnd1dNXOP75nrL 7rYbCp+iDf11Z0jevf5fZd6ikM5F3qamHd8esRlP7tI58frbvnfeBgJ9ASIv3iVPyX41p/XP RbEpmdYcckvU1x9ZocRSnJFoqMVcVJwIAGYw8pacAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUi6NEarDv5WE6kwe7PYhbTz/xltHj14ia7 xbUjzBZ/j39mtnjW+pLJ4siGs6wWp4/tZXZg91i3P8Djy5OXTB5dHy8zeeycdZfdY8mSn0we U2fOZvRYdecLawB7FJdNSmpOZllqkb5dAlfGmTUmBWvTKlbPeMDawHgjqIuRk0NCwETi4fYe ti5GLg4hgUOMEpuWfWYFSfAKCEr8mHyPpYuRg4NZQF1iypRciJqjTBItvVcYQWqEBaQlui7c ZYWwAyS2XD3ADlLPJqAlcWCNEUiYU8BJYueWPjaQMIuAqsS/FUYgY5gFrjFK3P2ygwWkhllA W+LJuwtQa20k+pa2skPsauGQ6O5YxASSEBGQk7i7opUR4mhZiVuzLzFPYBSYheTUWQinzkIy dgEj8ypG0aLUnMRKI73U0qJ8vcSCgpxUveT83E2MoJB3MufZwfjqoOEhRgEORiUe3si5OZFC rIllxZW5wADhYFYS4bXbDRTiTUmsrEotyo8vKs1JLT7EKM3BoiTOW/AwIlJIID2xJDU7NbUg tQgmy8TBKQUM5bmO/9cL1TPf1RN6unbRLPb58i2yl20b1id9MXIRkf5s71236s+r2CXXo+45 yR2Yb713onmDhMHEXZ2P9TjUzs0K/Pdb8Ntxcav7Od8nKJ7nTtZb8sYoouE9R95Jo7kWKsUR s37uT7018UPXRg/2tSxvf1rrXfSPv+AeYa8S8XvipBtbI5iNlFiKMxINtZiLihMB3L2nKXUC AAA=
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:15:52 -0000

Jordi,

464XLAT is the combination of a CLAT on the client and NAT64+DNS64 in =
the network.
This draft suggests operating the main IETF Wi-Fi as IPv6-only with =
NAT64+DNS64,
precisely so you can contact IPv4 servers using mechanisms like 464XLAT =
and HEv2.
I'm not sure what your point is.

David


> On Jul 17, 2017, at 16:13, JORDI PALET MARTINEZ =
 wrote:
>=20
> If we count number of devices using it, the bigger one is 464XLAT. No =
other transition technology has reached the millions of devices =
connected with an IPv6-only WAN but still providing IPv4 as a service =
(just look at cellular operators in several countries, millions of =
users/devices).
>=20
> Regards,
> Jordi
>=20
>=20
> -----Mensaje original-----
> De: Ted Lemon 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 16:09
> Para: Jen Linkova 
> CC: Jordi Palet Martinez , Randy Bush =
, IPv6 Ops WG , Russ Housley =
, Alissa Cooper , Jim Martin =
, Suresh Krishnan 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF =
Meetings
>=20
>    To be clear, the reason to privilege nat64 is that it gives you =
effectively an IPv6-only network, with enough of a shim that most stuff =
that still relies on legacy servers still works.   It is not that nat64 =
is the transition technology that the market has chosen (I don't =
actually know what the market has selected) but rather that it is the =
transition technology that allows us to not run _any_ IPv4 on the link.
>=20
>    On Mon, Jul 17, 2017 at 3:59 PM, Jen Linkova  =
wrote:
>=20
>    On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
>     wrote:
>> I=E2=80=99m saying:
>>=20
>> 1) We should not try experiments in the IETF network, it has been the =
rule for ages.
>> 2) If we decide to change that rule, we should try what is good for =
the market, not what we =E2=80=9Cwish=E2=80=9D
>=20
>    Could you pls elaborate on why proving that IPv6-only/NAT64 network
>    works (or if it does not, identifying the issues and getting them
>    fixed) is not good for the market? If, as you said, nobody is doing
>    Ipv6-only (and we have seen a number of comments stating the
>    opposite), wouldn't it be good for them if we prove that v6-only =
works
>    and start working on issues? If, as some people have said, there =
are
>    Ipv6-only network out >
>> Turning off IPv4 in the WAN, but keeping some sort of IPv4 =
connectivity, is feasible. This is what we need to try.
>=20
>>=20
>>=20
>> -----Mensaje original-----
>> De: Jen Linkova 
>> Responder a: 
>> Fecha: lunes, 17 de julio de 2017, 10:42
>> Para: Jordi Palet Martinez 
>> CC: IPv6 Ops WG , Jim Martin , =
Alissa Cooper , Suresh Krishnan =
, Russ Housley , Randy =
Bush 
>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
>>=20
>>    On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
>>     wrote:
>>> Tell your bank, your university, your library, etc., to try that.
>>>=20
>>> I now that some networks (mainly related to IETF work, vendors, =
etc.), are doing that, but not in a general market.
>>=20
>>    Are you saying IETF should wait until everyone else has done it =
and
>>    proved it works and only then we feel safe enough to try it? ;)
>>=20
>>> -----Mensaje original-----
>>> De: Jen Linkova 
>>> Responder a: 
>>> Fecha: lunes, 17 de julio de 2017, 10:34
>>> Para: Jordi Palet Martinez 
>>> CC: IPv6 Ops WG , Jim Martin , =
Russ Housley , Suresh Krishnan =
, Alissa Cooper , Randy =
Bush 
>>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
>>>=20
>>>    On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
>>>     wrote:
>>>> In the real world, you will not disable IPv4 in the LANs of =
end-users or enterprise customers (at least not now, may be in 3-5 years =
from now).
>>>=20
>>>    I disagree with this statement. There are networks doing this. =
Right
>>>    here right now.
>>>=20
>>>> -----Mensaje original-----
>>>> De: v6ops  en nombre de "Brzozowski, John" =

>>>> Responder a: 
>>>> Fecha: lunes, 17 de julio de 2017, 10:14
>>>> Para: Noah , Ted Lemon 
>>>> CC: Jim Martin , IPv6 Ops WG , =
Alissa Cooper , Russ Housley , =
Randy Bush , Suresh Krishnan 
>>>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
>>>>=20
>>>>    Agree with Noah and Ted.
>>>>=20
>>>>    Note the I-D explicitly documents that a fallback, dual stack =
SSID must remain available as Noah mentions below.
>>>>=20
>>>>    I fail to see how doing this will harm or discriminate.
>>>>=20
>>>>    We do need to eat our own dogfood, otherwise we are hypocrites.
>>>>=20
>>>>    John
>>>>=20
>>>>    +1-484-962-0060 
>>>>=20
>>>>    From:
>>>>    v6ops  on behalf of Noah =

>>>>    Date: Monday, July 17, 2017 at 09:01
>>>>    To: Ted Lemon 
>>>>    Cc: Randy Bush , v6ops , Alissa =
Cooper , Russ Housley , Jim =
Martin , Suresh Krishnan 
>>>>    Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi =
for IETF Meetings
>>>>=20
>>>>=20
>>>>=20
>>>>    FWIW and to cater for all, would a fallback dual stack SSID work =
for the status quo while this 2nd v6 SSID is also experimented upon =
which is a great idea considering this is IETF.
>>>>=20
>>>>=20
>>>>=20
>>>>    Noah
>>>>=20
>>>>=20
>>>>=20
>>>>    On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>>>>=20
>>>>    I don't think this is a social justice issue.   Does the IETF =
think that IPv6 works, or not?   If we think it works, and we have been =
working for what, 20 years, to make it work, and we have designed all =
this great
>>>>     transition tech, then why on earth would we not want to use it? =
  This isn't "one draft."   This is roughly half the work of the IETF =
for the past two decades.
>>>>=20
>>>>=20
>>>>    On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ =
 wrote:
>>>>=20
>>>>    So we agree to change the rules so that we use this network for =
every ID that want to experiment with it? Otherwise we discriminate =
among different authors =E2=80=A6
>>>>=20
>>>>    I think is a really bad precedent.
>>>>=20
>>>>    Regards,
>>>>    Jordi
>>>>=20
>>>>=20
>>>>    -----Mensaje original-----
>>>>    De: Ted Lemon 
>>>>    Responder a: 
>>>>    Fecha: lunes, 17 de julio de 2017, 8:48
>>>>    Para: JORDI PALET MARTINEZ 
>>>>    CC: IPv6 Ops WG , Jim Martin , =
Randy Bush , Suresh
>>>>     Krishnan , Russ Housley =
, Alissa Cooper 
>>>>    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi =
for IETF Meetings
>>>>=20
>>>>        I don't actually know what the goal of the IETF network is =
other than to provide connectivity.   Because of the vicissitudes of =
hotel topology, it is often the case that IETF participants experience =
issues with the
>>>>     network at least once or twice per IETF despite the best =
efforts (and they are quite exceptional) of the NOC team.   I do not =
really see what the damage is that you are hoping to protect against =
here.   Users who don't read the NOC announcement?   No sympathy.
>>>>      Sorry.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>    **********************************************
>>>>    IPv4 is over
>>>>    Are you ready for the new Internet ?
>>>>    http://www.consulintel.es
>>>>    The IPv6 Company
>>>>=20
>>>>    This electronic message contains information which may be =
privileged or confidential. 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 disclosure, copying, distribution or
>>>>     use of the contents of this information, including attached =
files, is prohibited.
>>>>=20
>>>>=20
>>>>=20
>>>>    _______________________________________________
>>>>    v6ops mailing list
>>>>    v6ops@ietf.org
>>>>    https://www.ietf.org/mailman/listinfo/v6ops
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>    _______________________________________________
>>>>    v6ops mailing list
>>>>    v6ops@ietf.org
>>>>    https://www.ietf.org/mailman/listinfo/v6ops
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>    _______________________________________________
>>>>    v6ops mailing list
>>>>    v6ops@ietf.org
>>>>    https://www.ietf.org/mailman/listinfo/v6ops
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> **********************************************
>>>> IPv4 is over
>>>> Are you ready for the new Internet ?
>>>> http://www.consulintel.es
>>>> The IPv6 Company
>>>>=20
>>>> This electronic message contains information which may be =
privileged or confidential. 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 disclosure, copying, distribution or use of =
the contents of this information, including attached files, is =
prohibited.
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>=20
>>>=20
>>>=20
>>>    --
>>>    SY, Jen Linkova aka Furry
>>>=20
>>>=20
>>>=20
>>>=20
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.consulintel.es
>>> The IPv6 Company
>>>=20
>>> This electronic message contains information which may be privileged =
or confidential. 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 disclosure, copying, distribution or use of the contents =
of this information, including attached files, is prohibited.
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>>=20
>>=20
>>    --
>>    SY, Jen Linkova aka Furry
>>=20
>>=20
>>=20
>>=20
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.consulintel.es
>> The IPv6 Company
>>=20
>> This electronic message contains information which may be privileged =
or confidential. 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 disclosure, copying, distribution or use of the contents =
of this information, including attached files, is prohibited.
>>=20
>>=20
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
>=20
>    --
>    SY, Jen Linkova aka Furry
>=20
>    _______________________________________________
>    v6ops mailing list
>    v6ops@ietf.org
>    https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>=20
> This electronic message contains information which may be privileged =
or confidential. 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 disclosure, copying, distribution or use of the contents =
of this information, including attached files, is prohibited.
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Jul 17 07:24:01 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ABE131B5A for ; Mon, 17 Jul 2017 07:23:59 -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, 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 QIWAB0tmQt3K for ; Mon, 17 Jul 2017 07:23:57 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1155413166B for ; Mon, 17 Jul 2017 07:23:57 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id h134so44033931iof.2 for ; Mon, 17 Jul 2017 07:23:57 -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=8dOCH2FvzDUxuStpMOYDrzvFPZIsN2G/Gj1YanWYGXs=; b=J68uADxZo57cNi9PlYFqEAuGWdYGPzR+NM0svmx3egSJs/a5cK3jGZvVTQG/1+aJox ElpIO4kcfJa2jSMMl22bHNQK3eJSceFHzX/6XmRtHrkaoyOevQZQCHu6K9Np5K55ehnU rZRpunUh71b222gw5uIsyzEj2fGD6F/o5iMP4zRJ0C2VcNWBTScHR+cm0qTLRH+86/4B yA1wIx58FFySyN4/McjFBGXbZ5VPz4J+QX9nMtjYB6ds8w4XKclbsTdB3MZxeS3ZPkqG n9hOkGOyNwf4fXIZ4OtJiGJnF5DNS6SVQLe7BEbRM29uNebywoZVlumpXz/+vO5h0W03 aRtA==
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=8dOCH2FvzDUxuStpMOYDrzvFPZIsN2G/Gj1YanWYGXs=; b=ZXG/FVL/oxB+Br0tMlbW473hL4blFNGdpRHPO261V3o9hRJqicZHRfF4JWI3DcGW4J MVgbcvc7gZxP3aPlLzuaEVyuIced5tKbVXFPMj3dhe6LIhnSLVPjFoE66uWwBow+YboV 1zONQGk1Yc1HwXpX2a66zoMTPOhSeVFn7nB6NCZ8f5irSMAetLG7v8uP0km4x8L78CHG GtgGwMh2CtdXB+Kn6akJQZUhrcMC2CyR/PeZBwt3BnuYcvTFBP/lkq6VmI8Ir9njmM0e sfiDVvbDy4ia1yM/cisIYei68WzB5hSYA/tSUglx0FVhvnN4G9yFuGwqlmBLFzt7DQh6 2uhg==
X-Gm-Message-State: AIVw112D/zr4M2bpU8rqYM7hi/kbGwBDIslUIPcLfsUeatKEeLbJU0uS Da83hESVSOcHgtPLLkex/ix2mBFpdgss
X-Received: by 10.107.197.4 with SMTP id v4mr19626977iof.124.1500301436312; Mon, 17 Jul 2017 07:23:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 07:23:35 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>  
From: Jen Linkova 
Date: Tue, 18 Jul 2017 00:23:35 +1000
Message-ID: 
To: Jordi Palet Martinez 
Cc: IPv6 Ops WG , Jim Martin , Alissa Cooper ,  Suresh Krishnan , Russ Housley , Randy Bush 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:24:00 -0000

On Tue, Jul 18, 2017 at 12:10 AM, JORDI PALET MARTINEZ
 wrote:
> If the end-users and enterprises are forced to switch to IPv6 only in the=
ir LANs, overnight, who is going to pay for replacing IP cameras, home auto=
mation, and many other old devices, that still work, but are IPv4-only?

To be honest I'm a bit lost now. Does anything I've said makes you
think that we are suggesting to migrate ALL end-user devices and
enterprise network on this planet to IPv6-only overnight? If it does,
my apologies, it was not what I meant.
I do not believe that switching between two existing SSID at one
conference is going to have such a world-wide impact ;)



> -----Mensaje original-----
> De: Jen Linkova 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 16:00
> Para: Jordi Palet Martinez 
> CC: IPv6 Ops WG , Jim Martin , Russ Hou=
sley , Suresh Krishnan , A=
lissa Cooper , Randy Bush 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Me=
etings
>
>     On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
>      wrote:
>     > I=E2=80=99m saying:
>     >
>     > 1) We should not try experiments in the IETF network, it has been t=
he rule for ages.
>     > 2) If we decide to change that rule, we should try what is good for=
 the market, not what we =E2=80=9Cwish=E2=80=9D
>
>     Could you pls elaborate on why proving that IPv6-only/NAT64 network
>     works (or if it does not, identifying the issues and getting them
>     fixed) is not good for the market? If, as you said, nobody is doing
>     Ipv6-only (and we have seen a number of comments stating the
>     opposite), wouldn't it be good for them if we prove that v6-only work=
s
>     and start working on issues? If, as some people have said, there are
>     Ipv6-only network out >
>     > Turning off IPv4 in the WAN, but keeping some sort of IPv4 connecti=
vity, is feasible. This is what we need to try.
>
>     >
>     >
>     > -----Mensaje original-----
>     > De: Jen Linkova 
>     > Responder a: 
>     > Fecha: lunes, 17 de julio de 2017, 10:42
>     > Para: Jordi Palet Martinez 
>     > CC: IPv6 Ops WG , Jim Martin , Al=
issa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
>     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
>     >
>     >     On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
>     >      wrote:
>     >     > Tell your bank, your university, your library, etc., to try t=
hat.
>     >     >
>     >     > I now that some networks (mainly related to IETF work, vendor=
s, etc.), are doing that, but not in a general market.
>     >
>     >     Are you saying IETF should wait until everyone else has done it=
 and
>     >     proved it works and only then we feel safe enough to try it? ;)
>     >
>     >     > -----Mensaje original-----
>     >     > De: Jen Linkova 
>     >     > Responder a: 
>     >     > Fecha: lunes, 17 de julio de 2017, 10:34
>     >     > Para: Jordi Palet Martinez 
>     >     > CC: IPv6 Ops WG , Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
>     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi=
 for IETF Meetings
>     >     >
>     >     >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
>     >     >      wrote:
>     >     >     > In the real world, you will not disable IPv4 in the LAN=
s of end-users or enterprise customers (at least not now, may be in 3-5 yea=
rs from now).
>     >     >
>     >     >     I disagree with this statement. There are networks doing =
this. Right
>     >     >     here right now.
>     >     >
>     >     >     > -----Mensaje original-----
>     >     >     > De: v6ops  en nombre de "Brzozo=
wski, John" 
>     >     >     > Responder a: 
>     >     >     > Fecha: lunes, 17 de julio de 2017, 10:14
>     >     >     > Para: Noah , Ted Lemon 
>     >     >     > CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
>     >     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only=
 Wi-Fi for IETF Meetings
>     >     >     >
>     >     >     >     Agree with Noah and Ted.
>     >     >     >
>     >     >     >     Note the I-D explicitly documents that a fallback, =
dual stack SSID must remain available as Noah mentions below.
>     >     >     >
>     >     >     >     I fail to see how doing this will harm or discrimin=
ate.
>     >     >     >
>     >     >     >     We do need to eat our own dogfood, otherwise we are=
 hypocrites.
>     >     >     >
>     >     >     >     John
>     >     >     >
>     >     >     >     +1-484-962-0060
>     >     >     >
>     >     >     >     From:
>     >     >     >     v6ops  on behalf of Noah 
>     >     >     >     Date: Monday, July 17, 2017 at 09:01
>     >     >     >     To: Ted Lemon 
>     >     >     >     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley =
, Jim Martin , Suresh Krishnan 
>     >     >     >     Subject: Re: [v6ops] Incremental Deployment of IPv6=
-only Wi-Fi for IETF Meetings
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     FWIW and to cater for all, would a fallback dual st=
ack SSID work for the status quo while this 2nd v6 SSID is also experimente=
d upon which is a great idea considering this is IETF.
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     Noah
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
>     >     >     >
>     >     >     >     I don't think this is a social justice issue.   Doe=
s the IETF think that IPv6 works, or not?   If we think it works, and we ha=
ve been working for what, 20 years, to make it work, and we have designed a=
ll this great
>     >     >     >      transition tech, then why on earth would we not wa=
nt to use it?   This isn't "one draft."   This is roughly half the work of =
the IETF for the past two decades.
>     >     >     >
>     >     >     >
>     >     >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTIN=
EZ  wrote:
>     >     >     >
>     >     >     >     So we agree to change the rules so that we use this=
 network for every ID that want to experiment with it? Otherwise we discrim=
inate among different authors =E2=80=A6
>     >     >     >
>     >     >     >     I think is a really bad precedent.
>     >     >     >
>     >     >     >     Regards,
>     >     >     >     Jordi
>     >     >     >
>     >     >     >
>     >     >     >     -----Mensaje original-----
>     >     >     >     De: Ted Lemon 
>     >     >     >     Responder a: 
>     >     >     >     Fecha: lunes, 17 de julio de 2017, 8:48
>     >     >     >     Para: JORDI PALET MARTINEZ 
>     >     >     >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
>     >     >     >      Krishnan , Russ Housley=
 , Alissa Cooper 
>     >     >     >     Asunto: Re: [v6ops] Incremental Deployment of IPv6-=
only Wi-Fi for IETF Meetings
>     >     >     >
>     >     >     >         I don't actually know what the goal of the IETF=
 network is other than to provide connectivity.   Because of the vicissitud=
es of hotel topology, it is often the case that IETF participants experienc=
e issues with the
>     >     >     >      network at least once or twice per IETF despite th=
e best efforts (and they are quite exceptional) of the NOC team.   I do not=
 really see what the damage is that you are hoping to protect against here.=
   Users who don't read the NOC announcement?   No sympathy.
>     >     >     >       Sorry.
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     **********************************************
>     >     >     >     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 confidential. The information is intended to be for th=
e use of the individual(s) named above. If you are not the intended recipie=
nt be aware that any disclosure, copying, distribution or
>     >     >     >      use of the contents of this information, including=
 attached files, is prohibited.
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     _______________________________________________
>     >     >     >     v6ops mailing list
>     >     >     >     v6ops@ietf.org
>     >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     _______________________________________________
>     >     >     >     v6ops mailing list
>     >     >     >     v6ops@ietf.org
>     >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >     _______________________________________________
>     >     >     >     v6ops mailing list
>     >     >     >     v6ops@ietf.org
>     >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > **********************************************
>     >     >     > 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 confidential. The information is intended to be for the us=
e of the individual(s) named above. If you are not the intended recipient b=
e aware that any disclosure, copying, distribution or use of the contents o=
f this information, including attached files, is prohibited.
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > _______________________________________________
>     >     >     > v6ops mailing list
>     >     >     > v6ops@ietf.org
>     >     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >
>     >     >
>     >     >
>     >     >     --
>     >     >     SY, Jen Linkova aka Furry
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > **********************************************
>     >     > 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 pri=
vileged or confidential. The information is intended to be for the use of t=
he individual(s) named above. If you are not the intended recipient be awar=
e that any disclosure, copying, distribution or use of the contents of this=
 information, including attached files, is prohibited.
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > v6ops mailing list
>     >     > v6ops@ietf.org
>     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
>     >
>     >     --
>     >     SY, Jen Linkova aka Furry
>     >
>     >
>     >
>     >
>     > **********************************************
>     > 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 privilege=
d or confidential. The information is intended to be for the use of the ind=
ividual(s) named above. If you are not the intended recipient be aware that=
 any disclosure, copying, distribution or use of the contents of this infor=
mation, including attached files, is prohibited.
>     >
>     >
>     >
>     > _______________________________________________
>     > v6ops mailing list
>     > v6ops@ietf.org
>     > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>     --
>     SY, Jen Linkova aka Furry
>
>
>
>
> **********************************************
> 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 c=
onfidential. The information is intended to be for the use of the individua=
l(s) named above. If you are not the intended recipient be aware that any d=
isclosure, copying, distribution or use of the contents of this information=
, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--=20
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 07:27:52 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9F131BFC for ; Mon, 17 Jul 2017 07:27:48 -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 JTH-QiKpBJib for ; Mon, 17 Jul 2017 07:27: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 786B3131B5A for ; Mon, 17 Jul 2017 07:27:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500301664; x=1500906464; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=pl8G04LPOyHG5/RFHzBb5DYg7 CJJ56NewnhVJmFuIEY=; b=QZuW/E3vdUhXP7ppTcfD6uaYGDO33Sn4pA8t+Sm78 nNTiID1s2Aqz1WlLnjuOqh8ImdP/IRIaHs7qoa6mhUDUQUEWQ4zzNBfEZZvGpGs2 n+9238BrHqZG7aq2UBqfVEuQmG4LPjaHegnsAF0obXUE2oQxVXViTHPU6gTDTOS0 vg=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Kq9nEkKo8lK7JqoqiK2ZDDCcPDiuFnoh5bx3xgIoWxYg1NHEsuxqUazHnbJD vq/rwBLvfbE3ZxZT3eY0rYtdeHGi/S0uDXKlfQ3hURBESFA0n/gALcQ7k uKHXr/AIv/qtTygfMbNiS6Wmf5ASQjx18A6I7Dj9peT1ud3Fj37Uic=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:27:43 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:27:41 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478567.msg for ; Mon, 17 Jul 2017 16:27:38 +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:170717:md50005478567::pmmRARHQCrML/HhG:00002z1u
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 16:27:32 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Alissa Cooper , Suresh Krishnan , Russ Housley , Jim Martin 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   <9CDFFE8B-DBEC-4059-8E93-44AEC304E31A@consulintel.es> <45A7CDF3-9832-4944-9D77-95E17EAEDB47@apple.com>
In-Reply-To: <45A7CDF3-9832-4944-9D77-95E17EAEDB47@apple.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:27:48 -0000

Ok, let me try to explain again =E2=80=A6

1) We want to try IPv6-only with NAT64/DNS64 to detect broken apps.
2) This means people using this NAT64 network will spend some time if they =
have some apps that don=E2=80=99t work thru NAT64 and detect them, and repo=
rt them to the NOC. Most folks will not necessarily be willing to do that, =
they will switch to the alternative SSID and keep working.
3) What I=E2=80=99m proposing is to use the same NAT64/DNS64 but at the sam=
e time provide a =E2=80=9CCLAT=E2=80=9D box in the same SSID (it can be mad=
e with Jool, I=E2=80=99ve a VM doing it already and I tested it in the prev=
ious IETF).
4) The result is the same, but people don=E2=80=99t need to spend time. We =
configure the Jool so it reports EVERY usage, so we can then process that f=
ile to detect WHAT was using the CLAT.
5) The result is the same as the suggested experiment, but NOT breaking any=
thing, not asking the participants to report anything, but having BETTER co=
llection of data about what will be broken if the CLAT is not there (anythi=
ng that goes into the CLAT).

This network is =E2=80=9Cspecial=E2=80=9D because most of the time, we have=
 only laptops and smartphones, which may work in a high % (may be even 80-8=
5%, just a guess), or we are able to =E2=80=9Ctrick=E2=80=9D it to work.

Real world networks (end-users and corporate which are not related to IETF)=
, will not (in 3-5 years), be willing to replace all the apps and devices t=
hat fail with just NAT64. They need a CLAT or similar support in their LANs=
.

For example as indicated before, MSoffice for MAC is not working, so defini=
tively anyone using it during the meeting, will need to switch to an altern=
ative SSID. No reporting from anything else broken for those participants.

Regards,
Jordi
=20

-----Mensaje original-----
De:  en nombre de David Schinazi 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 16:15
Para: 
CC: IPv6 Ops WG , Randy Bush , Alissa Cooper=
 , Suresh Krishnan , Russ Hou=
sley , Jim Martin 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    Jordi,
   =20
    464XLAT is the combination of a CLAT on the client and NAT64+DNS64 in t=
he network.
    This draft suggests operating the main IETF Wi-Fi as IPv6-only with NAT=
64+DNS64,
    precisely so you can contact IPv4 servers using mechanisms like 464XLAT=
 and HEv2.
    I'm not sure what your point is.
   =20
    David
   =20
   =20
    > On Jul 17, 2017, at 16:13, JORDI PALET MARTINEZ  wrote:
    >=20
    > If we count number of devices using it, the bigger one is 464XLAT. No=
 other transition technology has reached the millions of devices connected =
with an IPv6-only WAN but still providing IPv4 as a service (just look at c=
ellular operators in several countries, millions of users/devices).
    >=20
    > Regards,
    > Jordi
    >=20
    >=20
    > -----Mensaje original-----
    > De: Ted Lemon 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 16:09
    > Para: Jen Linkova 
    > CC: Jordi Palet Martinez , Randy Bush , IPv6 Ops WG , Russ Housley , Alissa Cooper , Jim Martin , Sur=
esh Krishnan 
    > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
    >=20
    >    To be clear, the reason to privilege nat64 is that it gives you ef=
fectively an IPv6-only network, with enough of a shim that most stuff that =
still relies on legacy servers still works.   It is not that nat64 is the t=
ransition technology that the market has chosen (I don't actually know what=
 the market has selected) but rather that it is the transition technology t=
hat allows us to not run _any_ IPv4 on the link.
    >=20
    >    On Mon, Jul 17, 2017 at 3:59 PM, Jen Linkova  w=
rote:
    >=20
    >    On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
    >     wrote:
    >> I=E2=80=99m saying:
    >>=20
    >> 1) We should not try experiments in the IETF network, it has been th=
e rule for ages.
    >> 2) If we decide to change that rule, we should try what is good for =
the market, not what we =E2=80=9Cwish=E2=80=9D
    >=20
    >    Could you pls elaborate on why proving that IPv6-only/NAT64 networ=
k
    >    works (or if it does not, identifying the issues and getting them
    >    fixed) is not good for the market? If, as you said, nobody is doin=
g
    >    Ipv6-only (and we have seen a number of comments stating the
    >    opposite), wouldn't it be good for them if we prove that v6-only w=
orks
    >    and start working on issues? If, as some people have said, there a=
re
    >    Ipv6-only network out >
    >> Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectiv=
ity, is feasible. This is what we need to try.
    >=20
    >>=20
    >>=20
    >> -----Mensaje original-----
    >> De: Jen Linkova 
    >> Responder a: 
    >> Fecha: lunes, 17 de julio de 2017, 10:42
    >> Para: Jordi Palet Martinez 
    >> CC: IPv6 Ops WG , Jim Martin , Ali=
ssa Cooper , Suresh Krishnan =
, Russ Housley , Randy Bush 
    >> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IE=
TF Meetings
    >>=20
    >>    On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
    >>     wrote:
    >>> Tell your bank, your university, your library, etc., to try that.
    >>>=20
    >>> I now that some networks (mainly related to IETF work, vendors, etc=
.), are doing that, but not in a general market.
    >>=20
    >>    Are you saying IETF should wait until everyone else has done it a=
nd
    >>    proved it works and only then we feel safe enough to try it? ;)
    >>=20
    >>> -----Mensaje original-----
    >>> De: Jen Linkova 
    >>> Responder a: 
    >>> Fecha: lunes, 17 de julio de 2017, 10:34
    >>> Para: Jordi Palet Martinez 
    >>> CC: IPv6 Ops WG , Jim Martin , Ru=
ss Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
    >>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for I=
ETF Meetings
    >>>=20
    >>>    On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
    >>>     wrote:
    >>>> In the real world, you will not disable IPv4 in the LANs of end-us=
ers or enterprise customers (at least not now, may be in 3-5 years from now=
).
    >>>=20
    >>>    I disagree with this statement. There are networks doing this. R=
ight
    >>>    here right now.
    >>>=20
    >>>> -----Mensaje original-----
    >>>> De: v6ops  en nombre de "Brzozowski, John"=
 
    >>>> Responder a: 
    >>>> Fecha: lunes, 17 de julio de 2017, 10:14
    >>>> Para: Noah , Ted Lemon 
    >>>> CC: Jim Martin , IPv6 Ops WG , A=
lissa Cooper , Russ Housley , Rand=
y Bush , Suresh Krishnan 
    >>>> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for =
IETF Meetings
    >>>>=20
    >>>>    Agree with Noah and Ted.
    >>>>=20
    >>>>    Note the I-D explicitly documents that a fallback, dual stack S=
SID must remain available as Noah mentions below.
    >>>>=20
    >>>>    I fail to see how doing this will harm or discriminate.
    >>>>=20
    >>>>    We do need to eat our own dogfood, otherwise we are hypocrites.
    >>>>=20
    >>>>    John
    >>>>=20
    >>>>    +1-484-962-0060 
    >>>>=20
    >>>>    From:
    >>>>    v6ops  on behalf of Noah 
    >>>>    Date: Monday, July 17, 2017 at 09:01
    >>>>    To: Ted Lemon 
    >>>>    Cc: Randy Bush , v6ops , Alissa =
Cooper , Russ Housley , Jim Martin=
 , Suresh Krishnan 
    >>>>    Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi =
for IETF Meetings
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    FWIW and to cater for all, would a fallback dual stack SSID wor=
k for the status quo while this 2nd v6 SSID is also experimented upon which=
 is a great idea considering this is IETF.
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    Noah
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
    >>>>=20
    >>>>    I don't think this is a social justice issue.   Does the IETF t=
hink that IPv6 works, or not?   If we think it works, and we have been work=
ing for what, 20 years, to make it work, and we have designed all this grea=
t
    >>>>     transition tech, then why on earth would we not want to use it=
?   This isn't "one draft."   This is roughly half the work of the IETF for=
 the past two decades.
    >>>>=20
    >>>>=20
    >>>>    On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ  wrote:
    >>>>=20
    >>>>    So we agree to change the rules so that we use this network for=
 every ID that want to experiment with it? Otherwise we discriminate among =
different authors =E2=80=A6
    >>>>=20
    >>>>    I think is a really bad precedent.
    >>>>=20
    >>>>    Regards,
    >>>>    Jordi
    >>>>=20
    >>>>=20
    >>>>    -----Mensaje original-----
    >>>>    De: Ted Lemon 
    >>>>    Responder a: 
    >>>>    Fecha: lunes, 17 de julio de 2017, 8:48
    >>>>    Para: JORDI PALET MARTINEZ 
    >>>>    CC: IPv6 Ops WG , Jim Martin =
, Randy Bush , Suresh
    >>>>     Krishnan , Russ Housley , Alissa Cooper 
    >>>>    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
    >>>>=20
    >>>>        I don't actually know what the goal of the IETF network is =
other than to provide connectivity.   Because of the vicissitudes of hotel =
topology, it is often the case that IETF participants experience issues wit=
h the
    >>>>     network at least once or twice per IETF despite the best effor=
ts (and they are quite exceptional) of the NOC team.   I do not really see =
what the damage is that you are hoping to protect against here.   Users who=
 don't read the NOC announcement?   No sympathy.
    >>>>      Sorry.
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    **********************************************
    >>>>    IPv4 is over
    >>>>    Are you ready for the new Internet ?
    >>>>    http://www.consulintel.es
    >>>>    The IPv6 Company
    >>>>=20
    >>>>    This electronic message contains information which may be privi=
leged or confidential. 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 disclosure, copying, distribution or
    >>>>     use of the contents of this information, including attached fi=
les, is prohibited.
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    _______________________________________________
    >>>>    v6ops mailing list
    >>>>    v6ops@ietf.org
    >>>>    https://www.ietf.org/mailman/listinfo/v6ops
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    _______________________________________________
    >>>>    v6ops mailing list
    >>>>    v6ops@ietf.org
    >>>>    https://www.ietf.org/mailman/listinfo/v6ops
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>    _______________________________________________
    >>>>    v6ops mailing list
    >>>>    v6ops@ietf.org
    >>>>    https://www.ietf.org/mailman/listinfo/v6ops
    >>>>=20
    >>>>=20
    >>>>=20
    >>>>=20
    >>>> **********************************************
    >>>> IPv4 is over
    >>>> Are you ready for the new Internet ?
    >>>> http://www.consulintel.es
    >>>> The IPv6 Company
    >>>>=20
    >>>> This electronic message contains information which may be privileg=
ed or confidential. The information is intended to be for the use of the in=
dividual(s) named above. If you are not the intended recipient be aware tha=
t any disclosure, copying, distribution or use of the contents of this info=
rmation, including attached files, is prohibited.
    >>>>=20
    >>>>=20
    >>>>=20
    >>>> _______________________________________________
    >>>> v6ops mailing list
    >>>> v6ops@ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/v6ops
    >>>=20
    >>>=20
    >>>=20
    >>>    --
    >>>    SY, Jen Linkova aka Furry
    >>>=20
    >>>=20
    >>>=20
    >>>=20
    >>> **********************************************
    >>> IPv4 is over
    >>> Are you ready for the new Internet ?
    >>> http://www.consulintel.es
    >>> The IPv6 Company
    >>>=20
    >>> This electronic message contains information which may be privilege=
d or confidential. The information is intended to be for the use of the ind=
ividual(s) named above. If you are not the intended recipient be aware that=
 any disclosure, copying, distribution or use of the contents of this infor=
mation, including attached files, is prohibited.
    >>>=20
    >>>=20
    >>>=20
    >>> _______________________________________________
    >>> v6ops mailing list
    >>> v6ops@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/v6ops
    >>=20
    >>=20
    >>=20
    >>    --
    >>    SY, Jen Linkova aka Furry
    >>=20
    >>=20
    >>=20
    >>=20
    >> **********************************************
    >> IPv4 is over
    >> Are you ready for the new Internet ?
    >> http://www.consulintel.es
    >> The IPv6 Company
    >>=20
    >> This electronic message contains information which may be privileged=
 or confidential. The information is intended to be for the use of the indi=
vidual(s) named above. If you are not the intended recipient be aware that =
any disclosure, copying, distribution or use of the contents of this inform=
ation, including attached files, is prohibited.
    >>=20
    >>=20
    >>=20
    >> _______________________________________________
    >> v6ops mailing list
    >> v6ops@ietf.org
    >> https://www.ietf.org/mailman/listinfo/v6ops
    >=20
    >=20
    >=20
    >    --
    >    SY, Jen Linkova aka Furry
    >=20
    >    _______________________________________________
    >    v6ops mailing list
    >    v6ops@ietf.org
    >    https://www.ietf.org/mailman/listinfo/v6ops
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.consulintel.es
    > The IPv6 Company
    >=20
    > This electronic message contains information which may be privileged =
or confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >=20
    >=20
    >=20
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =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 Mon Jul 17 07:30:22 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409D4131C08 for ; Mon, 17 Jul 2017 07:30:21 -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 s4iqi8HufCe2 for ; Mon, 17 Jul 2017 07:30:18 -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 25604131BFD for ; Mon, 17 Jul 2017 07:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500301816; x=1500906616; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=1axGJg8EjPThgljWvNjXU9aOF FVz4ZuhKWJN7O9Vs5I=; b=D5V+x9mwQa6HhFBMQK7lo/xlveaSnhkwZxM27mjjo 9BuyKoKjo0oV0g1aYzjbZRHZKC8SIliJqZqTqCnX5AFC/t7Dco7yx1xgY8zUx/E2 dBUHzI7Vgf39K4QtthE/RYtdYzB/1bUtsj3cA+KKEkircDQ5xUgAnoD/PfMW1FYp oE=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dx/77Zwc8G0QSuIhV9Szin9ynnzNxGAJJU1gDq6lbdAWgv/35UZ6QYk2Vk6q ZPsgzrCsbGKkCyBhq7r0ViQ62MWwcivlRbQXUSCKMnfTox9cxLC/a/uI2 eRqGMDr9UpXizg5/I3rf4Z/ITOlxBbReBR5k+s5oyHVT2w5RaQ2rxA=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:30:16 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:30:07 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478570.msg for ; Mon, 17 Jul 2017 16:30:05 +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:170717:md50005478570::lXCIBXYeG3nXG7mp:00002Y00
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 16:30:01 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Message-ID: <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:30:21 -0000

Exactly!

So the dogfood that we need to try (now) is the one that can sever the =E2=
=80=9Creal=E2=80=9D market, not the one that could serve the marked when th=
ey are ready to replace (in a big %) all the apps and devices that are IPv4=
 only. We could try this in a follow up phase (actually there is an SSID fo=
r that already).

Regards,
Jordi
=20

-----Mensaje original-----
De: Jen Linkova 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 16:24
Para: Jordi Palet Martinez 
CC: IPv6 Ops WG , Jim Martin , Alissa Coo=
per , Suresh Krishnan , Russ =
Housley , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Tue, Jul 18, 2017 at 12:10 AM, JORDI PALET MARTINEZ
     wrote:
    > If the end-users and enterprises are forced to switch to IPv6 only in=
 their LANs, overnight, who is going to pay for replacing IP cameras, home =
automation, and many other old devices, that still work, but are IPv4-only?
   =20
    To be honest I'm a bit lost now. Does anything I've said makes you
    think that we are suggesting to migrate ALL end-user devices and
    enterprise network on this planet to IPv6-only overnight? If it does,
    my apologies, it was not what I meant.
    I do not believe that switching between two existing SSID at one
    conference is going to have such a world-wide impact ;)
   =20
   =20
   =20
    > -----Mensaje original-----
    > De: Jen Linkova 
    > Responder a: 
    > Fecha: lunes, 17 de julio de 2017, 16:00
    > Para: Jordi Palet Martinez 
    > CC: IPv6 Ops WG , Jim Martin , Russ=
 Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
    > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IET=
F Meetings
    >
    >     On Mon, Jul 17, 2017 at 6:44 PM, JORDI PALET MARTINEZ
    >      wrote:
    >     > I=E2=80=99m saying:
    >     >
    >     > 1) We should not try experiments in the IETF network, it has be=
en the rule for ages.
    >     > 2) If we decide to change that rule, we should try what is good=
 for the market, not what we =E2=80=9Cwish=E2=80=9D
    >
    >     Could you pls elaborate on why proving that IPv6-only/NAT64 netwo=
rk
    >     works (or if it does not, identifying the issues and getting them
    >     fixed) is not good for the market? If, as you said, nobody is doi=
ng
    >     Ipv6-only (and we have seen a number of comments stating the
    >     opposite), wouldn't it be good for them if we prove that v6-only =
works
    >     and start working on issues? If, as some people have said, there =
are
    >     Ipv6-only network out >
    >     > Turning off IPv4 in the WAN, but keeping some sort of IPv4 conn=
ectivity, is feasible. This is what we need to try.
    >
    >     >
    >     >
    >     > -----Mensaje original-----
    >     > De: Jen Linkova 
    >     > Responder a: 
    >     > Fecha: lunes, 17 de julio de 2017, 10:42
    >     > Para: Jordi Palet Martinez 
    >     > CC: IPv6 Ops WG , Jim Martin =
, Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
    >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi f=
or IETF Meetings
    >     >
    >     >     On Mon, Jul 17, 2017 at 6:37 PM, JORDI PALET MARTINEZ
    >     >      wrote:
    >     >     > Tell your bank, your university, your library, etc., to t=
ry that.
    >     >     >
    >     >     > I now that some networks (mainly related to IETF work, ve=
ndors, etc.), are doing that, but not in a general market.
    >     >
    >     >     Are you saying IETF should wait until everyone else has don=
e it and
    >     >     proved it works and only then we feel safe enough to try it=
? ;)
    >     >
    >     >     > -----Mensaje original-----
    >     >     > De: Jen Linkova 
    >     >     > Responder a: 
    >     >     > Fecha: lunes, 17 de julio de 2017, 10:34
    >     >     > Para: Jordi Palet Martinez 
    >     >     > CC: IPv6 Ops WG , Jim Martin , Russ Housley , Suresh Krishnan , Alissa Cooper , Randy Bush 
    >     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-only W=
i-Fi for IETF Meetings
    >     >     >
    >     >     >     On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
    >     >     >      wrote:
    >     >     >     > In the real world, you will not disable IPv4 in the=
 LANs of end-users or enterprise customers (at least not now, may be in 3-5=
 years from now).
    >     >     >
    >     >     >     I disagree with this statement. There are networks do=
ing this. Right
    >     >     >     here right now.
    >     >     >
    >     >     >     > -----Mensaje original-----
    >     >     >     > De: v6ops  en nombre de "Br=
zozowski, John" 
    >     >     >     > Responder a: 
    >     >     >     > Fecha: lunes, 17 de julio de 2017, 10:14
    >     >     >     > Para: Noah , Ted Lemon 
    >     >     >     > CC: Jim Martin , IPv6 Ops WG , Alissa Cooper , Russ Housley , Randy Bush , Suresh Krishnan 
    >     >     >     > Asunto: Re: [v6ops] Incremental Deployment of IPv6-=
only Wi-Fi for IETF Meetings
    >     >     >     >
    >     >     >     >     Agree with Noah and Ted.
    >     >     >     >
    >     >     >     >     Note the I-D explicitly documents that a fallba=
ck, dual stack SSID must remain available as Noah mentions below.
    >     >     >     >
    >     >     >     >     I fail to see how doing this will harm or discr=
iminate.
    >     >     >     >
    >     >     >     >     We do need to eat our own dogfood, otherwise we=
 are hypocrites.
    >     >     >     >
    >     >     >     >     John
    >     >     >     >
    >     >     >     >     +1-484-962-0060
    >     >     >     >
    >     >     >     >     From:
    >     >     >     >     v6ops  on behalf of Noa=
h 
    >     >     >     >     Date: Monday, July 17, 2017 at 09:01
    >     >     >     >     To: Ted Lemon 
    >     >     >     >     Cc: Randy Bush , v6ops , Alissa Cooper , Russ Housley , Jim Martin , Suresh Krishnan 
    >     >     >     >     Subject: Re: [v6ops] Incremental Deployment of =
IPv6-only Wi-Fi for IETF Meetings
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     FWIW and to cater for all, would a fallback dua=
l stack SSID work for the status quo while this 2nd v6 SSID is also experim=
ented upon which is a great idea considering this is IETF.
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     Noah
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     On 17 Jul 2017 9:54 a.m., "Ted Lemon"  wrote:
    >     >     >     >
    >     >     >     >     I don't think this is a social justice issue.  =
 Does the IETF think that IPv6 works, or not?   If we think it works, and w=
e have been working for what, 20 years, to make it work, and we have design=
ed all this great
    >     >     >     >      transition tech, then why on earth would we no=
t want to use it?   This isn't "one draft."   This is roughly half the work=
 of the IETF for the past two decades.
    >     >     >     >
    >     >     >     >
    >     >     >     >     On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MA=
RTINEZ  wrote:
    >     >     >     >
    >     >     >     >     So we agree to change the rules so that we use =
this network for every ID that want to experiment with it? Otherwise we dis=
criminate among different authors =E2=80=A6
    >     >     >     >
    >     >     >     >     I think is a really bad precedent.
    >     >     >     >
    >     >     >     >     Regards,
    >     >     >     >     Jordi
    >     >     >     >
    >     >     >     >
    >     >     >     >     -----Mensaje original-----
    >     >     >     >     De: Ted Lemon 
    >     >     >     >     Responder a: 
    >     >     >     >     Fecha: lunes, 17 de julio de 2017, 8:48
    >     >     >     >     Para: JORDI PALET MARTINEZ 
    >     >     >     >     CC: IPv6 Ops WG , Jim Martin , Randy Bush , Suresh
    >     >     >     >      Krishnan , Russ Hou=
sley , Alissa Cooper 
    >     >     >     >     Asunto: Re: [v6ops] Incremental Deployment of I=
Pv6-only Wi-Fi for IETF Meetings
    >     >     >     >
    >     >     >     >         I don't actually know what the goal of the =
IETF network is other than to provide connectivity.   Because of the viciss=
itudes of hotel topology, it is often the case that IETF participants exper=
ience issues with the
    >     >     >     >      network at least once or twice per IETF despit=
e the best efforts (and they are quite exceptional) of the NOC team.   I do=
 not really see what the damage is that you are hoping to protect against h=
ere.   Users who don't read the NOC announcement?   No sympathy.
    >     >     >     >       Sorry.
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     **********************************************
    >     >     >     >     IPv4 is over
    >     >     >     >     Are you ready for the new Internet ?
    >     >     >     >     http://www.consulintel.es
    >     >     >     >     The IPv6 Company
    >     >     >     >
    >     >     >     >     This electronic message contains information wh=
ich may be privileged or confidential. The information is intended to be fo=
r the use of the individual(s) named above. If you are not the intended rec=
ipient be aware that any disclosure, copying, distribution or
    >     >     >     >      use of the contents of this information, inclu=
ding attached files, is prohibited.
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     _______________________________________________
    >     >     >     >     v6ops mailing list
    >     >     >     >     v6ops@ietf.org
    >     >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     _______________________________________________
    >     >     >     >     v6ops mailing list
    >     >     >     >     v6ops@ietf.org
    >     >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >     _______________________________________________
    >     >     >     >     v6ops mailing list
    >     >     >     >     v6ops@ietf.org
    >     >     >     >     https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     > **********************************************
    >     >     >     > 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 confidential. The information is intended to be for th=
e use of the individual(s) named above. If you are not the intended recipie=
nt be aware that any disclosure, copying, distribution or use of the conten=
ts of this information, including attached files, is prohibited.
    >     >     >     >
    >     >     >     >
    >     >     >     >
    >     >     >     > _______________________________________________
    >     >     >     > v6ops mailing list
    >     >     >     > v6ops@ietf.org
    >     >     >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     >     >
    >     >     >
    >     >     >
    >     >     >     --
    >     >     >     SY, Jen Linkova aka Furry
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     > **********************************************
    >     >     > 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 confidential. 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 disclosure, copying, distribution or use of the contents of =
this information, including attached files, is prohibited.
    >     >     >
    >     >     >
    >     >     >
    >     >     > _______________________________________________
    >     >     > v6ops mailing list
    >     >     > v6ops@ietf.org
    >     >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >     --
    >     >     SY, Jen Linkova aka Furry
    >     >
    >     >
    >     >
    >     >
    >     > **********************************************
    >     > 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 privi=
leged or confidential. 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 disclosure, copying, distribution or use of the contents of this i=
nformation, including attached files, is prohibited.
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > v6ops@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >     --
    >     SY, Jen Linkova aka Furry
    >
    >
    >
    >
    > **********************************************
    > 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 confidential. The information is intended to be for the use of the indiv=
idual(s) named above. If you are not the intended recipient be aware that a=
ny disclosure, copying, distribution or use of the contents of this informa=
tion, including attached files, is prohibited.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
   =20
   =20
   =20
    --=20
    SY, Jen Linkova aka Furry
   =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 Mon Jul 17 07:30:45 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82316131C17 for ; Mon, 17 Jul 2017 07:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnTXR7O64fFI for ; Mon, 17 Jul 2017 07:30:31 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3DD131B5A for ; Mon, 17 Jul 2017 07:30:30 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 549EF41BFC for ; Mon, 17 Jul 2017 16:30:28 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0A4E641BF8; Mon, 17 Jul 2017 16:30:28 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 0629A9BBC; Mon, 17 Jul 2017 16:30:28 +0200 (CEST)
Date: Mon, 17 Jul 2017 16:30:27 +0200
From: Gert Doering 
To: JORDI PALET MARTINEZ 
Cc: IPv6 Ops WG , Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Message-ID: <20170717143027.GT45648@Space.Net>
References:   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:30:44 -0000

Hi,

On Mon, Jul 17, 2017 at 04:10:44PM +0200, JORDI PALET MARTINEZ wrote:
> If the end-users and enterprises are forced to switch to IPv6 only in their LANs, overnight, who is going to pay for replacing IP cameras, home automation, and many other old devices, that still work, but are IPv4-only?

What exactly does this have to do with the IETF meeting network?

(But if it turns out that the IETF bought gear that is v4 only, maybe
purchasing policies need to be reviewed)

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

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


From nobody Mon Jul 17 07:36:48 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26368131C21 for ; Mon, 17 Jul 2017 07:36:47 -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 wI6FgInLVS4Q for ; Mon, 17 Jul 2017 07:36: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 922DD131C1D for ; Mon, 17 Jul 2017 07:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500302203; x=1500907003; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=z5DthB6jxYlkp/wsPYRNrE0fv 1Fpvm9c70rtT5Ef3V4=; b=EmxDgkVLCNJrMxN0cJMcCwGalUwFRNUnghvlOWf2W hyrKcgzawGs8bsICHsgI3bdGJnGk5sq/U76roWUXvwYg2ZVBWFzRl6HJSuNaRpzf subhhuWy5GEn8Q//IxxlV/i2c0ZRq1OGCrwRbcTeoyIaHsmiwuVTsFnSm/hPkKek mg=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cRKUn+IxZ0SHAyQq6piHnYcSlsnNY2HSwXzfkxeOwuUB/oLENQkLlT9lJMUM X089N6TgLpSd8VN51uo0lLKa7m9WxbFkIs7Ti+1Ud1upgrp+OwYLVfUAb c12PXyLUaMjmFBDtzMPuK01EKfDU1VX/JOX/pI4yE0aLc9k9rDzGwQ=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:36:43 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:36:42 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478578.msg for ; Mon, 17 Jul 2017 16:36:41 +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:170717:md50005478578::DU98hFJb5zjwOpdy:00003UCG
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 16:36:36 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References:   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   <20170717143027.GT45648@Space.Net>
In-Reply-To: <20170717143027.GT45648@Space.Net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Reply-To: jordi.palet@consulintel.es
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:36:47 -0000

If I understood correctly one of the main goals is to collect as much data as possible for broken apps.

Why doing it manually if it can be done automatically and we avoid disturbing anyone, which will mean that they will probably switch to the alternative SSID and stop reporting (as I needed to do myself because MS Office) ?

Regards,
Jordi
 

-----Mensaje original-----
De: Gert Doering 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 16:30
Para: JORDI PALET MARTINEZ 
CC: IPv6 Ops WG , Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Hi,
    
    On Mon, Jul 17, 2017 at 04:10:44PM +0200, JORDI PALET MARTINEZ wrote:
    > If the end-users and enterprises are forced to switch to IPv6 only in their LANs, overnight, who is going to pay for replacing IP cameras, home automation, and many other old devices, that still work, but are IPv4-only?
    
    What exactly does this have to do with the IETF meeting network?
    
    (But if it turns out that the IETF bought gear that is v4 only, maybe
    purchasing policies need to be reviewed)
    
    Gert Doering
            -- NetMaster
    -- 
    have you enabled IPv6 on something today...?
    
    SpaceNet AG                        Vorstand: Sebastian v. Bomhard
    Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
    



**********************************************
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 confidential. 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 disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.




From nobody Mon Jul 17 07:41:32 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DC8131C3B for ; Mon, 17 Jul 2017 07:41:30 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...J158udPDLSFo==EN4LHjWb_YzD5Q@mail.gmail.com>\n  
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 f4MLeHZLdgxr for ; Mon, 17 Jul 2017 07:41:29 -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 9DBB2131BF1 for ; Mon, 17 Jul 2017 07:41:28 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dX7DB-0000FzC; Mon, 17 Jul 2017 16:41:25 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   
In-reply-to: Your message of "Tue, 18 Jul 2017 00:23:35 +1000 ."  
Date: Mon, 17 Jul 2017 16:41:24 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:41:31 -0000

> To be honest I'm a bit lost now. Does anything I've said makes you
> think that we are suggesting to migrate ALL end-user devices and
> enterprise network on this planet to IPv6-only overnight? If it
> does, my apologies, it was not what I meant.  I do not believe that
> switching between two existing SSID at one conference is going to
> have such a world-wide impact ;)

If we assume that home wifi networks will remain dual stack for the next
couple of decades to support IPv4-only devices (the WAN link can be come
IPv6-only but the CPE will offer dual stack on wifi one way or another).

If we assume that most office wifi networks (and networks that connect measurement
equipment, industrial controllers, etc.) will do the same, then why would
we advocate that other wifi networks switch to a completely different way of
providing IPv4 connectivity?

Do we do that just to make sure that anything related to IPv6 is as confusing
as possible?

For extra confusion, we also call a network that supports NAT64 'IPv6-only'.
I guess that just to make sure that there is no way to describe a network that
really just provides IPv6 without any access to IPv4.



From nobody Mon Jul 17 07:42:00 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8E131C35 for ; Mon, 17 Jul 2017 07:41:52 -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 gSSe9_whCejh for ; Mon, 17 Jul 2017 07:41:50 -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 3C1CC131C3F for ; Mon, 17 Jul 2017 07:41:47 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id A5D91A2; Mon, 17 Jul 2017 16:41:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1500302504; bh=km8iF34ZS6XXu4g7ebp31pMkCR9pMOLz7WZiIZlT7a4=; h=Date:From:To:Subject:In-Reply-To:References:From; b=RjaeUfMidnmBRDqqWmTSicP/ddipX8nGeWlkG7GEq7bdSq+a5bKmBnYar2YgR+CVX aN0HTTf7l42JBrV2Lv8xYa9ce4WwFgWUsNK3DelSWq38mc2ocVkntsjDMyjzJGtl10 KRqp7EKuiuFWSwUyQhq70FNEQWWQlzNNRIGnAASA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DF1BA1 for ; Mon, 17 Jul 2017 16:41:44 +0200 (CEST)
Date: Mon, 17 Jul 2017 16:41:44 +0200 (CEST)
From: Mikael Abrahamsson 
To: IPv6 Ops WG 
In-Reply-To: <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es>
Message-ID: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es>
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-1567714210-1500302504=:29742"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:41:53 -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-1567714210-1500302504=:29742
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:

> So the dogfood that we need to try (now) is the one that can sever the 
> “real” market, not the one that could serve the marked when they are 
> ready to replace (in a big %) all the apps and devices that are IPv4 
> only. We could try this in a follow up phase (actually there is an SSID 
> for that already).

My android and iOS devices work great on IPv6 only using the proposed 
suggestion. My MacOS and Windows do not (because they don't have the 
464XLAT or bump-in-the-API that is available on the mobile platforms). I 
already know this. I don't need to prove it to anyone.

It's premature to go IPv6 only on the main wifi before main operating 
systems support the same mechanisms available on the mobile devices.

1. My "mosh" session only tries the same AF that it initially connected 
to. If I initially connected on an IPv4 network, it will never connect to 
anything on an IPv6 network.

2. My Windows VM which needs to reach IPv4 only resources have no way to 
do this through the Parallels NAT44. I would need a CLAT for this.

There are lots of desktop OS applications that do not work on IPv6 only 
DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is no 
need to do wider test. OS vendors need to implement CLAT (or equivalent) 
for it to be viable.

If the main wifi is going IPv6 only, I will run my mobile devices on it, 
but I will immediately swap to the dual stack SSID for my computer.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-1567714210-1500302504=:29742--


From nobody Mon Jul 17 07:44:04 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F771131C26 for ; Mon, 17 Jul 2017 07:43: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, 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=fugue-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 VVclxqzNQZ1y for ; Mon, 17 Jul 2017 07:43:52 -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 2324B131C42 for ; Mon, 17 Jul 2017 07:43:52 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id q86so77503119pfl.3 for ; Mon, 17 Jul 2017 07:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m9sH/PgXw42VxwSRlf58tIgG9IAwIKjNndudeeFx/Y0=; b=p3xlrjYJ6Xm/nzEAJB9efiZTwcstvP/yEAIawpwBfuy6/yC/6JS+mXLq5QswQ8HKaG MntFl4mf6paqbyafep/iW5A7sS9jrof/+iiiIYd5viUminBPEQ2bqpnLYw1vZ+GsbTkM le1lnVax2uZ66JOVQVjti0rcNzkpbfU/Vo2amrfDS9+aXssUFQ/o8eM6SelqdMiEzOBl dX1VEvNOpyF2Kn7Ll13KrdioS9EeCld0nD5BVKInXlyrfAZAPmhipfK9Wj9VgvM19wQK 1YgyMvOFh18jBXDae1C/B4V6JLUqKpw1RDqdghEu1gNrzR7FNIPLyakAzP3amTgacKpC QgPg==
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=m9sH/PgXw42VxwSRlf58tIgG9IAwIKjNndudeeFx/Y0=; b=Cpb6m4ktTpJgmiFegHa6Md/knEoZIDqebvXnii4gTXRAScujZeusPf7TrWDBCYbZXe shxU1Ny5fdsBUb4LqCBzz0UG4UhX+HXAfuMqqO9BhcJMAhRiVGVOtuAAJjQ1Sbj9sP8y OYdrgyPaBOx9FMpjqtP3MeVTBBc/Y9Hu81bhko55TB4cEjsChNLAm0HzK4DUaGeSQPMz A+dxwEnWtdZjOJ/W2MdZFrUBhWW/tVYaHJzI3Jckr2hWeKNTRIoC5BQMhJFawuWp5Zww fUeaIl9wZkSxzoakkHY0syZ4kyMq8SZU2S70asUafo9qMQdOVYgrmp8VNpECvnJRFUQa klGw==
X-Gm-Message-State: AIVw1139qxV9Ba9LjxC8Sowq0sizGYTyvYZWbh3oWBdPM8a77tzI5Tta +rtgWyCx7r5jhf5YEyesGFHVZmv1TqG87zw=
X-Received: by 10.98.67.147 with SMTP id l19mr19134967pfi.198.1500302631621; Mon, 17 Jul 2017 07:43:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 07:43:10 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> 
From: Ted Lemon 
Date: Mon, 17 Jul 2017 16:43:10 +0200
Message-ID: 
To: Mikael Abrahamsson 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="94eb2c0c0f4469ec400554846d16"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:43:57 -0000

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

I realize that Jordi is not satisfied by any of the responses to this
message that have been sent so far, and I don't want to minimize the
unfortunateness of that, but I do not think there is any change that
further discussion on the topic is going to result in that satisfaction
happening, and I don't think we are learning anything new by continuing the
discussion.   I am muting this thread now, so please do not take my
subsequent silence as agreement with Jordi's position.

On Mon, Jul 17, 2017 at 4:41 PM, Mikael Abrahamsson 
wrote:

> On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:
>
> So the dogfood that we need to try (now) is the one that can sever the
>> =E2=80=9Creal=E2=80=9D market, not the one that could serve the marked w=
hen they are ready
>> to replace (in a big %) all the apps and devices that are IPv4 only. We
>> could try this in a follow up phase (actually there is an SSID for that
>> already).
>>
>
> My android and iOS devices work great on IPv6 only using the proposed
> suggestion. My MacOS and Windows do not (because they don't have the
> 464XLAT or bump-in-the-API that is available on the mobile platforms). I
> already know this. I don't need to prove it to anyone.
>
> It's premature to go IPv6 only on the main wifi before main operating
> systems support the same mechanisms available on the mobile devices.
>
> 1. My "mosh" session only tries the same AF that it initially connected
> to. If I initially connected on an IPv4 network, it will never connect to
> anything on an IPv6 network.
>
> 2. My Windows VM which needs to reach IPv4 only resources have no way to
> do this through the Parallels NAT44. I would need a CLAT for this.
>
> There are lots of desktop OS applications that do not work on IPv6 only
> DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is no
> need to do wider test. OS vendors need to implement CLAT (or equivalent)
> for it to be viable.
>
> If the main wifi is going IPv6 only, I will run my mobile devices on it,
> but I will immediately swap to the dual stack SSID for my computer.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

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


I realize that Jordi is n=
ot satisfied by any of the responses to this message that have been sent so=
 far, and I don't want to minimize the unfortunateness of that, but I d=
o not think there is any change that further discussion on the topic is goi=
ng to result in that satisfaction happening, and I don't think we are l=
earning anything new by continuing the discussion. =C2=A0 I am muting this =
thread now, so please do not take my subsequent silence as agreement with J=
ordi's position.

On Mon, Jul 17, 2017 at 4:41 PM, Mikael Abrahamsson <sw=
mike@swm.pp.se> wrote:
On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:





So the dogfood that we need to try (now) is the one that can sever the =E2=
=80=9Creal=E2=80=9D market, not the one that could serve the marked when th=
ey are ready to replace (in a big %) all the apps and devices that are IPv4=
 only. We could try this in a follow up phase (actually there is an SSID fo=
r that already).





My android and iOS devices work great on IPv6 only using the proposed sugge=
stion. My MacOS and Windows do not (because they don't have the 464XLAT=
 or bump-in-the-API that is available on the mobile platforms). I already k=
now this. I don't need to prove it to anyone.



It's premature to go IPv6 only on the main wifi before main operating s=
ystems support the same mechanisms available on the mobile devices.



1. My "mosh" session only tries the same AF that it initially con=
nected to. If I initially connected on an IPv4 network, it will never conne=
ct to anything on an IPv6 network.



2. My Windows VM which needs to reach IPv4 only resources have no way to do=
 this through the Parallels NAT44. I would need a CLAT for this.



There are lots of desktop OS applications that do not work on IPv6 only DNS=
64+DNS64 without CLAT. I have tried this, it doesn't work, there is no =
need to do wider test. OS vendors need to implement CLAT (or equivalent) fo=
r it to be viable.



If the main wifi is going IPv6 only, I will run my mobile devices on it, bu=
t I will immediately swap to the dual stack SSID for my computer.



-- 

Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
___________________=
____________________________

v6ops mailing list

v6ops@ietf.org

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





--94eb2c0c0f4469ec400554846d16--


From nobody Mon Jul 17 07:44:25 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091D1131C51 for ; Mon, 17 Jul 2017 07:44:23 -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 QMv9zwNvuaKT for ; Mon, 17 Jul 2017 07:44:22 -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 A0739131C57 for ; Mon, 17 Jul 2017 07:44:14 -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 v6HEiD9h040490 for ; Mon, 17 Jul 2017 16:44:13 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0AC362041BC for ; Mon, 17 Jul 2017 16:44:13 +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 EB697200B51 for ; Mon, 17 Jul 2017 16:44:12 +0200 (CEST)
Received: from [132.166.84.54] ([132.166.84.54]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HEiCBc016917 for ; Mon, 17 Jul 2017 16:44:12 +0200
To: v6ops@ietf.org
References:   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   <20170717143027.GT45648@Space.Net> 
From: Alexandre Petrescu 
Message-ID: <2c798145-b684-dc5a-8ba4-256dc28bf4ec@gmail.com>
Date: Mon, 17 Jul 2017 16:44:12 +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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:44:24 -0000

Le 17/07/2017 à 16:36, JORDI PALET MARTINEZ a écrit :
> If I understood correctly one of the main goals is to collect as much
> data as possible for broken apps.

If the IPv6-only WiFi IETF experiment leads to installing a DHCPv6-PD 
server on the IETF network, and realisation that odhcp6c (DHCP client 
developped on openWRT) does not compile on Android because of a lacking 
libresolv - then I will be very happy.  It will probably help with maybe 
Android offering a working libresolv, and hence we can no longer say 
that DHCP-PD doesnt work on Android...  DHCP-PD is very important on 
cellular links.

Is there a DHCPv6-PD server on the IETF WiFi network?

Alex


From nobody Mon Jul 17 07:56:00 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2483D131C34 for ; Mon, 17 Jul 2017 07:55:58 -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 DOLx_Dzgd-y8 for ; Mon, 17 Jul 2017 07:55:56 -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 4753D131C52 for ; Mon, 17 Jul 2017 07:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500303354; x=1500908154; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=m5kgyyU3prB07cjlClucvvj2Y 2s/v6hBT8vIuA4/LNc=; b=AZwAcQKZJkDNyuTqBlvai3DnISjCpb7t2mSJ86GPn FFRpRKWL/0ASzUS2Sm+p231PAwzK+DHfeFjwHS7eFDp9EYir/4vkOdOC1ZakKvzA bX1domJbyWhtZ7g4WzJuQjnj3bCrz7+G+/2aIOWbvJ3D1UnfW5L8r2yTft44hJxE 00=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=NA8RqXJxXYExfZt5AOeO944G1ysfZiXSveAK4n0+bIASaWYKuYxtdx4Eoh2Q dOYPgZIPWCRC/ImMBEPrGvfvg0h6KY5NX6raRSvGHVRrCmPydae+Z+DZL 6y64w2DTPtb6lvK0QRjo417LtliP5jFBp6OrP7kzFr3ONYyjnFZgKY=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:55:54 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 16:55:52 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478618.msg for ; Mon, 17 Jul 2017 16:55:51 +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:170717:md50005478618::RFqtmakW6YnOvLL/:00003Nh0
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 16:55:44 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Jim Martin , Alissa Cooper , Suresh Krishnan , Russ Housley , Randy Bush 
Message-ID: <257B8C25-9BF7-4D02-8C58-8A6D9DF0C07C@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> 
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 14:55:58 -0000

Thanks to Mikael and Philip, seems that finally somebody understood my poin=
t =E2=80=A6 I didn=E2=80=99t expect it will be so hard to make it clear =E2=
=80=A6

May be the question is what is the main goal of the experiment?

1) Just to FORCE us to run with NAT64 (then switch back =E2=80=93 many of u=
s - to an alternative SSID)
2) To detect AS MANY broken apps as possible

That brings to the right decision I guess.

Regards,
Jordi
=20

-----Mensaje original-----
De: v6ops  en nombre de Mikael Abrahamsson 
Organizaci=C3=B3n: People's Front Against WWW
Responder a: 
Fecha: lunes, 17 de julio de 2017, 16:42
Para: IPv6 Ops WG 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:
   =20
    > So the dogfood that we need to try (now) is the one that can sever th=
e=20
    > =E2=80=9Creal=E2=80=9D market, not the one that could serve the marke=
d when they are=20
    > ready to replace (in a big %) all the apps and devices that are IPv4=
=20
    > only. We could try this in a follow up phase (actually there is an SS=
ID=20
    > for that already).
   =20
    My android and iOS devices work great on IPv6 only using the proposed=
=20
    suggestion. My MacOS and Windows do not (because they don't have the=20
    464XLAT or bump-in-the-API that is available on the mobile platforms). =
I=20
    already know this. I don't need to prove it to anyone.
   =20
    It's premature to go IPv6 only on the main wifi before main operating=
=20
    systems support the same mechanisms available on the mobile devices.
   =20
    1. My "mosh" session only tries the same AF that it initially connected=
=20
    to. If I initially connected on an IPv4 network, it will never connect =
to=20
    anything on an IPv6 network.
   =20
    2. My Windows VM which needs to reach IPv4 only resources have no way t=
o=20
    do this through the Parallels NAT44. I would need a CLAT for this.
   =20
    There are lots of desktop OS applications that do not work on IPv6 only=
=20
    DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is =
no=20
    need to do wider test. OS vendors need to implement CLAT (or equivalent=
)=20
    for it to be viable.
   =20
    If the main wifi is going IPv6 only, I will run my mobile devices on it=
,=20
    but I will immediately swap to the dual stack SSID for my computer.
   =20
    --=20
    Mikael Abrahamsson    email: swmike@swm.pp.se__________________________=
_____________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =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 Mon Jul 17 08:08:49 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD48E131C4C for ; Mon, 17 Jul 2017 08:08:44 -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, 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 2O2TmFt22MGj for ; Mon, 17 Jul 2017 08:08:43 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 725E0131C45 for ; Mon, 17 Jul 2017 08:08:43 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id h134so44840051iof.2 for ; Mon, 17 Jul 2017 08:08:43 -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=iNC3m2rohNg5TRLAIKZzZs/YSN9yC+9HDq6HjlFqP4o=; b=bVg8ZiCkg5yCJWM8ogFsCBUr/DdjTWnlcvuYfa5cINOjf3CNrj16bebtrSjVZUaq5N PGL9uAhvWqRKj1FnfnOP2v3pBKl9Ae6TXF2hzkvEkTvYjqbF5XpaUan4tBOuv0gnuvGu AT8Zh+hzccJA09VA8QIfkSnySgcLHUrOkoE/WA9OlRU2Dsn1cdJSF53xfEgPjyO3zL33 Oi3S3WIcscsZvEYFsR1mmAAhHOKZ/kNAMUU5Debvic1p3j8C38hPFeaRCrezArBsHyb1 11/kN1qOWM8pt5LzzkcW56HsmAb8Ve9BHUc7VPIJjMxYkhaAbglxHzDR16j0NmtoN37S luJQ==
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=iNC3m2rohNg5TRLAIKZzZs/YSN9yC+9HDq6HjlFqP4o=; b=L7IUA58GFjdaoMODWJ9uEIVixcYN4eoDd3pypPa1679SkMqaMb3kllg4VmWbaxVO9q UFta0dolKN+t2Xj8RhZ1gcc/OBjLhX6hYh5riGPRhx+mlSi0NiI9jWQ0Co6UaE2Z5O12 TNHt7+3Vo5F+ny1D2nYRrCeJ3XuviHdj5TIjFeEzaLM75UHZ6uq2W9IMcqlidiVVjLz7 NQyFDECQzlsm7Hpl1Gg7ynSihJwg/Y+x7/v3OBeYZOkk70x0xdprofJ0udXBstDGx5ph nBXioD2F8tyDzUF+Hb1Honlp0ODFVLxQaM7ec7BHybNe3tmPPhiDHMKutIP1BwVjmDtM XWtw==
X-Gm-Message-State: AIVw111wIua+dQGZNHRnvictPOo9elK3Z1YjkgOhB3fLSQ+QxRPX5Xki W8R/Azm/IVsou440c6h6vFTyuJ+/qrii
X-Received: by 10.107.137.161 with SMTP id t33mr19551165ioi.181.1500304122583;  Mon, 17 Jul 2017 08:08:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 08:08:21 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    
From: Jen Linkova 
Date: Tue, 18 Jul 2017 01:08:21 +1000
Message-ID: 
To: Philip Homburg 
Cc: "v6ops@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 15:08:45 -0000

On Tue, Jul 18, 2017 at 12:41 AM, Philip Homburg
 wrote:
> If we assume that home wifi networks will remain dual stack for the next
> couple of decades to support IPv4-only devices (the WAN link can be come
> IPv6-only but the CPE will offer dual stack on wifi one way or another).
>
> If we assume that most office wifi networks (and networks that connect measurement
> equipment, industrial controllers, etc.) will do the same, then why would
> we advocate that other wifi networks switch to a completely different way of
> providing IPv4 connectivity?

I find it quite amusing how almost any IPv6-related problem turns out
to be a chicken and egg one.
'Nobody is using this because it is broken. It is broken because
nobody is using it'..

-- 
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 08:17:13 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D95A131C55 for ; Mon, 17 Jul 2017 08:17: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, 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 sXAACbVnHPMt for ; Mon, 17 Jul 2017 08:17:10 -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 31CD8126D73 for ; Mon, 17 Jul 2017 08:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500304627; x=1500909427; 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=5GGRZ0WzXFwVA7TwnJS8qDWIx w6s6Vb45oA/WN2Ky1Q=; b=tGOdEhervN+gZM3/MnQI8qiYmrFeoTqOx5QFgTq22 ySMJ5StsA5z9+RHPgv1gnc5cbdo/xQ53o8hsIv8dWa+vg9UunNqVejwjqQfNx5IE 4Gckw8z/iGge2L/ejO+IUkvd3vXMrI2f3gB6i0GGLt0bYBEm06yBUqeIz5EAH6y9 wA=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VS2oSP+IqHkRpQM/2LwY2NULKSub98p5Al+b85RLksBB5ynKfrwWmEw/uw9q cq+xYVzqKOdbXmWOXcqhD1GcVw3lLw2UBmcUjMLkJrxv17ypPMLcGL2nK NVtekmmht9Cp9sdci9YoP4eligm351wvfAb+jdMwjSqFBpfOiTblfs=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 17:17:07 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 17:17:06 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478638.msg for ; Mon, 17 Jul 2017 17:17:05 +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:170717:md50005478638::hRSiJo0jrq0e3Iyf:00003J/3
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 17:16:59 +0200
From: JORDI PALET MARTINEZ 
To: "v6ops@ietf.org" 
Message-ID: <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>     
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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 15:17:12 -0000

I see it in another way around:

1) I really want to get IPv6 deployed ASAP
2) I need to be in touch with market reality
3) This means IPv6-only WAN is feasible only if we keep some =E2=80=9Cminim=
um=E2=80=9D IPv4 service in the LANs

Is not a chicken and egg. If we get ISPs having the possibility of deployin=
g IPv6-only ASAP, with CPEs that run basic IPv4 service, and this not means=
 investing in CGN and all kind of tricks to keep providing IPv4 service, we=
 will succeed in increase the rate of IPv6 global traffic, which will push =
the vendors of any kind of devices to support IPv6, so later on, we could h=
ave *real* IPv6-only LANs as well.

Regars,
Jordi
=20

-----Mensaje original-----
De: v6ops  en nombre de Jen Linkova 
Responder a: 
Fecha: lunes, 17 de julio de 2017, 17:09
Para: Philip Homburg 
CC: "v6ops@ietf.org" 
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meet=
ings

    On Tue, Jul 18, 2017 at 12:41 AM, Philip Homburg
     wrote:
    > If we assume that home wifi networks will remain dual stack for the n=
ext
    > couple of decades to support IPv4-only devices (the WAN link can be c=
ome
    > IPv6-only but the CPE will offer dual stack on wifi one way or anothe=
r).
    >
    > If we assume that most office wifi networks (and networks that connec=
t measurement
    > equipment, industrial controllers, etc.) will do the same, then why w=
ould
    > we advocate that other wifi networks switch to a completely different=
 way of
    > providing IPv4 connectivity?
   =20
    I find it quite amusing how almost any IPv6-related problem turns out
    to be a chicken and egg one.
    'Nobody is using this because it is broken. It is broken because
    nobody is using it'..
   =20
    --=20
    SY, Jen Linkova aka Furry
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =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 Mon Jul 17 08:17:40 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6839E129B5E for ; Mon, 17 Jul 2017 08:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKV5CVJr_RNM for ; Mon, 17 Jul 2017 08:17:37 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84862131C65 for ; Mon, 17 Jul 2017 08:17:27 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 16BA241BF9 for ; Mon, 17 Jul 2017 17:17:26 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E36FC41B72; Mon, 17 Jul 2017 17:17:25 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id D56119D98; Mon, 17 Jul 2017 17:17:25 +0200 (CEST)
Date: Mon, 17 Jul 2017 17:17:25 +0200
From: Gert Doering 
To: Mikael Abrahamsson 
Cc: IPv6 Ops WG 
Message-ID: <20170717151725.GU45648@Space.Net>
References: <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 15:17:39 -0000

Hi,

On Mon, Jul 17, 2017 at 04:41:44PM +0200, Mikael Abrahamsson wrote:
> 1. My "mosh" session only tries the same AF that it initially connected 
> to. If I initially connected on an IPv4 network, it will never connect to 
> anything on an IPv6 network.

This sounds like something that needs being worked on...  not much
different than the OpenVPN case - "stupid software, needs enough exposure
that people get annoyed and fix it".

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

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


From nobody Mon Jul 17 08:18:55 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B5E131C55 for ; Mon, 17 Jul 2017 08:18:53 -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 DnEtq-NZv6-O for ; Mon, 17 Jul 2017 08:18: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 8BD56131C67 for ; Mon, 17 Jul 2017 08:18: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 m1dX7nO-0000GTC; Mon, 17 Jul 2017 17:18:50 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      
In-reply-to: Your message of "Tue, 18 Jul 2017 01:08:21 +1000 ."  
Date: Mon, 17 Jul 2017 17:18:50 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 15:18:53 -0000

>I find it quite amusing how almost any IPv6-related problem turns out
>to be a chicken and egg one.
>'Nobody is using this because it is broken. It is broken because
>nobody is using it'..

I'm a very happy user of IPv6. No problem there.

Labeling IPv4 access as 'IPv6-only' provides the suggestion that this a actually
an IPv6 problem.

It isn't. This is a problem for people who want to stop supporting IPv4 but
realize that they have to keep supporting IPv4 for the next couple of decades.

What I find suprising is that people advocate supporting legacy IPv4 services
in a way that breaks how they are traditionally deployed. 

Oh yeah, we will support IPv4, but only if you upgrade each and every device 
that you expect to use IPv4 on.



From nobody Mon Jul 17 08:23:57 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE40D1287A0 for ; Mon, 17 Jul 2017 08:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWR0QYG6vtJ7 for ; Mon, 17 Jul 2017 08:23:48 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F3C1200FC for ; Mon, 17 Jul 2017 08:23:47 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2594741BF9 for ; Mon, 17 Jul 2017 17:23:46 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id F24A841B72; Mon, 17 Jul 2017 17:23:45 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id E34A29DB8; Mon, 17 Jul 2017 17:23:45 +0200 (CEST)
Date: Mon, 17 Jul 2017 17:23:45 +0200
From: Gert Doering 
To: Philip Homburg 
Cc: v6ops@ietf.org
Message-ID: <20170717152345.GV45648@Space.Net>
References:    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 15:23:55 -0000

Hi,

On Mon, Jul 17, 2017 at 05:18:50PM +0200, Philip Homburg wrote:
> Oh yeah, we will support IPv4, 

"Supporting unwilling remote endpoints" is something we cannot afford to
not-do in the next few years.

"Support unwilling applications" is something else, and their time is
running out.  If it can be done on the mobile world, why can it not 
be done in the windows or linux ecosystem?

IPv6-only with NAT64/DNS64 supports the first.

> but only if you upgrade each and every device that you expect to use IPv4 on.

So how many (client) devices do you have that have not been upgraded in the
last 10 years, and do not support IPv6, getaddrinfo(), and friends?

If IPv6 were something new, like "invented last year", that "expect 
devices to be upgraded" argument would be slightly more relevant than
for a protocol from last century.

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

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


From nobody Mon Jul 17 08:52:08 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A7B12EC12 for ; Mon, 17 Jul 2017 08:52:06 -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, 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 31WhxWNA-zbg for ; Mon, 17 Jul 2017 08:52:05 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1D2131C78 for ; Mon, 17 Jul 2017 08:52:05 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id v202so13650670itb.1 for ; Mon, 17 Jul 2017 08:52: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=Kzzo1iufgEpdgkO/62PPsbrpuWaEAF3VzXZotwjlflM=; b=qGMX+Vhj+ee18kssnhY9T6C2wvpqJE8DK+VSxtHAt7YmrItGaB+dfQQOaHiWrPB1i0 aP0DN4tC7J73yyjFNhh96dA3AfBbQYcGMxxpD4fnvjTLp6Dy17fj37agWpKvoEKFTTP1 gcYn9N4h9pDVGIyeEsOGtdBK/jiSGJ4w/W75B+M2yYeA97MIpdrFsiPoBIW2bjnH2mym nRyfNTyaIHw+USvfqFK9EE9LLNHQuR6uBWq9Kg9bQwHe5JXYTmvF1Wn01XEfalqayI40 UQ2+7Siy8h/v7zBjyGsHus1y1rEpc1184P0ej+MFw545/t+rLfoyA15MbXJRe+OHyZWv 1nGw==
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=Kzzo1iufgEpdgkO/62PPsbrpuWaEAF3VzXZotwjlflM=; b=CSBKheZVKEijZo3G0otUuY39tF5M7EW472b1krjeaEll5ylolOqPVJNsfHQYro3bRl kIDU+97/g5eIIiw4J8N4mD0mqfcE37Q1LM6D9mP47ZV2W1j1cMLeWUqrgOnRFq4y3Va6 hB0e23eTOfV4FgNbG+E6FJFPhRmpfqxq91a5Dzk5K21QsRy4q6V+EtHURA9uNZNIKseA WPWoESkMzdDYgPivrjSLk04uGfp/1sU6Yfqk1R+V7CrdPThJPEytNoHQLX99SF5+VoDG rd1OTjGV/Ks4enb3uoW2NRsTWIhus+JexQ1fX+HLWj2Zg26Sp/EntyXFhXZobNJhukiC 9/JQ==
X-Gm-Message-State: AIVw1121YOqpJCVtWkrcJxoEf9L6KESTRaToi8lIUfgU308sWY0cNM2M chgxelEKhZgSALMfbJoCYhyP/rYTd7D8
X-Received: by 10.36.196.67 with SMTP id v64mr6105265itf.89.1500306724832; Mon, 17 Jul 2017 08:52:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 08:51:43 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> 
From: Jen Linkova 
Date: Tue, 18 Jul 2017 01:51:43 +1000
Message-ID: 
To: Mikael Abrahamsson 
Cc: IPv6 Ops WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 15:52:07 -0000

On Tue, Jul 18, 2017 at 12:41 AM, Mikael Abrahamsson  wrote:
> My android and iOS devices work great on IPv6 only using the proposed
> suggestion. My MacOS and Windows do not (because they don't have the 464XLAT
> or bump-in-the-API that is available on the mobile platforms). I already
> know this. I don't need to prove it to anyone.

IMHO your email illustrates why exactly we need the proposed experiment.
Some people have said 'NAT64 does not work for me. It does not work
for most of the people here'.
Others said 'I've been using NAT64 SSID as a default one for years and
it works perfectly fine for me. Let's see if it's the case for others
and if it does not, what can be done to fix it'.
Let's go and get numbers.


-- 
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 09:03:38 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE88A131C84 for ; Mon, 17 Jul 2017 09:03: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] 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 Pt0a5nuJaqP3 for ; Mon, 17 Jul 2017 09:03:35 -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 801F1131C71 for ; Mon, 17 Jul 2017 09:03:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dX8Uf-0000FkC; Mon, 17 Jul 2017 18:03:33 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References:    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>       <20170717152345.GV45648@Space.Net> 
In-reply-to: Your message of "Mon, 17 Jul 2017 17:23:45 +0200 ." <20170717152345.GV45648@Space.Net> 
Date: Mon, 17 Jul 2017 18:03:32 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 16:03:37 -0000

>"Support unwilling applications" is something else, and their time is
>running out.  If it can be done on the mobile world, why can it not 
>be done in the windows or linux ecosystem?

First, many people have devices they don't want to part with.

Second, some people may run old operating systems that need local network 
connectivity while on the same LAN other devices need full internet connectivity.

So no matter what, lots of wifi or 802.3 will have to have some form of 
'native' IPv4 support.

For an ISP it doesn't make sense to provide CPEs with native IPv4 support
to one group of customers and NAT64 to another.

So most likely ISP will hand out CPEs that provide native IPv4 for the next
couple of decades. There is no way ISPs can affort the supports calls if they
break too many legacy devices or setups.

>> but only if you upgrade each and every device that you expect to use IPv4 on.
>
>So how many (client) devices do you have that have not been upgraded in the
>last 10 years, and do not support IPv6, getaddrinfo(), and friends?

How much code did you write that deals with IPv4 literals?

If the literal is already in binary form, you can use it directly. If you
already know that the literal is an IPv4 literal, then calling inet_pton is
way more convenient than calling getaddrinfo.

Next, if the application uses getaddrinfo but happens to be statically linked
with the getaddrinfo implementation then you are also out of luck.

So for most operating systems, something like 464XLAT makes most sense. You
want a 'socket(PF_INET, ...)' system call to work even if the application 
contains hand written assembly that makes the system call directly.

Operating systems started to include 464XLAT support only recently. And will take
a long time before essentially all operating systems have 464XLAT support. After
that it will take an enormous amount of time before all old devices
are either upgraded or retired.

And then what did we really achieve? Remove a tiny bit of code from CPEs and
related routers? Is it the religious IPv6 purity that demands that IPv4 native
needs to be killed as soon as possible?

>If IPv6 were something new, like "invented last year", that "expect 
>devices to be upgraded" argument would be slightly more relevant than
>for a protocol from last century.

This is an edge case, but you don't want to know how much I had to change to the
Atlas probes and related infrastructure to get them to support NAT64/DNS64. 


From nobody Mon Jul 17 09:06:37 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BDA131C9F for ; Mon, 17 Jul 2017 09:06:35 -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, 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 yikGosKuIwcZ for ; Mon, 17 Jul 2017 09:06:33 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34D2131C9E for ; Mon, 17 Jul 2017 09:06:33 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id v202so52289098itb.0 for ; Mon, 17 Jul 2017 09:06:33 -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=51HWlnNbfLD+/VkCqj2idAuPFC+Oj26F15vwlsNeFzs=; b=p1no5YaQN3jxUqo253AVFQz/urw9wTUidbeU497exyqI7fhTIbwLzSemOVjwFeFJfx zvoSP9nq2wYtJZZwxUnaG+VblevObSAjaaKiXiS0P5pLK1gyXrPvJY+OJLziLYUzPBgC Yjn/fo7L7xB82CN1hmeyvrGVTc6in3vTfbZFj7LVnhZ57JBtPPtakDaGLMRM6L+NiJc3 ADeiK6JK56WAGiX120ozUjkDh2CHxEf0ZpUaUzdaIgJ/ordIMvXV/a9YsdGEdFwRQ2Ca sqB3IxTo0LTP42Rs4CRzaZJIIjrNQUQApboydhXp97S4fyZkxoD/Gx2Y4lB9CaphE2kz c2UA==
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=51HWlnNbfLD+/VkCqj2idAuPFC+Oj26F15vwlsNeFzs=; b=ouuhkS3GBMtlAKY91oko/IfXjp6hueAXqq4G8ZfayDrLOKLCPsM0oVjtSxJ9m5yBya X5qi9BmJnIBdMXlaUwtEjd0WBrjdY4JxYGH/umHqevqfjjTTFj0FKtDqnhVfqVRDXG7L EWceiR2LS6FKpJTKnrY/WiurR1Ltf8yp86qnFu3kFOGv8ti1ahehjMaSISKM9xtFGeFg OZLZzD+xTIDVOj7OsExq7QCFZ5MtydNLksrdbxdFxUQ56Sl9m+jdwaBDiIWT8Dh0jgCY T7aA3rG7IgiK54GTW8vy15e89liIaMrJNYjnmqNkWx6jTykjYBXzIlW8DiJCK/qlNrNb A/xw==
X-Gm-Message-State: AIVw1125dv9dCEZtdNJbG71qr19OyCVSnIrfMB7yBfDhBkHyGR59ukn/ lgRvoxq77u39pWF3nsatp43f27Otmg==
X-Received: by 10.36.68.193 with SMTP id o184mr6118626ita.59.1500307593121; Mon, 17 Jul 2017 09:06:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Mon, 17 Jul 2017 09:06:11 -0700 (PDT)
In-Reply-To: <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>
From: Jen Linkova 
Date: Tue, 18 Jul 2017 02:06:11 +1000
Message-ID: 
To: Jordi Palet Martinez 
Cc: "v6ops@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 16:06:35 -0000

On Tue, Jul 18, 2017 at 1:16 AM, JORDI PALET MARTINEZ
 wrote:
> I see it in another way around:
>
> 1) I really want to get IPv6 deployed ASAP
> 2) I need to be in touch with market reality
> 3) This means IPv6-only WAN is feasible only if we keep some =E2=80=9Cmin=
imum=E2=80=9D IPv4 service in the LANs
>
> Is not a chicken and egg.

Let me clarify what I mean by the chicken and egg problem here.
'We can not turn off IPv4 because there are IPv4-only endpoints there
and they are not going away. Why those endpoints are not going away?
Because there is no demand for them to work on Ipv6-only networks. Why
there is
no demand for them to work on IPv6-only networks? Because nobody is
turning off IPv4'.



> -----Mensaje original-----
> De: v6ops  en nombre de Jen Linkova 
> Responder a: 
> Fecha: lunes, 17 de julio de 2017, 17:09
> Para: Philip Homburg 
> CC: "v6ops@ietf.org" 
> Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Me=
etings
>
>     On Tue, Jul 18, 2017 at 12:41 AM, Philip Homburg
>      wrote:
>     > If we assume that home wifi networks will remain dual stack for the=
 next
>     > couple of decades to support IPv4-only devices (the WAN link can be=
 come
>     > IPv6-only but the CPE will offer dual stack on wifi one way or anot=
her).
>     >
>     > If we assume that most office wifi networks (and networks that conn=
ect measurement
>     > equipment, industrial controllers, etc.) will do the same, then why=
 would
>     > we advocate that other wifi networks switch to a completely differe=
nt way of
>     > providing IPv4 connectivity?
>
>     I find it quite amusing how almost any IPv6-related problem turns out
>     to be a chicken and egg one.
>     'Nobody is using this because it is broken. It is broken because
>     nobody is using it'..
>
>     --
>     SY, Jen Linkova aka Furry
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> **********************************************
> 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 c=
onfidential. The information is intended to be for the use of the individua=
l(s) named above. If you are not the intended recipient be aware that any d=
isclosure, copying, distribution or use of the contents of this information=
, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--=20
SY, Jen Linkova aka Furry


From nobody Mon Jul 17 09:26:04 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2CC131CA8 for ; Mon, 17 Jul 2017 09:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 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_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 Dkmp8GFjqVPM for ; Mon, 17 Jul 2017 09:26:00 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 B6C73128BC8 for ; Mon, 17 Jul 2017 09:26:00 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id d136so12132018qkg.3 for ; Mon, 17 Jul 2017 09:26: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=fwtxUEjq3y5fpkSQEVMk6m5Mth/BiXZCQ9xrhKFgk0c=; b=f3HASZa8pNLGcrcLJjuVLCBWqBnxAGDuhnDvfpAFyEbpABhB/rSCUPybphgVuu0Quy kTkG/gP3+lpFtRS8aN4nWWrMJPMWJD6okcReUW8dlMHMO1vvNXhnl9vtBzik93JRjZgm iYLkmJN3H7AhqPO4p19q4KhlidY7cLZxEUwFNgITl/Eugk2xitwjpt+KFD00goVz53R2 xk1uWfwVSg1pqD4C8Of7k5iC3M3u96pdifJho8BJwBCALkX/3sgz7qsOmeBXe3c4ZeO5 McJn0S9n4vE1avC2JR+zL40pX3XTEC1neKT4WDPKq3xiVb8VjmNlOOCK6eqfbX35Icm6 oGPQ==
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=fwtxUEjq3y5fpkSQEVMk6m5Mth/BiXZCQ9xrhKFgk0c=; b=fBnY3xDwApH0L5u6HjpOhJbvZCA2nVa1wy78rR0XQBS3xgKT/m6eAXnlcwZrTV/Cgb +AXgVxD6pM3CxoLBlmmaIGLyfQBqlNZwYc3mMaKQriJ4KF3Toqm5vCpYDIGE5467Qi5W EQVjssGEvDHpfGthYKBbrIuv5J3fAgM0fDsJIzp86s61LX3eIDzB0wkpvByAWblkAuPw KpbewwFFD77HVcxJaL9I9qL/f17F8t+S+IZSRwKzWyMPHS6s1wphbYgR2cybKGHNeoaY XeGHIoCNBLQl49qPffS45A+0UDBdzXiBJ69GVQnGw8ErpQoGYEKJ+RZyBGi6XB7y069k /Cnw==
X-Gm-Message-State: AIVw111PTEcgGnSu+bRMIk5iM9Y5J2zYBGIAzoL1yppgn3zDsc3dfsJ2 /YyymeES7GxGFju7raoPILTk1OkX0A==
X-Received: by 10.55.33.195 with SMTP id f64mr28417705qki.208.1500308759785; Mon, 17 Jul 2017 09:25:59 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.12.169.25 with HTTP; Mon, 17 Jul 2017 09:25:58 -0700 (PDT)
Received: by 10.12.169.25 with HTTP; Mon, 17 Jul 2017 09:25:58 -0700 (PDT)
In-Reply-To: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> 
From: Erik Nygren 
Date: Mon, 17 Jul 2017 12:25:58 -0400
X-Google-Sender-Auth: kCs0ta8y_U-_aJHnCbB72FLAZec
Message-ID: 
To: Mikael Abrahamsson 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="001a11401636ae356d055485da45"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 16:26:03 -0000

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

I'll add to the list of problems I run into on the NAT64 network:  VPN with
split tunnelling and DNS sent through the VPN means the DNS64 gets
bypassed. I assume the same would hold true of clients overriding the
advertised DNS servers (eg, using Google DNS).

A local CLAT helps.  Ideally VPNs doing split tunnelling could be made
DNS64/NAT64 aware.  And apps being clever enough to do their own DNS should
ideally also resolve ipv4only.arpa via the system resolver to do their own
DNS64 synthesis.

- Erik.  (Torn on which ietf we start this with...)

     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

On Jul 17, 2017 9:42 AM, "Mikael Abrahamsson"  wrote:

> On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:
>
> So the dogfood that we need to try (now) is the one that can sever the
>> =E2=80=9Creal=E2=80=9D market, not the one that could serve the marked w=
hen they are ready
>> to replace (in a big %) all the apps and devices that are IPv4 only. We
>> could try this in a follow up phase (actually there is an SSID for that
>> already).
>>
>
> My android and iOS devices work great on IPv6 only using the proposed
> suggestion. My MacOS and Windows do not (because they don't have the
> 464XLAT or bump-in-the-API that is available on the mobile platforms). I
> already know this. I don't need to prove it to anyone.
>
> It's premature to go IPv6 only on the main wifi before main operating
> systems support the same mechanisms available on the mobile devices.
>
> 1. My "mosh" session only tries the same AF that it initially connected
> to. If I initially connected on an IPv4 network, it will never connect to
> anything on an IPv6 network.
>
> 2. My Windows VM which needs to reach IPv4 only resources have no way to
> do this through the Parallels NAT44. I would need a CLAT for this.
>
> There are lots of desktop OS applications that do not work on IPv6 only
> DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is no
> need to do wider test. OS vendors need to implement CLAT (or equivalent)
> for it to be viable.
>
> If the main wifi is going IPv6 only, I will run my mobile devices on it,
> but I will immediately swap to the dual stack SSID for my computer.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

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


I'll add to the list of problems I run into on the NA=
T64 network: =C2=A0VPN with split tunnelling and DNS sent through the VPN m=
eans the DNS64 gets bypassed. I assume the same would hold true of clients =
overriding the advertised DNS servers (eg, using Google DNS).

A local CLAT helps.=C2=A0 Ideally VPNs doin=
g split tunnelling could be made DNS64/NAT64 aware.=C2=A0 And apps being cl=
ever enough to do their own DNS should ideally also resolve ipv4only.arpa v=
ia the system resolver to do their own DNS64 synthesis.

- Erik. =C2=A0=
(Torn on which ietf we start this with...)

=C2=A0=C2=A0=C2=A0=C2=A0 =
[Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

On Jul 17, 2017=
 9:42 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:





So the dogfood that we need to try (now) is the one that can sever the =E2=
=80=9Creal=E2=80=9D market, not the one that could serve the marked when th=
ey are ready to replace (in a big %) all the apps and devices that are IPv4=
 only. We could try this in a follow up phase (actually there is an SSID fo=
r that already).





My android and iOS devices work great on IPv6 only using the proposed sugge=
stion. My MacOS and Windows do not (because they don't have the 464XLAT=
 or bump-in-the-API that is available on the mobile platforms). I already k=
now this. I don't need to prove it to anyone.



It's premature to go IPv6 only on the main wifi before main operating s=
ystems support the same mechanisms available on the mobile devices.



1. My "mosh" session only tries the same AF that it initially con=
nected to. If I initially connected on an IPv4 network, it will never conne=
ct to anything on an IPv6 network.



2. My Windows VM which needs to reach IPv4 only resources have no way to do=
 this through the Parallels NAT44. I would need a CLAT for this.



There are lots of desktop OS applications that do not work on IPv6 only DNS=
64+DNS64 without CLAT. I have tried this, it doesn't work, there is no =
need to do wider test. OS vendors need to implement CLAT (or equivalent) fo=
r it to be viable.



If the main wifi is going IPv6 only, I will run my mobile devices on it, bu=
t I will immediately swap to the dual stack SSID for my computer.



-- 

Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--001a11401636ae356d055485da45--


From nobody Mon Jul 17 09:26:31 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3CE131CA8 for ; Mon, 17 Jul 2017 09:26:29 -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 xuRFYNbp3orV for ; Mon, 17 Jul 2017 09:26:27 -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 287D0131CA3 for ; Mon, 17 Jul 2017 09:26:27 -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 v6HGQPIh033250 for ; Mon, 17 Jul 2017 18:26:25 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 28652205673 for ; Mon, 17 Jul 2017 18:26: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 1EC2D202EB7 for ; Mon, 17 Jul 2017 18:26:25 +0200 (CEST)
Received: from [132.166.84.48] ([132.166.84.48]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HGQOl8017994 for ; Mon, 17 Jul 2017 18:26:24 +0200
To: v6ops@ietf.org
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com>
From: Alexandre Petrescu 
Message-ID: <9948cb75-6c11-9071-697f-a79702472132@gmail.com>
Date: Mon, 17 Jul 2017 18:26:24 +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: <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 16:26:30 -0000

Well, this is to note that we too (Fred mentioned it too earlier) made
the ISC DHCPv6 dhclient work on Android, including DHCPv6 Solicit that
requests Prefix Delegation.

(but we still dont have a response to DHCP Solicit on cellular link).

Alex

Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit :
> Mark, noted, will try.
> 
> Just a note...
> 
> Le 06/07/2017 à 03:16, Mark Andrews a écrit :
>> 
>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>,
>> Alexandre Petrescu writes:
>>> Hello,
>>> 
>>> We discussed extensively about the potential use of DHCPv6
>>> Prefix Delegation on cellular links.
>>> 
>>> The chicken issue is the lack of DHCPv6 PD software on typical
>>> User Equipment.  For example, there is no DHCPv6-PD app on
>>> Android.  The egg issue is the lack of operator support of
>>> DHCPv6-PD towards the User Terminal.  For example, there is no
>>> cellular operator answering to DHCPv6-PD requests issued by the
>>> User Terminal.
>>> 
>>> To address the chicken issue, we started with an ISC DHCP open
>>> software client, which does implement Prefix Delegation.  It can
>>> be (cross)compiled on various platforms; then type "./dhclient -6
>>> -P"; this sends an DHCPv6 Solicit Identity Associtaion for Prefix
>>> Delegation message on the interface.
>>> 
>>> However, whereas this software runs ok on interfaces such as
>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the
>>> cellular interface of some IoT cellular platform.  The error can
>>> be corrected by the quick-and-dirty solution below.
>> 
>> The hack would be better as
>> 
>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] =
>> HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif 
>> default: log_fatal("Unsupported device type %ld for \"%s\"", (long
>> int)sa->sa_family, name); break;
>> 
>> with ARPHRD_XXXX being replaced by the correct macro for 503 from
>> .  Something like that is at least portable.
> 
> But it means when I go to other platform will have to modify again
> the ISC client source code?
> 
> In cellular terminals there are so many non-IEEE different kinds of
> links.
> 
> Other clients work out of the box on this - I agree with you, strange
> - "rmnet0" interface.
> 
> Alex
> 
>> 
>> As for the rest of it I have no idea about the presented hardware 
>> address of this type so I don't know it the rest of it make sense.
>> 
>>> Alex
>>> 
>>> ------------------------------------------------------------------------
>>>
>>> 
The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
>>> dhcp-4.3.5 ./common/lpf.c line number: 551
>>> 
>>> //default: //      log_fatal("Unsupported device type %ld for
>>> \"%s\"", //                (long int)sa->sa_family, name); 
>>> default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; 
>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break;
>>> 
>>> (two programmers worked this out).
>>> 
>>> Alex
>>> 
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Jul 17 10:03:26 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235FF131668 for ; Mon, 17 Jul 2017 10:03:25 -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 08FpYcNqj8xy for ; Mon, 17 Jul 2017 10:03:24 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D7D3E1300CE for ; Mon, 17 Jul 2017 10:03: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 m1dX9QX-0000DnC; Mon, 17 Jul 2017 19:03:21 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>  
In-reply-to: Your message of "Tue, 18 Jul 2017 02:06:11 +1000 ."  
Date: Mon, 17 Jul 2017 19:03:20 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:03:25 -0000

> Let me clarify what I mean by the chicken and egg problem here.
> 'We can not turn off IPv4 because there are IPv4-only endpoints
> there and they are not going away. Why those endpoints are not
> going away? Because there is no demand for them to work on Ipv6-only
> networks. Why there is no demand for them to work on IPv6-only
> networks? Because nobody is turning off IPv4'.

I find it fascinating that IPv6 is bad at competing with IPv4 even now
that IPv4 addresses have run out for a while, that you advocate actively
breaking IPv4.



From nobody Mon Jul 17 10:04:23 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F039B12EAB0 for ; Mon, 17 Jul 2017 10:04:21 -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 FaMdLegcGRSs for ; Mon, 17 Jul 2017 10:04:15 -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 5EC061300CE for ; Mon, 17 Jul 2017 10:04:15 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id x125so50315731ywa.0 for ; Mon, 17 Jul 2017 10:04:15 -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=AxT6P2IKhOPFlMCR/zb1IoAYd5c12TJP+81/6B25qkU=; b=l4rBfWWO+nU0j0qDsN3AYLn2ATkiK+DGYBgiupOWNBvASyMWXxW5C/NyetlMw2hK/H CT5Mx3xlCYYNqpjs+Eb8kTnN6oiLrCI6I3YFZduWg8z/uUIu0ptsWSJuUZUx+IIsXJIb N2X9xSCZOTA/RvkSsxVMlIE7mzoUHTkmcoNr2fMQk8bMsVfMci1qwcBy0FAp6KuEvqjJ 3jAFwexJGzpW09BgDpHg7U5rqymwuczPQZ0oBQgkaN0Qpf7/S0j5Bn11l+2pHpWNgnWF yJQKZopRWnQlvLwlTuWYjyvqHQURsC7gvQuirbtFU1tJXvXe3URrNipLjdqSUn99sLXQ z1jg==
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=AxT6P2IKhOPFlMCR/zb1IoAYd5c12TJP+81/6B25qkU=; b=uiPnRAkDjwZUnuQPlWdz4ORJUWgiHQD+kJO4ODXCfuWRJ78XwHOOZzwttK+Z28qZzI sz+FXw3+75IIdvFdxGHO1J7cyIX5NQPabyECuDiFJcteT0TCtfwH3cS9UV+A7lY/gWzZ MTkGbYB8Wh1pY+55l4pz+PFY91UTo/CPLar+9FdaKFQVVHxUkqSegchMAHTh37pplcYK MFRFeJQShPOj1WUUwRbZvdKwFpMFGUwqy8peoGimrryiTDNsQt1F1K3CFBWcsJ5uphIh poTufmKgOznJSgslLNzlPtngBACWUqQ5ZETAZIX/QsvK98fod0LdzUi7xT5ewSb9OoqN RL3Q==
X-Gm-Message-State: AIVw110XCCENYZrs9id83d2JzrtMPTrO44EZ0IacBPpOfae/bxy8ZvMI 0IXZKEfIofrFZaeSsxXk80nX6BkpIcwm
X-Received: by 10.13.237.133 with SMTP id w127mr16893825ywe.112.1500311054503;  Mon, 17 Jul 2017 10:04:14 -0700 (PDT)
MIME-Version: 1.0
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>  <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>    <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es>  
In-Reply-To: 
From: Ca By 
Date: Mon, 17 Jul 2017 17:04:03 +0000
Message-ID: 
To: Erik Nygren , Mikael Abrahamsson 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="94eb2c08833474d2b6055486637c"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:04:22 -0000

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

On Mon, Jul 17, 2017 at 9:26 AM Erik Nygren  wrote:

> I'll add to the list of problems I run into on the NAT64 network:  VPN
> with split tunnelling and DNS sent through the VPN means the DNS64 gets
> bypassed. I assume the same would hold true of clients overriding the
> advertised DNS servers (eg, using Google DNS).
>
> A local CLAT helps.  Ideally VPNs doing split tunnelling could be made
> DNS64/NAT64 aware.  And apps being clever enough to do their own DNS shou=
ld
> ideally also resolve ipv4only.arpa via the system resolver to do their ow=
n
> DNS64 synthesis.
>


Fyi, if you are running windows 10, just like Android, you may find you
have a local CLAT now that windows 10 has native support for 464xlat

https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stac=
k-features-in-the-creators-update-for-windows-10/

The larger point is that common production Operating Systems are
increasingly functional without ipv4 or multiple types of ipv6-only
networks that present nat64 / dns64





> - Erik.  (Torn on which ietf we start this with...)
>
>      [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>
> On Jul 17, 2017 9:42 AM, "Mikael Abrahamsson"  wrote:
>
>> On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:
>>
>> So the dogfood that we need to try (now) is the one that can sever the
>>> =E2=80=9Creal=E2=80=9D market, not the one that could serve the marked =
when they are ready
>>> to replace (in a big %) all the apps and devices that are IPv4 only. We
>>> could try this in a follow up phase (actually there is an SSID for that
>>> already).
>>>
>>
>> My android and iOS devices work great on IPv6 only using the proposed
>> suggestion. My MacOS and Windows do not (because they don't have the
>> 464XLAT or bump-in-the-API that is available on the mobile platforms). I
>> already know this. I don't need to prove it to anyone.
>>
>> It's premature to go IPv6 only on the main wifi before main operating
>> systems support the same mechanisms available on the mobile devices.
>>
>> 1. My "mosh" session only tries the same AF that it initially connected
>> to. If I initially connected on an IPv4 network, it will never connect t=
o
>> anything on an IPv6 network.
>>
>> 2. My Windows VM which needs to reach IPv4 only resources have no way to
>> do this through the Parallels NAT44. I would need a CLAT for this.
>>
>> There are lots of desktop OS applications that do not work on IPv6 only
>> DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is n=
o
>> need to do wider test. OS vendors need to implement CLAT (or equivalent)
>> for it to be viable.
>>
>> If the main wifi is going IPv6 only, I will run my mobile devices on it,
>> but I will immediately swap to the dual stack SSID for my computer.
>>
>> --
>> Mikael Abrahamsson    email: swmike@swm.pp.se
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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



On Mon, Jul 17, 2017 =
at 9:26 AM Erik Nygren <erik+i=
etf@nygren.org> wrote:
I'll add to the list of problems I run into on the NAT64 n=
etwork: =C2=A0VPN with split tunnelling and DNS sent through the VPN means =
the DNS64 gets bypassed. I assume the same would hold true of clients overr=
iding the advertised DNS servers (eg, using Google DNS).
<=
br>
A local CLAT helps.=C2=A0 Ideally VPNs doing spl=
it tunnelling could be made DNS64/NAT64 aware.=C2=A0 And apps being clever =
enough to do their own DNS should ideally also resolve ipv4only.arpa via th=
e system resolver to do their own DNS64 synthesis.
=



F=
yi, if you are running windows 10, just like Android, you may find you have=
 a local CLAT now that windows 10 has native support for 464xlat=C2=A0


The lar=
ger point is that common production Operating Systems are increasingly func=
tional without ipv4 or multiple types of ipv6-only networks that present na=
t64 / dns64=C2=A0





- Erik. =C2=A0(To=
rn on which ietf we start this with...)

=C2=A0=C2=A0=C2=A0=C2=A0 [Se=
nt from my IPv6 connected T-Mobile 4G LTE mobile device]
<=
div class=3D"gmail_extra">
On Jul 17, 2017 9:=
42 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Mon, 17 Jul 2017, JORDI PALET MARTINEZ =
wrote:





So the dogfood that we need to try (now) is the one that can sever the =E2=
=80=9Creal=E2=80=9D market, not the one that could serve the marked when th=
ey are ready to replace (in a big %) all the apps and devices that are IPv4=
 only. We could try this in a follow up phase (actually there is an SSID fo=
r that already).





My android and iOS devices work great on IPv6 only using the proposed sugge=
stion. My MacOS and Windows do not (because they don't have the 464XLAT=
 or bump-in-the-API that is available on the mobile platforms). I already k=
now this. I don't need to prove it to anyone.



It's premature to go IPv6 only on the main wifi before main operating s=
ystems support the same mechanisms available on the mobile devices.



1. My "mosh" session only tries the same AF that it initially con=
nected to. If I initially connected on an IPv4 network, it will never conne=
ct to anything on an IPv6 network.



2. My Windows VM which needs to reach IPv4 only resources have no way to do=
 this through the Parallels NAT44. I would need a CLAT for this.



There are lots of desktop OS applications that do not work on IPv6 only DNS=
64+DNS64 without CLAT. I have tried this, it doesn't work, there is no =
need to do wider test. OS vendors need to implement CLAT (or equivalent) fo=
r it to be viable.



If the main wifi is going IPv6 only, I will run my mobile devices on it, bu=
t I will immediately swap to the dual stack SSID for my computer.



-- 

Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
_________________________________=
______________

v6ops mailing list

v6ops@ietf.org

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



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--94eb2c08833474d2b6055486637c--


From nobody Mon Jul 17 10:17:43 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36798131A66 for ; Mon, 17 Jul 2017 10:17:42 -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 MY39wBmg091j for ; Mon, 17 Jul 2017 10:17:40 -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 CE81C129AD2 for ; Mon, 17 Jul 2017 10:17:40 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id 70so2444008ybn.2 for ; Mon, 17 Jul 2017 10:17:40 -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=OmcmWdcVxaMA3eC2WPzA0dnmkdl4Wz1lpWLz4SOZDU8=; b=JTLGVeXOTPXiJmwaJRG/HjBKE85lriH/jO4uKuK7cZQGcXxt/M/XqoEXKQ6qgA+5QP 4+AFoOjg6A08K+9Ax4hTwhUxynivCXS4IPHbf+ETcAEm/RZpyjkRepH25KJ88YB9gjG/ D5oNaK/gskZ4CFBKHXcGzSvAuzUlMzLyifEz5DGlemmjFIlrkcvJKRamdcCd8d+oGyYU DuMhDYu7XumwzZmZKnAlWiJdNez6ihqzT/W3GGihsTOJlKA31gWee0JfgYT02OM9mAOY di9jSZV+iUUl2NGuGbaceW42LQKS1faLRhRoGfI81etQ/zM4oE+gARXuZ9MJ0OaCE0BX cKoA==
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=OmcmWdcVxaMA3eC2WPzA0dnmkdl4Wz1lpWLz4SOZDU8=; b=YpAEK+iZqW3AdaxnrPRoyvA//Z81t4VBBA/DzMUTbmPnXyH9Dku8QzPL4vmEh7p36S 3RKxo2f4wc2KSqCLDvltZSdB3D8rlsjTuwNav2DwFNuT3mxYCU0GKKEyaxROnBrEoQTk 3Z/PnWWT0lpWLCB5el5HD9hjDOj1sSY+msxxol13T4XyzP7FSPS8AsdZmtEaIsC+veXy iwecy+R5clRPJsCS76Nhs3l0TnZm9Y8AhAjKHM65TmfKTSEktmUx9LQnm75bFZ4ESH4C s1ZSB1UNWwaOEYAunCQJM8QHVoX0NJU1FTc0SAbgwdZHBsn7zJim8oV3BK6ZIA1t+3XU CFrw==
X-Gm-Message-State: AIVw111n16r3I4EHqrBaB6RFjOd84AqzwwVZFD8ZUo6E/gLmoh/GT0q6 +5RUz965nrp1WPUcPaH/Q5dWQk9/PdvM
X-Received: by 10.37.203.209 with SMTP id b200mr10367399ybg.209.1500311859985;  Mon, 17 Jul 2017 10:17:39 -0700 (PDT)
MIME-Version: 1.0
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>  
In-Reply-To: 
From: Ca By 
Date: Mon, 17 Jul 2017 17:17:28 +0000
Message-ID: 
To: Philip Homburg , v6ops@ietf.org
Content-Type: multipart/alternative; boundary="001a114fb9de77afe705548693bf"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:17:42 -0000

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

On Mon, Jul 17, 2017 at 10:03 AM Philip Homburg 
wrote:

> > Let me clarify what I mean by the chicken and egg problem here.
> > 'We can not turn off IPv4 because there are IPv4-only endpoints
> > there and they are not going away. Why those endpoints are not
> > going away? Because there is no demand for them to work on Ipv6-only
> > networks. Why there is no demand for them to work on IPv6-only
> > networks? Because nobody is turning off IPv4'.
>
> I find it fascinating that IPv6 is bad at competing with IPv4 even now
> that IPv4 addresses have run out for a while, that you advocate actively
> breaking IPv4.
>
>
  ipv4 has been broken for 10 years now with the mass deployment of NAT.

User demans is irrelevant. We deploy ipv6only because we are out if ipv4
(in the real world). It is appropriet for the ietf to design and operate
real world scenarios instead of living in the legacy world abudent ipv4
addresses.


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

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



On Mon, Jul 17, 2017 =
at 10:03 AM Philip Homburg <pch-v6ops-7@u-1.phicoh.com> wrote:
> Let me clarify what I mean by the chicken and egg problem her=
e.

> 'We can not turn off IPv4 because there are IPv4-only endpoints
> there and they are not going away. Why those endpoints are not

> going away? Because there is no demand for them to work on Ipv6-only
> networks. Why there is no demand for them to work on IPv6-only

> networks? Because nobody is turning off IPv4'.



I find it fascinating that IPv6 is bad at competing with IPv4 even now

that IPv4 addresses have run out for a while, that you advocate actively
breaking IPv4.





=C2=A0 ipv4 has =
been broken for 10 years now with the mass deployment of NAT.=C2=A0

User demans is irrelevant. We d=
eploy ipv6only because we are out if ipv4 (in the real world). It is approp=
riet for the ietf to design and operate real world scenarios instead of liv=
ing in the legacy world abudent ipv4 addresses.=C2=A0



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--001a114fb9de77afe705548693bf--


From nobody Mon Jul 17 10:22:50 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132FB131B73 for ; Mon, 17 Jul 2017 10:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6fCgXxpJtdi for ; Mon, 17 Jul 2017 10:22:46 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4824124E15 for ; Mon, 17 Jul 2017 10:22:45 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CFDA441BFC for ; Mon, 17 Jul 2017 19:22:42 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A111841BF9; Mon, 17 Jul 2017 19:22:42 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 88B80200B7; Mon, 17 Jul 2017 19:22:42 +0200 (CEST)
Date: Mon, 17 Jul 2017 19:22:42 +0200
From: Gert Doering 
To: Philip Homburg 
Cc: v6ops@ietf.org, Gert Doering 
Message-ID: <20170717172242.GW45648@Space.Net>
References:  <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>       <20170717152345.GV45648@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KQHhAqde7z/0264B"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:22:48 -0000

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

Hi,

On Mon, Jul 17, 2017 at 06:03:32PM +0200, Philip Homburg wrote:
> And then what did we really achieve? Remove a tiny bit of code from CPEs =
and
> related routers? Is it the religious IPv6 purity that demands that IPv4 n=
ative
> needs to be killed as soon as possible?

It's the extra effort required of running a dual-stack network.

"as soon as possible" was about 10 years ago, so that's out anyway.

But after 20 years of IPv6, it's really time to seriously work on killing
IPv4.  Which will, as you point out, take quite some time to finish - but
if you never start ("this is hard, nobody sane would be willing to do this,
people find it hart to part with their IPv4-only furbies, can we go fishing
instead?"), you'll never succeed.


In other words: it's either get rid of IPv4, or declare IPv6 to be a=20
spectacular and costly fail, and get rid of that.  Customers pay more
to get their NAT444 fixed than for IPv6 deployment anyway.

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

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

--KQHhAqde7z/0264B
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlls8l8ACgkQ31bAZeTO
f8UmKQ/+Mx9g0pQv+XZvC9qTd6bJN4pLG6B9GknfZ57HSPESgLT9jWwT9Uqd6Lnx
5B7OFA2cN88qLwapTHlpqimm7WKUAbbFtepDncx/w/8166QlokI5QuG1gGBNUOHO
h3KDb7XEQDY78IWmbAOJ+iknpfryiy8lprKZUzCJKALNFykAeLvVEkgMK/RtTJCO
DiS0Z/e2fYMXaUWwhIwJx9OEGuDGZGhqMzX3GBOAFF5xRtc2ViI6mxLJIKYmj/uq
dzRDmpyRdsCKNASCuTpKGRZvLG+0PCZOQkutNGjeeha45/ha4DNUF3LfMWBIHoVp
MSIJmIhWi1Plcs9xcOPwRU0sZcKecXFg6NF7z+OQac0gikXLsCqmaMYVWmawboss
saTDTJtgRIxKzexKeAb1sSFhV9RBH/vJS3vI+qqLVm4Z0rinmEmXIyF6hrJfJOho
M/oKb4QrFWmNh0Sw6tfOe4iX9LzdAhcxL7obx+yC10Nw1esv6X5w3odi3nqPjiCI
6HErjhsOm4IPhYuMzo8C0YH2jp2HOZWRJX0KFl0tBDlOudY1z9GCDpTazLi8NTlK
SZzcu6XcPW416iGQarkAhTTDSTtE8P40I6fCbMTE5eeD88HcJbl2L5PuCG8abq8f
iN952Jw5XTIiWXrbj1cc8qzxh9nUOj5FBHbmmxCpqYvwlYi775A=
=R3lo
-----END PGP SIGNATURE-----

--KQHhAqde7z/0264B--


From nobody Mon Jul 17 10:33:02 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E07113166B for ; Mon, 17 Jul 2017 10:33: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] 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 g5yV1sbYEyrq for ; Mon, 17 Jul 2017 10:33:00 -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 A2EFB131668 for ; Mon, 17 Jul 2017 10:32:59 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dX9tC-0000GJC; Mon, 17 Jul 2017 19:32:58 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>    
In-reply-to: Your message of "Mon, 17 Jul 2017 17:17:28 +0000 ."  
Date: Mon, 17 Jul 2017 19:32:58 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:33:01 -0000

>User demans is irrelevant. We deploy ipv6only because we are out if ipv4
>(in the real world). It is appropriet for the ietf to design and operate
>real world scenarios instead of living in the legacy world abudent ipv4
>addresses.

If you are truely out of IPv4 address then you cannot deploy NAT64 so
the issue is moot.

If you do have enough public IPv4 addresses to deploy NAT64 then you can
just as well deploy any of the many other CGN techniques. Of course,
you may prefer to break legacy devices to promote IPv6. But that's then just
your choice.



From nobody Mon Jul 17 10:47:10 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AF012F4B2 for ; Mon, 17 Jul 2017 10:47:09 -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, 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 vtyvpnq6IRhb for ; Mon, 17 Jul 2017 10:47:07 -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 71ECE1289B0 for ; Mon, 17 Jul 2017 10:47:07 -0700 (PDT)
X-Envelope-To: 
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 v6HHl3pi075374 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jul 2017 18:47:04 +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: <596CF817.8040900@foobar.org>
Date: Mon, 17 Jul 2017 18:47:03 +0100
From: Nick Hilliard 
User-Agent: Postbox 5.0.15 (Macintosh/20170609)
MIME-Version: 1.0
To: IPv6 Operations 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:47:09 -0000

draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.

It has recently been claimed that IETF best current practice is that
DHCPv6 is not recommended due to the recommendations section in
RFC7934/BCP204.

The relevant text was slipped into
draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
days before the document went into IETF LC.  There was no discussion
about this text change either in the v6ops working group or at IETF
review or IESG level: perhaps the modification appeared innocuous or
maybe it just wasn't not noticed.

Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)

This presents a variety of problems, the most serious of which are 1)
that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
without extensive discussion or debate about this particular issue at
the relevant working group, and ignores the both the widespread use of
the protocol and its active development at the ietf, and 2) that a
change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
in the IPv6 host specification.

Job and I believe that this went through by mistake and that if the WG
had noticed the change at the time, consensus would never have been
reached on what is a serious semantic change to IETF lore.

Right now, the most prudent course of action would be to roll back the
change until a proper debate has been had.  We invite WG comments on
this doc.

Nick

internet-drafts@ietf.org wrote:
> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
> has been successfully submitted by Nick Hilliard and posted to the
> IETF repository.
> 
> Name:		draft-hilliard-v6ops-host-addr-update
> Revision:	00
> Title:		Update for IPv6 Host Address Availability Recommendations
> Document date:	2017-07-17
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/
> Htmlized:       https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00
> 
> 
> Abstract:
>    The IPv6 Host Address Availability Recommendations Best Current
>    Practice (RFC 7934), describes why IPv6 hosts should use multiple
>    global addresses when attaching to a network.  This document updates
>    RFC 7934 by removing a recommendation for networks to give the host
>    the ability to use new addresses without requiring explicit requests.
> 
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 


From nobody Mon Jul 17 10:49:57 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874BF128CFF for ; Mon, 17 Jul 2017 10:49:54 -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 spXgrxBrOONd for ; Mon, 17 Jul 2017 10:49: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 4B0011289B0 for ; Mon, 17 Jul 2017 10:49: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 m1dXA9Y-0000ChC; Mon, 17 Jul 2017 19:49:52 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References:  <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>       <20170717152345.GV45648@Space.Net>  <20170717172242.GW45648@Space.Net> 
In-reply-to: Your message of "Mon, 17 Jul 2017 19:22:42 +0200 ." <20170717172242.GW45648@Space.Net> 
Date: Mon, 17 Jul 2017 19:49:47 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:49:54 -0000

>But after 20 years of IPv6, it's really time to seriously work on killing
>IPv4.  

In a world where most people have no access to IPv6. Where IPv6 deployment
is just slightly more than a blip on the radar. 

Yeah, there it is very obvious that we should start killing IPv4 support.

Convincing people that IPv6 is a good idea is already hard enough. So now
we tell them that they should really do 'IPv6-only' and break all unmodified
IPv4 hosts. That should really help IPv6 adoption.


From nobody Mon Jul 17 10:55:24 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6409412EC1D for ; Mon, 17 Jul 2017 10:55: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 qh85HuLCPFUX for ; Mon, 17 Jul 2017 10:55: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 3344412EB5D for ; Mon, 17 Jul 2017 10:55:21 -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: <76[...]
Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 70C5F1BC37 for ; Mon, 17 Jul 2017 17:55:14 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson 
In-Reply-To: 
Date: Mon, 17 Jul 2017 18:55:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>      <6C141215-908F-4AFD-96E9-E99CB4931D7D@consulintel.es>  
To: "v6ops@ietf.org Operations" 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 17:55:23 -0000

Philip Homburg  wrote:

> I find it fascinating that IPv6 is bad at competing with IPv4 even now
> that IPv4 addresses have run out for a while, that you advocate =
actively
> breaking IPv4.

That's not how I read it.
As I read it, "most" modern software(& systems/configs) will work with =
IPv4 or IPv6 - and for such software there is no problem as IPv4 gets =
turned off.
Also, as I read it from various comments, for those that don't, many are =
due to config issues (such as referencing an IPv4 address in OpenVPN =
config). It would be useful to identify such issues so that they can be =
corrected by educating those responsible.
And for those few bits of software where it's the software itself, then =
making the problem known would allow the developer to fix it "at some =
point" as they release new versions.

Fixing such problems leads to a situation where IPv6 only will actually =
work. The alternative that some seem to be advocating is to "do nothing" =
which means that such problems never get fixed, so IPv4 support stays as =
a requirement "forever", and progress doesn't happen.

My take on the proposal is that with an IETF shindig you have a self =
selected group of people with above average technical/networking =
knowledge - and a common interest in progress. As such it's a perfect =
group (ie people that won't just whine that "the internet's broken" with =
no useful information added) to try an experiment with and see whether =
it is practical to run such a network.



Ca By  wrote:

>   ipv4 has been broken for 10 years now with the mass deployment of =
NAT.=20

Indeed, there seems to be a lot of argument about how to keep it working =
transparently when for the vast majority it only appears to work because =
of a lot of work behind the scenes to workaround what NAT breaks. In =
fact, a lot (not all, but a lot) of the modern complaint about =
surveillance and dependency on third parties continuing to provide =
servers (cf Zune and Revolv) is down to the need to workaround NAT.

Unfortunately, people don't believe anything is broken because of all =
this work that makes it appear as everything is working OK for them.


From nobody Mon Jul 17 11:07:53 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2F12EC1D for ; Mon, 17 Jul 2017 11:07:51 -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, 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=fugue-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 grD7i62F9GB5 for ; Mon, 17 Jul 2017 11:07: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 3CF7C12EB5D for ; Mon, 17 Jul 2017 11:07:48 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id k14so83756970pgr.0 for ; Mon, 17 Jul 2017 11:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1o4wAmQMXtUkYETZUyA201wFBcRJ91Y2wv7gQD/gvAk=; b=n+lf2R2E3Z78teU5Ey1Jd0tXLwiLoS/65VEUOHyz9/H/HdmeHkMeP/tcY3BlQ2oxVN DTpBKUCXOYpVzjbUFqeWjyfEzcxMMm9gth4hN2ntaWFgtj4QF0QKXu7V4kUQtVFSgkeY he/KmWAHUbjf0bmi3Andifksl7s+9icDlt6piNjQeE1MBGKAnwakcg1eloMl+UplTmKz onZeQ/1Yad00ca1SodkgewEeqSe2h2H3LwRyrcDkuFwmftp22+YuQaLF9vEvkrM4AH0T EOoHxrooaxxT9RrjKY13pPUe4OZjpuK2i/AcClR/I1cTJAmCf63o5LaV1oEvYf7uMN0m L5Kg==
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=1o4wAmQMXtUkYETZUyA201wFBcRJ91Y2wv7gQD/gvAk=; b=YiHVyDeSnZWpRStBvEDTtJSsdllXLTFCq5QHj4iVWxgsF9KmT4EdH5rJh/+qcgm6Ir qAiMfxCxZEtPg3g6kGE5Pv96odZBYsl4jCp7VAzwLKhdhG4hMkry+5NhdHuP+GV2yV7Z nRuvoq7IVmPIL2HitbcWpUvutnQBhk23iaRZ0uASahqtBiCviCr+gi+PhJZi3z/DSNkm fKlciFOCFo0pk/vUuMVjEITYJwpoYCZwwX6rSxg8HHVAT06LICzwkMwQddRDAjy1K9eh +RBpf7CpXO8Y/Tg7kO/jPB1fyyeg6pqZY14VQQNykRF4stBynWRRtHQbUo74ETML1Rmp rnqw==
X-Gm-Message-State: AIVw110LW3XeJloOtBN9WRz9IO1WUSU2vMuyMmrHuixUielUa9gfUKE4 mQf70iR+BPMHKIYxAymRqtudIaA1v/QJ
X-Received: by 10.99.167.79 with SMTP id w15mr29986057pgo.22.1500314868496; Mon, 17 Jul 2017 11:07:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 11:07:07 -0700 (PDT)
In-Reply-To: <9948cb75-6c11-9071-697f-a79702472132@gmail.com>
References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com>
From: Ted Lemon 
Date: Mon, 17 Jul 2017 20:07:07 +0200
Message-ID: 
To: Alexandre Petrescu 
Cc: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary="94eb2c1bdaa4c9d68305548746d2"
Archived-At: 
Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 18:07:52 -0000

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

Understood.   The issue here is that the ISC client is using bpf (or lpf)
to send packets rather than using the Linux stack.   Try compiling it with
#define USE_SOCKETS and see if the behavior changes.

On Mon, Jul 17, 2017 at 6:26 PM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> Well, this is to note that we too (Fred mentioned it too earlier) made
> the ISC DHCPv6 dhclient work on Android, including DHCPv6 Solicit that
> requests Prefix Delegation.
>
> (but we still dont have a response to DHCP Solicit on cellular link).
>
> Alex
>
> Le 06/07/2017 =C3=A0 18:32, Alexandre Petrescu a =C3=A9crit :
>
>> Mark, noted, will try.
>>
>> Just a note...
>>
>> Le 06/07/2017 =C3=A0 03:16, Mark Andrews a =C3=A9crit :
>>
>>>
>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>,
>>> Alexandre Petrescu writes:
>>>
>>>> Hello,
>>>>
>>>> We discussed extensively about the potential use of DHCPv6
>>>> Prefix Delegation on cellular links.
>>>>
>>>> The chicken issue is the lack of DHCPv6 PD software on typical
>>>> User Equipment.  For example, there is no DHCPv6-PD app on
>>>> Android.  The egg issue is the lack of operator support of
>>>> DHCPv6-PD towards the User Terminal.  For example, there is no
>>>> cellular operator answering to DHCPv6-PD requests issued by the
>>>> User Terminal.
>>>>
>>>> To address the chicken issue, we started with an ISC DHCP open
>>>> software client, which does implement Prefix Delegation.  It can
>>>> be (cross)compiled on various platforms; then type "./dhclient -6
>>>> -P"; this sends an DHCPv6 Solicit Identity Associtaion for Prefix
>>>> Delegation message on the interface.
>>>>
>>>> However, whereas this software runs ok on interfaces such as
>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the
>>>> cellular interface of some IoT cellular platform.  The error can
>>>> be corrected by the quick-and-dirty solution below.
>>>>
>>>
>>> The hack would be better as
>>>
>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen =3D 7; hw->hbuf[0] =3D
>>> HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif
>>> default: log_fatal("Unsupported device type %ld for \"%s\"", (long
>>> int)sa->sa_family, name); break;
>>>
>>> with ARPHRD_XXXX being replaced by the correct macro for 503 from
>>> .  Something like that is at least portable.
>>>
>>
>> But it means when I go to other platform will have to modify again
>> the ISC client source code?
>>
>> In cellular terminals there are so many non-IEEE different kinds of
>> links.
>>
>> Other clients work out of the box on this - I agree with you, strange
>> - "rmnet0" interface.
>>
>> Alex
>>
>>
>>> As for the rest of it I have no idea about the presented hardware
>>> address of this type so I don't know it the rest of it make sense.
>>>
>>> Alex
>>>>
>>>> ------------------------------------------------------------
>>>> ------------
>>>>
>>>>
>>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
>
>> dhcp-4.3.5 ./common/lpf.c line number: 551
>>>>
>>>> //default: //      log_fatal("Unsupported device type %ld for
>>>> \"%s\"", //                (long int)sa->sa_family, name); default:
>>>> hw->hlen =3D 7; hw->hbuf[0] =3D HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->=
sa_data,
>>>> 6); break;
>>>>
>>>> (two programmers worked this out).
>>>>
>>>> Alex
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>> _______________________________________________ v6ops mailing list
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Understood. =C2=A0 The issue here is that the ISC client i=
s using bpf (or lpf) to send packets rather than using the Linux stack. =C2=
=A0 Try compiling it with #define USE_SOCKETS and see if the behavior chang=
es.

On Mon, =
Jul 17, 2017 at 6:26 PM, Alexandre Petrescu <alexandre.petres=
cu@gmail.com> wrote:
Well, =
this is to note that we too (Fred mentioned it too earlier) made

the ISC DHCPv6 dhclient work on Android, including DHCPv6 Solicit that

requests Prefix Delegation.



(but we still dont have a response to DHCP Solicit on cellular link).



Alex



Le 06/07/2017 =C3=A0 18:32, Alexandre Petrescu a =C3=A9crit :



Mark, noted, will try.



Just a note...



Le 06/07/2017 =C3=A0 03:16, Mark Andrews a =C3=A9crit :





In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com=
>,

Alexandre Petrescu writes:



Hello,



We discussed extensively about the potential use of DHCPv6

Prefix Delegation on cellular links.



The chicken issue is the lack of DHCPv6 PD software on typical

User Equipment.=C2=A0 For example, there is no DHCPv6-PD app on

Android.=C2=A0 The egg issue is the lack of operator support of

DHCPv6-PD towards the User Terminal.=C2=A0 For example, there is no

cellular operator answering to DHCPv6-PD requests issued by the

User Terminal.



To address the chicken issue, we started with an ISC DHCP open

software client, which does implement Prefix Delegation.=C2=A0 It can

be (cross)compiled on various platforms; then type "./dhclient -6

-P"; this sends an DHCPv6 Solicit Identity Associtaion for Prefix

Delegation message on the interface.



However, whereas this software runs ok on interfaces such as

Ethernet, USBnet and WiFi interfaces, it breaks if run on the

cellular interface of some IoT cellular platform.=C2=A0 The error can

be corrected by the quick-and-dirty solution below.





The hack would be better as



#ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen =3D 7; hw->hbuf[0] =3D<=
br>
HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif =
default: log_fatal("Unsupported device type %ld for \"%s\"&q=
uot;, (long

int)sa->sa_family, name); break;



with ARPHRD_XXXX being replaced by the correct macro for 503 from

<net/if_arp.h>.=C2=A0 Something like that is at least portable.





But it means when I go to other platform will have to modify again

the ISC client source code?



In cellular terminals there are so many non-IEEE different kinds of

links.



Other clients work out of the box on this - I agree with you, strange

- "rmnet0" interface.



Alex







As for the rest of it I have no idea about the presented hardware address o=
f this type so I don't know it the rest of it make sense.





Alex



-----------------------------------------------------------------=
-------







The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."



dhcp-4.3.5 ./common/lpf.c line number: 551



//default: //=C2=A0 =C2=A0 =C2=A0 log_fatal("Unsupported device type %=
ld for

\"%s\"", //=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (long int)sa->sa_family, name); default: hw->hlen =3D 7; hw-&g=
t;hbuf[0] =3D HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); =
break;



(two programmers worked this out).



Alex



_______________________________________________ v6ops mailing

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





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





_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--94eb2c1bdaa4c9d68305548746d2--


From nobody Mon Jul 17 11:08:41 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803B712ECC6 for ; Mon, 17 Jul 2017 11:08:39 -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 y2MfLq1u_A7X for ; Mon, 17 Jul 2017 11:08:38 -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 2B9CB12EC1D for ; Mon, 17 Jul 2017 11:08:38 -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 ABA201BC37 for ; Mon, 17 Jul 2017 18:08:32 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson 
In-Reply-To: 
Date: Mon, 17 Jul 2017 19:08:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>       <20170717152345.GV45648@Space.Net>  <20170717172242.GW45648@Space.Net> 
To: "v6ops@ietf.org Operations" 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 18:08:39 -0000

Philip Homburg  wrote:

>> But after 20 years of IPv6, it's really time to seriously work on =
killing
>> IPv4. =20
>=20
> In a world where most people have no access to IPv6. Where IPv6 =
deployment
> is just slightly more than a blip on the radar.=20
>=20
> Yeah, there it is very obvious that we should start killing IPv4 =
support.
>=20
> Convincing people that IPv6 is a good idea is already hard enough. So =
now
> we tell them that they should really do 'IPv6-only' and break all =
unmodified
> IPv4 hosts. That should really help IPv6 adoption.

"Break all unmodified hosts ?"
I was under the impression that many unmodified hosts (and the software =
running on them) was capable of running on an IPv6 only network - but =
there are specific, notable exceptions (OpenVPN config specific, and MS =
Outlook an Mac are two that have been mentioned), and that the scale is =
not clearly known.
If there is an experiment that will allow some insight into the scale of =
the issue, and with a self selected group who are likely to be able to =
provide more meaningful feedback than "internet's broken") then it's =
useful to be done.

And when people talk of "kill IPv4", I don't get the impression that =
they mean to literally get rid of it any time soon. Before you can get =
rid of it, a lot has to happen - and already mentioned, if you don't =
start that process then it'll never happen.
You've raised a good point - many people don't have IPv6 - that's one =
area to be addressed, and a good way of addressing that is to show that =
it's here, it's working, and the ISPs responsible really need to extract =
digit from posterior and start providing it.

I see a parallel with the old walled gardens like AOL, back when they =
were dial up and not internet connected. Many thought this new fangled =
internet thing, with it's complicated "IP addresses", was something to =
be ignored. Remember what happened to them ? it didn't happen overnight =
- but bit by bit they "went internet". First it was with "gateways", and =
eventually native IP - right now we are still at the "gateways" stage =
with IPv6 adoption, with many still stuck in the IPv4 walled garden, =
while many of us have this new fangled IPv6.

But if we sit back and wait, then those IPv4 walled gardens will remain, =
and the argument will be "but you can't kill it off" forever. I doubt if =
IPv4 will ever truly disappear (just as I still have some old kit doing =
AppleTalk !) - but it will get to the point where end users having to =
have it will be few and far between, eventually.
But, as Laozi said, "a journey of a thousand miles begins with a single =
step". A lot of people seem afraid of taking a single step, let alone a =
journey.


From nobody Mon Jul 17 11:17:48 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C912EB96 for ; Mon, 17 Jul 2017 11:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=fugue-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 xJxVEo7NLEXw for ; Mon, 17 Jul 2017 11:17:44 -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 B5334124D68 for ; Mon, 17 Jul 2017 11:17:44 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id e26so12333439pfd.0 for ; Mon, 17 Jul 2017 11:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kJGZgH47Ey4rBdGkVp2ZXV9QcNyGY1kjOBN+7IZJA6E=; b=JERgT7gV+onvkb1cFH/tGao+edsW1kTNIf43y0M54frgoPb+uJawYgfX+dbDm2dVVp jztFcK2Scci5bFpkBrAOxWbr94QcLPG6sQTB0mq/ZDyryrriqHwbGpcEJdJpKFGYo8t9 suauQQDXI5oM0BzMR12Lv2oq99jtzS3rpkgO7rSEBkTnR9zOh+zFKhwUv7m+CrzfDBJr tA8NMOkC/orRi+SpbZ5xa9Vmt9pljiCWxgxU1Owgsq1Jo2UIKiseA6RFGgO/MwNwnrNN BeF9yYsyE/rJQ7ITDmgmlmw9j3R6ofzEv8UyEU5e1nzae50w451Xc8AIOG3GHHWEdiKu 1msA==
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=kJGZgH47Ey4rBdGkVp2ZXV9QcNyGY1kjOBN+7IZJA6E=; b=fZLybXUaOO5gv+J8phTV1R3mwsZNpbw8G1VCp7/UWYGgf35lAjsCn4mg+MGzOvG3Gt t2ALnvLOwa8QHvpSBtrQnzVx8/HDAKQXcm7imIr1dLMuRzjif2kYfscEawd+PqOd2185 5OKpRhSr+QIKjFDZfIwePamJM0BV5EhH3E834ZjqceR1CZpOlWM8j/eEupkpushubIsN g43Fw4qv2Lv4WyyDglQBtR7ikhhOBJTh8utRhLt07m154EgvZnqkBD2qSq8+/bEHMqet KBQ7xfr1ZPQ0UK7GJcHM4I0+PFGErsDo5t1QFImpIVmqbwpwPQxzeN6gONIgM5+nN+ej X/qA==
X-Gm-Message-State: AIVw112xz4GxsNB4p5RGZ08NwEF/UDmyY/4CtDERADALtpDCOVnwW3QH WGCK/C3sMh+GkmJTyGyjYenELwjsuHOA
X-Received: by 10.98.193.68 with SMTP id i65mr5947346pfg.142.1500315464242; Mon, 17 Jul 2017 11:17:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 11:17:03 -0700 (PDT)
In-Reply-To: <596CF817.8040900@foobar.org>
References: <596CF817.8040900@foobar.org>
From: Ted Lemon 
Date: Mon, 17 Jul 2017 20:17:03 +0200
Message-ID: 
To: Nick Hilliard 
Cc: IPv6 Operations 
Content-Type: multipart/alternative; boundary="94eb2c1847204c6a4c0554876a8c"
Archived-At: 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 18:17:47 -0000

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

The RFC doesn't say that anywhere in it.   There is no version of the draft
that was published on 2/12/2016.   The -01 version of the draft was
published in March of that year; the final version in July.   Can you
please point out the place in the text where it says what you are saying it
says?

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard  wrote:

> draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.
>
> It has recently been claimed that IETF best current practice is that
> DHCPv6 is not recommended due to the recommendations section in
> RFC7934/BCP204.
>
> The relevant text was slipped into
> draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
> days before the document went into IETF LC.  There was no discussion
> about this text change either in the v6ops working group or at IETF
> review or IESG level: perhaps the modification appeared innocuous or
> maybe it just wasn't not noticed.
>
> Next thing, there's a BCP which is being interpreted as meaning that
> DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)
>
> This presents a variety of problems, the most serious of which are 1)
> that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
> without extensive discussion or debate about this particular issue at
> the relevant working group, and ignores the both the widespread use of
> the protocol and its active development at the ietf, and 2) that a
> change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
> in the IPv6 host specification.
>
> Job and I believe that this went through by mistake and that if the WG
> had noticed the change at the time, consensus would never have been
> reached on what is a serious semantic change to IETF lore.
>
> Right now, the most prudent course of action would be to roll back the
> change until a proper debate has been had.  We invite WG comments on
> this doc.
>
> Nick
>
> internet-drafts@ietf.org wrote:
> > A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
> > has been successfully submitted by Nick Hilliard and posted to the
> > IETF repository.
> >
> > Name:         draft-hilliard-v6ops-host-addr-update
> > Revision:     00
> > Title:                Update for IPv6 Host Address Availability
> Recommendations
> > Document date:        2017-07-17
> > Group:                Individual Submission
> > Pages:                4
> > URL:            https://www.ietf.org/internet-
> drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> > Status:         https://datatracker.ietf.org/
> doc/draft-hilliard-v6ops-host-addr-update/
> > Htmlized:       https://tools.ietf.org/html/draft-hilliard-v6ops-host-
> addr-update-00
> > Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-hilliard-v6ops-host-addr-update-00
> >
> >
> > Abstract:
> >    The IPv6 Host Address Availability Recommendations Best Current
> >    Practice (RFC 7934), describes why IPv6 hosts should use multiple
> >    global addresses when attaching to a network.  This document updates
> >    RFC 7934 by removing a recommendation for networks to give the host
> >    the ability to use new addresses without requiring explicit requests.
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


The RFC doesn't say that anywhere in it. =C2=A0 There =
is no version of the draft that was published on 2/12/2016. =C2=A0 The -01 =
version of the draft was published in March of that year; the final version=
 in July. =C2=A0 Can you please point out the place in the text where it sa=
ys what you are saying it says?

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard <nick@foo=
bar.org> wrote:
draft-hilli=
ard-v6ops-host-addr-update-00 has just been posted as an ID.



It has recently been claimed that IETF best current practice is that

DHCPv6 is not recommended due to the recommendations section in

RFC7934/BCP204.



The relevant text was slipped into

draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple o=
f

days before the document went into IETF LC.=C2=A0 There was no discussion
about this text change either in the v6ops working group or at IETF

review or IESG level: perhaps the modification appeared innocuous or

maybe it just wasn't not noticed.



Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.=C2=A0 Wow. :-)



This presents a variety of problems, the most serious of which are 1)

that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED&quo=
t;

without extensive discussion or debate about this particular issue at

the relevant working group, and ignores the both the widespread use of

the protocol and its active development at the ietf, and 2) that a

change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge=
 hole

in the IPv6 host specification.



Job and I believe that this went through by mistake and that if the WG

had noticed the change at the time, consensus would never have been

reached on what is a serious semantic change to IETF lore.



Right now, the most prudent course of action would be to roll back the

change until a proper debate has been had.=C2=A0 We invite WG comments on
this doc.



Nick



internet-drafts@ietf.org wr=
ote:

> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.tx=
t

> has been successfully submitted by Nick Hilliard and posted to the

> IETF repository.

>

> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hilliard-v6ops-host-=
addr-update

> Revision:=C2=A0 =C2=A0 =C2=A000

> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Update f=
or IPv6 Host Address Availability Recommendations

> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-07-17

> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu=
al Submission

> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4

> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts=
/draft-hilliard-v6ops-host-addr-update-00.txt

> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hilliard-v6ops=
-host-addr-update/

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hilliard-v6ops-host-ad=
dr-update-00

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hilliar=
d-v6ops-host-addr-update-00

>

>

> Abstract:

>=C2=A0 =C2=A0 The IPv6 Host Address Availability Recommendations Best C=
urrent

>=C2=A0 =C2=A0 Practice (RFC 7934), describes why IPv6 hosts should use =
multiple

>=C2=A0 =C2=A0 global addresses when attaching to a network.=C2=A0 This =
document updates

>=C2=A0 =C2=A0 RFC 7934 by removing a recommendation for networks to giv=
e the host

>=C2=A0 =C2=A0 the ability to use new addresses without requiring explic=
it requests.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.
>

> The IETF Secretariat

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--94eb2c1847204c6a4c0554876a8c--


From nobody Mon Jul 17 11:20:26 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4857130133 for ; Mon, 17 Jul 2017 11:20:24 -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 5WR5c-_0g1Vb for ; Mon, 17 Jul 2017 11:20:23 -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 CD8AF12EB96 for ; Mon, 17 Jul 2017 11:20:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dXAd4-0000GoC; Mon, 17 Jul 2017 20:20:22 +0200
Message-Id: 
To: v6ops@ietf.org
Cc: Simon Hobson 
X-Cc: "v6ops@ietf.org Operations" 
From: Philip Homburg 
Sender: pch-b7900FA3D@u-1.phicoh.com
References:  <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>       <20170717152345.GV45648@Space.Net>  <20170717172242.GW45648@Space.Net>   
In-reply-to: Your message of "Mon, 17 Jul 2017 19:08:32 +0100 ."  
Date: Mon, 17 Jul 2017 20:20:21 +0200
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 18:20:25 -0000

In your letter dated Mon, 17 Jul 2017 19:08:32 +0100 you wrote:
>"Break all unmodified hosts ?"
>I was under the impression that many unmodified hosts (and the software runnin
>g on them) was capable of running on an IPv6 only network - but there are spec
>ific, notable exceptions (OpenVPN config specific, and MS Outlook an Mac are t
>wo that have been mentioned), and that the scale is not clearly known.

I'll just assume that with 'IPv6 only' you mean NAT64/DNS64.

So the most obvious example that breaks with DNS64 is a web page that
refers to another http resource using an IPv4 literal. 

Anything that the user has done using IPv4 literals also breaks. Say the
address of a mail server, an ssh host, etc.

Of course, anyone who has manually configured Google's public DNS resolvers
is also in for a surprise.



From nobody Mon Jul 17 11:23:45 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D37131BDE for ; Mon, 17 Jul 2017 11:23: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 0_Tu-V_igz5H for ; Mon, 17 Jul 2017 11:23:41 -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 7F04313168D for ; Mon, 17 Jul 2017 11:23:41 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id 35so58504044uax.3 for ; Mon, 17 Jul 2017 11:23: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=ccsazonw4FN4L3cSWn6eGH8m9klOJTXogu8CjdkUZKc=; b=eDXSN7wrMvRjZfBJhJPN8+X0IRhgxenSqMaxgtWIvjbiEraSL0+gM81mYhQ3rF9z+O jibaV8QM9N0Fc/YA17o6j24V2G7KXGcZfsO1t79euPijxcPMJMR2FY9h3GnLGMnSW1No J8qDX69IBlOkrunat2kTZ1pjvPetM1t+6sVNpnSYgdZiOs2odEtsWymHlv8sbhSoVtG+ tp7EBZQhvJDJ2GZj0uArJPAWItIPD6t4SMoijAR+YUSv7lfg+rHdWHk39ZvACqd0SfNA 9QMOoGgbRUgzsohR8vu/P38d/5xRl+RlI5B/kWOW22G8c7c8kl1izPbqYErQGSNCCZxi VsrQ==
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=ccsazonw4FN4L3cSWn6eGH8m9klOJTXogu8CjdkUZKc=; b=csJTVtFO+q+PXABsoB91eLrG4SZeqvO5p3B9z3YbOEjjow5FqETdgO3k6xASP89SiW YZ6Fd3zgdfsc00VAP5PPxT9mascgXylnPpzw9dxWi7bc4sLXRo17bz86tVs4FxV0J2CH Wpb9OqxyJY+mvefEDjsW+FIsvWQX9nA2fBsMlU27qrae5EAOkyehxLu6YVb8F8iUx/zx QfEEaH2NIdpuAVK+i/HWFxtyqVAWjxhwgyj9id0lcWkUfuqivpkQtdkNDiyJbNsTz2OD 8QvrsdFjlW7yCgteZnjk35IaNl3HCcN7O43nDgoaXqClH/lr8YYFKoddYCmylLGIjuUn E7TQ==
X-Gm-Message-State: AIVw112Wn1zMEWovJVDuarmEPsyMaCYVhgV8pIOifpvz0lMD/KdW09t4 H/G3r2K7D0Kt6OE8pZrNn+4d+qL+Yq2QDnk=
X-Received: by 10.31.209.199 with SMTP id i190mr13146418vkg.125.1500315820195;  Mon, 17 Jul 2017 11:23:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.48.129 with HTTP; Mon, 17 Jul 2017 11:23:19 -0700 (PDT)
In-Reply-To: <596CF817.8040900@foobar.org>
References: <596CF817.8040900@foobar.org>
From: Lorenzo Colitti 
Date: Mon, 17 Jul 2017 20:23:19 +0200
Message-ID: 
To: Nick Hilliard 
Cc: IPv6 Operations 
Content-Type: multipart/alternative; boundary="001a114e6e18840da50554877f21"
Archived-At: 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 18:23:44 -0000

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

Nick,

the text you mention was not "slipped in" by mistake, it was the outcome of
WG discussion.

In September 2015 (-01), the text read:

   If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD).

Some in the WG felt that it was not correct to single out DHCPv6 PD,
because it was not in wide use. Thus, in February 2016 (-05), the text was
changed to:

   Due to the drawbacks imposed by requiring explicit requests for
   address space (see section Section 4), 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.  The prefix MAY be
   provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other
   means.

There were dozens or maybe hundreds on emails on this text, so I don't
think the WG was blindsided.

Cheers,
Lorenzo

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard  wrote:

> draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.
>
> It has recently been claimed that IETF best current practice is that
> DHCPv6 is not recommended due to the recommendations section in
> RFC7934/BCP204.
>
> The relevant text was slipped into
> draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
> days before the document went into IETF LC.  There was no discussion
> about this text change either in the v6ops working group or at IETF
> review or IESG level: perhaps the modification appeared innocuous or
> maybe it just wasn't not noticed.
>
> Next thing, there's a BCP which is being interpreted as meaning that
> DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)
>
> This presents a variety of problems, the most serious of which are 1)
> that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
> without extensive discussion or debate about this particular issue at
> the relevant working group, and ignores the both the widespread use of
> the protocol and its active development at the ietf, and 2) that a
> change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
> in the IPv6 host specification.
>
> Job and I believe that this went through by mistake and that if the WG
> had noticed the change at the time, consensus would never have been
> reached on what is a serious semantic change to IETF lore.
>
> Right now, the most prudent course of action would be to roll back the
> change until a proper debate has been had.  We invite WG comments on
> this doc.
>
> Nick
>
> internet-drafts@ietf.org wrote:
> > A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
> > has been successfully submitted by Nick Hilliard and posted to the
> > IETF repository.
> >
> > Name:         draft-hilliard-v6ops-host-addr-update
> > Revision:     00
> > Title:                Update for IPv6 Host Address Availability
> Recommendations
> > Document date:        2017-07-17
> > Group:                Individual Submission
> > Pages:                4
> > URL:            https://www.ietf.org/internet-
> drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> > Status:         https://datatracker.ietf.org/
> doc/draft-hilliard-v6ops-host-addr-update/
> > Htmlized:       https://tools.ietf.org/html/d
> raft-hilliard-v6ops-host-addr-update-00
> > Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-hilliard-v6ops-host-addr-update-00
> >
> >
> > Abstract:
> >    The IPv6 Host Address Availability Recommendations Best Current
> >    Practice (RFC 7934), describes why IPv6 hosts should use multiple
> >    global addresses when attaching to a network.  This document updates
> >    RFC 7934 by removing a recommendation for networks to give the host
> >    the ability to use new addresses without requiring explicit requests.
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Nick,

the text you mention was not &quo=
t;slipped in" by mistake, it was the outcome of WG discussion.

In September 2015 (-01), the text read:

=C2=A0 =C2=A0If the network requires explicit requests
=C2=A0 =C2=A0for address space (e.g., if it requires DHCPv6 to connect),=
 it is
=C2=A0 =C2=A0RECOMMENDED that the network assign a /64 pre=
fix to every host (e.g.,
=C2=A0 =C2=A0via DHCPv6 PD).
=


Some in the WG felt that it was not correct to single o=
ut DHCPv6 PD, because it was not in wide use. Thus, in February 2016 (-05),=
 the text was changed to:

=C2=A0 =C2=A0Due to=
 the drawbacks imposed by requiring explicit requests for
=C2=A0 =
=C2=A0address space (see section Section 4), it is RECOMMENDED that the
=C2=A0 =C2=A0network give the host the ability to use new addresses =
without
=C2=A0 =C2=A0requiring explicit requests.=C2=A0 This can =
be achieved either by allowing
=C2=A0 =C2=A0the host to form new =
addresses autonomously (e.g., via SLAAC), or by
=C2=A0 =C2=A0prov=
iding the host with a dedicated /64 prefix.=C2=A0 The prefix MAY be
=C2=A0 =C2=A0provided using DHCPv6 PD, SLAAC with per-device VLANs, or a=
ny other
=C2=A0 =C2=A0means.

There=
 were dozens or maybe hundreds on emails on this text, so I don't think=
 the WG was blindsided.

Cheers,
Lorenzo<=
/div>

On Mon, Jul =
17, 2017 at 7:47 PM, Nick Hilliard <nick@foobar.org> wrote:
draft-hilliard-v6ops-host-addr-update-=
00 has just been posted as an ID.



It has recently been claimed that IETF best current practice is that

DHCPv6 is not recommended due to the recommendations section in

RFC7934/BCP204.



The relevant text was slipped into

draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple o=
f

days before the document went into IETF LC.=C2=A0 There was no discussion
about this text change either in the v6ops working group or at IETF

review or IESG level: perhaps the modification appeared innocuous or

maybe it just wasn't not noticed.



Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.=C2=A0 Wow. :-)



This presents a variety of problems, the most serious of which are 1)

that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED&quo=
t;

without extensive discussion or debate about this particular issue at

the relevant working group, and ignores the both the widespread use of

the protocol and its active development at the ietf, and 2) that a

change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge=
 hole

in the IPv6 host specification.



Job and I believe that this went through by mistake and that if the WG

had noticed the change at the time, consensus would never have been

reached on what is a serious semantic change to IETF lore.



Right now, the most prudent course of action would be to roll back the

change until a proper debate has been had.=C2=A0 We invite WG comments on
this doc.



Nick



internet-draf=
ts@ietf.org wrote:

> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.tx=
t

> has been successfully submitted by Nick Hilliard and posted to the

> IETF repository.

>

> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hilliard-v6ops-host-addr-update

> Revision:=C2=A0 =C2=A0 =C2=A000

> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Update f=
or IPv6 Host Address Availability Recommendations

> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-07-17

> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu=
al Submission

> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4

> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts=
/draft-hilliard-v6ops-host-addr-update-00.txt

> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hilliard-v6ops=
-host-addr-update/

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hilliar=
d-v6ops-host-addr-update-00

>

>

> Abstract:

>=C2=A0 =C2=A0 The IPv6 Host Address Availability Recommendations Best C=
urrent

>=C2=A0 =C2=A0 Practice (RFC 7934), describes why IPv6 hosts should use =
multiple

>=C2=A0 =C2=A0 global addresses when attaching to a network.=C2=A0 This =
document updates

>=C2=A0 =C2=A0 RFC 7934 by removing a recommendation for networks to giv=
e the host

>=C2=A0 =C2=A0 the ability to use new addresses without requiring explic=
it requests.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.
>

> The IETF Secretariat

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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





--001a114e6e18840da50554877f21--


From nobody Mon Jul 17 11:55:11 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EDD12EC01 for ; Mon, 17 Jul 2017 11:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level: 
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_03_06=3.027, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 iBf4w16pQtjQ for ; Mon, 17 Jul 2017 11:55:08 -0700 (PDT)
Received: from atl4mhob12.registeredsite.com (atl4mhob12.registeredsite.com [209.17.115.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B2A127B57 for ; Mon, 17 Jul 2017 11:55:07 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob12.registeredsite.com (8.14.4/8.14.4) with ESMTP id v6HIt4EN012266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jul 2017 14:55:05 -0400
Received: (qmail 15974 invoked by uid 0); 17 Jul 2017 18:55:04 -0000
X-TCPREMOTEIP: 88.208.89.131
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?172.20.3.204?) (lee@asgard.org@88.208.89.131) by 0 with ESMTPA; 17 Jul 2017 18:55:04 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 17 Jul 2017 20:54:56 -0400
From: Lee Howard 
To: , IPv6 Ops WG 
CC: Randy Bush , Russ Housley , Suresh Krishnan , Alissa Cooper , Jim Martin 
Message-ID: 
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   <9CDFFE8B-DBEC-4059-8E93-44AEC304E31A@consulintel.es> <45A7CDF3-9832-4944-9D77-95E17EAEDB47@apple.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 18:55:10 -0000

On 7/17/17, 10:27 AM, "v6ops on behalf of JORDI PALET MARTINEZ"
 wrote:

>
>4) The result is the same, but people don=E2=80=99t need to spend time. We
>configure the Jool so it reports EVERY usage, so we can then process that
>file to detect WHAT was using the CLAT.

Your proposal is to log the 5-tuple of every connection (using the CLAT)
on the IETF network?
Any privacy concerns?

>5) The result is the same as the suggested experiment, but NOT breaking
>anything, not asking the participants to report anything, but having
>BETTER collection of data about what will be broken if the CLAT is not
>there (anything that goes into the CLAT).

I=E2=80=99m not sure that logging the 5-tuple (if that=E2=80=99s what you mean to log)
gives you that information.
For instance, if Outlook for Mac isn=E2=80=99t working, and we don=E2=80=99t know why,
then you may not see anything; the DNS lookup may happen over IPv6, and
OfM barfs without ever sending a packet. At most you=E2=80=99ll see a packet to a=
n
SMTP/POP/IMAP port, but it won=E2=80=99t tell you whether it was the client or th=
e
server that failed.
I=E2=80=99m not sure how to know of VPN failures where the DNS goes through the
VPN.=20

>
>
>Real world networks (end-users and corporate which are not related to
>IETF), will not (in 3-5 years), be willing to replace all the apps and
>devices that fail with just NAT64. They need a CLAT or similar support in
>their LANs.

I don=E2=80=99t know how many corporate apps/devices fail with IPv6 + NAT64. Mayb=
e
some legacy business systems, but that=E2=80=99s not the case for all, and won=E2=80=99=
t
be in 3-5 years. Even if it is, it may well make more sense for an
enterprise to use IPv6 on client networks, and surround legacy systems
with NAT64.

No, I don=E2=80=99t expect 90% of users will be doing IPv6-only in their homes or
corporate LANs in 3 years, but I wouldn=E2=80=99t be surprised if it=E2=80=99s 10-20%.

Lee



From nobody Mon Jul 17 12:19:52 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18A129A92 for ; Mon, 17 Jul 2017 12:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] 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 akM7CtWH79yB for ; Mon, 17 Jul 2017 12:19:49 -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 B1CAB12702E for ; Mon, 17 Jul 2017 12:19:48 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id y43so5683337wrd.3 for ; Mon, 17 Jul 2017 12:19:48 -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=u1sVB+0IK39uaYD/bGsWLyi3Gbm7pEbvDfG6rElP7MI=; b=YDFZKBHq4kTM1jhA7RRLk3T2N0tqOsNLkw02mVDDh3sr5BFAdZ6zK2dgvQQ43dCx8k u9P1/QvR3tCzG2Hdbp6ev016zun1Mx+eZu6g/sr5choIs5dqTwGHz6Frdc6aeQHwSGWx hHULDaj4IrjJ8gw7RkGvdwGWe7PjWTqc48W4lNxIwf34tesVDWN/c0tXQNlGVxkNq0r3 5UIOxeKF68TY5AcG30lOl1TD/StPQRnJBPwQwtBe2WQy6Ee5lSHJRRxE5YcVQ6jj/wON 55PtYBfRDJ9nkHhaNwgemLzY6Cw9Sz00lH+HXgUlyjTui/mG3SUyKp7hlar+Jngrl6+l wPEg==
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=u1sVB+0IK39uaYD/bGsWLyi3Gbm7pEbvDfG6rElP7MI=; b=QmNqQKUPSMOKSQYnrap1X5UZ2jsIX6YdZSnNWG2UCXodcg5CBBFBUNCEK0YzqJp6iX WrdTy8jrafx2tvZP8c0xF9ha5lOBTdn59tsMD7NqoA+3gq8QB/dZmzYrmQjzKXjWUZAe 51+U29qiE8stliBrF8/EWDqEPfLhAypLEBonDMRzdjyQZUXAUgvm8zVrwUw8L/6BVNBK EasvEClJtxn+CIGumORgZLBOR5meQp8D6LpxGuJLU2l/dsj/up7muANKpEQWnDU2tKPo 5gnP7EiG3Wlc+K3K7gO4aN2T64Pv79CLU3FI/qWXcUlIQ3EtKGli63qyxaMW+Nf5rEAM tHDA==
X-Gm-Message-State: AIVw111GO8g8cubeNpflD1Z1XW+4oBSP4RyVLTwiJNUY+ToVqet/HRnR Pjs0lJMCyWf/9I5ntFDVQRbzhEmRq8FeCJc=
X-Received: by 10.223.162.156 with SMTP id s28mr11894040wra.2.1500319187067; Mon, 17 Jul 2017 12:19:47 -0700 (PDT)
MIME-Version: 1.0
References: <596CF817.8040900@foobar.org> 
In-Reply-To: 
From: Job Snijders 
Date: Mon, 17 Jul 2017 19:19:34 +0000
Message-ID: 
To: Nick Hilliard , Ted Lemon 
Cc: IPv6 Operations 
Content-Type: multipart/alternative; boundary="f403045ec4943206610554884871"
Archived-At: 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 19:19:51 -0000

--f403045ec4943206610554884871
Content-Type: text/plain; charset="UTF-8"

Hi Ted,

This contribution made us realize that perhaps a clarification would be
useful: https://www.ietf.org/mail-archive/web/ipv6/current/msg28040.html

Kind regards,

Job

On Mon, 17 Jul 2017 at 20:17, Ted Lemon  wrote:

> The RFC doesn't say that anywhere in it.   There is no version of the
> draft that was published on 2/12/2016.   The -01 version of the draft was
> published in March of that year; the final version in July.   Can you
> please point out the place in the text where it says what you are saying it
> says?
>
> On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard  wrote:
>
>> draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.
>>
>> It has recently been claimed that IETF best current practice is that
>> DHCPv6 is not recommended due to the recommendations section in
>> RFC7934/BCP204.
>>
>> The relevant text was slipped into
>> draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
>> days before the document went into IETF LC.  There was no discussion
>> about this text change either in the v6ops working group or at IETF
>> review or IESG level: perhaps the modification appeared innocuous or
>> maybe it just wasn't not noticed.
>>
>> Next thing, there's a BCP which is being interpreted as meaning that
>> DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)
>>
>> This presents a variety of problems, the most serious of which are 1)
>> that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
>> without extensive discussion or debate about this particular issue at
>> the relevant working group, and ignores the both the widespread use of
>> the protocol and its active development at the ietf, and 2) that a
>> change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
>> in the IPv6 host specification.
>>
>> Job and I believe that this went through by mistake and that if the WG
>> had noticed the change at the time, consensus would never have been
>> reached on what is a serious semantic change to IETF lore.
>>
>> Right now, the most prudent course of action would be to roll back the
>> change until a proper debate has been had.  We invite WG comments on
>> this doc.
>>
>> Nick
>>
>> internet-drafts@ietf.org wrote:
>> > A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
>> > has been successfully submitted by Nick Hilliard and posted to the
>> > IETF repository.
>> >
>> > Name:         draft-hilliard-v6ops-host-addr-update
>> > Revision:     00
>> > Title:                Update for IPv6 Host Address Availability
>> Recommendations
>> > Document date:        2017-07-17
>> > Group:                Individual Submission
>> > Pages:                4
>> > URL:
>> https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt
>> > Status:
>> https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/
>> > Htmlized:
>> https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00
>> > Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00
>> >
>> >
>> > Abstract:
>> >    The IPv6 Host Address Availability Recommendations Best Current
>> >    Practice (RFC 7934), describes why IPv6 hosts should use multiple
>> >    global addresses when attaching to a network.  This document updates
>> >    RFC 7934 by removing a recommendation for networks to give the host
>> >    the ability to use new addresses without requiring explicit requests.
>> >
>> >
>> >
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of
>> submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > The IETF Secretariat
>> >
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Hi Ted,

This contribution made us realize that perhaps a clarification would=
 be useful:=C2=A0https://www.ietf.org/mail-archive/web/ipv6/current/msg28=
040.html

Kind regard=
s,

Job

On Mon, 17 Jul 2017 at 20:17, Ted Lemon <mellon@fugue.com> wrote:
The RFC doesn't say that anywhere in it.=
 =C2=A0 There is no version of the draft that was published on 2/12/2016. =
=C2=A0 The -01 version of the draft was published in March of that year; th=
e final version in July. =C2=A0 Can you please point out the place in the t=
ext where it says what you are saying it says?

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hi=
lliard <nick@=
foobar.org> wrote:
draft-hi=
lliard-v6ops-host-addr-update-00 has just been posted as an ID.



It has recently been claimed that IETF best current practice is that

DHCPv6 is not recommended due to the recommendations section in

RFC7934/BCP204.



The relevant text was slipped into

draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of

days before the document went into IETF LC.=C2=A0 There was no discussion
about this text change either in the v6ops working group or at IETF

review or IESG level: perhaps the modification appeared innocuous or

maybe it just wasn't not noticed.



Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.=C2=A0 Wow. :-)



This presents a variety of problems, the most serious of which are 1)

that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED&quo=
t;

without extensive discussion or debate about this particular issue at

the relevant working group, and ignores the both the widespread use of

the protocol and its active development at the ietf, and 2) that a

change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge=
 hole

in the IPv6 host specification.



Job and I believe that this went through by mistake and that if the WG

had noticed the change at the time, consensus would never have been

reached on what is a serious semantic change to IETF lore.



Right now, the most prudent course of action would be to roll back the

change until a proper debate has been had.=C2=A0 We invite WG comments on
this doc.



Nick



internet-draf=
ts@ietf.org wrote:

> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt

> has been successfully submitted by Nick Hilliard and posted to the

> IETF repository.

>

> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hilliard-v6ops-host-addr-=
update

> Revision:=C2=A0 =C2=A0 =C2=A000

> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Update f=
or IPv6 Host Address Availability Recommendations

> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-07-17

> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu=
al Submission

> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4

> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf=
t-hilliard-v6ops-host-addr-update-00.txt

> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host=
-addr-update/

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-=
00

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hilliard-v6o=
ps-host-addr-update-00

>

>

> Abstract:

>=C2=A0 =C2=A0 The IPv6 Host Address Availability Recommendations Best C=
urrent

>=C2=A0 =C2=A0 Practice (RFC 7934), describes why IPv6 hosts should use =
multiple

>=C2=A0 =C2=A0 global addresses when attaching to a network.=C2=A0 This =
document updates

>=C2=A0 =C2=A0 RFC 7934 by removing a recommendation for networks to giv=
e the host

>=C2=A0 =C2=A0 the ability to use new addresses without requiring explic=
it requests.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.
>

> The IETF Secretariat

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--f403045ec4943206610554884871--


From nobody Mon Jul 17 12:20:21 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1382127B57 for ; Mon, 17 Jul 2017 12:20:19 -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 6wMlCzzqrVE2 for ; Mon, 17 Jul 2017 12:20:16 -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 5F37C12F287 for ; Mon, 17 Jul 2017 12:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500319208; x=1500924008; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=rOHqB2NYphwS/9gUgx+/MKFAc ePd0QGEOUVNthF+lv8=; b=a6qFpQliAy8nMgbek+NuV3uvwn7MirO/3dW4S57Mc ZRUNZwB2I1Gi6P1cHCh9cK4noif8I8vFfIa9uIRMkKvySBMtS4D7mDKQCtIoezXz qUb6kJX0m6nUgxhqOU0/XyAYKWWqzpKUqkeYrRuY5NDNptk0ykVyYaY72IJJTw27 kQ=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=oY5R4QNPDROCTyFq1jfahj1Vc18TMIocBGgA2KiMYEUGqeKyPFa89BFPT9Vs pX4uGx/1MS3BD0OTFubmVBT7LYhiq1YDmSL9iQbBsKEd4+3F6Y7kPvT+9 OgvTC7Zf6vLPZxVkEzoC2o2+GQSIZK3viMDLKaMSKjIO5ehH3MZvVs=;
X-MDAV-Processed: mail.consulintel.es, Mon, 17 Jul 2017 21:20:08 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 17 Jul 2017 21:20:07 +0200
Received: from [31.133.186.60] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005478807.msg for ; Mon, 17 Jul 2017 21:20:06 +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:170717:md50005478807::AHF1i+gB7xeNS+AI:00001/s/
X-MDRemoteIP: 31.133.186.60
X-Return-Path: prvs=13714351ed=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Mon, 17 Jul 2017 21:20:01 +0200
From: JORDI PALET MARTINEZ 
To: IPv6 Ops WG 
CC: Randy Bush , Russ Housley , Suresh Krishnan , Alissa Cooper , Jim Martin 
Message-ID: <59186F7C-BA8B-485B-8B53-C03E7D0E0223@consulintel.es>
Thread-Topic: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es>    <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es>   <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es>    <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>   <9CDFFE8B-DBEC-4059-8E93-44AEC304E31A@consulintel.es> <45A7CDF3-9832-4944-9D77-95E17EAEDB47@apple.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: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 19:20:20 -0000

Below in-line with [Jordi].
   =20
    On 7/17/17, 10:27 AM, "v6ops on behalf of JORDI PALET MARTINEZ"
     wrote:
   =20
    >
    >4) The result is the same, but people don=E2=80=99t need to spend time=
. We
    >configure the Jool so it reports EVERY usage, so we can then process t=
hat
    >file to detect WHAT was using the CLAT.
   =20
    Your proposal is to log the 5-tuple of every connection (using the CLAT=
)
    on the IETF network?
    Any privacy concerns?

[Jordi] I don=E2=80=99t have privacy concerns myself, but I understand that=
, and obviously whatever we do, I suggest to be anonymized.

After all if we do the other way, people will need to tell what apps and we=
b sites or whatever are they visiting, so the issue is the same and we add =
the need for manual reporting.


   =20
    >5) The result is the same as the suggested experiment, but NOT breakin=
g
    >anything, not asking the participants to report anything, but having
    >BETTER collection of data about what will be broken if the CLAT is not
    >there (anything that goes into the CLAT).
   =20
    I=E2=80=99m not sure that logging the 5-tuple (if that=E2=80=99s what y=
ou mean to log)
    gives you that information.
    For instance, if Outlook for Mac isn=E2=80=99t working, and we don=E2=
=80=99t know why,
    then you may not see anything; the DNS lookup may happen over IPv6, and
    OfM barfs without ever sending a packet. At most you=E2=80=99ll see a p=
acket to an
    SMTP/POP/IMAP port, but it won=E2=80=99t tell you whether it was the cl=
ient or the
    server that failed.

[Jordi] I don't think we need to identify =E2=80=9Cwhy=E2=80=9D something i=
s not working. We just need to tell the =E2=80=9Capp=E2=80=9D or =E2=80=9Cs=
erver=E2=80=9D owner (example Microsoft in case of Outlook), what is failin=
g. I don=E2=80=99t think is our job, neither we have, even if voluntary, re=
sources to do more than that. So yes, maybe we need to log some additional =
data, such as port/protocol failing. We may need even to capture a few pack=
ets at the beginning of each traffic flow. I think I mention in one of the =
earlier emails I=E2=80=99m not a software developer, but I believe that we =
may figure out a simple way to do that if Jool itself don=E2=80=99t provide=
s all the tools/data that we need.



    I=E2=80=99m not sure how to know of VPN failures where the DNS goes thr=
ough the
    VPN.=20

[Jordi] Of course I was not suggesting to look into =E2=80=9CVPN=E2=80=9D t=
raffic. My mention about OpenVPN was because first attempts it failed. So I=
 was talking about OpenVPN as one app not surviving the NAT64, which now is=
 sorted out.


   =20
    >
    >
    >Real world networks (end-users and corporate which are not related to
    >IETF), will not (in 3-5 years), be willing to replace all the apps and
    >devices that fail with just NAT64. They need a CLAT or similar support=
 in
    >their LANs.
   =20
    I don=E2=80=99t know how many corporate apps/devices fail with IPv6 + N=
AT64. Maybe
    some legacy business systems, but that=E2=80=99s not the case for all, =
and won=E2=80=99t
    be in 3-5 years. Even if it is, it may well make more sense for an
    enterprise to use IPv6 on client networks, and surround legacy systems
    with NAT64.

[Jordi] There are many business with VoIP systems that will not work if the=
y don=E2=80=99t have IPv4 (even with private addresses as they have today) =
in the LAN. Same for security systems (IP cameras), devices that check the =
time the people come in/out the office, office automation, lighting automat=
ion, and I can keep going like that. Same for apps, like business apps (old=
er IBM systems still used very frequently here), banking apps, I=E2=80=99ve=
 been in many situations of web sites with dual-stack (even for governments=
 and banks) that don=E2=80=99t work with NAT64 (and of course, you can tell=
 as many times you want to the bank or government, they will not sort out f=
or you). So end of the history, we like it or not, we can=E2=80=99t have th=
e corporate LANs with just NAT64 for a while, they need to keep private IPv=
4, even if they turn off IPv4 in the WAN.
   =20
    No, I don=E2=80=99t expect 90% of users will be doing IPv6-only in thei=
r homes or
    corporate LANs in 3 years, but I wouldn=E2=80=99t be surprised if it=E2=
=80=99s 10-20%.
   =20
    Lee
   =20
   =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 Mon Jul 17 12:31:25 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9818B129A92 for ; Mon, 17 Jul 2017 12:31:23 -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 M9AMrRvh7U2p for ; Mon, 17 Jul 2017 12:31:22 -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 F2B70120721 for ; Mon, 17 Jul 2017 12:31:21 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id z37so3893240ybh.1 for ; Mon, 17 Jul 2017 12:31: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=TQY5gH1G5b1iYON8HZMGHBxzFXMnI6/jg8kTyZ68jeY=; b=nLHpt0R5WaZIPud2FTQIEZ2SZVSq4uM++u6mJkBFnAIPI9Dl4mvbwna3L4YW2ppslF gjAlxwztaVJxPWQ1OmeLQ8kk6sYKGkluJw4KhqSktwCzpHpwKJfGSa4YdgG5SHJ9nHtw kVdN3lrTRg7xJ+ZnKbc70dpT56bWorY9E+uck00yzmemIzWl9MZ8RJzN00zv6AqReoUB Uts7NSGB7XHhjiWWXaNpyfeGvLZ5hi0BE1P9Nz0coJKZGeIPlEOXkIzqf3M1OyFROXjH 1c7ll1G6olgsRwcKUVY0G6B7inl3S3cRFMKMZ+jClWT052SXVmiv83BX6FYk3R6/tVB1 iDYA==
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=TQY5gH1G5b1iYON8HZMGHBxzFXMnI6/jg8kTyZ68jeY=; b=KKXWw3cmWQS7+7/jrWPdMW6PDMxoNtd/ga/NY4Wm+dhlr5At3cMgPvgQH4Izf1Rw+A 6NSgzb5WEwbtIvfdBfNIHpRK3sdO0ftqOXZqVpM3B6Ss3TH2lNrGJRnM528l2Pae0OMw C9n+mk+FveR8fLy5HMESuMTrONh4JN5s+3nV4WNRg5S/nKXHUBXFBtEiW/rEM/04R3nE XoL6ytsXn58ZXV46KqDcBX1Lsd+1vREclwiooQKOuk6Dg2zbpyrpJqiNon/5zSSDIQcU zKH7NQJEVJZfDfYa52a2f1KkEU0/dCq5KEZd3I747I80Z6/mT3kiFTpAxLlZUrQUn6sr Ehyw==
X-Gm-Message-State: AIVw111P5u9IGhR2AkOYmaR/BdKpBLrLerTFhjdTyuX1fmp/0C8EjoJL sZjqEVhhPIhAiXPifpGj18gKfXszsIoAhDhUCQ==
X-Received: by 10.37.178.9 with SMTP id i9mr19526616ybj.8.1500319880840; Mon, 17 Jul 2017 12:31:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.35.69 with HTTP; Mon, 17 Jul 2017 12:31:00 -0700 (PDT)
In-Reply-To: 
References:  <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es>       <20170717152345.GV45648@Space.Net>  <20170717172242.GW45648@Space.Net>   
From: Erik Kline 
Date: Tue, 18 Jul 2017 04:31:00 +0900
Message-ID: 
To: Philip Homburg 
Cc: "v6ops@ietf.org" , Simon Hobson 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045f37fe9251d905548871ca"
Archived-At: 
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 19:31:24 -0000

--f403045f37fe9251d905548871ca
Content-Type: text/plain; charset="UTF-8"

> Of course, anyone who has manually configured Google's public DNS resolvers
> is also in for a surprise.

Assuming the WKP is in use, they're free to manually assign the Google
Public DNS64 servers:

    https://developers.google.com/speed/public-dns/docs/dns64

Though that's just setting them up for a different surprise on other
networks.  :)

--f403045f37fe9251d905548871ca
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgzR79AgGUf+qTBQL1eOdktU6lPYog9Ehf
EGHG8Z7B4jEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE3
MTkzMTIxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBANA+apsvezHXHNsntpFily015WH8ilSrGAr9qSTfaOZT622LyRUI
YbWAwBpUK7afk0FUE5zLZlCHYk9PrDx3CLrLJt7cCdP6k814KBg2rZdhT+bAczYZofqgRIgCMqmF
GlCEKcENxrJLqkUIZ4jtlPAmxYsDDahDN/ov92e2yzYZfPEJy/xyx6zuayVFUoe1kXhlQrQPF8Cn
KIBneKvanLHeCpd8U6c7VeR/DQTMOjm5RR8L3CtWo4YvL4zmTnkeBSHYKPKKy8kcNi5jpScdFMzX
CWkPfXsMB3jK6SP+v7hz1IPmBFcW0z2RQQ1RBFM/BCkeXURnP45M9xD31C2qGCE=
--f403045f37fe9251d905548871ca--


From nobody Mon Jul 17 12:31:37 2017
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CA2131798 for ; Mon, 17 Jul 2017 12:31:29 -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, 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=fugue-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 Y2B6fPTlyBgm for ; Mon, 17 Jul 2017 12:31:26 -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 D4B2D127B57 for ; Mon, 17 Jul 2017 12:31:25 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id e26so13191431pfd.0 for ; Mon, 17 Jul 2017 12:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KRfyCKLdNh038KgunqI76ZjXEjbh6r5pcjJJxAJuIvc=; b=xKfZCylYKS10s31z7DwptBvHwd97shGH5z1Vlo4hv1btlyrWjEVmf7MERLuCWaalRB WuNgJBnMqM46VXiTMhIEDM5kMy3evZR20R81Ox+JzK6AKwCHKbtRIg7twRs0xF1xE3DX kbQxH2KOSKSis1+I66fyzavmpmTSMDL8bRkARvsZwVRI4pSI8oAtsSuAmcu1F/qMpmnS BAonEq6rCVap+Qp0cN17TPl3Ubw9tMVRvlnS6xhS65uGshYesRhWwa2Tg0kQ0ofeL7u5 j7fJik1X153E3RH88D61FXL+meA+MgAOuWkD7XIsrYCJL6w1w8yvAYNnX56RQ6kyQzbH YJvA==
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=KRfyCKLdNh038KgunqI76ZjXEjbh6r5pcjJJxAJuIvc=; b=PJns35d8XsXPygLaoEEFqKtDIf18s2FwQvLpqvXf08OrcAfpSNc1QFa4Vv0W6cO1pI fOF+OrU4NQ91l0MRkOOYkI5RlB/5akBDPqvwgJJmUpDUxeRmTgr02XQff2joyGk5MXy5 +7vmEOJ2NxBHpT8JvMKsUgsQ/ZAodBL0VSDZsODqNDoD+9Pfq9H1bPg0/kNRUbF0Hz00 IWf9oXqho8mjC4wROjMzyx2hWIpGgUOI/EsJffvMysoD3OyQcA+MAjYIpHctEKYSNBie SAgrLWqUBsGOlupOgeMa7KF1hZU0sQieAsJC31R+7UfoDI9Nj/mBvhawCG8Nh7PGr47u BA3g==
X-Gm-Message-State: AIVw112TNTCZdhvvlsSHx3EP86jQTByKtv4qhLgPePAH2w+5OiOIvcrg gBPl4wdG4YJ5Ae7y04CZ54eYQA4c8O6wxhU=
X-Received: by 10.98.15.71 with SMTP id x68mr20745062pfi.176.1500319885257; Mon, 17 Jul 2017 12:31:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 12:30:44 -0700 (PDT)
In-Reply-To: 
References: <596CF817.8040900@foobar.org>  
From: Ted Lemon 
Date: Mon, 17 Jul 2017 21:30:44 +0200
Message-ID: 
To: Job Snijders 
Cc: Nick Hilliard , IPv6 Operations 
Content-Type: multipart/alternative; boundary="001a1137741ecf81fe0554887181"
Archived-At: 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Jul 2017 19:31:29 -0000

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

The following is a misreading of the document:

First, networks that require DHCPv6 assignment are explicitly NOT
> RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section
> 8 says "it is RECOMMENDED that the network give the host the ability to use
> new addresses without requiring explicit requests". A DHCPv6-only network
> cannot meet this recommendation, because on a DHCPv6-only network, all
> addresses acquisition requires an explicit request to the network.


What the document actually implies is that individual address assignment
using DHCPv6 is not recommended; instead it is recommended that each host
get a /64.  The only way to do that right now is with DHCPv6 PD.   So the
document is explicitly recommending the use of DHCPv6.

However, if the only DHCP service available is individual address
allocation, then indeed that is not recommended, because it has serious
privacy implications.   And it is not _generally_ recommended that people
operate networks that require DHCPv6 static individual address allocation
(IA_NA) for this same reason.   Using the DHCPv6 privacy profile does
mitigate this concern, but still the best thing to do is just enable SLAAC.

I don't think these views are particularly controversial in the IETF.   I'm
one of the authors of RFC3315, and I agree with this view.

On Mon, Jul 17, 2017 at 9:19 PM, Job Snijders  wrote:

> Hi Ted,
>
> This contribution made us realize that perhaps a clarification would be
> useful: https://www.ietf.org/mail-archive/web/ipv6/current/msg28040.html
>
> Kind regards,
>
> Job
>
> On Mon, 17 Jul 2017 at 20:17, Ted Lemon  wrote:
>
>> The RFC doesn't say that anywhere in it.   There is no version of the
>> draft that was published on 2/12/2016.   The -01 version of the draft was
>> published in March of that year; the final version in July.   Can you
>> please point out the place in the text where it says what you are saying it
>> says?
>>
>> On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard  wrote:
>>
>>> draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.
>>>
>>> It has recently been claimed that IETF best current practice is that
>>> DHCPv6 is not recommended due to the recommendations section in
>>> RFC7934/BCP204.
>>>
>>> The relevant text was slipped into
>>> draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
>>> days before the document went into IETF LC.  There was no discussion
>>> about this text change either in the v6ops working group or at IETF
>>> review or IESG level: perhaps the modification appeared innocuous or
>>> maybe it just wasn't not noticed.
>>>
>>> Next thing, there's a BCP which is being interpreted as meaning that
>>> DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)
>>>
>>> This presents a variety of problems, the most serious of which are 1)
>>> that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
>>> without extensive discussion or debate about this particular issue at
>>> the relevant working group, and ignores the both the widespread use of
>>> the protocol and its active development at the ietf, and 2) that a
>>> change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
>>> in the IPv6 host specification.
>>>
>>> Job and I believe that this went through by mistake and that if the WG
>>> had noticed the change at the time, consensus would never have been
>>> reached on what is a serious semantic change to IETF lore.
>>>
>>> Right now, the most prudent course of action would be to roll back the
>>> change until a proper debate has been had.  We invite WG comments on
>>> this doc.
>>>
>>> Nick
>>>
>>> internet-drafts@ietf.org wrote:
>>> > A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
>>> > has been successfully submitted by Nick Hilliard and posted to the
>>> > IETF repository.
>>> >
>>> > Name:         draft-hilliard-v6ops-host-addr-update
>>> > Revision:     00
>>> > Title:                Update for IPv6 Host Address Availability
>>> Recommendations
>>> > Document date:        2017-07-17
>>> > Group:                Individual Submission
>>> > Pages:                4
>>> > URL:            https://www.ietf.org/internet-
>>> drafts/draft-hilliard-v6ops-host-addr-update-00.txt
>>> > Status:         https://datatracker.ietf.org/
>>> doc/draft-hilliard-v6ops-host-addr-update/
>>> > Htmlized:       https://tools.ietf.org/html/draft-hilliard-v6ops-host-
>>> addr-update-00
>>> > Htmlized:       https://datatracker.ietf.org/
>>> doc/html/draft-hilliard-v6ops-host-addr-update-00
>>> >
>>> >
>>> > Abstract:
>>> >    The IPv6 Host Address Availability Recommendations Best Current
>>> >    Practice (RFC 7934), describes why IPv6 hosts should use multiple
>>> >    global addresses when attaching to a network.  This document updates
>>> >    RFC 7934 by removing a recommendation for networks to give the host
>>> >    the ability to use new addresses without requiring explicit
>>> requests.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Please note that it may take a couple of minutes from the time of
>>> submission
>>> > until the htmlized version and diff are available at tools.ietf.org.
>>> >
>>> > The IETF Secretariat
>>> >
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>

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


The following is a misreading of the document:

First, networks that require =
DHCPv6 assignment are explicitly NOT RECOMMENDED by current IETF best pract=
ices. Specifically,=C2=A0RFC 7934 section 8 says "it is RECOMMENDED th=
at the network give the host the ability to use new addresses without requi=
ring explicit requests". A DHCPv6-only network cannot meet this recomm=
endation, because on a DHCPv6-only network, all addresses acquisition requi=
res an explicit request to the network.

<=
div>What the document actually implies is that individual address assignmen=
t using DHCPv6 is not recommended; instead it is recommended that each host=
 get a /64.=C2=A0 The only way to do that right now is with DHCPv6 PD. =C2=
=A0 So the document is explicitly recommending the use of DHCPv6.

However, if the only DHCP service available is individual a=
ddress allocation, then indeed that is not recommended, because it has seri=
ous privacy implications. =C2=A0 And it is not _generally_ recommended that=
 people operate networks that require DHCPv6 static individual address allo=
cation (IA_NA) for this same reason. =C2=A0 Using the DHCPv6 privacy profil=
e does mitigate this concern, but still the best thing to do is just enable=
 SLAAC.

I don't think these views are particul=
arly controversial in the IETF. =C2=A0 I'm one of the authors of RFC331=
5, and I agree with this view.

On Mon, Jul 17, 2017 at 9:19 PM, Job Snijders <jo=
b@instituut.net> wrote:
Hi Ted,

This contribution made us realize that perhaps a clarification would be=
 useful:=C2=A0https://www.ietf.org/mail-archive/we=
b/ipv6/current/msg28040.html

Kind regards,

Job

On =
Mon, 17 Jul 2017 at 20:17, Ted Lemon <mellon@fugue.com> wrote:
The RFC doesn't say that anywhere in it. =C2=A0 T=
here is no version of the draft that was published on 2/12/2016. =C2=A0 The=
 -01 version of the draft was published in March of that year; the final ve=
rsion in July. =C2=A0 Can you please point out the place in the text where =
it says what you are saying it says?

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard <nick@foobar.org=
> wrote:
draft-hilliard-v6o=
ps-host-addr-update-00 has just been posted as an ID.



It has recently been claimed that IETF best current practice is that

DHCPv6 is not recommended due to the recommendations section in

RFC7934/BCP204.



The relevant text was slipped into

draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple o=
f

days before the document went into IETF LC.=C2=A0 There was no discussion
about this text change either in the v6ops working group or at IETF

review or IESG level: perhaps the modification appeared innocuous or

maybe it just wasn't not noticed.



Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.=C2=A0 Wow. :-)



This presents a variety of problems, the most serious of which are 1)

that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED&quo=
t;

without extensive discussion or debate about this particular issue at

the relevant working group, and ignores the both the widespread use of

the protocol and its active development at the ietf, and 2) that a

change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge=
 hole

in the IPv6 host specification.



Job and I believe that this went through by mistake and that if the WG

had noticed the change at the time, consensus would never have been

reached on what is a serious semantic change to IETF lore.



Right now, the most prudent course of action would be to roll back the

change until a proper debate has been had.=C2=A0 We invite WG comments on
this doc.



Nick



internet-draf=
ts@ietf.org wrote:

> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.tx=
t

> has been successfully submitted by Nick Hilliard and posted to the

> IETF repository.

>

> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hilliard-v6ops-host-=
addr-update

> Revision:=C2=A0 =C2=A0 =C2=A000

> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Update f=
or IPv6 Host Address Availability Recommendations

> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-07-17

> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu=
al Submission

> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4

> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts=
/draft-hilliard-v6ops-host-addr-update-00.txt

> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hilliard-v6ops=
-host-addr-update/

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hilliard-v6ops-host-ad=
dr-update-00

> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hilliar=
d-v6ops-host-addr-update-00

>

>

> Abstract:

>=C2=A0 =C2=A0 The IPv6 Host Address Availability Recommendations Best C=
urrent

>=C2=A0 =C2=A0 Practice (RFC 7934), describes why IPv6 hosts should use =
multiple

>=C2=A0 =C2=A0 global addresses when attaching to a network.=C2=A0 This =
document updates

>=C2=A0 =C2=A0 RFC 7934 by removing a recommendation for networks to giv=
e the host

>=C2=A0 =C2=A0 the ability to use new addresses without requiring explic=
it requests.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.
>

> The IETF Secretariat

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




_______________________________________________

v6ops mailing list

v6ops@ietf.org

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

--001a1137741ecf81fe0554887181-- From nobody Mon Jul 17 13:12:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A526C131B1F for ; Mon, 17 Jul 2017 13:12:32 -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 0HJ5jqDTx6p9 for ; Mon, 17 Jul 2017 13:12:29 -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 92230131B12 for ; Mon, 17 Jul 2017 13:12:29 -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 v6HKCRn9019685 for ; Mon, 17 Jul 2017 22:12:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BB612205873 for ; Mon, 17 Jul 2017 22:12:27 +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 B1F6C2041E1 for ; Mon, 17 Jul 2017 22:12:27 +0200 (CEST) Received: from [132.166.84.150] ([132.166.84.150]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HKCO1K000633 for ; Mon, 17 Jul 2017 22:12:26 +0200 To: v6ops@ietf.org References: <596CF817.8040900@foobar.org> From: Alexandre Petrescu Message-ID: <53fb3617-206f-669b-56e7-a8a46c951942@gmail.com> Date: Mon, 17 Jul 2017 22:12:19 +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: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:12:33 -0000 Le 17/07/2017 à 21:30, Ted Lemon a écrit : > The following is a misreading of the document: > > First, networks that require DHCPv6 assignment are explicitly NOT > RECOMMENDED by current IETF best practices. Specifically, RFC 7934 > section 8 says "it is RECOMMENDED that the network give the host the > ability to use new addresses without requiring explicit requests". A > DHCPv6-only network cannot meet this recommendation, because on a > DHCPv6-only network, all addresses acquisition requires an explicit > request to the network. > > > What the document actually implies is that individual address > assignment using DHCPv6 is not recommended; instead it is recommended > that each host get a /64. The only way to do that right now is with > DHCPv6 PD. Ted - I would really like to agree with you, but DHCPv6 PD is not the only way for a host to get a /64. What the authors had in mind is the cellular link with RA, or alternatively a WiFi link with draft-unique-prefix-per-host. In these two cases the way it works is that RA advertises a /64 to the Host; because of that, and because it is a point-to-point link, or because the RA is unicast to the Host, then that /64 is practically entirely for the Host. The authors explicitely said that DHCPv6-PD is not the way to send a /64 to the Host. And I disagree with them. When that BCP was written I expressed this view several times but to no avail. When I see the misunderstanding that BCP created I am tempted to ask to question its BCP status... It is a huge misudnerstanding, and it continues to be cited. > So the document is explicitly recommending the use of DHCPv6. If it were so, I would agree with it. But it is not so. Alex > However, if the only DHCP service available is individual address > allocation, then indeed that is not recommended, because it has > serious privacy implications. And it is not _generally_ recommended > that people operate networks that require DHCPv6 static individual > address allocation (IA_NA) for this same reason. Using the DHCPv6 > privacy profile does mitigate this concern, but still the best thing > to do is just enable SLAAC. > > I don't think these views are particularly controversial in the IETF. > I'm one of the authors of RFC3315, and I agree with this view. > > On Mon, Jul 17, 2017 at 9:19 PM, Job Snijders > wrote: > > Hi Ted, > > This contribution made us realize that perhaps a clarification would > be useful: > https://www.ietf.org/mail-archive/web/ipv6/current/msg28040.html > > > Kind regards, > > Job > > On Mon, 17 Jul 2017 at 20:17, Ted Lemon > wrote: > > The RFC doesn't say that anywhere in it. There is no version of the > draft that was published on 2/12/2016. The -01 version of the draft > was published in March of that year; the final version in July. Can > you please point out the place in the text where it says what you are > saying it says? > > On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard > wrote: > > draft-hilliard-v6ops-host-addr-update-00 has just been posted as an > ID. > > It has recently been claimed that IETF best current practice is that > DHCPv6 is not recommended due to the recommendations section in > RFC7934/BCP204. > > The relevant text was slipped into > draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple > of days before the document went into IETF LC. There was no > discussion about this text change either in the v6ops working group > or at IETF review or IESG level: perhaps the modification appeared > innocuous or maybe it just wasn't not noticed. > > Next thing, there's a BCP which is being interpreted as meaning that > DHCPv6 is NOT RECOMMENDED for operational use. Wow. :-) > > This presents a variety of problems, the most serious of which are > 1) that a BCP is implying that the use of DHCPv6 was "NOT > RECOMMENDED" without extensive discussion or debate about this > particular issue at the relevant working group, and ignores the both > the widespread use of the protocol and its active development at the > ietf, and 2) that a change in the status of DHCPv6 to "NOT > RECOMMENDED" leaves a huge hole in the IPv6 host specification. > > Job and I believe that this went through by mistake and that if the > WG had noticed the change at the time, consensus would never have > been reached on what is a serious semantic change to IETF lore. > > Right now, the most prudent course of action would be to roll back > the change until a proper debate has been had. We invite WG comments > on this doc. > > Nick > > internet-drafts@ietf.org wrote: >> A new version of I-D, > draft-hilliard-v6ops-host-addr-update-00.txt >> has been successfully submitted by Nick Hilliard and > posted to the >> IETF repository. >> >> Name: draft-hilliard-v6ops-host-addr-update Revision: >> 00 Title: Update for IPv6 Host Address > Availability Recommendations >> Document date: 2017-07-17 Group: Individual >> Submission Pages: 4 URL: > https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt > > >> Status: > https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/ > > >> Htmlized: > https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00 > > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00 > > >> >> >> Abstract: The IPv6 Host Address Availability Recommendations > Best Current >> Practice (RFC 7934), describes why IPv6 hosts should > use multiple >> global addresses when attaching to a network. This > document updates >> RFC 7934 by removing a recommendation for networks to > give the host >> the ability to use new addresses without requiring > explicit requests. >> >> >> >> >> >> Please note that it may take a couple of minutes from the > time of submission >> until the htmlized version and diff are available at > tools.ietf.org . >> >> The IETF Secretariat >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jul 17 13:33:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B20131B33 for ; Mon, 17 Jul 2017 13:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 7QiPMosX_wKE for ; Mon, 17 Jul 2017 13:33:52 -0700 (PDT) Received: from mta04.svc.cra.dublin.eircom.net (mta04.svc.cra.dublin.eircom.net [159.134.118.171]) by ietfa.amsl.com (Postfix) with SMTP id CC175131C1F for ; Mon, 17 Jul 2017 13:33:51 -0700 (PDT) Received: (qmail 16111 messnum 20189979 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 17 Jul 2017 20:33:49 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (HELO avas01) (213.94.190.12) by mta04.svc.cra.dublin.eircom.net (qp 16111) with SMTP; 17 Jul 2017 20:33:49 -0000 Received: from [192.168.1.4] ([86.40.119.162]) by Cloudmark Gateway with SMTP id XChQdFGMDcTICXCiDdx5Rt; Mon, 17 Jul 2017 21:33:49 +0100 X-CNFS-Analysis: v=2.2 cv=DPn/22Fb c=1 sm=1 tr=0 a=ET4DzX2cQ4ZB4To4uwT5YA==:117 a=ET4DzX2cQ4ZB4To4uwT5YA==:17 a=mDhKZzf2AAAA:8 a=48vgC7mUAAAA:8 a=7ywY2KPW2V2m4r9PoiMA:9 a=tudWCk7Ck0KkMc1Z:21 a=fe-H6QdZc47eanjp:21 a=CjuIK1q_8ugA:10 a=2vPGa-vXXZzu3RC8VFUA:9 a=vy607ylgVl9k41Ja:21 a=KvP-Hodjt3UBZtbW:21 a=-zKv3T-qIoLWFnH6:21 a=_W_S_7VecoQA:10 a=CdbHPLkhJ6Q0XNsaeua2:22 a=w1C3t2QeGrPiZgrLijVG:22 From: Ross Chandler Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_02B777C9-A6D8-4ADA-A1A9-A54EDF99ABC2" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) Date: Mon, 17 Jul 2017 21:33:48 +0100 In-Reply-To: Cc: Job Snijders , IPv6 Operations To: Ted Lemon References: <596CF817.8040900@foobar.org> X-Mailer: Apple Mail (2.3439) X-CMAE-Envelope: MS4wfFGjEhfsfvcp9vu9g/vHPRjRvoRH8AXruttV8EKFS/cwonMddm9HEOhn5F/JkJSah5VwOUa3gy9KztS3+BABsn7xNK6ARf/Kr3MHwZeYu8NFPPdBF3jl zRQja3InNMS9Lo/ianUGFTrjQENRuDF+9gsb9t/uLvJxDPA00DT5IFn8aVxTGyvHl/uK8WNOsqwEU6juB0UyHHBu+YyJ+DUREsE= Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:33:54 -0000 --Apple-Mail=_02B777C9-A6D8-4ADA-A1A9-A54EDF99ABC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17 Jul 2017, at 20:30, Ted Lemon > wrote: >=20 > What the document actually implies is that individual address = assignment using DHCPv6 is not recommended; instead it is recommended = that each host get a /64. The only way to do that right now is with = DHCPv6 PD. So the document is explicitly recommending the use of = DHCPv6. = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 6 = Section 4 describes a way of assigning a /64 per host using RAs that is = already deployed in real networks. No DHCPv6 involved. https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt = Introduces an eXclusive flag to optimize RA for nodes that are exclusive = receivers of all traffic to the prefix.=20 > However, if the only DHCP service available is individual address = allocation, then indeed that is not recommended, because it has serious = privacy implications. And it is not _generally_ recommended that = people operate networks that require DHCPv6 static individual address = allocation (IA_NA) for this same reason. Using the DHCPv6 privacy = profile does mitigate this concern, but still the best thing to do is = just enable SLAAC. >=20 > I don't think these views are particularly controversial in the IETF. = I'm one of the authors of RFC3315, and I agree with this view. Given the above two drafts DHCPv6-PD to hosts has an uphill struggle to = ever achieve widespread deployment. Ross= --Apple-Mail=_02B777C9-A6D8-4ADA-A1A9-A54EDF99ABC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 17 = Jul 2017, at 20:30, Ted Lemon <mellon@fugue.com> wrote:

What the document actually implies is that individual address = assignment using DHCPv6 is not recommended; instead it is recommended = that each host get a /64.  The only way to do that right now is = with DHCPv6 PD.   So the document is explicitly recommending the = use of DHCPv6.

https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-06

Section 4 describes a way of assigning a /64 per host using = RAs that is already deployed in real networks. No DHCPv6 = involved.

https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bi= t-02.txt

Introduces an eXclusive flag to optimize RA for nodes that = are exclusive receivers of all traffic to the prefix. 

However, if the only DHCP service = available is individual address allocation, then indeed that is not = recommended, because it has serious privacy implications.   And it = is not _generally_ recommended that people operate networks that require = DHCPv6 static individual address allocation (IA_NA) for this same = reason.   Using the DHCPv6 privacy profile does mitigate this = concern, but still the best thing to do is just enable SLAAC.

I don't think these = views are particularly controversial in the IETF.   I'm one of the = authors of RFC3315, and I agree with this = view.

Given the above two drafts DHCPv6-PD to hosts has an uphill = struggle to ever achieve widespread deployment.

Ross
= --Apple-Mail=_02B777C9-A6D8-4ADA-A1A9-A54EDF99ABC2-- From nobody Mon Jul 17 13:58:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE110126D46 for ; Mon, 17 Jul 2017 13:58:11 -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 8JZBFK9RyLuT for ; Mon, 17 Jul 2017 13:58:10 -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 9E6491243F6 for ; Mon, 17 Jul 2017 13:58: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 v6HKw7Yt131637 for ; Mon, 17 Jul 2017 22:58:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 85F2020587C for ; Mon, 17 Jul 2017 22:58:07 +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 7CC65205873 for ; Mon, 17 Jul 2017 22:58:07 +0200 (CEST) Received: from [132.166.84.163] ([132.166.84.163]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HKw4aE004527 for ; Mon, 17 Jul 2017 22:58:05 +0200 To: v6ops@ietf.org References: <596CF817.8040900@foobar.org> From: Alexandre Petrescu Message-ID: <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> Date: Mon, 17 Jul 2017 22:58:03 +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=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:58:12 -0000 Le 17/07/2017 22:33, Ross Chandler a crit : > >> On 17 Jul 2017, at 20:30, Ted Lemon > > wrote: >> >> What the document actually implies is that individual address >> assignment using DHCPv6 is not recommended; instead it is >> recommended that each host get a /64. The only way to do that >> right now is with DHCPv6 PD. So the document is explicitly >> recommending the use of DHCPv6. > > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 > > Section 4 describes a way of assigning a /64 per host using RAs that > is already deployed in real networks. No DHCPv6 involved. There is something wrong with that draft: it only allows for 64. Why? DHCPv6-PD can delegate other plengths, like 65. > https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt > > Introduces an eXclusive flag to optimize RA for nodes that are > exclusive receivers of all traffic to the prefix. This is another way of calling RA "Prefix Delegation". There are other drafts doing Prefix Delegation with RA, have you considered them? >> However, if the only DHCP service available is individual address >> allocation, then indeed that is not recommended, because it has >> serious privacy implications. And it is not _generally_ >> recommended that people operate networks that require DHCPv6 static >> individual address allocation (IA_NA) for this same reason. Using >> the DHCPv6 privacy profile does mitigate this concern, but still >> the best thing to do is just enable SLAAC. >> >> I don't think these views are particularly controversial in the >> IETF. I'm one of the authors of RFC3315, and I agree with this >> view. > > Given the above two drafts DHCPv6-PD to hosts has an uphill struggle > to ever achieve widespread deployment. I dont think so. I think DHCPv6-PD should be trialled at IETF WiFi and then we'll see. Alex From nobody Mon Jul 17 14:21:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ACD131CC5 for ; Mon, 17 Jul 2017 14:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AQZwSc6Y3O4z for ; Mon, 17 Jul 2017 14:21:15 -0700 (PDT) Received: from mta04.svc.cra.dublin.eircom.net (mta04.svc.cra.dublin.eircom.net [159.134.118.171]) by ietfa.amsl.com (Postfix) with SMTP id 0E084131CBB for ; Mon, 17 Jul 2017 14:21:14 -0700 (PDT) Received: (qmail 31828 messnum 20195015 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 17 Jul 2017 21:21:13 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (HELO avas02) (213.94.190.14) by mta04.svc.cra.dublin.eircom.net (qp 31828) with SMTP; 17 Jul 2017 21:21:13 -0000 Received: from [192.168.1.4] ([86.40.119.162]) by Cloudmark Gateway with SMTP id XDS5dFM71dkx5XDS5dLRJz; Mon, 17 Jul 2017 22:21:13 +0100 X-CNFS-Analysis: v=2.2 cv=EOR26xRC c=1 sm=1 tr=0 a=ET4DzX2cQ4ZB4To4uwT5YA==:117 a=ET4DzX2cQ4ZB4To4uwT5YA==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=30CTBInHot3YrxSAE4AA:9 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) From: Ross Chandler In-Reply-To: <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> Date: Mon, 17 Jul 2017 22:21:13 +0100 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4171F21D-A063-4173-8B9D-634DC360D891@eircom.net> References: <596CF817.8040900@foobar.org> <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3439) X-CMAE-Envelope: MS4wfBukHR97+PEzO03iwcOrzgtfG9hg3x7n6vQ84ZcoxZxnQUPzxmV6JZWzce5C1ioNzZ3YYDzHhRoH9QafJpOSythu3dC34nTZ2R2EhqsNGZi6DXm7Jhjc tpCcoVYcgKDJtxO2Pr1jeH7MOURXk4NcZAjwGjFUIBqm5KP1QI21lhuzVM1hwy0eTTAUNfrivHa9JbUYa24gMoSOI2qM1KBhVaI= Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:21:17 -0000 > On 17 Jul 2017, at 21:58, Alexandre Petrescu = wrote: >=20 > There is something wrong with that draft: it only allows for 64. Why? > DHCPv6-PD can delegate other plengths, like 65. I agree that is a deficiency. >> = https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt >>=20 >> Introduces an eXclusive flag to optimize RA for nodes that are >> exclusive receivers of all traffic to the prefix. >=20 > This is another way of calling RA =E2=80=9CPrefix Delegation". Fair enough. > There are other drafts doing Prefix Delegation with RA, have you > considered them? No, what are they? The above one caught my eye because of the employer = of one of the authors. >>> uthors of RFC3315, and I agree with this >>> view. >> Given the above two drafts DHCPv6-PD to hosts has an uphill struggle >> to ever achieve widespread deployment. >=20 > I don=E2=80=99t think so. You=E2=80=99re more optimistic than me then.=20 > I think DHCPv6-PD should be trialled at IETF WiFi and then we=E2=80=99ll= see. Yes, it should. Ross= From nobody Mon Jul 17 14:24:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC691200F3 for ; Mon, 17 Jul 2017 14:24:03 -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 zKo6-bTPe1nr for ; Mon, 17 Jul 2017 14:24:02 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C041200ED for ; Mon, 17 Jul 2017 14:24:01 -0700 (PDT) Received: from [2a02:c0:2:4:443:6:0:100d] (port=39220 helo=sloth.fud.no) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1dXDUl-00027r-OT; Mon, 17 Jul 2017 23:23:59 +0200 To: Philip Homburg References: <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es> <20170717152345.GV45648@Space.Net> From: Tore Anderson Cc: v6ops@ietf.org Message-ID: <29616c41-49d5-a960-8048-9441284fd171@fud.no> Date: Mon, 17 Jul 2017 23:23:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] NAT64/DNS64 support in RIPE Atlas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:24:03 -0000 * Philip Homburg > you don't want to know how much I had to change to the Atlas probes > and related infrastructure to get them to support NAT64/DNS64. I do want to know, you certainly are tickling my curiosity here. Is this about DNSSEC, did you implement a 464XLAT CLAT, or something else entirely? If it cannot be summarised in an e-mail, perhaps write a RIPE Labs article about the subject? (I changed the subject, as to the best of my knowledge the Atlas probes have their 802.11 radios disabled, and as such are very unlikely to ever be connected to a conference wireless network.) Tore From nobody Mon Jul 17 14:33:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A366912778E for ; Mon, 17 Jul 2017 14:33:41 -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, 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 AeOIaOZq-YvP for ; Mon, 17 Jul 2017 14:33:39 -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 2BDDA124234 for ; Mon, 17 Jul 2017 14:33:38 -0700 (PDT) X-Envelope-To: v6ops@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 v6HLXYIv003009 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2017 22:33:35 +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: <596D2D2D.5080406@foobar.org> Date: Mon, 17 Jul 2017 22:33:33 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: IPv6 Operations , "v6ops-chairs@tools.ietf.org Chairs" References: <596CF817.8040900@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:33:42 -0000 [v6ops-chairs explicitly cc:'d because there is a serious WG consensus problem here which has materially affected the outcome of an IETF process] Lorenzo Colitti wrote: > the text you mention was not "slipped in" by mistake, it was the outcome > of WG discussion. No, it categorically was not. There was extensive discussion about this at -04, where it was clear there there there was operator support for the position that DHCPv6 IA_NA was a viable option which would match the aims of the draft, for example: https://www.ietf.org/mail-archive/web/v6ops/current/msg23997.html https://www.ietf.org/mail-archive/web/v6ops/current/msg23999.html + several others. Or the posting that sums this whole situation up: https://www.ietf.org/mail-archive/web/v6ops/current/msg23856.html As far as I can tell, there were very few people other than you advocating the position that there was a problem with DHCPv6 IA_NA. Despite this, you completely ignored the feedback from the working group about DHCPv6 IA_NA, and changed the wording in -05 to state: -- Due to the drawbacks imposed by requiring explicit requests for address space (see section Section 4), it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests. --- -05 was introduced to the WG by the following email: https://www.ietf.org/mail-archive/web/v6ops/current/msg24279.html There was no mention of the fact that a change was made which effectively ignored the outcome of the discussion. 12 days later without any comment about this change, the document went to IETF LC. You ignored the WG, didn't point it out, and despite extensive previous objections, unfortunately the WG didn't notice. The term "blindside" is your choice of phrase. Nick From nobody Mon Jul 17 14:38:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4DB129432 for ; Mon, 17 Jul 2017 14:38:51 -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, 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 e8HBCFncUMsP for ; Mon, 17 Jul 2017 14:38:48 -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 7D52D126CC7 for ; Mon, 17 Jul 2017 14:38:48 -0700 (PDT) X-Envelope-To: v6ops@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 v6HLciLp003607 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2017 22:38:45 +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: <596D2E63.3070401@foobar.org> Date: Mon, 17 Jul 2017 22:38:43 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ted Lemon CC: IPv6 Operations References: <596CF817.8040900@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:38:51 -0000 > https://www.ietf.org/mail-archive/web/v6ops/current/msg24278.html + this url for the diffs > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-05 see section 8 - recommendations. Nick Ted Lemon wrote: > The RFC doesn't say that anywhere in it. There is no version of the > draft that was published on 2/12/2016. The -01 version of the draft > was published in March of that year; the final version in July. Can > you please point out the place in the text where it says what you are > saying it says? > > On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard > wrote: > > draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID. > > It has recently been claimed that IETF best current practice is that > DHCPv6 is not recommended due to the recommendations section in > RFC7934/BCP204. > > The relevant text was slipped into > draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of > days before the document went into IETF LC. There was no discussion > about this text change either in the v6ops working group or at IETF > review or IESG level: perhaps the modification appeared innocuous or > maybe it just wasn't not noticed. > > Next thing, there's a BCP which is being interpreted as meaning that > DHCPv6 is NOT RECOMMENDED for operational use. Wow. :-) > > This presents a variety of problems, the most serious of which are 1) > that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED" > without extensive discussion or debate about this particular issue at > the relevant working group, and ignores the both the widespread use of > the protocol and its active development at the ietf, and 2) that a > change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole > in the IPv6 host specification. > > Job and I believe that this went through by mistake and that if the WG > had noticed the change at the time, consensus would never have been > reached on what is a serious semantic change to IETF lore. > > Right now, the most prudent course of action would be to roll back the > change until a proper debate has been had. We invite WG comments on > this doc. > > Nick > > internet-drafts@ietf.org wrote: > > A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt > > has been successfully submitted by Nick Hilliard and posted to the > > IETF repository. > > > > Name: draft-hilliard-v6ops-host-addr-update > > Revision: 00 > > Title: Update for IPv6 Host Address Availability > Recommendations > > Document date: 2017-07-17 > > Group: Individual Submission > > Pages: 4 > > URL: > https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt > > > Status: > https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/ > > > Htmlized: > https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00 > > > > > > > Abstract: > > The IPv6 Host Address Availability Recommendations Best Current > > Practice (RFC 7934), describes why IPv6 hosts should use multiple > > global addresses when attaching to a network. This document > updates > > RFC 7934 by removing a recommendation for networks to give the host > > the ability to use new addresses without requiring explicit > requests. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at > tools.ietf.org . > > > > The IETF Secretariat > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Mon Jul 17 14:56:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC55126C23 for ; Mon, 17 Jul 2017 14:55: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, 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 kTPcq91ixocf for ; Mon, 17 Jul 2017 14:55:58 -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 A3CBD126BFD for ; Mon, 17 Jul 2017 14:55:56 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l21so643276ywb.1 for ; Mon, 17 Jul 2017 14:55: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=5ij7uTf4J4rFwaGVRqOnn44+fqTqooH8p2eJuixCn4k=; b=RfBrdEC44jz8pg+tnD+1b0YLZ7TGNMkFLP/qrGnfxrhWtmqf/E54piP04CjvcjnStN za2GTqQiooM4fWHJnOxuoqyrUc9nNUWBYgDUXv4KbZO5KG0me4dOKuZmXPPUoPGCRK2a GCsuD62/mvczZ3qhadS2liRoMu2cxShd7zXUaJ3uaFNKOOJoz9Tu27U06tQjWwXyf7n1 zAK8F9COrrIcdT7MTQ6IYySmqOCUtLiourLD/IcVI4lPgggcL+tLEu7sqmCEPmRV+G7b O4skFsAir6WqFmqo6Bst/Gm8FxqbWeQl1ieajoy2gqwwn+l322cUsBeAO+Iqej/rFez3 zmOA== 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=5ij7uTf4J4rFwaGVRqOnn44+fqTqooH8p2eJuixCn4k=; b=gWqYAym0d6byh5uFNJqzGcyAlDXb6cK4NaSJzHdiHWl8rLPrUAbxzddhL3yX0y7a/l p2esCpMsvXwmXz9fNMQCOmjsxNHVC8YsCK2M91xCn1TXf7oIRKV/c5Fz2l923YT5QmP3 r7ulNejzZH2Xrt7Fvg2PJqUQiCQsuac4Yl3GaCZM/4WJqstL9BSn1zCeZ3sfY5eshe6q 7EixWLhu4mI8AqZpURMqDosnrIhjX3IqnlZJZqeGN/WFYMrT3uva/AbWRJYN4Mtj2ePG AQZUKLTjrxMWazU0nMBCyaBxyoe7zBh53tP3ACGTfcCzwAa1eRAHWjfkONKLBm6miLBD uExw== X-Gm-Message-State: AIVw112FjqZHCt129lEfOgYlBRxjoDonv2dewORARe1GPLZbJWyA0eXP 3CTUnupZKfohQe3Qv6/TYAHPj2wke6eelErvsw== X-Received: by 10.13.214.18 with SMTP id y18mr18745543ywd.340.1500328555635; Mon, 17 Jul 2017 14:55:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Mon, 17 Jul 2017 14:55:35 -0700 (PDT) In-Reply-To: <596D2E63.3070401@foobar.org> References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> From: Erik Kline Date: Tue, 18 Jul 2017 06:55:35 +0900 Message-ID: To: Nick Hilliard Cc: Ted Lemon , IPv6 Operations Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c076e90a1112605548a7638" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:55:59 -0000 --94eb2c076e90a1112605548a7638 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In Prague 2 years ago this was presented (https://www.ietf.org/proceedings/93/slides/slides-93-v6ops-7.pdf). At that time, the minutes record that the "ask[ing...] on the fly section [wa]s vague": https://tools.ietf.org/wg/v6ops/minutes?item=3Dminutes-93-v6ops.html Limitations of asking for more on the fly section is vague. Lots = of things require waiting for something to happen. Lots of cases whe= re you know ahead of time you=E2=80=99ll need more than one. Launchi= ng a VM will require on the fly, but enumerate these cases better. And the slides from IETF 94 mention this issue and states that the doc addresses this: https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-9.pdf The topic in general was discussed. --94eb2c076e90a1112605548a7638 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgr2nRkq6WHV165RaFUf/sdZ+SeFC8LfEB N1BDjtSbmecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE3 MjE1NTU2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAIlHvksm+IkUyuAVze6TnzWwtl73MfzCh65oG/LN0afh3V0WMHYf n8clw9fyAI7c2GmUj8BJBtI4ss4EwVjy8oe8CFNmmdhKHWIVkWIzU85QG4kE0YQASZQnhS0wqc23 Sg431mWh0BOnZqY56VZ70QGn/udkmI+/6n4amjv3ls4La/q9dJIDZEYvFJmuqFGZ8C19eUblJwBW X0FpB2hgHcoHVGuxu/yW4ciZgEOUUekiDM5x4/5GxHHDOtxcw6fGCxyNsngL8bAf7HOnDEt5lzzn jSk4W3oCc5ghXaBA1aWGlHlw9ToFFheRCFClB2B3AQDTIA6ioOcK7vlXcrolN1k= --94eb2c076e90a1112605548a7638-- From nobody Mon Jul 17 15:25:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5A129B47 for ; Mon, 17 Jul 2017 15:25:04 -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 9CVyo4uWNXMm for ; Mon, 17 Jul 2017 15:25:02 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 9D206126BF3 for ; Mon, 17 Jul 2017 15:25:02 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z62so4633944ioi.3 for ; Mon, 17 Jul 2017 15:25:02 -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=5IkYrouyQmak95LnetqKtGyo0GyypeX2iLiL/BhUnoI=; b=VnRhEpFVfSlVvlwcl5KizK25cLjBeKIlVX5P5UzATjlM3hv2kVqvU+SFgt5W8pgywE ++ZoXIHATqOduDNQu+RHu7X0JMUosBddem4aOLPHw7xX1BmzcqNVVyGCGDZw+xls7pku j0s2RrSL+/usmZlAGFRsnNEcH/rjlwbIZFReBUrp4HGF3qhSyCtbL2Egh2IaMQnzMoLl a9KBkbyAIkDtSZrKFG/Jlm2DNElQzI7fvipZ34p/P8ruu3pMuDJzj0D+dBxGNLa/RFHU yMY2Rqd9bClRR2Qx4h7/FZCMRU9F4anupV5nzTk/JttKpxXTjeH93hVifIMzIKnwXDXd AwwQ== 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=5IkYrouyQmak95LnetqKtGyo0GyypeX2iLiL/BhUnoI=; b=gxI4DeDwGgQCINJWb9m3SqeyLNh8zC59fVlgJEXWDxPGIlb8RmafSd6S7QhsaAHlUr U3zD4bGGHX7KBoTuR0Y72wsshwH+Cx77a74u7k9AOW1JvXGdqIIHwRdgDfihhIWKUhqH mZjmqqejxU/qDSihZb143f8z2tBVvXq+NJ7dnXcB6GGoQ+fIcFf8IDQinfKH48cXGmhE LRX8AvyebJLKOvPAY5lR9X1W3mrsDbS8HGvow0NIGQe8kC+Mnp7fCgnZYIUYZ8rW5sTw hYXkOgKmTyOorzPeQsDg6u2YFlKMyYJ9sRlbv5hiMmoeb9rQ3CvMPP1qVQ1HhfB7ACdN TBqw== X-Gm-Message-State: AIVw112iRFVvukkxbpN/mJX2Ygyy1ANFY++wlJqRr8WD6xb4KQX9Q9vG LhGuBYTgR6XoHWtob6cCMHzZWmOY0TvuirNoyg== X-Received: by 10.107.168.164 with SMTP id e36mr20251552ioj.40.1500330301439; Mon, 17 Jul 2017 15:25:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.180.199 with HTTP; Mon, 17 Jul 2017 15:24:40 -0700 (PDT) In-Reply-To: <596D2D2D.5080406@foobar.org> References: <596CF817.8040900@foobar.org> <596D2D2D.5080406@foobar.org> From: Lorenzo Colitti Date: Tue, 18 Jul 2017 00:24:40 +0200 Message-ID: To: Nick Hilliard Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org Chairs" Content-Type: multipart/alternative; boundary="001a11426e7caa754105548ade68" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 22:25:05 -0000 --001a11426e7caa754105548ade68 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 17, 2017 at 11:33 PM, Nick Hilliard wrote: > [v6ops-chairs explicitly cc:'d because there is a serious WG consensus > problem here which has materially affected the outcome of an IETF process] > > Lorenzo Colitti wrote: > > the text you mention was not "slipped in" by mistake, it was the outcome > > of WG discussion. > > No, it categorically was not. [...] Despite this, you completely ignored the feedback from the working group > about DHCPv6 IA_NA, If you read the discussion threads carefully, you'll see that the main issue being raised in that version of the draft (mostly by Philip and Gert, as I recall) was not "IA_NA should be used", but "DHCPv6 PD is not the only way to assign a prefix, and not a widely adopted way". -05 addressed that issue by de-emphasizing DHCPv6 PD. As I read it, at the time there was pretty broad agreement at the time that IA_NA was not a good choice both because it is limited in terms of the number of total addresses that can be assigned and because it requires that the client send explicit requests, which has the problems listed in section 4. There was no mention of the fact that a change was made which > effectively ignored the outcome of the discussion. 12 days later > without any comment about this change, the document went to IETF LC. > > You ignored the WG, didn't point it out, and despite extensive previous > objections, unfortunately the WG didn't notice. But there was no change on this topic. No version of the draft since -01 ever recommended IA_NA in the recommendations section. You assert that -05 made a change in this area, but there was no substantive change. Here's the text in question. -04 says: If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses (e.g. 32) would accommodate current clients but sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications. and -05 says: Due to the drawbacks imposed by requiring explicit requests for address space (see section Section 4), 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. The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide multiple addresses when the host connects (e.g. the approximately 30 addresses that can fit into a single packet) would accommodate current clients, but sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications. In both cases, the recommendation is that if a network uses DHCPv6 as the only way to provide address space, it should assign a /64 to every host. --001a11426e7caa754105548ade68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 17, 2017 at 11:33 PM, Nick Hilliard <nick@foobar.org> wrote:
[v6ops-chairs= explicitly cc:'d because there is a serious WG consensus
problem here which has materially affected the outcome of an IETF process]<= br>
Lorenzo Colitti wrote:
> the text you mention was not "slipped in" by mistake, it was= the outcome
> of WG discussion.

No, it categorically was not.=C2=A0
[...]=C2=A0
Despite this, you completely ignored the feedback from the working group about DHCPv6 IA_NA,

If you read the discuss= ion threads carefully, you'll see that the main issue being raised in t= hat version of the draft (mostly by Philip and Gert, as I recall) was not &= quot;IA_NA should be used", but "DHCPv6 PD is not the only way to= assign a prefix, and not a widely adopted way". -05 addressed that is= sue by de-emphasizing DHCPv6 PD. As I read it, at the time there was pretty= broad agreement at the time that IA_NA was not a good choice both because = it is limited in terms of the number of total addresses that can be assigne= d and because it requires that the client send explicit requests, which has= the problems listed in section 4.

There was no mention of the fact that a c= hange was made which
effectively ignored the outcome of the discussion.=C2=A0 12 days later
without any comment about this change, the document went to IETF LC.

You ignored the WG, didn't point it out, and despite extensive previous=
objections, unfortunately the WG didn't notice.

But there was no change on this topic. No version of the draft sin= ce -01 ever recommended IA_NA in the recommendations section. You assert th= at -05 made a change in this area, but there was no substantive change. Her= e's the text in question. -04 says:

= =C2=A0 =C2=A0If the network requires explicit requests
=C2=A0= =C2=A0for address space (e.g., if it requires DHCPv6 to connect), it is
=C2=A0 =C2=A0RECOMMENDED that the network assign a /64 prefix to ev= ery host (e.g.,
=C2=A0 =C2=A0via DHCPv6 PD).=C2=A0 Using DHCPv6 I= A_NA or IA_TA to request a sufficient
=C2=A0 =C2=A0number of addr= esses (e.g. 32) would accommodate current clients but
=C2=A0 =C2= =A0sets a limit on the number of addresses available to hosts when they
=C2=A0 =C2=A0attach and would limit the development of future applic= ations.

and -05 says:
<= br>
=C2=A0 =C2=A0Due to the drawbacks imposed by requiring e= xplicit requests for
=C2=A0 =C2=A0address space (see section = Section 4), it is RECOMMENDED that the
=C2=A0 =C2=A0network give = the host the ability to use new addresses without
=C2=A0 =C2=A0re= quiring explicit requests.=C2=A0 This can be achieved either by allowing
=C2=A0 =C2=A0the host to form new addresses autonomously (e.g., via= SLAAC), or by
=C2=A0 =C2=A0providing the host with a dedicated /= 64 prefix.=C2=A0 The prefix MAY be
=C2=A0 =C2=A0provided using DH= CPv6 PD, SLAAC with per-device VLANs, or any other
=C2=A0 =C2=A0m= eans.

=C2=A0 =C2=A0Using stateful address assignme= nt (DHCPv6 IA_NA or IA_TA) to provide
=C2=A0 =C2=A0multiple addre= sses when the host connects (e.g. the approximately 30
=C2=A0 =C2= =A0addresses that can fit into a single packet) would accommodate
=C2=A0 =C2=A0current clients, but sets a limit on the number of addresses<= /div>
=C2=A0 =C2=A0available to hosts when they attach and would limit = the development
=C2=A0 =C2=A0of future applications.
<= div>
In both cases, the recommendation is that if a network u= ses DHCPv6 as the only way to provide address space, it should assign a /64= to every host.
--001a11426e7caa754105548ade68-- From nobody Mon Jul 17 16:57:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3FA131CF5 for ; Mon, 17 Jul 2017 16:57: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, 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 itTDPXg9ecIw for ; Mon, 17 Jul 2017 16:57:08 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 3061B129ACD for ; Mon, 17 Jul 2017 16:57:08 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id v190so2566998pgv.2 for ; Mon, 17 Jul 2017 16:57: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=KzkfNssVvw8oI3wrv4xFSlGs1Y6SE5JNHmLjkbQDjbs=; b=Siaq9Zcv/8e4b6196cg4N8KF8HkjRProKu0S+w2yqRwNN9O+ZZHijgevqD0pTDrhRz vXkOLojlOoR4qb1AAFMWPVy1m4js8L1B7uhJAiYckPsk21tvp7CiROWLxUto8613FsEz F4HMe4CjFxtKdU+mWn1wwWi4F2KSr4FS6EvcjXeQfIjQPCjm8EPH4lk0kY6fGxr4oLKR HFUqPTXReqwHutt0JCFLShRLnK900EqC+014ddZ1p6engqQ5/fkTOGXwbXz+J2TtpnwY b9+qNPLfdlDrs5IMYwgFyvAzEpaYNJgp/m2yeJkg48vzvNac0iIh5xwjOQ226ucm2ae0 +Wzg== 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=KzkfNssVvw8oI3wrv4xFSlGs1Y6SE5JNHmLjkbQDjbs=; b=eCSgiizUOzC8L5jwbaoajzQ28kvmxw5n/8/BzJVzewGfXQhAV40D3GM7YgUCEURmVh AcjkuNzAe54RpEEd96bKNZZtAPxBgpZpga6ffzO2+YS9WmKEngJVrR32vYtAgaH/IK3B Ypjw2+CgtZrbPy2lT+ELW1knmccHf1f/GMKs8I+yvOiQsIPQpu4GaGizes01YNWNJ94d WYZPCDu9lwST3+0Cy/Yv4ov0YJr1Q+KgeIo0OzsV5bwLjB3r6KA+BpjAdJ6aFSltkhPF w7kyT/TgcSUQFfcGzelDlxMw3RvfZXVJYonLEOybnPpo6WcTxHa6Q2VOAsppWnnVROGn RyvQ== X-Gm-Message-State: AIVw110STZ4pRV+j8lsmmuQQvY+I2oysnKWgmgnjpkKlHzEIKIbWrw62 sTnvP2/J2C+iKYcl X-Received: by 10.99.122.28 with SMTP id v28mr132727pgc.98.1500335827574; Mon, 17 Jul 2017 16:57:07 -0700 (PDT) Received: from [130.216.38.122] (sc-cs-316965.cs.auckland.ac.nz. [130.216.38.122]) by smtp.gmail.com with ESMTPSA id y6sm604783pgq.41.2017.07.17.16.57.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 16:57:07 -0700 (PDT) To: IPv6 Operations References: <596CF817.8040900@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8c429167-78b7-ac6d-e650-ca69cf2595c4@gmail.com> Date: Tue, 18 Jul 2017 11:57:04 +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: <596CF817.8040900@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 23:57:09 -0000 On 18/07/2017 05:47, Nick Hilliard wrote: > draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID. > > It has recently been claimed that IETF best current practice is that > DHCPv6 is not recommended due to the recommendations section in > RFC7934/BCP204. I'm a bit confused. That section says >> The prefix MAY be provided >> using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. >> >> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide >> multiple addresses when the host connects (e.g., the approximately 30 >> addresses that can fit into a single packet) would accommodate >> current clients... I am rather unclear how that could be understood to mean that DHCPv6 is NOT RECOMMENDED (which is very different from not saying RECOMMENDED). Brian From nobody Mon Jul 17 17:59:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDEE1205F0 for ; Mon, 17 Jul 2017 17:59:47 -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 ZG_rDe3zX57P for ; Mon, 17 Jul 2017 17:59:46 -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 28100131B6B for ; Mon, 17 Jul 2017 17:59:46 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 64so6684483uae.2 for ; Mon, 17 Jul 2017 17:59:46 -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=Y70B4+cfkl2h3y0ljV9lGgdiIVeXYKSp2+COkndyCW0=; b=D3A7uCNoRTlSpbMh2btTQ3xGbSuR4xDwVNLq0wlX12tO4ktraQW2Lmmu6K2xPE6GXq sVF7VMKJ5VD+YnY8+d17r0t4tgWbpjJgWji/YGCNcnWz18tdWpZRLx4AdhdTPB7z/VqC KI4o/R7AIDEbrxzCZIOUjy00ONXNxLQUjbnn7oP7WcgcsvR1r5zyRGBKrXeIwko52k5r 725AWv9JDiBuYxsEY3UjT1crvtO+SXXJR2DulYo7NhZE0qqaug4JLXZeeFSYgl2r4spf Jod2xDWajC2h6dHo+5P93RGtyF09HJMzRAO4bMT2Hy8fh7Gbfcfhq8jjJhOke0hInCsN KwxA== 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=Y70B4+cfkl2h3y0ljV9lGgdiIVeXYKSp2+COkndyCW0=; b=lXZ7nN0+GsMCudY6PmTl1dT6kku9Rarpgs4z1ZQlI9VhBuGDlyAtYuWddJaHeR+VRg qoItDU0g+PTJOdZ+xKcGlLXjkEhFvquw9S9IeRxLxuZOuXt5jJ4JzNQoL2k1ZbwhNj0n 1PDzne1pNBCkQDkqqxnPpseBgVUstbikXJ/Y11yNjAamYV35SgoO6JYzuy4CO3eHtY9L Zm49otcTjrItkJXt6Mt0vAhGQeqy3e5ZQkB+H06N1G+YbWWB4aXz/aS/zt9johvkutxF YXRqq0p4e0SX/KPdwrE5XZIF+3CzcLmVYcQn7kdPrp5cbnTPxVBYMnYYnKUbSTRWa+Ox /hLg== X-Gm-Message-State: AIVw112CX07ktAqb2ZaIbU0VP47wZSwteCI0Q6d1VcyL/gBiQ9fx2yPW dZjst2FGRl4RlH8x96AX6XPZBxi1BpkU X-Received: by 10.31.99.5 with SMTP id x5mr162690vkb.62.1500339585168; Mon, 17 Jul 2017 17:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Mon, 17 Jul 2017 17:59:14 -0700 (PDT) In-Reply-To: <596CF817.8040900@foobar.org> References: <596CF817.8040900@foobar.org> From: Mark Smith Date: Tue, 18 Jul 2017 10:59:14 +1000 Message-ID: To: Nick Hilliard Cc: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 00:59:47 -0000 Hi, I don't remember it being a mistake. The fundamental intention and theme of the BCP is to ensure that hosts can have enough addresses for whatever they and their applications require, to ensure that lack of addresses doesn't become a constraint hosts and applications have to work around. An on-demand, permission based model for individual addresses doesn't prevent that constraint. The alternative is continuing to treat addresses as though they are a scarce resource and therefore assignment needs to be controlled at an individual address level. Fundamentally, we don't want hosts and application developers to have to ask for permission from the network to innovate, nor have the network impose artificial constraints on innovation. Artificial address scarcity is following the traditional telephone network scarcity model. (See David Isenberg's "Rise of the Stupid Network") "The IPv6 self-selection addressing model does not necessarily suit the deployment requirements for many types of ipv6 networks, including enterprise, provider hosting, and various access network protocols (e.g. docsis / gpon / ipoe); " What are the specific deployment requirements? If it is the common "address use auditing for security purposes", that doesn't survive analysis. You can't force a malicious client to use DHCPv6 for its addressing. A malicious client can use statically configured addresses from within one of the link prefixes and the DHCPv6 server won't have any record of it. A set of malicious clients can use link-local addresses for traffic between themselves or bring up a new prefix on the link shared between themselves via static configuration and the DHCPv6 server won't have any record of it. The RFC mentions ND cache contents recording for auditing purposes, which is going to be much more effective, because it isn't dependent on the address configuration method (i.e., currently stateful DHCPv6, SLAAC, static configuration, and would accommodate any future ones if they come into being.) Regards, Mark. From nobody Tue Jul 18 00:07:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0012FEE2 for ; Tue, 18 Jul 2017 00:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_03_06=3.027, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, WEIRD_PORT=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 j-iizMnccg-p for ; Tue, 18 Jul 2017 00:07:06 -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 7497312EC0D for ; Tue, 18 Jul 2017 00:07:06 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob14.registeredsite.com (8.14.4/8.14.4) with ESMTP id v6I773od023586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Jul 2017 03:07:03 -0400 Received: (qmail 18571 invoked by uid 0); 18 Jul 2017 07:07:03 -0000 X-TCPREMOTEIP: 31.133.140.245 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.140.245?) (lee@asgard.org@31.133.140.245) by 0 with ESMTPA; 18 Jul 2017 07:07:02 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 18 Jul 2017 09:06:56 -0400 From: Lee Howard To: Message-ID: Thread-Topic: note takers and Jabber scribe needed Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3583213623_16057061" Archived-At: Subject: [v6ops] note takers and Jabber scribe needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:07: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_3583213623_16057061 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Before we can start today, we need note takers and a Jabber scribe. Please consider volunteering. Etherpad so minute takers can collaborate: http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-v6ops?useMonospaceFont=3D= t rue Jabber room: v6ops@jabber.ietf.og Also, in case you haven=E2=80=99t noticed the updated Note Well, which advises yo= u of the intellectual property status of your participation: https://www.ietf.org/about/note-well.html Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to= : =E2=80=A2The IETF plenary session =E2=80=A2The IESG, or any member thereof on behalf of the IESG =E2=80=A2Any IETF mailing list, including the IETF list itself, any working group= or design team list, or any other list functioning under IETF auspices =E2=80=A2Any IETF working group or portion thereof =E2=80=A2Any Birds of a Feather (BOF) session =E2=80=A2The IAB or any member thereof on behalf of the IAB =E2=80=A2The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 8179 . Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 8179 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. Lee --B_3583213623_16057061 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Before we can start today, we nee= d note takers and a Jabber scribe. Please consider volunteering.

Jabber room: v6ops@jabber.ietf.og=


Also, in c= ase you haven’t noticed the updated Note Well, which advises you of th= e intellectual property status of your participation:

Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or= RFC and any statement made within the context of an IETF activity is considered= an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time= or place, which are addressed to:

•The IETF= plenary session
•The IESG= , or any member thereof on behalf of the IESG
•Any IETF= mailing list, including the IETF list itself, any working group or design team list, or any other l= ist functioning under IETF auspices
•Any IETF= working group or portion thereof
•Any Bird= s of a Feather (BOF) session
•The IAB = or any member thereof on behalf of the IAB
•The RFC = Editor or the Internet-Drafts function

All IETF Contributions are sub= ject to the rules of RFC 5378RFC 8179.=

Statements made outside of an = IETF session, mailing list or other function, that are clearly not intended to b= e input to an IETF activity, group or function, are not IETF Contributions in= the context of this notice.  Please consult RFC 5378 and RFC 8179 for details.

A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements.

A participant in any IETF acti= vity acknowledges that written, audio and video records of meetings may be made = and may be available to the public.



=

Lee



--B_3583213623_16057061-- From nobody Tue Jul 18 00:44:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18540131691 for ; Tue, 18 Jul 2017 00:44:35 -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 26b95pAvtU-d for ; Tue, 18 Jul 2017 00:44:33 -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 0E1E812ECF0 for ; Tue, 18 Jul 2017 00:44:33 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id a10so16580875wrd.0 for ; Tue, 18 Jul 2017 00:44:32 -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=MnCheOox00/TRk8er63W+00AkEahLqjWYst8r59HoEM=; b=KWxuiehIDwB/4n2XWoy9rsB/74+kGm8zEHg1tv/CGir2Zb5LZeW8jggcpL3AVWD0gS uoZiKnZwcGiuTpLEijXpHm+bEAY7eZpSaVJIIbkx/sFtexC1anih3PNCU1pOxTBW45/Y PFco6xWhkGgq64D5b+7a947RQydJbg7VSoOJ9HtGuAEv0jZ3t+p0P9bY3fuCK8+NH19B 4Lwr9l6IazS7noa1aUjETfYaH7oPLtLPMpMsBB+xrK6+eSGkPXLzqbMwKSJXpfzEPp+q Yi4mo4EIiw+GTgtP4ii/oTQsfDfO1WWjI7pTMJctNgDv1OvDXw3qkVaHSSFdHWC5cBV/ OvPQ== 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=MnCheOox00/TRk8er63W+00AkEahLqjWYst8r59HoEM=; b=jzZN7tvxV5XuvfDGq7NfDiUQYiehXDDE61Ur494qxqL+bW0zed01B7VP8un6s9xPW7 Trc+3hePQsW4oM3E7UXpfjJOnfqiJwXbbu3xn2kttxJ9J/4HP5bKGmG+WYvyfw1KdApL gxs2Jc8eNZaBnvTPd+3VRA18uTdeDpqVO3ebZ6EIIQvF779lBo57JAFhhqov5LNqfOmN NhRuRwVhqu+VgQf2Z5eeMpjcu0lUfyvboo1YzdA2l8EnLFJXtoe0WvcBLe3GYrLlgCKJ 9r4I0/b9FiHzb0Dp7nUiRVPxfGyev69lJTkJnWaYe2qeZvQJr4TGW6HoX+ux3SoK8dt6 9KSg== X-Gm-Message-State: AIVw112r1gOzsVaZAanpHpDJHgvkOzZ6GMBbfKFIbB1Q1hr0RKctXLnn z0ZXx5NNILwTR/aBXoIwvQ== X-Received: by 10.223.172.183 with SMTP id o52mr247889wrc.1.1500363871136; Tue, 18 Jul 2017 00:44:31 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:55e6:3e2c:1b59:16a0? ([2001:67c:1232:144:55e6:3e2c:1b59:16a0]) by smtp.gmail.com with ESMTPSA id 199sm1947629wmu.0.2017.07.18.00.44.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 00:44:30 -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\)) Date: Tue, 18 Jul 2017 00:44:29 -0700 References: <596CF817.8040900@foobar.org> To: IPv6 Operations In-Reply-To: <596CF817.8040900@foobar.org> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:44:35 -0000 On Jul 17, 2017, at 10:47, Nick Hilliard wrote: > internet-drafts@ietf.org wrote: >> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt >> has been successfully submitted by Nick Hilliard and posted to the >> IETF repository. I have reviewed this document. Its reasoning for proposing an update to = RFC 7934 is unsound. One relevant excerpt from =C2=A71 Introduction = should suffice to explain. The text following the excerpt is premised = entirely on the bad reasoning shown below, and it can be ignored = accordingly. >>> [=E2=80=A6] The recommendations in Section 8 of this document = included the text: >>>=20 >>> 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. >>>=20 >>> This text could be interpreted as recommending that IPv6 networks >>> should not use not DHCPv6 [RFC3736], which provides new addresses = in >>> response to explicit requests. [=E2=80=A6] That would be a gross misinterpretation of the recommendation. The = recommendation in RFC 7934 is clearly written and does not need updating = to provide more clarity about the implications for usage of DHCPv6. The = clear implication of the recommendation is *NOT* that networks SHOULD = NOT provide DHCPv6 services. The clear implication of the recommendation = is that networks SHOULD NOT require hosts to use DHCPv6 with IA_NA/IA_TA = to obtain all their addresses. >>>=20 >>> [=E2=80=A6] This interpretation is = based on the >>> fact that a host which uses DHCPv6 IA_NA or IA_TA cannot use new >>> addresses without requesting them from a DHCPv6 server on the >>> network. That=E2=80=99s not a fact. In fact. Factually speaking, a host which = uses DHCPv6 IA_NA or IA_TA absolutely MAY use new addresses without = requesting them from a DHCPv6 server on the networks. On a related note, = see how the draft makes another leap of unsound reasoning in =C2=A73 = Rationale. >>> [=E2=80=A6] as it formally recommends = that new >>> addresses should be assigned without explicit requests. This >>> implicitly excludes all address assignment mechanisms, including >>> DHCPv6, which are not handled by the host itself. A network MAY also provide a Prefix Information Option with A=3D1 for = the host to use SLAAC to configure them. There are additional ways for = networks to configure hosts with aggregated sets of addresses, e.g. = obtaining prefixs with DHCPv6 Prefix Delegation, e.g. resolving prefixes = with a Distributed Node Consensus Protocol [RFC 7787], et cetera. > Right now, the most prudent course of action would be to roll back the > change until a proper debate has been had. We invite WG comments on > this doc. For a proper debate to commence, the draft should be rewritten so that = it=E2=80=99s reasoning about what RFC 7934 actually implies for networks = using DHCPv6 is fundamentally sound. I=E2=80=99m not sure what such a = draft would say, however, so I can=E2=80=99t comment about what the = authors might be hoping to discuss. --james woodyatt From nobody Tue Jul 18 00:45:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894D9131DA6 for ; Tue, 18 Jul 2017 00:45:33 -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, 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=fugue-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 GFvcCSZDMMgu for ; Tue, 18 Jul 2017 00:45:32 -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 49592131DA5 for ; Tue, 18 Jul 2017 00:45:31 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q85so7509012pfq.1 for ; Tue, 18 Jul 2017 00:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SPVaS9UKPTBYCSA4AQ/7h6x1U1J2nGTHZOpWjYibFUk=; b=fg/mQfZ5/12iEw2ZSp/BBKIBT5js+fGR1Pl+sTLV6Ky1IM6bR+Y2AvwBLGdOxzsl/K GRUw4WSv4zNVwgRNUb9zBtH7fPm/WRLvPwtVfAKnADmigKNW0pSJ9MejfcqP+L6tI5aR 1dE9WT4x01BLAnto6kVwjM5vPfe/yGvE/q2Fe+WfQSLiyYA8i0D+LQbY+iYJjlbXT3P+ 2FPkoIxDMDf55V855hbigT9Ag3csvv0IKXrpOq5wjpYFbQiVZoW1K3xuh+5D6I6I3yKO 0mWH7SB+B2X34PUJqOMLjPX7UtultYsjrqnIQ5JUy8tEBID3tW5e5SquCzPcV0fWi6fE fYEg== 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=SPVaS9UKPTBYCSA4AQ/7h6x1U1J2nGTHZOpWjYibFUk=; b=W35zphZufJtTLaEp61kHVWoMf5chlrYBBFGZHlHDYWm4UDLXJJO2/OxKyoGiuETXLH MCaHxjOGCZAlrq8R0QgOXZzCxgQ5j+nTYgWUyaIOPJv0F3qWf0Zk1pZTp/i4G2OL9SNM jtrg/Cppt3R9WM+g7mQsPznOHizAgo9Gic9ut2vRQKfSe+z5KMTu1uHcyURJOjVKGbTB W08p3Ppb3U//yIffWPQHSJzI7vt7KymcbrU31iQtN2je3n6wGLe2kBd7VtIWAgi419hB ukLOuZCEGWVHBfCZIjYMJC9A4cZR0I+moYwazpII8DRQ0bs7XkYeqweyIZ86JFEHlTau p/XQ== X-Gm-Message-State: AIVw110Z73dZMqZFefBYHcwNjQaLVI/aY3pN5JHBoOGiLf0ENCNdfTTt 47/yllES3eIRRs+iLsV5hwPuDdrXtCUm X-Received: by 10.84.231.16 with SMTP id f16mr310801plk.131.1500363930773; Tue, 18 Jul 2017 00:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 00:44:50 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Ted Lemon Date: Tue, 18 Jul 2017 09:44:50 +0200 Message-ID: To: Mark Smith Cc: Nick Hilliard , IPv6 Operations Content-Type: multipart/alternative; boundary="f4030436018220c02b055492b38a" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:45:33 -0000 --f4030436018220c02b055492b38a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, a couple of reminders here. First, the text in the RFC is explicitly recommending the use of IA_PD as the _only_ solution to delegating prefixes. Second, this is an RFC, and the document that proposes a way to delegate prefixes without DHCP is a draft, not an RFC. That document is not mentioned in the RFC. So to suggest that this document says that IETF consensus is that DHCP is NOT RECOMMENDED is simply incorrect.=E2=80=8B --f4030436018220c02b055492b38a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, a couple of reminders here.=C2=A0 First, the text in= the RFC is explicitly recommending the use of IA_PD as the _only_ solution= to delegating prefixes. =C2=A0 Second, this is an RFC, and the document th= at proposes a way to delegate prefixes without DHCP is a draft, not an RFC.= =C2=A0 That document is not mentioned in the RFC. =C2=A0 So to suggest tha= t this document says that IETF consensus is that DHCP is NOT RECOMMENDED is= simply incorrect.=E2=80=8B
--f4030436018220c02b055492b38a-- From nobody Tue Jul 18 00:48:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AECF131DA5 for ; Tue, 18 Jul 2017 00:48: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 jgKnFEtxspqC for ; Tue, 18 Jul 2017 00:48: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 9E206131A4F for ; Tue, 18 Jul 2017 00:48:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dXNEk-0000EGC; Tue, 18 Jul 2017 09:48:06 +0200 Message-Id: To: v6ops@ietf.org Cc: Tore Anderson From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es> <20170717152345.GV45648@Space.Net> <29616c41-49d5-a960-8048-9441284fd171@fud.no> In-reply-to: Your message of "Mon, 17 Jul 2017 23:23:59 +0200 ." <29616c41-49d5-a960-8048-9441284fd171@fud.no> Date: Tue, 18 Jul 2017 09:48:06 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 support in RIPE Atlas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:48:21 -0000 >> you don't want to know how much I had to change to the Atlas probes >> and related infrastructure to get them to support NAT64/DNS64. >I do want to know, you certainly are tickling my curiosity here. Is this >about DNSSEC, did you implement a 464XLAT CLAT, or something else >entirely? If it cannot be summarised in an e-mail, perhaps write a RIPE >Labs article about the subject? > >(I changed the subject, as to the best of my knowledge the Atlas probes >have their 802.11 radios disabled, and as such are very unlikely to ever >be connected to a conference wireless network.) Let me start with the last part. Sometime ago we start working on support for measuring eduroam. So there now exists firmware that can enable the wifi radio and connect to a wireless network. Note that by default, probes have firmware that does not contain any wireless device drivers, etc. We are working on a way for a probe host to opt in. At the moment we have manually allowed wifi firmware for some probes in educational institutions. The only SSID we currently envision is eduroam. Though of course the community can ask for others as well. With this wifi capability it is easy to play around and connect a 'dev probe' to the NAT64 network at a RIPE meeting. So what goes wrong. Currently unsolved is that measurements are either v4 or v6. So if you measure a v4-only target with a v4 measurement then probes on a NAT64 with never measure anything. You need a v6 measurement for that. Then there was the problem that the system tries to be helpful. If you create a v6 measurement and the target doesn't have a v6 address then the measurement is not scheduled. Fortunately other people needed an override for that check as well. The next thing is that the libraries used by the probe assume that DNS resolvers are listed in /etc/resolv.conf. This is not entirely correct if you have both a wired and wireless interface, but by and large it works. Of course this completely fails when the wired interface is dual stack and the wireless interface uses NAT64/DNS64. Finally, traceroute output is extremely confusing and/or broken. I still have to spend some time with some packets I captured during the RIPE meeting. The reason is that IPv4 error ICMPs have to be converted to IPv6 error IMCPs. But of course IPv4 error ICMPs do not adhere to all the requirements of IPv6 error ICMPs. So this causes a protocol violation. And breaks some assumptions in the Atlas traceroute code. I have no intent to solve that. From nobody Tue Jul 18 00:58:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9609A12ECC0 for ; Tue, 18 Jul 2017 00:58: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 ZUgf33YrLJI1 for ; Tue, 18 Jul 2017 00:58:33 -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 B135112ECF0 for ; Tue, 18 Jul 2017 00:58:32 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id w4so16797694wrb.2 for ; Tue, 18 Jul 2017 00:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7H9mVnGWGhh5WjhOMBVa1q6eyCGCXKof9yHMtlZWrNQ=; b=GeXCgHIcVhk0FnY3ECfZnzoJn+4fMwSQdRqrgO7dS/IMThf1TUlrvDcm/OkvL9DCqp 5l7ftj5La3U9DRL09mJa4mnOLBis6jVHmDRtBnkbLwx7Ua0dda9bqoPYz0o0BtwYBuPg Rm6LTzpaMLug+y6qLdCi4XYIHsKTsRo5yLc3G+4Ed6aNC5Z3f3JrYoPljRr1KWUWle59 aEZQW+mfVP4/67g/XxMbSk8yImxk2xez/KZNgbC10EvJcCuXfh/JbHpe0RrSm/c68qVI Np8XlIFL5YG7oKyKF0LQbRLqnN88YWRgr20zpVGTEqi8rtRHAWcAjKdzM/ML7Uj7qRis aHDw== 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:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7H9mVnGWGhh5WjhOMBVa1q6eyCGCXKof9yHMtlZWrNQ=; b=WD4QHIZsm5uFZZS0424GtT3tKRCXtAV0MBpxppzAoGxyprb4dFQ4r2pClpLwZX8HoQ wwxp4mdicEvSbSwHfw5CBxYN6K6zPmkj00CUjmJD+T0kN4jbJXfp0cTQ/3ZFx0lMzPw1 vn6F7Y+DLuIWvFiCFsaDGQMHZ23Mmp+44wWImfQerObmuNOYhcFK8HYTpFc5JYj8Va34 PHXga9U0AZlM/i1pmWUV4kqAPFarNuTStDad5DcE8305RjydUZ9N4nNN+slDI6lUrw+d olyeh8VXEaniP5buvIli8Jak5hqyZBSzkn/7X5KnZ2kQVGkHcz14rdvU5BUF6oB+Bikz gogQ== X-Gm-Message-State: AIVw113zVdlkeKKZhj2u9oCYU8AtgJSWC3jmqkdfbT3zkYHZgqpiZn+A +HusrPVAlNsX7jMN X-Received: by 10.28.5.137 with SMTP id 131mr717312wmf.103.1500364710962; Tue, 18 Jul 2017 00:58:30 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:a0e7:c3d8:b7ea:e612? ([2001:67c:370:128:a0e7:c3d8:b7ea:e612]) by smtp.gmail.com with ESMTPSA id g83sm9394722wmf.29.2017.07.18.00.58.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 00:58:30 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: Ross Chandler Cc: v6ops@ietf.org References: <596CF817.8040900@foobar.org> <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> <4171F21D-A063-4173-8B9D-634DC360D891@eircom.net> Message-ID: <909a24c0-ea34-52b2-a0d4-73a7baef7a61@gmail.com> Date: Tue, 18 Jul 2017 09:58:29 +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: <4171F21D-A063-4173-8B9D-634DC360D891@eircom.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:58:35 -0000 Le 17/07/2017 à 23:21, Ross Chandler a écrit : > > >> On 17 Jul 2017, at 21:58, Alexandre Petrescu >> wrote: >> >> There is something wrong with that draft: it only allows for 64. >> Why? DHCPv6-PD can delegate other plengths, like 65. > > I agree that is a deficiency. > >>> https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt >>> >>> >>> >>> Introduces an eXclusive flag to optimize RA for nodes that are >>> exclusive receivers of all traffic to the prefix. >> >> This is another way of calling RA “Prefix Delegation". > > Fair enough. > >> There are other drafts doing Prefix Delegation with RA, have you >> considered them? > > No, what are they? The above one caught my eye because of the > employer of one of the authors. draft-kaiser-nd-pd-00 "Prefix Delegation extension to Neighbor Discovery protocol" and the year 2002 drafts it cites like draft-lutchann-ipv6-delegate-option-00.txt and draft-haberman-ipngwg-auto-prefix-02.txt During these discussions of these draft it was often said that DHCPv6-PD is the way to go, so let's go that way. (this suggestion is independent of the 3GPP link discussion). Alex > >>>> uthors of RFC3315, and I agree with this view. >>> Given the above two drafts DHCPv6-PD to hosts has an uphill >>> struggle to ever achieve widespread deployment. >> >> I don’t think so. > > You’re more optimistic than me then. > >> I think DHCPv6-PD should be trialled at IETF WiFi and then we’ll >> see. > > > Yes, it should. > > Ross > From nobody Tue Jul 18 01:10:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845E712ECF0 for ; Tue, 18 Jul 2017 01:10:12 -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 FUlH7AgcfHm6 for ; Tue, 18 Jul 2017 01:10:10 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 BD94012ECC0 for ; Tue, 18 Jul 2017 01:10:10 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h199so5239367ith.0 for ; Tue, 18 Jul 2017 01:10: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=RaaD+RCgDtBIe7JxUkzE1baRdSGS4EynWfAULooAKY4=; b=pnJoxCEYoxK2cRoy7BqmmuTqcDY93hKrYBgQO476cdeKLD2tfOEBQWf2cpHKgfTl0d mOBjLg59wIiwaE448m3sJJLhGSC/35aWcpN1lbkwRNHB2mK07eBYDsyn8dkHkL2g4gpg EzvWrB3qvXbvX1SKSNAFnrBhg1bzIkeuWOgfjfurXqZAaDV0viLSoOIFhFVM9wuu9U16 YvwCWa2xsA3zfe0hXXH2MKBxjmrClvxwoD8GlG1+gmZCDwtN5rRZezwPeCi67wLRMPrN kX1k125LRCukrx+9oi0ZbCy8cVYadafsVEQgd0fYPvaHIaxv7E/qGkn37ZDCw1wv7o0k VvfA== 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=RaaD+RCgDtBIe7JxUkzE1baRdSGS4EynWfAULooAKY4=; b=Qf+hqA5JNt/2qYUHQDJ937yYFBeIGewVJo9/NivwE5QVbf9Y0mvGCQpmtBRybsl3W4 0fO9RAwVkvJqAKvjJJcOKfxTriEwec7VOCSA5CSu8BMIV9hcQxWp4JqaApqfxD1Cw/iH B43bgSL5p0YXncXLe2InwZ3FnfeypNRAMkbes5/0i0ok+ooCq+3y2E1bzWZeGM8y2ksR wE184W9EnknU1C6yy9j5iXMjr0XP8yUO8vo6vlqSjtgeIWyXqYG3EHqUolnWcfHjAzMF 0oTUA3h8JrOwPz58N5cvr+RCAlMysYDWYkRL4llpo/nBqVdr1YsViC6x+Aj0wxdpBQeE w03g== X-Gm-Message-State: AIVw111i6UqlOCTuCFMJTQEZpa7IYqpUV7MoN/Py0mdoEbD7YKKBb293 kQEIglhM1rn9n+hcsu9Aiha5CC5qyuEd X-Received: by 10.36.175.1 with SMTP id t1mr1286523ite.95.1500365409825; Tue, 18 Jul 2017 01:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.164 with HTTP; Tue, 18 Jul 2017 01:09:49 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Lorenzo Colitti Date: Tue, 18 Jul 2017 10:09:49 +0200 Message-ID: To: Ted Lemon Cc: Mark Smith , IPv6 Operations Content-Type: multipart/alternative; boundary="f403045dc13649ccc40554930bbb" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:10:13 -0000 --f403045dc13649ccc40554930bbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct, the RFC does not say that DHCPv6 is NOT RECOMMENDED. It does say that running a network for general purpose hosts that only provides addresses via DHCPv6 IA_NA or IA_TA is NOT RECOMMENDED. More precisely: if a network only provides addressing using DHCPv6, then it should use a DHCPv6 mechanism that provides a /64 to each host. Currently the only such mechanism is DHCPv6 PD. Of course, it can use other non-DHCPv6 mechanisms as well, as long as they either allow forming addresses on demand and/or they provide a /64 to every device. On Tue, Jul 18, 2017 at 9:44 AM, Ted Lemon wrote: > Yeah, a couple of reminders here. First, the text in the RFC is > explicitly recommending the use of IA_PD as the _only_ solution to > delegating prefixes. Second, this is an RFC, and the document that > proposes a way to delegate prefixes without DHCP is a draft, not an RFC. > That document is not mentioned in the RFC. So to suggest that this > document says that IETF consensus is that DHCP is NOT RECOMMENDED is simp= ly > incorrect.=E2=80=8B > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --f403045dc13649ccc40554930bbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct, the RFC does not say that DHCPv6 is NOT RECOMMEND= ED.

It does say that running a network for general purpo= se hosts that only provides addresses via DHCPv6 IA_NA or IA_TA is NOT RECO= MMENDED. More precisely: if a network only provides addressing using DHCPv6= , then it should use a DHCPv6 mechanism that provides a /64 to each host. C= urrently the only such mechanism is DHCPv6 PD.

Of = course, it can use other non-DHCPv6 mechanisms as well, as long as they eit= her allow forming addresses on demand and/or they provide a /64 to every de= vice.

On Tue, = Jul 18, 2017 at 9:44 AM, Ted Lemon <mellon@fugue.com> wrote:<= br>
Yeah, a couple of remind= ers here.=C2=A0 First, the text in the RFC is explicitly recommending the u= se of IA_PD as the _only_ solution to delegating prefixes. =C2=A0 Second, t= his is an RFC, and the document that proposes a way to delegate prefixes wi= thout DHCP is a draft, not an RFC. =C2=A0 That document is not mentioned in= the RFC. =C2=A0 So to suggest that this document says that IETF consensus = is that DHCP is NOT RECOMMENDED is simply incorrect.=E2=80=8B

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


--f403045dc13649ccc40554930bbb-- From nobody Tue Jul 18 01:51:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA8131DB9 for ; Tue, 18 Jul 2017 01:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 wLWQT_3Kzp3I for ; Tue, 18 Jul 2017 01:51:47 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00B8131D0E for ; Tue, 18 Jul 2017 01:51:46 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6I8ZD1v036694; Tue, 18 Jul 2017 10:35:13 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707180835.v6I8ZD1v036694@givry.fdupont.fr> From: Francis Dupont To: Ted Lemon cc: Alexandre Petrescu , IPv6 Ops WG In-reply-to: Your message of Mon, 17 Jul 2017 20:07:07 +0200. Date: Tue, 18 Jul 2017 10:35:13 +0200 Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:51:48 -0000 In your previous mail you wrote: > Understood. The issue here is that the ISC client is using bpf (or lpf) > to send packets rather than using the Linux stack. Try compiling it with > #define USE_SOCKETS and see if the behavior changes. => in fact it uses BPF/LPF/... for DHCPv4 but as you can't disable DHCPv4 yet you should recompile with the socket only option. This can break direct DHCPv4 on some systems but it doesn't matter as you want only DHCPv6. Note if (when?) this will become a common case you can ask for a feature request so it will be handled directly at the configuration phase. Regards Francis.Dupont@fdupont.fr (and also fdupont@isc.org) From nobody Tue Jul 18 01:55:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3961E131A92 for ; Tue, 18 Jul 2017 01:55:53 -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, 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=fugue-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 mJPjFGDjCJ1I for ; Tue, 18 Jul 2017 01:55:51 -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 D07D9131A78 for ; Tue, 18 Jul 2017 01:55:51 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id o88so1945060pfk.3 for ; Tue, 18 Jul 2017 01:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5zAhxlCxtW4skr0I2RBdYKih/aa6xQwTQxvr/R1VwwE=; b=rNcBPveFkRjwix3hk4Ib/rdiirOipA+uGx7YM1nExeeqPZiYGl2p29yKtz1sDNbzzR QG24b3U27pEq+BQIAoLZYHIoHVPNdjJW6vlEcZ+7C9UkmwIDPd30zuYhpFPo+Sk+dtN+ lId4dHthZMm70FYjZ1TU/SwbijHb3rkhRcNRgG7He6VkdhSebbloz0zqqDn04IyPLzEv KsDLa7hHfA0YaJrdrmlWBze+vcJre8RImgyjQowc1XCXhjD9Bn4Q9ImAzYhVjAGPFdJD Hb177yqaXbOtBHlcSpRkyqHJkd1eLN3uHSXixdO/mopP+khfJlJqhyDZ7EkWTRZlyXS/ zsjQ== 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=5zAhxlCxtW4skr0I2RBdYKih/aa6xQwTQxvr/R1VwwE=; b=dNskIj/auCaJRhvsRugLj6c0Xb1LMHzQkg4kdslUk5GwnNw+/gMZbOB8Js23yBwkXB GCYRoVh4Pts++YdMndUy8+9B4igtCyJS1OrZ+wA8k7YdkEHh5nYmD62eXoKjdXimi2jF RNt5QrT2+jd14aNzIOU5W9jNdhUYbd7/h21q0DzDnyxvspVDakm37cFspKv3dZKV0Iw1 f1c2u2xBL25psrGCfbpHXNmuUvZPWw2i/vQ44HWRn7BKs+3dpU7pihKbrPZhMclkb/z5 MA6k03jmJvChS5aT6Ndw2TgMHpjijisENg+SoaiAXjippyd5N4y+SAGMCHgTmPRdiu2v tc2A== X-Gm-Message-State: AIVw1129wt95lI4+xsbzqsFkKTwLbUVE7QbtDuHB4impU72W5MRPFWve aTw0PeyGwTOePjngf6LoZS3nvBegCkyU X-Received: by 10.98.67.147 with SMTP id l19mr550933pfi.198.1500368151454; Tue, 18 Jul 2017 01:55:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 01:55:10 -0700 (PDT) In-Reply-To: <201707180835.v6I8ZD1v036694@givry.fdupont.fr> References: <201707180835.v6I8ZD1v036694@givry.fdupont.fr> From: Ted Lemon Date: Tue, 18 Jul 2017 10:55:10 +0200 Message-ID: To: Francis Dupont Cc: Alexandre Petrescu , IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c0c0f44b33d50055493ae7b" Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:55:53 -0000 --94eb2c0c0f44b33d50055493ae7b Content-Type: text/plain; charset="UTF-8" I think you can do DHCPv4 on linux without using LPF. Also possibly on various modern BSDs. The advanced socket API appears to support this. On Tue, Jul 18, 2017 at 10:35 AM, Francis Dupont wrote: > In your previous mail you wrote: > > > Understood. The issue here is that the ISC client is using bpf (or > lpf) > > to send packets rather than using the Linux stack. Try compiling it > with > > #define USE_SOCKETS and see if the behavior changes. > > => in fact it uses BPF/LPF/... for DHCPv4 but as you can't disable > DHCPv4 yet you should recompile with the socket only option. > This can break direct DHCPv4 on some systems but it doesn't matter as > you want only DHCPv6. Note if (when?) this will become a common case > you can ask for a feature request so it will be handled directly > at the configuration phase. > > Regards > > Francis.Dupont@fdupont.fr (and also fdupont@isc.org) > --94eb2c0c0f44b33d50055493ae7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you can do DHCPv4 on linux without using LPF. =C2= =A0 Also possibly on various modern BSDs. =C2=A0 The advanced socket API ap= pears to support this.

On Tue, Jul 18, 2017 at 10:35 AM, Francis Dupont <Franc= is.Dupont@fdupont.fr> wrote:
=C2=A0In your previous mail you wrote:

>=C2=A0 Understood.=C2=A0 =C2=A0The issue here is that the ISC client is= using bpf (or lpf)
>=C2=A0 to send packets rather than using the Linux stack.=C2=A0 =C2=A0T= ry compiling it with
>=C2=A0 #define USE_SOCKETS and see if the behavior changes.

=3D> in fact it uses BPF/LPF/... for DHCPv4 but as you can't = disable
DHCPv4 yet you should recompile with the socket only option.
=C2=A0This can break direct DHCPv4 on some systems but it doesn't matte= r as
you want only DHCPv6. Note if (when?) this will become a common case
you can ask for a feature request so it will be handled directly
at the configuration phase.

Regards

Francis.Dupont@fdupont.fr = (and also fdupont@isc.org)

--94eb2c0c0f44b33d50055493ae7b-- From nobody Tue Jul 18 02:19:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42162131DCB for ; Tue, 18 Jul 2017 02:19:55 -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 uY8K2KUcd_OS for ; Tue, 18 Jul 2017 02:19:52 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F423131DC7 for ; Tue, 18 Jul 2017 02:19:48 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 1AD3DE6065; Tue, 18 Jul 2017 11:19:47 +0200 (CEST) Date: Tue, 18 Jul 2017 11:19:47 +0200 (CEST) Message-Id: <20170718.111947.74661387.sthaug@nethelp.no> To: Francis.Dupont@fdupont.fr Cc: mellon@fugue.com, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <201707180835.v6I8ZD1v036694@givry.fdupont.fr> References: <201707180835.v6I8ZD1v036694@givry.fdupont.fr> 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: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:19:55 -0000 > > Understood. The issue here is that the ISC client is using bpf (or lpf) > > to send packets rather than using the Linux stack. Try compiling it with > > #define USE_SOCKETS and see if the behavior changes. > > => in fact it uses BPF/LPF/... for DHCPv4 but as you can't disable > DHCPv4 yet you should recompile with the socket only option. > This can break direct DHCPv4 on some systems but it doesn't matter as > you want only DHCPv6. Note if (when?) this will become a common case > you can ask for a feature request so it will be handled directly > at the configuration phase. The problem, at least on some systems, is being able to receive DHCP *broadcast* packets (e.g. the first Discover packet in a DHCPv4 transaction). I run ISC DHCP on FreeBSD, compiled without BPF, and with all DHCP traffic via relay agents. No problems. Steinar Haug, AS2116 From nobody Tue Jul 18 02:41:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E451126E3A for ; Tue, 18 Jul 2017 02:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 bMD12PEKkYyC for ; Tue, 18 Jul 2017 02:41:45 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE50131DD1 for ; Tue, 18 Jul 2017 02:41:44 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6I9PBdf040428; Tue, 18 Jul 2017 11:25:11 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707180925.v6I9PBdf040428@givry.fdupont.fr> From: Francis Dupont To: Ted Lemon cc: Alexandre Petrescu , IPv6 Ops WG In-reply-to: Your message of Tue, 18 Jul 2017 10:55:10 +0200. Date: Tue, 18 Jul 2017 11:25:11 +0200 Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:41:46 -0000 In your previous mail you wrote: > I think you can do DHCPv4 on linux without using LPF. Also possibly on > various modern BSDs. The advanced socket API appears to support this. => this is why I added "on some systems". Note it is harder on the client side, and on the server side with a relay BPF/LBF/... is never required. Of course this applies only to DHCPv4. Regards Francis.Dupont@fdupont.fr From nobody Tue Jul 18 02:45:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC47A131A93 for ; Tue, 18 Jul 2017 02:45:16 -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 2W4TbowKgzC5 for ; Tue, 18 Jul 2017 02:45:15 -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 542BB126E3A for ; Tue, 18 Jul 2017 02:45:15 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id a10so21151970wrd.0 for ; Tue, 18 Jul 2017 02:45:15 -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:message-id:date :to; bh=2g+Bl4lhxSWaUn9xUd/sf7Pp/3X1M/9rBlXql7gHQFs=; b=HxRZlINfnkfEe61BrMwfvqcTggWCgB+plgfUwLd7BPiXgrLcpxywi4hWjaUpbVXeoF 2HUSM8Oy1qbOg/l0LLlnkbxhDjTCoe7BhdN8+PWNWKty4m5SXbZnN6fHU5q/ekERQO1k /UsahNIKHaOYnRHQRsDfJxDZCiFwejqCVCmlUCDikkZG6RSJhMBSYcW/1ScQWGD8g8mr jsmojC458GIW8209nXGQ4NL2di/U/SKl4Dn7OINat18/JNc776/pjbIMiASyrHYJMNm0 +arKVsCqCWxw1mavwdvL7YzhVy83ydurb4vjB9gLQ9ScecauK2VmhBGGuoYH3inEXgvM 9CTg== 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:message-id:date:to; bh=2g+Bl4lhxSWaUn9xUd/sf7Pp/3X1M/9rBlXql7gHQFs=; b=s5CikTGyngYB15DQa8MT7O3oBXW0yyHXD6FAJkDrbBxviqkO7dl48yZtf4aFXdIuFn 3ZxZ1rhYv0ad7la2xCbDrnNVl0z6wpNwB3PBAWwiYVk3f+g3NWhHM9DHC9hVVC9rYHIf KDwCOHSJ6sAKJUdJYyTpHXq9s6pN6PSyg0UDrO112pjHyC0o7CzgDqOwQ6l5EP6DWg3v kzEaFi1hnNfWgIY5vpQycZvbnxgs4gpvKuI/MfRf3yz69kkMcaxHPgjSmkDBRst0wG8p OvDrFs9QG4vMqEzAGtn6mNJ0MPvlIxw2ECaJnXBDVkcf2ZL4+u8i7NirhQcGN/XN+qrA tTeg== X-Gm-Message-State: AIVw110iFc0bYy2gKkNaMAs8i1WbKRTWbp4CWec18OczhJs8HPGgqtfT 8gm4cDuuW6nWNFRVeB01hQ== X-Received: by 10.28.107.76 with SMTP id g73mr1466148wmc.57.1500371113506; Tue, 18 Jul 2017 02:45:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:f9d9:8575:96d0:73e5? ([2001:67c:370:1998:f9d9:8575:96d0:73e5]) by smtp.gmail.com with ESMTPSA id c55sm1558722wrc.7.2017.07.18.02.45.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 02:45:13 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 18 Jul 2017 11:45:11 +0200 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] I-D.ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:45:17 -0000 Hi V6OPS, As I just said at the microphone, I think it would be helpful to add = something to this document that connects to Host Address Availability = Recommendations [RFC 7934]. In simple terms, we need routers to be = capable of making addresses available to hosts without requiring them to = make an explicit request for each one, and this draft should cite RFC = 7934 accordingly. --james woodyatt From nobody Tue Jul 18 02:50:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B034131DCE for ; Tue, 18 Jul 2017 02:50:26 -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] 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 cq1nuEp7tvYi for ; Tue, 18 Jul 2017 02:50:24 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE56D1286B2 for ; Tue, 18 Jul 2017 02:50:24 -0700 (PDT) Received: from mb.local ([IPv6:2001:67c:370:1998:3d94:d5ca:99f4:da1]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v6I9oLU3090115 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 18 Jul 2017 09:50:23 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:1998:3d94:d5ca:99f4:da1] claimed to be mb.local To: Alexandre Petrescu , v6ops@ietf.org References: <596CF817.8040900@foobar.org> <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> From: joel jaeggli Message-ID: Date: Tue, 18 Jul 2017 11:50:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i2ntDK24xtEtooPi9LwHlwkeWMrM0kLv0" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:50:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i2ntDK24xtEtooPi9LwHlwkeWMrM0kLv0 Content-Type: multipart/mixed; boundary="iQKQdEWkA32jPTD3Bo6vpf04eqK7gp566"; protected-headers="v1" From: joel jaeggli To: Alexandre Petrescu , v6ops@ietf.org Message-ID: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt References: <596CF817.8040900@foobar.org> <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> In-Reply-To: <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> --iQKQdEWkA32jPTD3Bo6vpf04eqK7gp566 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/17/17 22:58, Alexandre Petrescu wrote: >=20 >=20 > Le 17/07/2017 =E0 22:33, Ross Chandler a =E9crit : >> >>> On 17 Jul 2017, at 20:30, Ted Lemon >> > wrote: >>> >>> What the document actually implies is that individual address >>> assignment using DHCPv6 is not recommended; instead it is >>> recommended that each host get a /64.=A0 The only way to do that >>> right now is with DHCPv6 PD.=A0=A0 So the document is explicitly >>> recommending the use of DHCPv6. >> >> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-ho= st-06 >> >> >> =A0Section 4 describes a way of assigning a /64 per host using RAs tha= t >> is already deployed in real networks. No DHCPv6 involved. >=20 > There is something wrong with that draft: it only allows for 64.=A0 Why= ? > DHCPv6-PD can delegate other plengths, like 65. "a Unique IPv6 prefix (currently a /64 prefix)" seems like a coordination problem. where it would be best not to constrain the delegated prefix if it assumes that 64bit iids will be assigned via slaac then /64 is the lower bound, however it could be shorter e.g. 60 56 48 etc. so it would seem to be possible to delegate the appropiate sized prefix for that application. >> https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.tx= t >> >> =A0Introduces an eXclusive flag to optimize RA for nodes that are >> exclusive receivers of all traffic to the prefix. >=20 > This is another way of calling RA "Prefix Delegation". >=20 > There are other drafts doing Prefix Delegation with RA, have you > considered them? >=20 >>> However, if the only DHCP service available is individual address >>> allocation, then indeed that is not recommended, because it has >>> serious privacy implications.=A0=A0 And it is not _generally_ >>> recommended that people operate networks that require DHCPv6 static >>> individual address allocation (IA_NA) for this same reason.=A0=A0 Usi= ng >>> the DHCPv6 privacy profile does mitigate this concern, but still >>> the best thing to do is just enable SLAAC. >>> >>> I don't think these views are particularly controversial in the >>> IETF. I'm one of the authors of RFC3315, and I agree with this >>> view. >> >> Given the above two drafts DHCPv6-PD to hosts has an uphill struggle >> to ever achieve widespread deployment. >=20 > I dont think so. >=20 > I think DHCPv6-PD should be trialled at IETF WiFi and then we'll see. >=20 > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --iQKQdEWkA32jPTD3Bo6vpf04eqK7gp566-- --i2ntDK24xtEtooPi9LwHlwkeWMrM0kLv0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAllt2dwACgkQ8AA1q7Z/VrINSQCfWRbmMut13xtJtWP+Hd+YcHrQ TowAnixfIOJhWWiVx596K4xKpBWvPVqC =XOAI -----END PGP SIGNATURE----- --i2ntDK24xtEtooPi9LwHlwkeWMrM0kLv0-- From nobody Tue Jul 18 03:40:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350D8131DD1 for ; Tue, 18 Jul 2017 03:40:13 -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 6pmOChTFf3E8 for ; Tue, 18 Jul 2017 03:40:11 -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 BF12F12EBFA for ; Tue, 18 Jul 2017 03:40:11 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so18302787uah.1 for ; Tue, 18 Jul 2017 03:40:11 -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=npwv4SDy1XbE6YLtyQMOHgkGzKxuUofIX/+bnEHIMMo=; b=HrFWjrpXTbfUy3Hi56IrlxMlBLexSnvCw3foLJP0a6nCa1ne+UAXc1+mz/UaaKpVIP nD2+T6IbqGvgmiEQ7lxM9kBiftdqHcidEBSMpHs31y5JO+oq3vAIOW6b4ApQ2O3zPfKj /iWmnGaKzUMK8Ev9zKswpQFd0lU/bUmbRIk5zpWd0wPQ7ZLZD2NEKn7ObncEg7v2i31O 842BaZsCdRv0SP3LW18G4cJodCT8y2/8UfdSw+gkUu4oKa2vfZsEoFtNmRNvYcCvHQfx JQ8SHIulyBCU0RWJvwrEjLwXyU9DG6rQb0kb4RvL+DN0G54/CIpmq+laeho4y/AlHLcV XiHA== 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=npwv4SDy1XbE6YLtyQMOHgkGzKxuUofIX/+bnEHIMMo=; b=CLv2ikoZ7Clv12X6kDewZsVtDkSO3UWyLjbTGTI2MYz++OrgqaMOEa2ITRTHmrsCpb 3kpuoAjPcGqgdiRDTQz9Ma/Tt+24gFuwfqtXiCcVYPmqTzOpc25QKhWNbkPv4qOSR5h+ pU7to12AhfgM0grd0E3HzdMhv6fHDeaWeZLKhTgixcF+Ugc4Hhp/TL/hxFpLsy2dCXgp WVJenPXUa9ZT1aVKwjdfkrx9RnZguFIidCOsW8WceX1DHk8vPtRdqkbf0gS+AAQdzCkT 7YLAXFEGQy8O0r78kgmp6YGQCtphrYqMkydGa8ZsDnGH72jX0WvM4fmUDkXctH7gwKYH 5wnQ== X-Gm-Message-State: AIVw113DIAsG+eDr6q+2cw+rYgKePDP7OiuIDZvdWBBWtK0N5BGCOFT0 owlgFpkGtn1EqASeOrzTut78JIUW3A== X-Received: by 10.176.74.8 with SMTP id q8mr498161uae.33.1500374410862; Tue, 18 Jul 2017 03:40:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Tue, 18 Jul 2017 03:39:40 -0700 (PDT) In-Reply-To: <201707180925.v6I9PBdf040428@givry.fdupont.fr> References: <201707180925.v6I9PBdf040428@givry.fdupont.fr> From: Mark Smith Date: Tue, 18 Jul 2017 20:39:40 +1000 Message-ID: To: Francis Dupont Cc: Ted Lemon , IPv6 Ops WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 10:40:13 -0000 On 18 July 2017 at 19:25, Francis Dupont wrote: > In your previous mail you wrote: > >> I think you can do DHCPv4 on linux without using LPF. Also possibly on >> various modern BSDs. The advanced socket API appears to support this. > > => this is why I added "on some systems". Note it is harder on the client > side, and on the server side with a relay BPF/LBF/... is never required. > Of course this applies only to DHCPv4. > You're right, I'm miss-attributing these sort of client issues to a server. I'm pretty sure under Linux all interfaces are IPv4 enabled by default, which I think would mean that even if the interface doesn't have an address, it will still receive and process IPv4 broadcasts. IPv6 is the same, although there is a disable_ipv6 knob to disable all IPv6 packet processing on an interface. So in the OPs case, even though the host is an "IPv6 only" host, it could still receive and process some IPv4 packets. Filtering them or not running a DHCPv4 process is probably the only option. Regards, Mark. > Regards > > Francis.Dupont@fdupont.fr > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 18 03:55:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555512F280 for ; Tue, 18 Jul 2017 03:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 9djpBnYJXqIz for ; Tue, 18 Jul 2017 03:55:52 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8711316C3 for ; Tue, 18 Jul 2017 03:55:35 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6IAd2fN044957; Tue, 18 Jul 2017 12:39:02 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707181039.v6IAd2fN044957@givry.fdupont.fr> From: Francis Dupont To: sthaug@nethelp.no cc: mellon@fugue.com, v6ops@ietf.org In-reply-to: Your message of Tue, 18 Jul 2017 11:19:47 +0200. <20170718.111947.74661387.sthaug@nethelp.no> Date: Tue, 18 Jul 2017 12:39:02 +0200 Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 10:55:54 -0000 In your previous mail you wrote: > The problem, at least on some systems, is being able to receive DHCP > *broadcast* packets (e.g. the first Discover packet in a DHCPv4 > transaction). => or worse to send it without an IP address assigned to the interface... > I run ISC DHCP on FreeBSD, compiled without BPF, and with all DHCP > traffic via relay agents. No problems. => yes, this case is known always to work. Kea offers the UDP socket (vs BPF/LPF) in its configuretion file so you don't need to recompile (i.e., Kea learnt from ISC DHCP :-). Regards Francis.Dupont@fdupont.fr PS: to summary: the hack used to make the DHCP client to work an Adroid is not a real hack and is perfectly safe for its goal (DHCPv6 prefix delagation). From nobody Tue Jul 18 05:17:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37F4131461 for ; Tue, 18 Jul 2017 05:16:59 -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 T6IOK9rPoBcC for ; Tue, 18 Jul 2017 05:16:58 -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 D3351127599 for ; Tue, 18 Jul 2017 05:16:57 -0700 (PDT) X-Envelope-To: v6ops@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 v6ICGrfM014117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2017 13:16:53 +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: <596DFC35.7080509@foobar.org> Date: Tue, 18 Jul 2017 13:16:53 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ted Lemon CC: Mark Smith , IPv6 Operations References: <596CF817.8040900@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:17:00 -0000 Ted Lemon wrote: > Yeah, a couple of reminders here. First, the text in the RFC is > explicitly recommending the use of IA_PD as the _only_ solution to > delegating prefixes. Which is problematic because there was no consensus that I could see during the discussion phase of draft-ietf-v6ops-host-addr-availability that there was widespread use of DHCPv6-PD as a means of satisfying the aims providing extra addresses for end hosts (as opposed to delegating them to routers, which is a different issue entirely). The lack of consensus was remarked on at the time. It seems extraordinary that this also ended up > Second, this is an RFC, and the document that > proposes a way to delegate prefixes without DHCP is a draft, not an RFC. > That document is not mentioned in the RFC. So to suggest that this > document says that IETF consensus is that DHCP is NOT RECOMMENDED is > simply incorrect.​ The interpretation of the principal author of BCP206 is diametrically opposite on this point. If there are polar opposite views in v6ops on how BCP206 should be interpreted, this suggests that there is an ambiguity in the document. If people in v6ops-wg cannot agree on what the document means, what hope does anyone else have in interpreting it? Nick From nobody Tue Jul 18 05:18:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5CF12EBF7 for ; Tue, 18 Jul 2017 05:18:26 -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 o6AAwVOhmmil for ; Tue, 18 Jul 2017 05:18:25 -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 3126813146C for ; Tue, 18 Jul 2017 05:18:24 -0700 (PDT) X-Envelope-To: v6ops@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 v6ICILv5014366 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2017 13:18:21 +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: <596DFC8D.7020404@foobar.org> Date: Tue, 18 Jul 2017 13:18:21 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ted Lemon CC: Mark Smith , IPv6 Operations References: <596CF817.8040900@foobar.org> <596DFC35.7080509@foobar.org> In-Reply-To: <596DFC35.7080509@foobar.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:18:26 -0000 Nick Hilliard wrote: > It seems extraordinary that this also ended up "It seems extraordinary that this also ended up in the document." reminder: finish emails before sending. Nick From nobody Tue Jul 18 05:21:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B772E131DF8 for ; Tue, 18 Jul 2017 05:21:03 -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 LF5FdS6Pmv-7 for ; Tue, 18 Jul 2017 05:20: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 8584E131B45 for ; Tue, 18 Jul 2017 05:20:57 -0700 (PDT) X-Envelope-To: v6ops@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 v6ICKtOU014605 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2017 13:20:55 +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: <596DFD26.4050206@foobar.org> Date: Tue, 18 Jul 2017 13:20:54 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Erik Kline CC: IPv6 Operations References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:21:04 -0000 Erik Kline wrote: > The topic in general was discussed. ... without consensus in the context of draft-ietf-v6ops-host-addr-availability, and after the change was made in section 8 despite a lack of consensus that it was an appropriate change to make, there was no further discussion. Nick From nobody Tue Jul 18 05:35:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF786131B38 for ; Tue, 18 Jul 2017 05:35: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 AnsKOLMeextV for ; Tue, 18 Jul 2017 05:34:59 -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 4DEDA131948 for ; Tue, 18 Jul 2017 05:34:59 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id o88so4515965pfk.3 for ; Tue, 18 Jul 2017 05:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=940ztzWnJD7Ym/wdOOIwPJZSDrnB2TyvdwHuYbHuhcc=; b=ZoCacBgTK78dzuUOm5GE4x+WXVxuRkwq5mV7hLUAEeKaa3dCKkRs2tmTVqusysJTNK CKDeJOpTBzF7Rf7GEJGljjx1J2se3/DvpP74kLdlpA5HAiybsvRbdl1oO9qSmwzixPde K7x7FqKipMMKUN77JZhZGVRA865OJ8pdVMRIAOF7exjHEqsnzo9WkVYZiCexwwYNEZsJ pDErNhlER/RqGf1rXBmm8eRh7Et2K+AOCc/FY/Rw0a12Oi5iZbqnsWZJ64ccSXDJibdW 9ex/H1RyHmLUtY/yFY8rQpBG8PR4BoxcqwjMeSE7f0I2Y6Je2EWc8AFcV+t7UJbC+Ldt 4rvQ== 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=940ztzWnJD7Ym/wdOOIwPJZSDrnB2TyvdwHuYbHuhcc=; b=o+r2rx4AloYRnlQfBLgJdpYyyMZbhZ77SlOODp60wNcu1lK6b9xqPStZllTCYXkdPu 4n8FER69WqNcVbIoXjl5M0sJL5f1Z1UdXj63xW3X5qij9aAQi3R2E3gqW280KuGVIYz7 lEUm8eRvUxBE7Ii7vi+VYpAa1qHrseBlikEtzs1lawbGfd2T8Y5pmIay89EQKM6HwBgT CqSYVn9v1uRbs6aAXen+kC0hezeyerfbNihDGBssTzdv70gnlF+pLmnIPxNspbAqZkuT FYSA/+UZHQADFer6NZUQvPkWvMjEVCAjsEj8uxc0674+Ns/NkAicY5/dM8bWiTBLb2ZT 5iiQ== X-Gm-Message-State: AIVw113MuduIH2eA7scA/jc2N3nWygbkGRq8Q+xJCEQ8rsI9xsTN+BB0 SeJGAPPGeLBwBSq0RTZz1XxnmSe2bnjb X-Received: by 10.101.91.70 with SMTP id y6mr1085242pgr.122.1500381298851; Tue, 18 Jul 2017 05:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 05:34:18 -0700 (PDT) In-Reply-To: <596DFD26.4050206@foobar.org> References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> <596DFD26.4050206@foobar.org> From: Ted Lemon Date: Tue, 18 Jul 2017 14:34:18 +0200 Message-ID: To: Nick Hilliard Cc: Erik Kline , IPv6 Operations Content-Type: multipart/alternative; boundary="089e08238144589d88055496be9d" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:35:01 -0000 --089e08238144589d88055496be9d Content-Type: text/plain; charset="UTF-8" Nick, it's not actually up to you to determine consensus, and you do not seem to actually be describing a situation where there was a lack of consensus. If you feel that there was indeed an error made by the chairs, who *were* responsible for calling consensus, the right thing to do would be to appeal to the chairs, and if you are not satisfied by their response, to appeal to the IESG, and so on. What you should not do is have an argument about whether or not there was consensus on the working group mailing list a year after the RFC was published. On Tue, Jul 18, 2017 at 2:20 PM, Nick Hilliard wrote: > Erik Kline wrote: > > The topic in general was discussed. > > ... without consensus in the context of > draft-ietf-v6ops-host-addr-availability, and after the change was made > in section 8 despite a lack of consensus that it was an appropriate > change to make, there was no further discussion. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e08238144589d88055496be9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nick, it's not actually up to you to determine consens= us, and you do not seem to actually be describing a situation where there w= as a lack of consensus. =C2=A0 If you feel that there was indeed an error m= ade by the chairs, who were=C2=A0responsible for calling consensus, = the right thing to do would be to appeal to the chairs, and if you are not = satisfied by their response, to appeal to the IESG, and so on.

What you should not do is have an argument about whether or not ther= e was consensus on the working group mailing list a year after the RFC was = published.

On Tue, Jul 18, 2017 at 2:20 PM, Nick Hilliard <<= a href=3D"mailto:nick@foobar.org" target=3D"_blank">nick@foobar.org>= wrote:
Erik Klin= e wrote:
> The topic in general was discussed.

... without consensus in the context of
draft-ietf-v6ops-host-addr-availability, and after the change was made=
in section 8 despite a lack of consensus that it was an appropriate
change to make, there was no further discussion.

Nick

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

--089e08238144589d88055496be9d-- From nobody Tue Jul 18 06:15:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49C12EB8C for ; Tue, 18 Jul 2017 06:15:03 -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 N5boGcAIdUxy for ; Tue, 18 Jul 2017 06:14: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 279BB131B46 for ; Tue, 18 Jul 2017 06:14:56 -0700 (PDT) X-Envelope-To: v6ops@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 v6IDEr8H021030 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2017 14:14:53 +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: <596E09CC.3@foobar.org> Date: Tue, 18 Jul 2017 14:14:52 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ted Lemon CC: IPv6 Operations References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> <596DFD26.4050206@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:15:04 -0000 Ted Lemon wrote: > Nick, it's not actually up to you to determine consensus, and you do not > seem to actually be describing a situation where there was a lack of > consensus. If you feel that there was indeed an error made by the > chairs, who /were/ responsible for calling consensus, the right thing to > do would be to appeal to the chairs, and if you are not satisfied by > their response, to appeal to the IESG, and so on. I'm not attempting to determine consensus, simply expressing an opinion that there was substantial opposition to the principals behind a sentence that was inserted into the draft, i.e. querying whether that consensus existed to start with. There isn't a problem with querying a decision. The difficulty with formally appealing the consensus call is that the change was inserted into the document in Feb 2016, and there were several more revisions of the document before it was published as a BCP some months later, and there were no objections because it wasn't obvious what it meant at the time. As an aside, the fact that there is a good deal of disagreement on its interpretation today makes it clear that that this sentence is open to vastly different interpretations. So procedurally, there was not a problem with the consensus process which means that an appeal to the chairs / IESG / etc would be almost certain to fail, not least because this happened some time ago. The only obvious way to deal with the problem is to bring it back to the working group with an explicit statement of the semantic problem, which is what has happened. It would be useful for the chairs to express an opinion if a different approach were more appropriate. Nick From nobody Tue Jul 18 07:00:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BB112785F for ; Tue, 18 Jul 2017 07:00: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 8dwsdbjpY5sM for ; Tue, 18 Jul 2017 07:00: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 35D65129B15 for ; Tue, 18 Jul 2017 07:00:03 -0700 (PDT) X-Envelope-To: v6ops@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 v6IDxw1K026307 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2017 14:59:58 +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: <596E145C.8010603@foobar.org> Date: Tue, 18 Jul 2017 14:59:56 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: "v6ops-chairs@tools.ietf.org Chairs" , IPv6 Operations References: <596CF817.8040900@foobar.org> <596D2D2D.5080406@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:00:11 -0000 Lorenzo Colitti wrote: > If you read the discussion threads carefully, you'll see that the main > issue being raised in that version of the draft (mostly by Philip and > Gert, as I recall) was not "IA_NA should be used", but "DHCPv6 PD is not > the only way to assign a prefix, and not a widely adopted way". -05 > addressed that issue by de-emphasizing DHCPv6 PD. As I read it, at the > time there was pretty broad agreement at the time that IA_NA was not a > good choice both because it is limited in terms of the number of total > addresses that can be assigned and because it requires that the client > send explicit requests, which has the problems listed in section 4. I don't expect you to agree with the opinions expressed in draft-hilliard-v6ops-host-addr-update. To requote Gert: > I missed that this was intended for BCP, otherwise I would have complained > earlier. Haven't seen anyone state that they are deploying DHCPv6-PD to > hosts except you, so "CP" is really questionable... > > For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds > about right. However, there is no basis for you to assert that there was broad agreement that IA_NA was a bad choice, and less still to codify that into a statement which, in your opinion, creates an IETF recommendation not to use DHCPv6 IA_NA. Nick From nobody Tue Jul 18 07:09:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57400131B67 for ; Tue, 18 Jul 2017 07:09: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 eDRMjaPyoUkm for ; Tue, 18 Jul 2017 07:09:16 -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 EDEBF1286B2 for ; Tue, 18 Jul 2017 07:09:15 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u5so13356951pgq.3 for ; Tue, 18 Jul 2017 07:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ocQB7WmxTYd2QwTXvI1GOQfs+qYIHipbfsBDJku5vh0=; b=Yj72yKKQe5peg5sJD5ss5D1nakXV9l/3m3/RK4v6Tx9hRASJyuFMg04TooPalr1Tkx 9W1kCYjP9X+cVkYFaiQkkPEFJBVV3XPL4s4HsMXQjjV3uP0PuXROI4Z+KszvLjy2Wdqz Nzhu9sd15IdpPPv3ngkmALTQAOl2MwB/2fuTFjCy0jiMvkRj9qow4GIAS4TvQUl/WTDb YVDl7jp7ouLUI+F/EEgOwVjFolhb48LlALfEyFJ730ZDEHe95DGvqauWaCHcbdpEW6PO BQUSbJScAFI56+pdxysq8fXzKbCpJIGnTVHOAvVHQJPJ0lxvfymsmwxF+JIC14FCAVwY 5eFQ== 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=ocQB7WmxTYd2QwTXvI1GOQfs+qYIHipbfsBDJku5vh0=; b=S7jEBGSmgZhlVRbY+rC/fxESUXcQIyRHYLQbRz/+bzgiZPxWfAaurZTs35wQXTiZzd e5eQj0IK1TxLbXGSKRPh3Eb/bq54wvFZPQUaA7kTIMEIVfgxd8cnyG2NvKeQdO2ee9bH BBOkJF4UPWtVhA1J63Kp0uowbiBfkTvY2czxfL6qBbwf0a9y/Sw9IT17pWJGgcx60b4V 4vmGYUvbjJDMqEgEzFrOmbPSrdU72NjqkPEx43DzFi7ZQpnsfeKcltZMtJ4lg9krKmMh HdZ/bN+RCOGJyNASIBMg97fQ377XwFzzJ7jO1Z1+1IARbUkJxC8XvJdbn74VSKyMcmU3 1Guw== X-Gm-Message-State: AIVw1137qKaU76UhjESaQfBznLyl56QB+1Hx+HIVqQaPYoCoVo1VMwOA T3ibgEWdo5UestrjBr8EPLOBrBUF2W3o X-Received: by 10.84.231.16 with SMTP id f16mr1975397plk.131.1500386955508; Tue, 18 Jul 2017 07:09:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 07:08:34 -0700 (PDT) In-Reply-To: <596E09CC.3@foobar.org> References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> <596DFD26.4050206@foobar.org> <596E09CC.3@foobar.org> From: Ted Lemon Date: Tue, 18 Jul 2017 16:08:34 +0200 Message-ID: To: Nick Hilliard Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="f403043601828254270554980f15" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:09:18 -0000 --f403043601828254270554980f15 Content-Type: text/plain; charset="UTF-8" The change was not inserted into the document in February of 2016. Be that as it may, my point is that this particular aspect of the discussion is out of scope: if there was a process failure, appeal is your option. I agree that it's not a practical option. So, independent of that, if you think that the current documented consensus is a *problem, *then you are absolutely right to want to do a new document. If that's what you want, you need to do (at least) two things: 1. Explain, in a way that actually makes sense, what it is that the document says that is wrong, and why it is wrong. You haven't done that. 2. Explain what it should say instead. I would argue that your explanation either has to say "privacy isn't that important after all" or else address the privacy issue in a way that is equally satisfactory. I don't see any way to do that with IA_NA. IA_NA by definition puts the whole privacy thing off on the DHCP server, which may or may not do the right thing. The client has no agency. Using IA_PD or prefix delegation are both clearly superior solutions to the problem. On Tue, Jul 18, 2017 at 3:14 PM, Nick Hilliard wrote: > Ted Lemon wrote: > > Nick, it's not actually up to you to determine consensus, and you do not > > seem to actually be describing a situation where there was a lack of > > consensus. If you feel that there was indeed an error made by the > > chairs, who /were/ responsible for calling consensus, the right thing to > > do would be to appeal to the chairs, and if you are not satisfied by > > their response, to appeal to the IESG, and so on. > > I'm not attempting to determine consensus, simply expressing an opinion > that there was substantial opposition to the principals behind a > sentence that was inserted into the draft, i.e. querying whether that > consensus existed to start with. There isn't a problem with querying a > decision. > > The difficulty with formally appealing the consensus call is that the > change was inserted into the document in Feb 2016, and there were > several more revisions of the document before it was published as a BCP > some months later, and there were no objections because it wasn't > obvious what it meant at the time. > > As an aside, the fact that there is a good deal of disagreement on its > interpretation today makes it clear that that this sentence is open to > vastly different interpretations. > > So procedurally, there was not a problem with the consensus process > which means that an appeal to the chairs / IESG / etc would be almost > certain to fail, not least because this happened some time ago. The > only obvious way to deal with the problem is to bring it back to the > working group with an explicit statement of the semantic problem, which > is what has happened. > > It would be useful for the chairs to express an opinion if a different > approach were more appropriate. > > Nick > > --f403043601828254270554980f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The change was not inserted into the document in February = of 2016.=C2=A0 Be that as it may, my point is that this particular aspect o= f the discussion is out of scope: if there was a process failure, appeal is= your option. =C2=A0 I agree that it's not a practical option. =C2=A0= =C2=A0

So, independent of that, if you think that the cu= rrent documented consensus is a problem, then you are absolutely rig= ht to want to do a new document. =C2=A0 If that's what you want, you ne= ed to do (at least) two things:

1. Explain, in= a way that actually makes sense, what it is that the document says that is= wrong, and why it is wrong. =C2=A0 You haven't done that.
2. Explain what it should say instead. =C2=A0 I would argue th= at your explanation either has to say "privacy isn't that importan= t after all" or else address the privacy issue in a way that is equall= y satisfactory.=C2=A0 I don't see any way to do that with IA_NA. =C2=A0= IA_NA by definition puts the whole privacy thing off on the DHCP server, w= hich may or may not do the right thing. =C2=A0 The client has no agency. = =C2=A0 Using IA_PD or prefix delegation are both clearly superior solutions= to the problem.


<= div class=3D"gmail_quote">On Tue, Jul 18, 2017 at 3:14 PM, Nick Hilliard <ni= ck@foobar.org> wrote:
Ted Lemon wrote:
> Nick, it's not actually up to you to determine consensus, and you = do not
> seem to actually be describing a situation where there was a lack of > consensus.=C2=A0 =C2=A0If you feel that there was indeed an error made= by the
> chairs, who /were/ responsible for calling consensus, the right= thing to
> do would be to appeal to the chairs, and if you are n= ot satisfied by
> their response, to appeal to the IESG, and so on.

I'm not attempting to determine consensus, simply expressing an = opinion
that there was substantial opposition to the principals behind a
sentence that was inserted into the draft, i.e. querying whether that
consensus existed to start with.=C2=A0 There isn't a problem with query= ing a
decision.

The difficulty with formally appealing the consensus call is that the
change was inserted into the document in Feb 2016, and there were
several more revisions of the document before it was published as a BCP
some months later, and there were no objections because it wasn't
obvious what it meant at the time.

As an aside, the fact that there is a good deal of disagreement on its
interpretation today makes it clear that that this sentence is open to
vastly different interpretations.

So procedurally, there was not a problem with the consensus process
which means that an appeal to the chairs / IESG / etc would be almost
certain to fail, not least because this happened some time ago.=C2=A0 The only obvious way to deal with the problem is to bring it back to the
working group with an explicit statement of the semantic problem, which
is what has happened.

It would be useful for the chairs to express an opinion if a different
approach were more appropriate.

Nick


--f403043601828254270554980f15-- From nobody Tue Jul 18 07:10:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C58131B72 for ; Tue, 18 Jul 2017 07:10:29 -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, 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=fugue-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 dNG_K6noYOYQ for ; Tue, 18 Jul 2017 07:10:27 -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 441E9131B70 for ; Tue, 18 Jul 2017 07:10:27 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 123so13514270pgj.1 for ; Tue, 18 Jul 2017 07:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TbLKba7fosUfJscz9j8GjTgXLJ8GSlvkDq+wtPcneLY=; b=rVwFOD5fT7SwETbE7vDIRWBEzOsy2Bh5Vap14VP6NXIgzO8rATWIW6xx9y555W4E4X 5DPf68d6GTTiXgii85woPiAL40iiHSv2GaCFs5V2cVnDS+KfHlZ+CPSzvQwqCLCN1UWF 88X2gqqIyjS1lUBDyNoXTNU7v91FCi/4LWZPnVAF0s06gFaY16Ga7KtbF1Xjffi/F5PI SJX3rJAq1/eN5qRF28N50evAnT53eTKsnfUnZ5hZ+GbBIqsPyw5v/d8UunHTD3Qoopnv JPLCkgwwnjYIObk8CZbokJsUvEq05HgQ5mVPtqn6vS5WMbSPUYQUatgrdiZdkfhMqyg+ oJxw== 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=TbLKba7fosUfJscz9j8GjTgXLJ8GSlvkDq+wtPcneLY=; b=OrAhj+EOADYItvudoLTsiMKu/BEjDURcaFWZTOpYGQ+/dzAfEAdscpt411yhShbduW oBCeNUSKTUTMMTsVprx28zlqJUlN+MPyaa3ufKgL9FuVRgPKY2+2O1S7j5ziQgThSwPn NEiaXh0kRnha9JbPkwOQxBx+BjdoKiIDRoN/lRpTWvY4fsA/4aofHnI/0tW8UiarcKzL Oi/gw2BTSoiadRBOZLmMn3alWHhr86w2PHod/fcY4xL4izEdkf+24QX6EK72XJHCbRBL SCJgejRzfChGUgkFka7BfMDZGrJgvSJ9BIEHjtrJlxazU3BDctTzvbZLe2RG0dn/558F e7cA== X-Gm-Message-State: AIVw112CcB65yc2K1YGrtYD3Wi5dVDiXtr7J/UjX1Gps2BPzT/vp+d+U uuR5yUrsH5Q7r8k4yKJMgFHvieMT40GNslA= X-Received: by 10.84.224.66 with SMTP id a2mr2114207plt.64.1500387026905; Tue, 18 Jul 2017 07:10:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 07:09:46 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> <596DFD26.4050206@foobar.org> <596E09CC.3@foobar.org> From: Ted Lemon Date: Tue, 18 Jul 2017 16:09:46 +0200 Message-ID: To: Nick Hilliard Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="f40304374f50c3bf3b0554981383" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:10:29 -0000 --f40304374f50c3bf3b0554981383 Content-Type: text/plain; charset="UTF-8" > Using IA_PD or prefix delegation are both clearly superior solutions to the problem. That was meant to be "or SLAAC." On Tue, Jul 18, 2017 at 4:08 PM, Ted Lemon wrote: > The change was not inserted into the document in February of 2016. Be > that as it may, my point is that this particular aspect of the discussion > is out of scope: if there was a process failure, appeal is your option. I > agree that it's not a practical option. > > So, independent of that, if you think that the current documented > consensus is a *problem, *then you are absolutely right to want to do a > new document. If that's what you want, you need to do (at least) two > things: > > 1. Explain, in a way that actually makes sense, what it is that the > document says that is wrong, and why it is wrong. You haven't done that. > > 2. Explain what it should say instead. I would argue that your > explanation either has to say "privacy isn't that important after all" or > else address the privacy issue in a way that is equally satisfactory. I > don't see any way to do that with IA_NA. IA_NA by definition puts the > whole privacy thing off on the DHCP server, which may or may not do the > right thing. The client has no agency. Using IA_PD or prefix delegation > are both clearly superior solutions to the problem. > > > On Tue, Jul 18, 2017 at 3:14 PM, Nick Hilliard wrote: > >> Ted Lemon wrote: >> > Nick, it's not actually up to you to determine consensus, and you do not >> > seem to actually be describing a situation where there was a lack of >> > consensus. If you feel that there was indeed an error made by the >> > chairs, who /were/ responsible for calling consensus, the right thing to >> > do would be to appeal to the chairs, and if you are not satisfied by >> > their response, to appeal to the IESG, and so on. >> >> I'm not attempting to determine consensus, simply expressing an opinion >> that there was substantial opposition to the principals behind a >> sentence that was inserted into the draft, i.e. querying whether that >> consensus existed to start with. There isn't a problem with querying a >> decision. >> >> The difficulty with formally appealing the consensus call is that the >> change was inserted into the document in Feb 2016, and there were >> several more revisions of the document before it was published as a BCP >> some months later, and there were no objections because it wasn't >> obvious what it meant at the time. >> >> As an aside, the fact that there is a good deal of disagreement on its >> interpretation today makes it clear that that this sentence is open to >> vastly different interpretations. >> >> So procedurally, there was not a problem with the consensus process >> which means that an appeal to the chairs / IESG / etc would be almost >> certain to fail, not least because this happened some time ago. The >> only obvious way to deal with the problem is to bring it back to the >> working group with an explicit statement of the semantic problem, which >> is what has happened. >> >> It would be useful for the chairs to express an opinion if a different >> approach were more appropriate. >> >> Nick >> >> > --f40304374f50c3bf3b0554981383 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Using IA_PD or = prefix delegation are both clearly superior solutions to the problem.

That was meant to be "or SLAAC."
=

On Tue, Jul 18, 2= 017 at 4:08 PM, Ted Lemon <mellon@fugue.com> wrote:
The change was not inserted into = the document in February of 2016.=C2=A0 Be that as it may, my point is that= this particular aspect of the discussion is out of scope: if there was a p= rocess failure, appeal is your option. =C2=A0 I agree that it's not a p= ractical option. =C2=A0=C2=A0

So, independent of that, i= f you think that the current documented consensus is a problem, then= you are absolutely right to want to do a new document. =C2=A0 If that'= s what you want, you need to do (at least) two things:

1. Explain, in a way that actually makes sense, what it is that th= e document says that is wrong, and why it is wrong. =C2=A0 You haven't = done that.

2. Explain what it should say instead. = =C2=A0 I would argue that your explanation either has to say "privacy = isn't that important after all" or else address the privacy issue = in a way that is equally satisfactory.=C2=A0 I don't see any way to do = that with IA_NA. =C2=A0 IA_NA by definition puts the whole privacy thing of= f on the DHCP server, which may or may not do the right thing. =C2=A0 The c= lient has no agency. =C2=A0 Using IA_PD or prefix delegation are both clear= ly superior solutions to the problem.


On Tue, Jul 18, 2017 at 3:14 PM, Nick Hilliard <nick@foobar.org= > wrote:
Ted Lemon wr= ote:
> Nick, it's not actually up to you to determine consensus, and you = do not
> seem to actually be describing a situation where there was a lack of > consensus.=C2=A0 =C2=A0If you feel that there was indeed an error made= by the
> chairs, who /were/ responsible for calling consensus, the right= thing to
> do would be to appeal to the chairs, and if you are not satisfie= d by
> their response, to appeal to the IESG, and so on.

I'm not attempting to determine consensus, simply expressing an = opinion
that there was substantial opposition to the principals behind a
sentence that was inserted into the draft, i.e. querying whether that
consensus existed to start with.=C2=A0 There isn't a problem with query= ing a
decision.

The difficulty with formally appealing the consensus call is that the
change was inserted into the document in Feb 2016, and there were
several more revisions of the document before it was published as a BCP
some months later, and there were no objections because it wasn't
obvious what it meant at the time.

As an aside, the fact that there is a good deal of disagreement on its
interpretation today makes it clear that that this sentence is open to
vastly different interpretations.

So procedurally, there was not a problem with the consensus process
which means that an appeal to the chairs / IESG / etc would be almost
certain to fail, not least because this happened some time ago.=C2=A0 The only obvious way to deal with the problem is to bring it back to the
working group with an explicit statement of the semantic problem, which
is what has happened.

It would be useful for the chairs to express an opinion if a different
approach were more appropriate.

Nick



--f40304374f50c3bf3b0554981383-- From nobody Tue Jul 18 07:41:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2EB1317CA for ; Tue, 18 Jul 2017 07:41:33 -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 jeoPTYoXYjML for ; Tue, 18 Jul 2017 07:41:26 -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 249A4127136 for ; Tue, 18 Jul 2017 07:41:26 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id v105so2258699wrb.0 for ; Tue, 18 Jul 2017 07:41:26 -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=QR8P+YmdZ9AK/tdfznNs/tbWkk5iNi5NS2oUZf7HX/E=; b=DxAA3cJ27mql/dufKNXgMLJeh0dbbVGM5+bzFZMLD5kBMYy3ESXSaBn4V2Sg3MXl7z ZSG6CKqnImlI93enmOPJw/U3b5UcgTpx6FWPdo/+5T0QQnJvrd2xvbWvohmK8vPLeRfX 2f8MlE4bQndrEFI8274uEbtC4ZnyXo78S7vsGv8GlY+2gT3Ee8QXqdfaSZpHwyUhex2i 7jibhB58LmH8c1iR+niB0hyVTr3IjMmX6mNDxtQTo0L/u1fUcI+UwxTxhHWDgLFYmRk4 tUPiphhxZYzKMwLiqwqpQ6H47XhZ4+b3NzgoZDMv7iIWwRdakCadmn1Uf1asFda2hmny 5Xrw== 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=QR8P+YmdZ9AK/tdfznNs/tbWkk5iNi5NS2oUZf7HX/E=; b=nRjn6aqRJQ/bj2DUrCl4qqMZtJuspmL4/4bFhu9ZTvyYxw80Gmhz5BOjMfVgjOP8wK GBEVIqbU/dpRspwItQGEVGVHwLNLBf3CbtTJq0ZFmDcVqJamK6rQRBf0270vh+eLHDYy 12XiEYs7cQISue5C9s4DleTiwn6Tp+8pqds1v6Q9PjGdh7ZbHApJyE1u/8Q95PsCdCoA jLfOUajfn7/cu9RQfZR7nVXT4+Gnr9vS0klFckImTOoGjCXNGpVxE+8VbPaPKtaNC8wj 5BGqDdonose8IhNUDvEqZqRlpkIrpRQOZtztso153DIa9o3nlyYFDyOjgZZMFRKc25d3 j0tQ== X-Gm-Message-State: AIVw113T5wQP0/mFDbnabbggHTOw9mfkYT8EL+D2VVNuLNJNoB2NDQwy 3nUlSDftlLGtY+4jgwWDUg== X-Received: by 10.223.136.178 with SMTP id f47mr1447091wrf.117.1500388884269; Tue, 18 Jul 2017 07:41:24 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:b861:3e9c:13d8:5a91? ([2001:67c:370:1998:b861:3e9c:13d8:5a91]) by smtp.gmail.com with ESMTPSA id b80sm4512705wmf.10.2017.07.18.07.41.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 07:41:23 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_324ACE75-D3B1-46C9-92C9-9411AB74024B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 16:41:22 +0200 References: <596CF817.8040900@foobar.org> <596D2D2D.5080406@foobar.org> <596E145C.8010603@foobar.org> To: IPv6 Operations In-Reply-To: <596E145C.8010603@foobar.org> Message-Id: <3EE8B48E-2C4A-4D24-9E3A-237A5F87938F@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:41:34 -0000 --Apple-Mail=_324ACE75-D3B1-46C9-92C9-9411AB74024B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 18, 2017, at 15:59, Nick Hilliard wrote: >=20 > However, there is no basis for you to assert that there was broad > agreement that IA_NA was a bad choice and less still to codify that > into a statement which, in your opinion, creates an IETF = recommendation > not to use DHCPv6 IA_NA. Once again, RFC 7934 does not entail that, and the only people in the = working group who are claiming that it does=E2=80=94 despite its = otherwise clear language=E2=80=94 are the authors of = I-D.hilliard-v6ops-host-addr-update. There is no recommendation in RFC = 7934=E2=80=94 explicit or implicit=E2=80=94 against the use of DHCPv6 = IA_NA in conjunction with other methods for hosts to obtain addresses = without making explicit requests to the network. There is a bullet list in =C2=A74 "Problems with Restricting the Number = of Addresses per Host=E2=80=9D that goes into some detail about some = (not all) of the problems with networks where hosts MUST acquire IPv6 = interface addresses with explicit requests to the network, e.g. using = DHCPv6 with IA_NA or IA_TA. Doing *that* is explicitly NOT RECOMMENDED = in =C2=A78 =E2=80=9CRecommendations=E2=80=9D of RFC 7934, and it is a = fact that most IPv6 network deployments conform to this best current = practice accordingly, and there are many additional well-known problems = with diverging from that practice that were not documented in RFC 7934. It=E2=80=99s not at all clear to me what is the purpose of this draft, = but if I understand correctly, then its objective is to propose that = IETF Best Current Practice include general purpose Internet networks = where general purpose hosts acquire IPv6 interface addresses only by = using DHCPv6 IA_NA requests to obtain addresses from a constrained pool = one at a time. I have a lot of difficulty seeing how that makes any = sense given the clear reasoning provided in RFC 7934 for the = recommendation against it. --james woodyatt > --Apple-Mail=_324ACE75-D3B1-46C9-92C9-9411AB74024B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 18, 2017, at 15:59, Nick Hilliard <nick@foobar.org> = wrote:

However, there is = no basis for you to assert that there was broad
agreement that IA_NA was a bad = choice and less still to codify = that
into a statement which, in your opinion, creates = an IETF recommendation
not to use DHCPv6 = IA_NA.

Once again, RFC 7934 does not entail that, and the = only people in the working group who are claiming that it does=E2=80=94 = despite its otherwise clear language=E2=80=94 are the authors of = I-D.hilliard-v6ops-host-addr-update. There is no recommendation in RFC = 7934=E2=80=94 explicit or implicit=E2=80=94 against the use of DHCPv6 = IA_NA in conjunction with other methods for hosts to obtain addresses = without making explicit requests to the network.

There is a bullet list = in =C2=A74 "Problems with Restricting the Number of Addresses per = Host=E2=80=9D that goes into some detail about some (not all) of the = problems with networks where hosts MUST acquire IPv6 interface addresses = with explicit requests to the network, e.g. using DHCPv6 with IA_NA or = IA_TA. Doing *that* is explicitly NOT RECOMMENDED in =C2=A78 = =E2=80=9CRecommendations=E2=80=9D of RFC 7934, and it is a fact that = most IPv6 network deployments conform to this best current practice = accordingly, and there are many additional well-known problems with = diverging from that practice that were not documented in RFC = 7934.

It=E2=80=99s not at all clear = to me what is the purpose of this draft, but if I understand correctly, = then its objective is to propose that IETF Best Current Practice include = general purpose Internet networks where general purpose hosts acquire = IPv6 interface addresses only by using DHCPv6 IA_NA requests to obtain = addresses from a constrained pool one at a time. I have a lot of = difficulty seeing how that makes any sense given the clear reasoning = provided in RFC 7934 for the recommendation against it.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_324ACE75-D3B1-46C9-92C9-9411AB74024B-- From nobody Tue Jul 18 07:54:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E91317BE for ; Tue, 18 Jul 2017 07:54:43 -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 FKck2LCskwaM for ; Tue, 18 Jul 2017 07:54:42 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF64129459 for ; Tue, 18 Jul 2017 07:54:42 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h199so14513384ith.1 for ; Tue, 18 Jul 2017 07:54: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=aGKpr0mqBSjjUXLhlgROBAghdUSWmKFSijq4DC2BFRY=; b=vIYeCXtzyVtPXhqC6HzUNJlUats1PbUXX0mbpY4By4Awl3La5pSSbQ4Q/aC6qrcGjC iV3Y39WH8GzKCBVQZCVDNhLkYYs4dvffnKizJ71K3J0jZKodl6XXVsRDXQWnkSa5uiDn ddR7XV48bJ0mrimbZZKPmDoyXAOMg5tgcHzf0itNjlWhSo0/Od9EjGYaOejYfCYza37i naQz6PzVVOxErxS9RY5qifTh/pZXlWSU0iO+kv/215quzsbDjUabS7fvZy9lbilEgtlm CkSIU3vpikpevyZr77pMzs5or7ZaPGHlzx6yD5QtFT/2n2iz0eOvkOMwhl/4AQicF+gI d1+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=aGKpr0mqBSjjUXLhlgROBAghdUSWmKFSijq4DC2BFRY=; b=oJ6cjL6RexONtW9rjtLx5xXIq/88/vTcCzSyKdNYKAONjzAMWwx2lwa+EUCd71kEuf dbOi69lOqT8f/oVY2laSOqTr9U/E6h5rt+SDufUfDCnWuYawy0U9NoYMNWPJMssnXAuU P5t7k09mOonHJmZLDzgucWs9OQD9mscur24DFOVkMKA+WiN5J8KX1UfKt9VHGESkGvKb UHdtx304Wi9dtaBDidRDJCzH0mNYz+2a4uPCzZ/7oF/Mu2loB041vjEhO0RFNR3koOY0 lG/7hDVcPKjSquz0dr6kM0QWlzYUU+m2l9VXDsh7h0l3Cl9ZFfxrpimxK74HDiMsY5d5 c+Kw== X-Gm-Message-State: AIVw112MpXpK45EtLgnFW9rcZ7Bj4mXRY2rYqqD7JtUXRAvbqzsaklUR qb4nt3JoctUurVZD4CJCOQePSTwW31jF5wk= X-Received: by 10.36.175.1 with SMTP id t1mr2881092ite.95.1500389681355; Tue, 18 Jul 2017 07:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.164 with HTTP; Tue, 18 Jul 2017 07:54:20 -0700 (PDT) In-Reply-To: <596E09CC.3@foobar.org> References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> <596DFD26.4050206@foobar.org> <596E09CC.3@foobar.org> From: Lorenzo Colitti Date: Tue, 18 Jul 2017 16:54:20 +0200 Message-ID: To: Nick Hilliard Cc: Ted Lemon , IPv6 Operations Content-Type: multipart/alternative; boundary="f403045dc136fc00d9055498b1a1" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:54:44 -0000 --f403045dc136fc00d9055498b1a1 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 3:14 PM, Nick Hilliard wrote: > I'm not attempting to determine consensus, simply expressing an opinion > that there was substantial opposition to the principals behind a > sentence that was inserted into the draft, i.e. querying whether that > consensus existed to start with. There isn't a problem with querying a > decision. > There was opposition on an earlier revision, but then the text was amended. I think it's fair to say that anyone wanting to continue to object had the opportunity to do so. The difficulty with formally appealing the consensus call is that the > change was inserted into the document in Feb 2016, There was no substantive change in this area since -01 was published in September 2015. The recommendation that if a network requires DHCPv6 it should use DHCPv6 PD to hand out a /64 has been in the draft since then. As an aside, the fact that there is a good deal of disagreement on its > interpretation today makes it clear that that this sentence is open to > vastly different interpretations. > I think a lot of the disagreement on interpretation is due to the fact that some in the discussion (including myself) have inappropriately characterized the RFC as recommending against the *use of DHCPv6 in general*. It doesn't - it recommends against *requiring* the use of IA_NA / IA_TA in order to use IPv6 on a particular network. I think the confusion is limited to this thread though; then RFC itself is pretty clear. --f403045dc136fc00d9055498b1a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 3:14 PM, Nick Hilliard <nick@foobar.org> w= rote:
I'm not attempting to determine= consensus, simply expressing an opinion
that there was substantial opposition to the principals behind a
sentence that was inserted into the draft, i.e. querying whether that
consensus existed to start with.=C2=A0 There isn't a problem with query= ing a
decision.

There was opposition on an ea= rlier revision, but then the text was amended. I think it's fair to say= that anyone wanting to continue to object had the opportunity to do so.

The difficulty with formal= ly appealing the consensus call is that the
change was inserted into the document in Feb 2016,

There was no substantive change in this area since -01 was publishe= d in September 2015. The recommendation that if a network requires DHCPv6 i= t should use DHCPv6 PD to hand out a /64 has been in the draft since then.<= /div>

As an aside, the fact th= at there is a good deal of disagreement on its
interpretation today makes it clear that that this sentence is open to
vastly different interpretations.

I thi= nk a lot of the disagreement on interpretation is due to the fact that some= in the discussion (including myself) have inappropriately characterized th= e RFC as recommending against the *use of DHCPv6 in general*. It doesn'= t =C2=A0- it recommends against *requiring* the use of IA_NA / IA_TA in ord= er to use IPv6 on a particular network. I think the confusion is limited to= this thread though; then RFC itself is pretty clear.
--f403045dc136fc00d9055498b1a1-- From nobody Tue Jul 18 08:24:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135C0128DE5 for ; Tue, 18 Jul 2017 08:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX_7Dh8kzU7i for ; Tue, 18 Jul 2017 08:23:58 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 D716212EC19 for ; Tue, 18 Jul 2017 08:23:57 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id k3so2369250ita.3 for ; Tue, 18 Jul 2017 08:23:57 -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=zs4VE2oCCDi7Tre67oUMW0mNJ1VxYy8G2ln67ZOPg8M=; b=Vbd6z5YFtdH3Y2veBo+q8YUD6PL2hVRIr8JVyFoqBjRMaQ9L8//HG+JbktzOGQthrl vAV6GlhH5HrQXok0RAjB/tNHtrlNTBXlOPSRQAD2QKp9LVB6TQnz13bJ6ZuxQAe+AXy8 Mf3VfBgG1ggCxxlB4hwwLhkewmJmiqqb6aK1ECtqkU7QkdWcz5TTYvIv7XwMP47b76Em 6I1pGvekgkJxZSlsUFA4IBP4xQjAcfdhPjolWwrhfN55P1tCBQ1whzjX0rGGnyEQ6o7t gBTq7pppn8U85CAs1MKOKfih672fJIj5hN55Bgj5qSBT5NBiF64WabGV7AGLiH6pQaMI ilFA== 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=zs4VE2oCCDi7Tre67oUMW0mNJ1VxYy8G2ln67ZOPg8M=; b=nW7Auio/mo0iL7jzwYnO+NFkT4d1e+Xl9/D8wc3J3Ch2Na/LzGXWx19HT+bqxlxUU1 xAdsnXgYRtm0rRfgG5Lnb1hIYM0xuIehiFquL2VmMMtTgTvhEi948UrRt4smfC/E859C ew+hcivd3NihOVpR97xrCRqB3qU4uKDhBJD6Xw3qrkZZgkQUZxamkKCzmDzbevcQg/Fh z0DPsTPe3RblcsiNAt1fT5n+60feHHnzftQ6ASilyxWCNPACFlkiojFWqF0twz/w8kyv TSQH1d8dbCFwHo+e3LVCwMwqzNOcaBZiCwH+fMteVDGFuL4FQE+oEuiqIrKGGsSDj55Y 04VQ== X-Gm-Message-State: AIVw113hh4LKEr7nJvly94x+OQBaiNKkpN+7/a/9ZqM28wrc/ng4Djzk IhfJ5t3Pcz4kJ7nRCYgN+qaH+Qd58cFkp6c= X-Received: by 10.36.196.67 with SMTP id v64mr2614812itf.89.1500391437055; Tue, 18 Jul 2017 08:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Tue, 18 Jul 2017 08:23:36 -0700 (PDT) In-Reply-To: <596CF817.8040900@foobar.org> References: <596CF817.8040900@foobar.org> From: Jen Linkova Date: Wed, 19 Jul 2017 01:23:36 +1000 Message-ID: To: Nick Hilliard Cc: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:24:04 -0000 I have read the draft and re-read rfc7934 and now I'm completely confused. First of all, I can not see where rfc7934 says that DHCPv6 is not recommended. I had to use all my imagination and still not sure how the phrase 'it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests.' can be read as 'DHCPv6 is not recommended'. Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot use new addresses without requesting them from a DHCPv6 server on the network.' does not seem to be accurate. As this statement appears to be the key point of your document, I believe it needs to be fixed before we can proceed. The third point: "The third paragraph notes that DHCPv6 stateful address assignment (IA_NA or IA_TA) can be used to provide multiple addresses when the host connects to the network, but does not mention that the host can issue multiple dhcpv6 requests, thereby allowing arbitrary numbers of assignments rather than the stated limit of approximately 30. As the text in this paragraph is incorrect, it too has been removed. " If you believe the text is incorrect (or shall I say 'incomplete'?) as it does not mention multiple requests, it would probably make sense to see some suggestions on amending the text, updating it with details re: multiple requests? I do not think that the second and third paragraphs should be removed as they contain clarifications on the recommendations provided in the first paragraph. Removing them would make the document less clear and would open the door to misrepresentations instead of preventing them. Last but not least...The first paragraph of the section 3 sounds a bit like an overstatement..It's not clear from that text how recommendations provided in the rfc7934 can have such dramatic impact on the future of DHCPv6. On Tue, Jul 18, 2017 at 3:47 AM, Nick Hilliard wrote: > draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID. > > It has recently been claimed that IETF best current practice is that > DHCPv6 is not recommended due to the recommendations section in > RFC7934/BCP204. > > The relevant text was slipped into > draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of > days before the document went into IETF LC. There was no discussion > about this text change either in the v6ops working group or at IETF > review or IESG level: perhaps the modification appeared innocuous or > maybe it just wasn't not noticed. > > Next thing, there's a BCP which is being interpreted as meaning that > DHCPv6 is NOT RECOMMENDED for operational use. Wow. :-) > > This presents a variety of problems, the most serious of which are 1) > that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED" > without extensive discussion or debate about this particular issue at > the relevant working group, and ignores the both the widespread use of > the protocol and its active development at the ietf, and 2) that a > change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole > in the IPv6 host specification. > > Job and I believe that this went through by mistake and that if the WG > had noticed the change at the time, consensus would never have been > reached on what is a serious semantic change to IETF lore. > > Right now, the most prudent course of action would be to roll back the > change until a proper debate has been had. We invite WG comments on > this doc. > > Nick > > internet-drafts@ietf.org wrote: >> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt >> has been successfully submitted by Nick Hilliard and posted to the >> IETF repository. >> >> Name: draft-hilliard-v6ops-host-addr-update >> Revision: 00 >> Title: Update for IPv6 Host Address Availability Recommendations >> Document date: 2017-07-17 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt >> Status: https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/ >> Htmlized: https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00 >> >> >> Abstract: >> The IPv6 Host Address Availability Recommendations Best Current >> Practice (RFC 7934), describes why IPv6 hosts should use multiple >> global addresses when attaching to a network. This document updates >> RFC 7934 by removing a recommendation for networks to give the host >> the ability to use new addresses without requiring explicit requests. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry From nobody Tue Jul 18 08:37:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7508131A54 for ; Tue, 18 Jul 2017 08:37:47 -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 bzPXOheRqlm1 for ; Tue, 18 Jul 2017 08:37:46 -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 452D412EC3F for ; Tue, 18 Jul 2017 08:37:45 -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 v6IFbjTW046100; Tue, 18 Jul 2017 08:37:45 -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 v6IFbZRr045598 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 18 Jul 2017 08:37:35 -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; Tue, 18 Jul 2017 08:37:34 -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, 18 Jul 2017 08:37:34 -0700 From: "Templin, Fred L" To: Francis Dupont , Ted Lemon CC: IPv6 Ops WG Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHS/6oaWot1NBqzi02aMaVjO9WlAaJZt+6w Date: Tue, 18 Jul 2017 15:37:34 +0000 Message-ID: References: Your message of Tue, 18 Jul 2017 10:55:10 +0200. <201707180925.v6I9PBdf040428@givry.fdupont.fr> In-Reply-To: <201707180925.v6I9PBdf040428@givry.fdupont.fr> 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: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:37:48 -0000 I have been running my own little DHCPv6 PD client on Android for a long ti= me. Works great with the kea server, and probably with other DHCPv6 servers tha= t I haven't had time to try yet. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Francis Dupont > Sent: Tuesday, July 18, 2017 2:25 AM > To: Ted Lemon > Cc: IPv6 Ops WG > Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android >=20 > In your previous mail you wrote: >=20 > > I think you can do DHCPv4 on linux without using LPF. Also possibly = on > > various modern BSDs. The advanced socket API appears to support this= . >=20 > =3D> this is why I added "on some systems". Note it is harder on the clie= nt > side, and on the server side with a relay BPF/LBF/... is never required. > Of course this applies only to DHCPv4. >=20 > Regards >=20 > Francis.Dupont@fdupont.fr >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 18 10:38:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDD5131B57 for ; Tue, 18 Jul 2017 10:38: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, 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 y0-s4mUJ9fLA for ; Tue, 18 Jul 2017 10:38:10 -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 53B0012EC3A for ; Tue, 18 Jul 2017 10:38:10 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 35so32215390uax.3 for ; Tue, 18 Jul 2017 10:38:10 -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=lCa/pb1Of8m9/s2C5hXGOsPfyjES073MCml3qVAJ6nU=; b=MoMMT/QSMQZtKHUHew9bMqIgCLt0x3uN4j28Y2FWvwbwRnTHxzFuAXuIRp2ZCau0Ze nQ5M6WSUuhdo47bFjYWO/YLJWRy65RHArnSMIGiTvbUMtHJ68801Q/NlRbA2rEzFvjRT GHJqhEwG7qfVgUrpIxu03kh6FOWIS8QChwjJI3JRIlWV+f92LRj+y+6EPIYCH0Y5Wx2K p+f6gNYlmCsPg4WbIVjsDmCJX8+2dJxHzs872XchNIkw9dYhC84BRgHnQg6AR5EfOuFB rJKsqSWRYdq/c+dNhuGcU0PoVg9xc1T5K9i9KNnw1tRldcHK/sGm9Z0XfEomd4/tnG6n jT/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=lCa/pb1Of8m9/s2C5hXGOsPfyjES073MCml3qVAJ6nU=; b=PNaAVO2f3OmuWTGhaHmUJ9Gc4KCswgV9C10HCIRm6mzgPYpecVvOJBvWTpChNAOIHr Q4pLiyzgUwBkKmxrHkRv3A08C8t7Uv8LL4RUBjVnNEB6B25xJ6/x29MKPpdUX9TA03AN SfXsJO29QHRHlxJ1mtWjS+YuCoAbkCLFgWEMfp8Zz68rMHb/dUX5wmUWN/NW1LWMzpmP 3SgN10NXvPDHL4DsYshSBZNEyQ2iMEFbbff+/NoyRf7CdmucqKGhrGzWhCUEnR/YBEjE MZQtAMrH++zmft4EWlUYpu74+AXoBHwdm+t8ITp1jy9J8KhCDyGIuVP86LK98CNa21EJ X17g== X-Gm-Message-State: AIVw111S5DW24ce0+CBspdFe6OLsyzcacW/GfKp3OT8NlilB8jod06Na N1CuMmluWIXFNXuvcklkXiQxeM+Psw== X-Received: by 10.31.70.6 with SMTP id t6mr1331229vka.21.1500399489372; Tue, 18 Jul 2017 10:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.164.72 with HTTP; Tue, 18 Jul 2017 10:38:08 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Scott Morizot Date: Tue, 18 Jul 2017 12:38:08 -0500 Message-ID: To: Mark Smith Cc: Nick Hilliard , IPv6 Operations Content-Type: multipart/alternative; boundary="001a11484e3895d74405549afa98" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:38:13 -0000 --001a11484e3895d74405549afa98 Content-Type: text/plain; charset="UTF-8" Perhaps the actual problem is a limited active participation in the IETF process by certain groups, such as the large enterprise networks (outside enterprise networks of large technology companies) sphere? That has always been my day to day environment and focus whether as an application developer, network engineer, or from any of the other hats that are dropped in my lap, including interacting with groups of organizations outside my own. I confess I read mailing list discussions intermittently and actively say anything much less frequently than I read. But comments like the below leave me bemused. Those sorts of networks are highly constrained. Hosts and developers have to coordinate even to be allowed on the network. Things that are purchased and deployed generally have to meet our requirements and lots of things are eliminated from consideration because they don't. If something has special requirements, there's a lengthy process designing, testing, and documenting the changes in the security boundary. Innovation is certainly restricted and coordinated, even with in house developed applications. There are lots of processes and tools integrated with DHCP assignment information. But that's hardly the only data collected, the only layer of protection, or the only avenue pursued when doing forensic analysis of an attack. Connection security in one form or another is used. ARP/Neighbor table information (as well as configuration in general) is collected and tracked. Log data at every level is collected. There's IDS/IPS and packet collectors at different key points. There are firewalls at all sorts of different points from the host up. But no large enterprise is merely looking for purely malicious traffic. They are also auditing and analyzing all activity by authorized users. It's a highly inspected, highly constrained networking environment and always will be. A lot of those automated processes are tied into DHCP data. It's not that that's the only source of forensic data, the sole audit point, or the single point of protection. But a lot of automated tools/processes are built around that data and that is not going to change quickly. Perhaps when IPv4 is removed from much of the enterprise, it can be considered, though there would have to be a compelling reason for enterprises to make such a change. No such compelling reason currently exists. It will not happen before then except in very special circumstances on different networks from most hosts, not on general purpose data networks. Host developers who want to sell to such enterprises will support DHCPv6 IA_NA address assignment on networks that provide no other alternative. They already do for the most part because those networks exist today. And they will continue to exist for a good number of years to come, whatever the IETF decides to recommend or not recommend. If a host/node developer has a special use case (as a limited IOT device such as door key card access devices and alarm sensors very well might) and a large enterprise of the sort I've described has a need for it, that might be engineered in a special network of its own. So it's not an absolute that any given host/node that wants to sell to large enterprises of the sort I've noted above has to support DHCPv6 IA_NA address assignment. But as a general rule of thumb? That should probably be the default expectation. It should be considered, at least. So I support the idea behind the changes to RFC 7934 proposed in the draft, however they might be wordsmithed, as it more accurately reflects reality. The current description may reflect a "best common practice" for general use data on some networks and in some environments. It is not even vaguely the common practice elsewhere. And it's unlikely to be anytime soon. If the purpose of the document is to express what the IETF wished were the common practice on most networks, that's fine. If its purpose is to express the actual common practice, the current document falls short. I have a hard time feeling too strongly about it, though. Host/node developers often do want to sell to large enterprises, and as such they typically will meet their specified requirements. I don't expect that to change whatever the IETF chooses to publish. That's one situation in which money does usually talk. Scott On Mon, Jul 17, 2017 at 7:59 PM, Mark Smith wrote: > Fundamentally, we don't want hosts and application developers to have > to ask for permission from the network to innovate, nor have the > network impose artificial constraints on innovation. Artificial > address scarcity is following the traditional telephone network > scarcity model. (See David Isenberg's "Rise of the Stupid Network") > > --001a11484e3895d74405549afa98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps the actual problem is a limited active participati= on in the IETF process by certain groups, such as the large enterprise netw= orks (outside enterprise networks of large technology companies) sphere? Th= at has always been my day to day environment and focus whether as an applic= ation developer, network engineer, or from any of the other hats that are d= ropped in my lap, including interacting with groups of organizations outsid= e my own. I confess I read mailing list discussions intermittently and acti= vely say anything much less frequently than I read. But comments like the b= elow leave me bemused.

Those sorts of networks are highl= y constrained. Hosts and developers have to coordinate even to be allowed o= n the network. Things that are purchased and deployed generally have to mee= t our requirements and lots of things are eliminated from consideration bec= ause they don't. If something has special requirements, there's a l= engthy process designing, testing, and documenting the changes in the secur= ity boundary. Innovation is certainly restricted and coordinated, even with= in house developed applications.

There are lots o= f processes and tools integrated with DHCP assignment information. But that= 's hardly the only data collected, the only layer of protection, or the= only avenue pursued when doing forensic analysis of an attack. Connection = security in one form or another is used. ARP/Neighbor table information (as= well as configuration in general) is collected and tracked. Log data at ev= ery level is collected. There's IDS/IPS and packet collectors at differ= ent key points. There are firewalls at all sorts of different points from t= he host up. But no large enterprise is merely looking for purely malicious = traffic. They are also auditing and analyzing all activity by authorized us= ers. It's a highly inspected, highly constrained networking environment= and always will be.

A lot of those automated proc= esses are tied into DHCP data. It's not that that's the only source= of forensic data, the sole audit point, or the single point of protection.= But a lot of automated tools/processes are built around that data and that= is not going to change quickly. Perhaps when IPv4 is removed from much of = the enterprise, it can be considered, though there would have to be a compe= lling reason for enterprises to make such a change. No such compelling reas= on currently exists. It will not happen before then except in very special = circumstances on different networks from most hosts, not on general purpose= data networks.

Host developers who want to sell t= o such enterprises will support DHCPv6 IA_NA address assignment on networks= that provide no other alternative. They already do for the most part becau= se those networks exist today. And they will continue to exist for a good n= umber of years to come, whatever the IETF decides to recommend or not recom= mend. If a host/node developer has a special use case (as a limited IOT dev= ice such as door key card access devices and alarm sensors very well might)= and a large enterprise of the sort I've described has a need for it, t= hat might be engineered in a special network of its own. So it's not an= absolute that any given host/node that wants to sell to large enterprises = of the sort I've noted above has to support DHCPv6 IA_NA address assign= ment. But as a general rule of thumb? That should probably be the default e= xpectation. It should be considered, at least.

So = I support the idea behind the changes to RFC 7934 proposed in the draft, ho= wever they might be wordsmithed, as it more accurately reflects reality. Th= e current description may reflect a "best common practice" for ge= neral use data on some networks and in some environments. It is not even va= guely the common practice elsewhere. And it's unlikely to be anytime so= on. If the purpose of the document is to express what the IETF wished were = the common practice on most networks, that's fine. If its purpose is to= express the actual common practice, the current document falls short.

I have a hard time feeling too strongly about it, thou= gh. Host/node developers often do want to sell to large enterprises, and as= such they typically will meet their specified requirements. I don't ex= pect that to change whatever the IETF chooses to publish. That's one si= tuation in which money does usually talk.=C2=A0

Sc= ott

On = Mon, Jul 17, 2017 at 7:59 PM, Mark Smith <markzzzsmith@gmail.com&= gt; wrote:
Fundamentally, we don&#= 39;t want hosts and application developers to have
to ask for permission from the network to innovate, nor have the
network impose artificial constraints on innovation. Artificial
address scarcity is following the traditional telephone network
scarcity model. (See David Isenberg's "Rise of the Stupid Network&= quot;)

--001a11484e3895d74405549afa98-- From nobody Tue Jul 18 10:55:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB92A131B19 for ; Tue, 18 Jul 2017 10:55: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 pg61pcAGd_g7 for ; Tue, 18 Jul 2017 10:55:00 -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 5E831131B66 for ; Tue, 18 Jul 2017 10:54:59 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id u5so16539459pgq.3 for ; Tue, 18 Jul 2017 10:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nQCv2agBwlEL2PS5mSxFTNHvaHdh790aVeOEyL2V4KU=; b=sYoLEBB+6vsPUmxHF7Bif4qMaURG+sRQdXZjP3S2RjHgCyt01ZH27PiViU7dJSPA4V 95D0ppN9JqocrWEfePeBMIbnM7stoWzTw0Nl5+ngUXOSYuvpmpW4ojpVQTpqGKKf2LiG FdCk/GLcCXi6+PSDsNgQb89s7M0HmugjHCu538z2g24sUWlRWMDCao0EhZhPg2EIMdrt dNyZKFw/MymB42Vfbq4Brft2MQRj3ilVVE7BnNQjhN8Z503Kk/5mlCokWScgcQYtdCj9 ciuVgYDLQ+BWGiVtIJCBeERBX+Dr1DvntuzGU6jHBevacFx+ld1zWXE/+GWbpLL4luTL VAnw== 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=nQCv2agBwlEL2PS5mSxFTNHvaHdh790aVeOEyL2V4KU=; b=ckgmpiEMMuMQIkLNwsvDKZT5ZBDJ+9fT54zvUXko95dd8HcTkoSn4iFAzjvzYe8BVM HJMlArugrn7BhyQWGkVVS7iuewr89rCpnDc6Wvb7echuDj7ggfEyrAgysbt45O6TsCrC zF4VLmvdzuNvQ27+BF+S+G5tBOO2KmCm7n7Cn9MVcaBfSpA+oCCOCDpeOLSiX7TMi0rU 3XQqlzW5nc7PINIbqSV6aZMJhtTpZE67Dgli0+0HXKaw1KNwRMtK81+DJCtmwhUcwNre rF7LMep+Ut6iT0uK5CQuUrk3+kGvNMq5pLs2KiR4dU0c16LBTEShyKOcjB3JqpUi5Yzx hJiw== X-Gm-Message-State: AIVw110ECYAg5110awJ+HTLofcvMeIPvEU+CGdZmenQ4yYEI/x3DsZg4 dRrB62IqMphMxSg46Np5YGuU0fUOxp9A X-Received: by 10.99.62.65 with SMTP id l62mr2924506pga.220.1500400498863; Tue, 18 Jul 2017 10:54:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 10:54:18 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Ted Lemon Date: Tue, 18 Jul 2017 19:54:18 +0200 Message-ID: To: Scott Morizot Cc: Mark Smith , IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c18ff6ac1852505549b363d" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:55:05 -0000 --94eb2c18ff6ac1852505549b363d Content-Type: text/plain; charset="UTF-8" The current document recommends generally against the particular use of DHCP that you are using, but does not forbid it. This is the correct recommendation for most devices on the Internet. The set of devices that you use do not fall into that category, so the suggestion is really not at all applicable to your use case. This is why the document says what it says. It doesn't even say "SHOULD NOT." It just says "won't have good privacy characteristics, and therefore is not preferred." Asking that IETF recommendations, which, again, remember, are aimed at *all devices on the internet*, instead be tailored to just your use case, is not reasonable. The reason that the language reads the way it does is so as to not exclude your use case. I don't see how you could possibly justify language that was any more accommodating of your use case. As you say, vendors of the sorts of devices that you use are not going to read that document and think "oh, I guess I should disable IA_NA support now." So what exactly would an update accomplish? Please don't send another long wall of text. Just explain how we can balance these two competing needs better than we currently are doing? On Tue, Jul 18, 2017 at 7:38 PM, Scott Morizot wrote: > Perhaps the actual problem is a limited active participation in the IETF > process by certain groups, such as the large enterprise networks (outside > enterprise networks of large technology companies) sphere? That has always > been my day to day environment and focus whether as an application > developer, network engineer, or from any of the other hats that are dropped > in my lap, including interacting with groups of organizations outside my > own. I confess I read mailing list discussions intermittently and actively > say anything much less frequently than I read. But comments like the below > leave me bemused. > > Those sorts of networks are highly constrained. Hosts and developers have > to coordinate even to be allowed on the network. Things that are purchased > and deployed generally have to meet our requirements and lots of things are > eliminated from consideration because they don't. If something has special > requirements, there's a lengthy process designing, testing, and documenting > the changes in the security boundary. Innovation is certainly restricted > and coordinated, even with in house developed applications. > > There are lots of processes and tools integrated with DHCP assignment > information. But that's hardly the only data collected, the only layer of > protection, or the only avenue pursued when doing forensic analysis of an > attack. Connection security in one form or another is used. ARP/Neighbor > table information (as well as configuration in general) is collected and > tracked. Log data at every level is collected. There's IDS/IPS and packet > collectors at different key points. There are firewalls at all sorts of > different points from the host up. But no large enterprise is merely > looking for purely malicious traffic. They are also auditing and analyzing > all activity by authorized users. It's a highly inspected, highly > constrained networking environment and always will be. > > A lot of those automated processes are tied into DHCP data. It's not that > that's the only source of forensic data, the sole audit point, or the > single point of protection. But a lot of automated tools/processes are > built around that data and that is not going to change quickly. Perhaps > when IPv4 is removed from much of the enterprise, it can be considered, > though there would have to be a compelling reason for enterprises to make > such a change. No such compelling reason currently exists. It will not > happen before then except in very special circumstances on different > networks from most hosts, not on general purpose data networks. > > Host developers who want to sell to such enterprises will support DHCPv6 > IA_NA address assignment on networks that provide no other alternative. > They already do for the most part because those networks exist today. And > they will continue to exist for a good number of years to come, whatever > the IETF decides to recommend or not recommend. If a host/node developer > has a special use case (as a limited IOT device such as door key card > access devices and alarm sensors very well might) and a large enterprise of > the sort I've described has a need for it, that might be engineered in a > special network of its own. So it's not an absolute that any given > host/node that wants to sell to large enterprises of the sort I've noted > above has to support DHCPv6 IA_NA address assignment. But as a general rule > of thumb? That should probably be the default expectation. It should be > considered, at least. > > So I support the idea behind the changes to RFC 7934 proposed in the > draft, however they might be wordsmithed, as it more accurately reflects > reality. The current description may reflect a "best common practice" for > general use data on some networks and in some environments. It is not even > vaguely the common practice elsewhere. And it's unlikely to be anytime > soon. If the purpose of the document is to express what the IETF wished > were the common practice on most networks, that's fine. If its purpose is > to express the actual common practice, the current document falls short. > > I have a hard time feeling too strongly about it, though. Host/node > developers often do want to sell to large enterprises, and as such they > typically will meet their specified requirements. I don't expect that to > change whatever the IETF chooses to publish. That's one situation in which > money does usually talk. > > Scott > > On Mon, Jul 17, 2017 at 7:59 PM, Mark Smith > wrote: > >> Fundamentally, we don't want hosts and application developers to have >> to ask for permission from the network to innovate, nor have the >> network impose artificial constraints on innovation. Artificial >> address scarcity is following the traditional telephone network >> scarcity model. (See David Isenberg's "Rise of the Stupid Network") >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --94eb2c18ff6ac1852505549b363d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current document recommends generally against the part= icular use of DHCP that you are using, but does not forbid it. =C2=A0 This = is the correct recommendation for most devices on the Internet. =C2=A0 The = set of devices that you use do not fall into that category, so the suggesti= on is really not at all applicable to your use case. =C2=A0 This is why the= document says what it says. =C2=A0 It doesn't even say "SHOULD NO= T." =C2=A0 It just says "won't have good privacy characterist= ics, and therefore is not preferred."

Asking that I= ETF recommendations, which, again, remember, are aimed at all devices on= the internet, instead be tailored to just your use case, is not reason= able. =C2=A0 The reason that the language reads the way it does is so as to= not exclude your use case. =C2=A0 I don't see how you could possibly j= ustify language that was any more accommodating of your use case. =C2=A0 As= you say, vendors of the sorts of devices that you use are not going to rea= d that document and think "oh, I guess I should disable IA_NA support = now."

So what exactly would an update accompl= ish? =C2=A0 Please don't send another long wall of text. =C2=A0 Just ex= plain how we can balance these two competing needs better than we currently= are doing?

On Tue, Jul 18, 2017 at 7:38 PM, Scott Morizot <= tmorizot@gmail.com<= /a>> wrote:
Pe= rhaps the actual problem is a limited active participation in the IETF proc= ess by certain groups, such as the large enterprise networks (outside enter= prise networks of large technology companies) sphere? That has always been = my day to day environment and focus whether as an application developer, ne= twork engineer, or from any of the other hats that are dropped in my lap, i= ncluding interacting with groups of organizations outside my own. I confess= I read mailing list discussions intermittently and actively say anything m= uch less frequently than I read. But comments like the below leave me bemus= ed.

Those sorts of networks are highly constrained. Host= s and developers have to coordinate even to be allowed on the network. Thin= gs that are purchased and deployed generally have to meet our requirements = and lots of things are eliminated from consideration because they don't= . If something has special requirements, there's a lengthy process desi= gning, testing, and documenting the changes in the security boundary. Innov= ation is certainly restricted and coordinated, even with in house developed= applications.

There are lots of processes and too= ls integrated with DHCP assignment information. But that's hardly the o= nly data collected, the only layer of protection, or the only avenue pursue= d when doing forensic analysis of an attack. Connection security in one for= m or another is used. ARP/Neighbor table information (as well as configurat= ion in general) is collected and tracked. Log data at every level is collec= ted. There's IDS/IPS and packet collectors at different key points. The= re are firewalls at all sorts of different points from the host up. But no = large enterprise is merely looking for purely malicious traffic. They are a= lso auditing and analyzing all activity by authorized users. It's a hig= hly inspected, highly constrained networking environment and always will be= .

A lot of those automated processes are tied into= DHCP data. It's not that that's the only source of forensic data, = the sole audit point, or the single point of protection. But a lot of autom= ated tools/processes are built around that data and that is not going to ch= ange quickly. Perhaps when IPv4 is removed from much of the enterprise, it = can be considered, though there would have to be a compelling reason for en= terprises to make such a change. No such compelling reason currently exists= . It will not happen before then except in very special circumstances on di= fferent networks from most hosts, not on general purpose data networks.

Host developers who want to sell to such enterprises = will support DHCPv6 IA_NA address assignment on networks that provide no ot= her alternative. They already do for the most part because those networks e= xist today. And they will continue to exist for a good number of years to c= ome, whatever the IETF decides to recommend or not recommend. If a host/nod= e developer has a special use case (as a limited IOT device such as door ke= y card access devices and alarm sensors very well might) and a large enterp= rise of the sort I've described has a need for it, that might be engine= ered in a special network of its own. So it's not an absolute that any = given host/node that wants to sell to large enterprises of the sort I'v= e noted above has to support DHCPv6 IA_NA address assignment. But as a gene= ral rule of thumb? That should probably be the default expectation. It shou= ld be considered, at least.

So I support the idea = behind the changes to RFC 7934 proposed in the draft, however they might be= wordsmithed, as it more accurately reflects reality. The current descripti= on may reflect a "best common practice" for general use data on s= ome networks and in some environments. It is not even vaguely the common pr= actice elsewhere. And it's unlikely to be anytime soon. If the purpose = of the document is to express what the IETF wished were the common practice= on most networks, that's fine. If its purpose is to express the actual= common practice, the current document falls short.

I have a hard time feeling too strongly about it, though. Host/node devel= opers often do want to sell to large enterprises, and as such they typicall= y will meet their specified requirements. I don't expect that to change= whatever the IETF chooses to publish. That's one situation in which mo= ney does usually talk.=C2=A0

Scott

On Mon, Jul 17, 201= 7 at 7:59 PM, Mark Smith <markzzzsmith@gmail.com> wrote= :
Fundamentally, we don't want hosts = and application developers to have
to ask for permission from the network to innovate, nor have the
network impose artificial constraints on innovation. Artificial
address scarcity is following the traditional telephone network
scarcity model. (See David Isenberg's "Rise of the Stupid Network&= quot;)


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


--94eb2c18ff6ac1852505549b363d-- From nobody Tue Jul 18 10:57:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB4131A66 for ; Tue, 18 Jul 2017 10:57:38 -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 WlZutalv0xUk for ; Tue, 18 Jul 2017 10:57:36 -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 3F7A112EC15 for ; Tue, 18 Jul 2017 10:57:36 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id y47so17564991uag.0 for ; Tue, 18 Jul 2017 10:57:36 -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=4hgG3Povy8dQltr6BpegKYelVPbrggS28Qs+1ONHfzo=; b=MjBAZuWoaNk7H3ax7jcUBRqhQbvw7Jxz8ewXMLqjQ1DivULE1KAx+S4r189xqYWkgv gh5CT6NDQzmO/KJefbStY6s47woJDn31/n0+dSEZPk+SBUB54BLuN9AaYA78UDv0Y0Q5 zbEf9cdEjbZm38ADq2ZcFcvlkTHmg7J6ACikZ7NLJ3bW5rUdgGSvrjwB4ARHg6moTMxh wZrNMuRqy6eXxT/Yw+bn1zN818EDOWfzYSIsULlC0Xy1EE1dtwkvFMWjuVyCZBxdAr+7 rh2S9oBNfKTqx0sysYDojt7c/oFJztIjfpUjOkXMVHINW4msPQ6qe7AGsxhzFlxpQEUc MPlw== 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=4hgG3Povy8dQltr6BpegKYelVPbrggS28Qs+1ONHfzo=; b=LybPcuzLtUj5Lw0PIx03GtUFpkXsOiLu5pCBKW41qMTC8Q+fCU03d2GZv7d/RLvgf4 LUr4lynfqr+QbAEm5fwIUZUw7C3otQ+UCn1BcJ9vrWavpV4mlwFMJ/qFwZvXKPNOyzNV umFjI99qxn9tNvBqJd8To27AyqeO0POueP5Ims8ITrHyXcA+06JWhMqu0xz1AXfeTXFG +UxkVo+sYOcWuvDP0C7wtozCssK7p8vtQ+Ofi6hWBD3sRRa7KxFDq+E3NENsa2RTx7rZ 8YH3tkKVBtN4Z4ouP5Yz7SJiDuGcyf3csWKb2RAfUErmswDGDwKSh5Gms3xk6pjBnzA3 onjA== X-Gm-Message-State: AIVw112xHJKs4YPr3A2MVtvlsvX7lMuIN4F67dxb9bNM2t+3xR39eE1R NAvqPYjbqOW53rEU/l4ybCkRL2hiyh/fKjY= X-Received: by 10.176.4.111 with SMTP id 102mr1647435uav.146.1500400655435; Tue, 18 Jul 2017 10:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.164.72 with HTTP; Tue, 18 Jul 2017 10:57:34 -0700 (PDT) In-Reply-To: <3EE8B48E-2C4A-4D24-9E3A-237A5F87938F@google.com> References: <596CF817.8040900@foobar.org> <596D2D2D.5080406@foobar.org> <596E145C.8010603@foobar.org> <3EE8B48E-2C4A-4D24-9E3A-237A5F87938F@google.com> From: Scott Morizot Date: Tue, 18 Jul 2017 12:57:34 -0500 Message-ID: To: jhw@google.com Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c056834168b3005549b403e" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:57:38 -0000 --94eb2c056834168b3005549b403e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2017 at 9:41 AM, james woodyatt wrote: > > It=E2=80=99s not at all clear to me what is the purpose of this draft, bu= t if I > understand correctly, then its objective is to propose that IETF Best > Current Practice include general purpose Internet networks where general > purpose hosts acquire IPv6 interface addresses only by using DHCPv6 IA_NA > requests to obtain addresses from a constrained pool one at a time. I hav= e > a lot of difficulty seeing how that makes any sense given the clear > reasoning provided in RFC 7934 for the recommendation against it. > > I have no particular problem with that as a recommendation for general purpose Internet networks if the recommendation is intended to exclude a significant chunk of the enterprise network world. For a general purpose network meant to support devices controlled and operated by other parties from the network operators, it may even be a fine recommendation. (That's not really my world, so I can't say.) I think this came up, if I tracked discussions properly (a big if), because this recommendation for address assignment in general purpose networks was used as one of the reasons to fight against recommending that node developers should support DHCPv6 elsewhere. Again, not really a node/client developer except in the past for some limited in house things, but that strikes me as bad advice to that group depending on their target user. Of course, I don't really think such developers are going to rely on an IETF recommendation to decide which features they need to incorporate anyway. Or at least not solely. So that's why I don't feel too strongly about it either way. I would object more strenuously if someone were actually trying to change the actual DHCPv6 protocol standard to eliminate IA_NA/IA_TA, but I believe there would be a chorus of objections to such a move anyway, so I'm not particularly concerned about that. --94eb2c056834168b3005549b403e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 9:41 AM, james woodyatt <jhw@google.com> = wrote:

It=E2=80=99s not at all clear to me what is the = purpose of this draft, but if I understand correctly, then its objective is= to propose that IETF Best Current Practice include general purpose Interne= t networks where general purpose hosts acquire IPv6 interface addresses onl= y by using DHCPv6 IA_NA requests to obtain addresses from a constrained poo= l one at a time. I have a lot of difficulty seeing how that makes any sense= given the clear reasoning provided in RFC 7934 for the recommendation agai= nst it.


I = have no particular problem with that as a recommendation for general purpos= e Internet networks if the recommendation is intended to exclude a signific= ant chunk of the enterprise network world. For a general purpose network me= ant to support devices controlled and operated by other parties from the ne= twork operators, it may even be a fine recommendation. (That's not real= ly my world, so I can't say.)

I think this cam= e up, if I tracked discussions properly (a big if), because this recommenda= tion for address assignment in general purpose networks was used as one of = the reasons to fight against recommending that node developers should suppo= rt DHCPv6 elsewhere. Again, not really a node/client developer except in th= e past for some limited in house things, but that strikes me as bad advice = to that group depending on their target user. Of course, I don't really= think such developers are going to rely on an IETF recommendation to decid= e which features they need to incorporate anyway. Or at least not solely. S= o that's why I don't feel too strongly about it either way.=C2=A0

I would object more strenuously if someone were act= ually trying to change the actual DHCPv6 protocol standard to eliminate IA_= NA/IA_TA, but I believe there would be a chorus of objections to such a mov= e anyway, so I'm not particularly concerned about that.
--94eb2c056834168b3005549b403e-- From nobody Tue Jul 18 11:13:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11264131B3F for ; Tue, 18 Jul 2017 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 ma5ynYLk50gh for ; Tue, 18 Jul 2017 11:12:59 -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 B075D131668 for ; Tue, 18 Jul 2017 11:12:59 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 123so16907631pgj.1 for ; Tue, 18 Jul 2017 11:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wTDBr+BOh6QwV3XkZHEVVMoQF9jVCW1Vs4GMVlkqB+k=; b=mrbGiNam6A1LOdfFeZF1XrdVqj2cl8xhkFGzW4McyCc2Q1Il3pwb7TewVK1BJOViDj PV7BZvgDPytCWPft05cz7L6gQOfOyaEs43078xN9rb9SqXqqck5GqWWiUORnaSvD9UP4 kwhbagzb1PRxHvmFo1VuaBgHoebiBXnn3fODqaZN3ki8FSK6Kno1bqRIkG3YsfrLkgqw 2lWgbcB3OxDRq8UkpTinQKSK1RZkiE5Bua84xsp1fMycwZjia1zAxGJPPPTXWkmpS3Wx zww7oloMlscWu3Z0P54IQ/PMqE6qAZYEvmMIytmCvI4I9OkxxylepH8/A6FbEZh51PSy obgg== 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=wTDBr+BOh6QwV3XkZHEVVMoQF9jVCW1Vs4GMVlkqB+k=; b=jMCfrqFtXe71vhD0oWS65mfDMLae+7FF85qYN0zgrjcySKAFXI113wQfck/2pzyS9p Adaezup58uRmG6/Ef5KnC+I8t5/0xC3TG01QBPuk+Q62rkzT4oMMXbZPcvj9ZVnG9Q0P rLRbc/IkcL5QjKu7dFu2rd7v14/3jBPiHNWo1KgV31faLQ0GpFUS4abBR9IzPJyVR5+h FaRqbkvNApV9gk+zVuLNzJz3nzjSdtEnGBPoUIKLEfQLULIzztBQEsXEfGwl61e9DXL1 lxw37p7Bcw0F7vNrsKGYqOoXX772b162eT2T+NAs9FMrbFbZ0GDlUflmV+D9uCaQdZD2 AX/Q== X-Gm-Message-State: AIVw110KQ6upJjPdTxksurfvnwBZrWK92Z6t8hb/JhXP6fiGr6rZcHVy wtlifRDEdQXtvGW0ZUWSIo+WUAQzzrzp X-Received: by 10.98.15.71 with SMTP id x68mr3047662pfi.176.1500401579060; Tue, 18 Jul 2017 11:12:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 11:12:18 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <596D2D2D.5080406@foobar.org> <596E145C.8010603@foobar.org> <3EE8B48E-2C4A-4D24-9E3A-237A5F87938F@google.com> From: Ted Lemon Date: Tue, 18 Jul 2017 20:12:18 +0200 Message-ID: To: Scott Morizot Cc: james woodyatt , IPv6 Operations Content-Type: multipart/alternative; boundary="001a1137741e24375b05549b77fc" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:13:02 -0000 --001a1137741e24375b05549b77fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The way this stuff works is that we (the IETF) make a recommendation based on what the most common use case is, and make the recommendation open enough that it covers the less common use cases, or else enumerate expected use cases and make recommendations specific to each case. In this case, the text falls into the first category. It would be totally inappropriate to deprecate IA_NA on the basis of this text. As far as I know, no such plan is afoot in the DHC working group. It would also be inappropriate to make that change in this working group. :) On Tue, Jul 18, 2017 at 7:57 PM, Scott Morizot wrote: > On Tue, Jul 18, 2017 at 9:41 AM, james woodyatt wrote: > >> >> It=E2=80=99s not at all clear to me what is the purpose of this draft, b= ut if I >> understand correctly, then its objective is to propose that IETF Best >> Current Practice include general purpose Internet networks where general >> purpose hosts acquire IPv6 interface addresses only by using DHCPv6 IA_N= A >> requests to obtain addresses from a constrained pool one at a time. I ha= ve >> a lot of difficulty seeing how that makes any sense given the clear >> reasoning provided in RFC 7934 for the recommendation against it. >> >> > I have no particular problem with that as a recommendation for general > purpose Internet networks if the recommendation is intended to exclude a > significant chunk of the enterprise network world. For a general purpose > network meant to support devices controlled and operated by other parties > from the network operators, it may even be a fine recommendation. (That's > not really my world, so I can't say.) > > I think this came up, if I tracked discussions properly (a big if), > because this recommendation for address assignment in general purpose > networks was used as one of the reasons to fight against recommending tha= t > node developers should support DHCPv6 elsewhere. Again, not really a > node/client developer except in the past for some limited in house things= , > but that strikes me as bad advice to that group depending on their target > user. Of course, I don't really think such developers are going to rely o= n > an IETF recommendation to decide which features they need to incorporate > anyway. Or at least not solely. So that's why I don't feel too strongly > about it either way. > > I would object more strenuously if someone were actually trying to change > the actual DHCPv6 protocol standard to eliminate IA_NA/IA_TA, but I belie= ve > there would be a chorus of objections to such a move anyway, so I'm not > particularly concerned about that. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a1137741e24375b05549b77fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The way this stuff works is that we (the IETF) make a reco= mmendation based on what the most common use case is, and make the recommen= dation open enough that it covers the less common use cases, or else enumer= ate expected use cases and make recommendations specific to each case. =C2= =A0 In this case, the text falls into the first category. =C2=A0 It would b= e totally inappropriate to deprecate IA_NA on the basis of this text. =C2= =A0 As far as I know, no such plan is afoot in the DHC working group. =C2= =A0 It would also be inappropriate to make that change in this working grou= p. =C2=A0 :)

On Tue, Jul 18, 2017 at 7:57 PM, Scott Morizot <tmorizot@gmail.com&g= t; wrote:
On Tue, Jul= 18, 2017 at 9:41 AM, james woodyatt <jhw@google.com> wrote:

It=E2=80=99s not at all clear to me what is the purpose o= f this draft, but if I understand correctly, then its objective is to propo= se that IETF Best Current Practice include general purpose Internet network= s where general purpose hosts acquire IPv6 interface addresses only by usin= g DHCPv6 IA_NA requests to obtain addresses from a constrained pool one at = a time. I have a lot of difficulty seeing how that makes any sense given th= e clear reasoning provided in RFC 7934 for the recommendation against it.


I ha= ve no particular problem with that as a recommendation for general purpose = Internet networks if the recommendation is intended to exclude a significan= t chunk of the enterprise network world. For a general purpose network mean= t to support devices controlled and operated by other parties from the netw= ork operators, it may even be a fine recommendation. (That's not really= my world, so I can't say.)

I think this came = up, if I tracked discussions properly (a big if), because this recommendati= on for address assignment in general purpose networks was used as one of th= e reasons to fight against recommending that node developers should support= DHCPv6 elsewhere. Again, not really a node/client developer except in the = past for some limited in house things, but that strikes me as bad advice to= that group depending on their target user. Of course, I don't really t= hink such developers are going to rely on an IETF recommendation to decide = which features they need to incorporate anyway. Or at least not solely. So = that's why I don't feel too strongly about it either way.=C2=A0

I would object more strenuously if someone were actua= lly trying to change the actual DHCPv6 protocol standard to eliminate IA_NA= /IA_TA, but I believe there would be a chorus of objections to such a move = anyway, so I'm not particularly concerned about that.
=

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


--001a1137741e24375b05549b77fc-- From nobody Tue Jul 18 11:14:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06319131BC2 for ; Tue, 18 Jul 2017 11:14:14 -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 11D6euAfHSV5 for ; Tue, 18 Jul 2017 11:14:12 -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 87993131B47 for ; Tue, 18 Jul 2017 11:14:12 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 64so33508127uae.2 for ; Tue, 18 Jul 2017 11:14:12 -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=mJELhA4/jro/YwEdAu6ksVBCgLZAwnfquysRDj0IRFk=; b=PqrYsHuzYKzfZY7DIuuF7oqrY4RJWsrCbi5RBsHmax9kik8dBHdAWQg6nq2t90Rp7W Yt+5XkLDAKhAJOSVzLqqLq5WNvfhtdbDmQ/LtJy0NEp6sN4CNJWSZaBlscqKQM7CwtEw JLaBkfw67oRVbuHZguSGOaiXvQ6o+NcIfBh6gDUbFj2GCu/D6cniovvNyNhxZ3US9psI AnNji7ENsJ3arC2Kl2OVfnFyC6Whyn3AOmNkVw9lJy+A/TD/BkgoaWw+blMEXuNojibd 9tE0oHzYk1u/dZkiC1Un+SSNUAAEl4vBEC2PBy+OuyD6lFWaZDoeRsetXswzHWpwMGir JxLw== 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=mJELhA4/jro/YwEdAu6ksVBCgLZAwnfquysRDj0IRFk=; b=j1NH5Ei+KXIRUefi54PpPDyyM7mZ7QISMASQxfunbxHf3aR0wvU89UlBodeLHHI67y sbnVLFyeOrqHRE+ZVckS7zU9Eb0h0ejw7+Z1eaYmY+w3xgSzdCwVVhNI+GTnjp8bibrq X8IM9NIY2w2mpNDqiq9ezvON56Wn8eRknlBlBuwdx1bm+Umk6oI9sQ7K4CgmVW6pb5Ip AXrzSkDJ482Oj2uoRtbJ8a4wrqvEB97KjngjznUG1/HFstZH+yIIH3U5GZlGYaP78pB0 U+fHOy9b5T28KRMT5Uz0GTejVGog1h6gT3RyPjWlSKNkj4XOYvNWAmg3xoClqfuVcHWP XEyQ== X-Gm-Message-State: AIVw113xCFbTahdSFt5QxdVaapLSmOeR6kI5HOO4CA5uaBz5F0Z0LwHU scPpaoO346YYIgdTcn4EgkXU8C6cxiTxI/E= X-Received: by 10.31.66.141 with SMTP id p135mr1444352vka.85.1500401651738; Tue, 18 Jul 2017 11:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.164.72 with HTTP; Tue, 18 Jul 2017 11:14:10 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Scott Morizot Date: Tue, 18 Jul 2017 13:14:10 -0500 Message-ID: To: Ted Lemon Cc: Mark Smith , IPv6 Operations Content-Type: multipart/alternative; boundary="001a1144b32678eef005549b7bdd" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:14:14 -0000 --001a1144b32678eef005549b7bdd Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 12:54 PM, Ted Lemon wrote: > So what exactly would an update accomplish? Please don't send another > long wall of text. Just explain how we can balance these two competing > needs better than we currently are doing? > > As a recommendation for host address assignment on a general purpose network, it's fine. However, it appears that making DHCPv6 IA_NA/IA_TA NOT RECOMMENDED for host address assignment in that context is being taken as a reason by some to recommend against hosts supporting it. I can see the logic being used. If the IETF recommends against it for networks, it should recommend against support for it in hosts. But that's not exactly the same thing. Again, from a practical perspective I don't think it will matter much either way. But I was simply trying to point out that there are some pretty large networks out there where the general recommendation really doesn't apply. --001a1144b32678eef005549b7bdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 12:54 PM, Ted Lemon <mellon@fugue.com> wr= ote:
So what exactl= y would an update accomplish? =C2=A0 Please don't send another long wal= l of text. =C2=A0 Just explain how we can balance these two competing needs= better than we currently are doing?
=

As a recommendation for host add= ress assignment on a general purpose network, it's fine. However, it ap= pears that making DHCPv6 IA_NA/IA_TA NOT RECOMMENDED for host address assig= nment in that context is being taken as a reason by some to recommend again= st hosts supporting it. I can see the logic being used. If the IETF recomme= nds against it for networks, it should recommend against support for it in = hosts. But that's not exactly the same thing. Again, from a practical p= erspective I don't think it will matter much either way. But I was simp= ly trying to point out that there are some pretty large networks out there = where the general recommendation really doesn't apply.
--001a1144b32678eef005549b7bdd-- From nobody Tue Jul 18 11:47:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E5A12EC11 for ; Tue, 18 Jul 2017 11:47:29 -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 Hu8IEmvieGEP for ; Tue, 18 Jul 2017 11:47:26 -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 B0961131BCA for ; Tue, 18 Jul 2017 11:47:25 -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 v6IIlNo6009183 for ; Tue, 18 Jul 2017 20:47:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E229F205A8C for ; Tue, 18 Jul 2017 20:47:23 +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 D8B2E201394 for ; Tue, 18 Jul 2017 20:47:23 +0200 (CEST) Received: from [132.166.84.73] ([132.166.84.73]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6IIlN6b001930 for ; Tue, 18 Jul 2017 20:47:23 +0200 To: v6ops@ietf.org References: <596CF817.8040900@foobar.org> From: Alexandre Petrescu Message-ID: Date: Tue, 18 Jul 2017 20:47:23 +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: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:47:29 -0000 I agree that in the past there may have existed a risk of cellular networks assigning a single IPv6 address (w/o even a plen) to one UE. So one wanted a recommendation against DHCPv6 single address per End node. However, I still think this RFC is a mis-written recommendation. It would have been much simpler to RECOMMEND to allocate multiple addresses per End node, as many as that End node requires, be them individual addresses, or addresses aggregated into prefixes, or multiple prefixes. But the current recommendation as it stands looks weird. Le 18/07/2017 à 17:23, Jen Linkova a écrit : > I have read the draft and re-read rfc7934 and now I'm completely > confused. First of all, I can not see where rfc7934 says that DHCPv6 > is not recommended. RFC7934: > In order to avoid the problems described above and preserve the > Internet's ability to support new applications that use more than one > IPv6 address, it is RECOMMENDED that IPv6 network deployments provide > multiple IPv6 addresses from each prefix to general-purpose hosts. What makes one think that some network deployment might block the forming of multiple IPv6 addresses from each prefix? Or maybe the "from each prefix" is superfluous? Because I dont think there is any method that provides a prefix yet restricts the use to just one address in that prefix. If a Router sends an RA to many Hosts then each of these Hosts may configure many addresses within it. If a Router sends an RA unicast to a Host then that Host may configure many addresses within it. If an address is delivered by a DHCP Server, then that is an address without any prefix specified. If a prefix is delegated by a DHCP Server then a receiving Client may configure many addresses within that prefix. > To support future use cases, it is NOT RECOMMENDED to impose a hard > limit on the size of the address pool assigned to a host. What do you mean? Is that pool a DHCP pool? What is an example of someone imposing a hard limit on the size of that pool? > Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 > address per prefix. I did not see any place where there is such a restriction. I wonder what is an example where a Host was limited to only one IPv6 address formed out of a prefix. > 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. 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. This "either or" sounds like exclusive or. But on cellular networks the Host is provided a dedicated prefix _and_ forms new addresses autonomously. This is confusing. > Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide > multiple addresses when the host connects (e.g., the approximately 30 > addresses that can fit into a single packet) ? is there such a restriction in the DHCP spec? Is it that DHCP Ack/Advertise could carry only 30 addresses? > would accommodate current clients, but it sets a limit on the number > of addresses available to hosts when they attach and therefore limits > the development of future applications. Yes, it would set a limit _if_ DHCP had such a limit. Do you think DHCP has a limit in the number of addresses it could assign in an Ack or Advertise? > The maximum number of IPv6 addresses that can be provided in a single > DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is > approximately 30. Do we have a packet dump showing this? I am asking because 30 addresses make for 480bytes... Jen said: > I had to use all my imagination and still not sure how the phrase 'it > is RECOMMENDED that the network give the host the ability to use new > addresses without requiring explicit requests.' can be read as > 'DHCPv6 is not recommended'. Because SLAAC does not obtain addresses by using Requests. That's DHCP who uses Requests to obtain addresses. That RECOMMENDation is clearly written by someone who has some deep disapproval of DHCP. > Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA > cannot use new addresses without requesting them from a DHCPv6 server > on the network.' does not seem to be accurate. As this statement > appears to be the key point of your document, I believe it needs to > be fixed before we can proceed. On my side, I can agree. But that is your discussion. Alex From nobody Tue Jul 18 12:29:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349241242F7 for ; Tue, 18 Jul 2017 12:29: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, 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=fugue-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 YQgYm566cjdD for ; Tue, 18 Jul 2017 12:29:16 -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 5DFE21201F2 for ; Tue, 18 Jul 2017 12:29:16 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id e199so15865909pfh.2 for ; Tue, 18 Jul 2017 12:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VwosIqdkGtw4c1zC/ktbZVH3TXufjmE6gEg4LlOAtdo=; b=EarUW8Xb0AM1eJoAWxVf8owYBhL/1WM8/Hdhz5bWIlviDuAAkFU8Dgots6aYlsO9Es 6wBEfpD3F135yL4K6Ugo15rhxVHNPXL4Yc8iPVSDBNBU4pE9wGNGM+L7YXGT77xE1/uN HbLLRDqZkH+ZZINJbxwYWNK9CI3SCxYUslZVFxux2y6u1JnvALkRp4JRJqgvCUegwDCD iTv6IPxvAHqfBPYwluHsXaa2hCACXPxKzDnt1UXtm2XkKEwbUFcOPqxV6SMVTdaXgK85 NvliKiC/PwXDYBD+eKU9HwuPx24ujcYXqeNnWI7cLY56q/yVy9yfLupLvNqvpOpjmv4w AC+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=VwosIqdkGtw4c1zC/ktbZVH3TXufjmE6gEg4LlOAtdo=; b=XLuDA01OcFSsfynKbGjwFv7vi0c42+yLA2ShqdoH9w36GQXci0XGNArXzPm8hQNFdh O/mjYKnKR2mRf/YDaUaNEccHiVxerFpyQ5ftAqnLjhNi+wJLe+gb8D10vfVR5DKfyqDg VLDgoX7fZZHQYvm0VWGWmEXJAiYBa5nAIkgq3Av/g7Ac3KEoObNHotT4xv9laadjhgse uMYfoFlBU9O/Yi2QB0327lzu5bUro0Nbqh/13ykx7naTpoY17JXpPC9UZ7akR9558G/i p7MwNB51WEKOh8+fPS+k7QZOEMRKYh2ZyYhLJD8pNUsNcnpYPD1BSKIsU3mw/uJ7eCdm Yo5A== X-Gm-Message-State: AIVw110wr+72KxrfseLSgVLXy8N4eKN63npUFDR1GYxLj5jNVUzSj6tX COAIw1yW4w4qx6i0MJm8pqsDwraidEzf X-Received: by 10.99.167.79 with SMTP id w15mr3362255pgo.22.1500406155999; Tue, 18 Jul 2017 12:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 12:28:35 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Ted Lemon Date: Tue, 18 Jul 2017 21:28:35 +0200 Message-ID: To: Alexandre Petrescu Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c1bdaa4f2915405549c870d" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 19:29:19 -0000 --94eb2c1bdaa4f2915405549c870d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alexandre, it's a really important recommendation of the document that the host be allowed to allocate *its own* addresses, rather than having to rely on the correctness of the DHCP IA_NA implementation. So the language you are proposing would completely change that. On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > I agree that in the past there may have existed a risk of cellular > networks assigning a single IPv6 address (w/o even a plen) to one UE. > So one wanted a recommendation against DHCPv6 single address per End node= . > > However, I still think this RFC is a mis-written recommendation. > > It would have been much simpler to RECOMMEND to allocate multiple > addresses per End node, as many as that End node requires, be them > individual addresses, or addresses aggregated into prefixes, or multiple > prefixes. > > But the current recommendation as it stands looks weird. > > Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit : > >> I have read the draft and re-read rfc7934 and now I'm completely >> confused. First of all, I can not see where rfc7934 says that DHCPv6 is = not >> recommended. >> > > RFC7934: > >> In order to avoid the problems described above and preserve the >> Internet's ability to support new applications that use more than one >> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide >> multiple IPv6 addresses from each prefix to general-purpose hosts. >> > > What makes one think that some network deployment might block the > forming of multiple IPv6 addresses from each prefix? > > Or maybe the "from each prefix" is superfluous? > > Because I dont think there is any method that provides a prefix yet > restricts the use to just one address in that prefix. > > If a Router sends an RA to many Hosts then each of these Hosts may > configure many addresses within it. > > If a Router sends an RA unicast to a Host then that Host may configure > many addresses within it. > > If an address is delivered by a DHCP Server, then that is an address > without any prefix specified. > > If a prefix is delegated by a DHCP Server then a receiving Client may > configure many addresses within that prefix. > > To support future use cases, it is NOT RECOMMENDED to impose a hard limit >> on the size of the address pool assigned to a host. >> > > What do you mean? Is that pool a DHCP pool? What is an example of > someone imposing a hard limit on the size of that pool? > > Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 >> address per prefix. >> > > I did not see any place where there is such a restriction. I wonder > what is an example where a Host was limited to only one IPv6 address > formed out of a prefix. > > 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. 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. >> > > This "either or" sounds like exclusive or. But on cellular networks the > Host is provided a dedicated prefix _and_ forms new addresses autonomousl= y. > > This is confusing. > > Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide >> multiple addresses when the host connects (e.g., the approximately 30 >> addresses that can fit into a single packet) >> > > ? is there such a restriction in the DHCP spec? Is it that DHCP > Ack/Advertise could carry only 30 addresses? > > would accommodate current clients, but it sets a limit on the number of >> addresses available to hosts when they attach and therefore limits >> the development of future applications. >> > > Yes, it would set a limit _if_ DHCP had such a limit. Do you think DHCP > has a limit in the number of addresses it could assign in an Ack or > Advertise? > > The maximum number of IPv6 addresses that can be provided in a single >> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is >> approximately 30. >> > > Do we have a packet dump showing this? I am asking because 30 addresses > make for 480bytes... > > Jen said: > >> I had to use all my imagination and still not sure how the phrase 'it >> is RECOMMENDED that the network give the host the ability to use new >> addresses without requiring explicit requests.' can be read as 'DHCPv6 i= s >> not recommended'. >> > > Because SLAAC does not obtain addresses by using Requests. That's DHCP > who uses Requests to obtain addresses. > > That RECOMMENDation is clearly written by someone who has some deep > disapproval of DHCP. > > Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot >> use new addresses without requesting them from a DHCPv6 server >> on the network.' does not seem to be accurate. As this statement >> appears to be the key point of your document, I believe it needs to >> be fixed before we can proceed. >> > > On my side, I can agree. But that is your discussion. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c1bdaa4f2915405549c870d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alexandre, it's a really important recommendation of t= he document that the host be allowed to allocate its own=C2=A0addres= ses, rather than having to rely on the correctness of the DHCP IA_NA implem= entation. =C2=A0 So the language you are proposing would completely change = that.

On Tue= , Jul 18, 2017 at 8:47 PM, Alexandre Petrescu <alexandre.petres= cu@gmail.com> wrote:
I agre= e that in the past there may have existed a risk of cellular
networks assigning a single IPv6 address (w/o even a plen) to one UE.
So one wanted a recommendation against DHCPv6 single address per End node.<= br>
However, I still think this RFC is a mis-written recommendation.

It would have been much simpler to RECOMMEND to allocate multiple
addresses per End node, as many as that End node requires, be them
individual addresses, or addresses aggregated into prefixes, or multiple prefixes.

But the current recommendation as it stands looks weird.

Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit :
I have read the draft and re-read rfc7934 and now I'm completely confus= ed. First of all, I can not see where rfc7934 says that DHCPv6 is not recom= mended.

RFC7934:
In order to avoid the problems described above and preserve the Internet= 9;s ability to support new applications that use more than one
IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
multiple IPv6 addresses from each prefix to general-purpose hosts.

What makes one think that some network deployment might block the
forming of multiple IPv6 addresses from each prefix?

Or maybe the "from each prefix" is superfluous?

Because I dont think there is any method that provides a prefix yet
restricts the use to just one address in that prefix.

If a Router sends an RA to many Hosts then each of these Hosts may
configure many addresses within it.

If a Router sends an RA unicast to a Host then that Host may configure
many addresses within it.

If an address is delivered by a DHCP Server, then that is an address
without any prefix specified.

If a prefix is delegated by a DHCP Server then a receiving Client may
configure many addresses within that prefix.

To support future use cases, it is NOT RECOMMENDED to impose a hard limit o= n the size of the address pool assigned to a host.

What do you mean?=C2=A0 Is that pool a DHCP pool?=C2=A0 What is an example = of
someone imposing a hard limit on the size of that pool?

Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6
=C2=A0address per prefix.

I did not see any place where there is such a restriction.=C2=A0 I wonder what is an example where a Host was limited to only one IPv6 address
formed out of a prefix.

Due to the drawbacks imposed by requiring explicit requests for address spa= ce (see Section 4), it is RECOMMENDED that the network give the host the ab= ility to use new addresses without requiring explicit requests.=C2=A0 This = can be achieved either by allowing the host
=C2=A0to form new addresses autonomously (e.g., via SLAAC) or by providing<= br> =C2=A0the host with a dedicated /64 prefix.

This "either or" sounds like exclusive or.=C2=A0 But on cellular = networks the
Host is provided a dedicated prefix _and_ forms new addresses autonomously.=

This is confusing.

Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide multip= le addresses when the host connects (e.g., the approximately 30
addresses that can fit into a single packet)

?=C2=A0 is there such a restriction in the DHCP spec?=C2=A0 Is it that DHCP=
Ack/Advertise could carry only 30 addresses?

would accommodate current clients, but it sets a limit on the number of add= resses available to hosts when they attach and therefore limits
the development of future applications.

Yes, it would set a limit _if_ DHCP had such a limit.=C2=A0 Do you think DH= CP
has a limit in the number of addresses it could assign in an Ack or
Advertise?

The maximum number of IPv6 addresses that can be provided in a single
DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is
approximately 30.

Do we have a packet dump showing this?=C2=A0 I am asking because 30 address= es
make for 480bytes...

Jen said:
I had to use all my imagination and still not sure how the phrase 'it is RECOMMENDED that the network give the host the ability to use new
addresses without requiring explicit requests.' can be read as 'DHC= Pv6 is not recommended'.

Because SLAAC does not obtain addresses by using Requests.=C2=A0 That's= DHCP
who uses Requests to obtain addresses.

That RECOMMENDation is clearly written by someone who has some deep
disapproval of DHCP.

Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot= use new addresses without requesting them from a DHCPv6 server
on the network.' does not seem to be accurate.=C2=A0 As this statement<= br> appears to be the key point of your document, I believe it needs to
be fixed before we can proceed.

On my side, I can agree.=C2=A0 But that is your discussion.

Alex

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

--94eb2c1bdaa4f2915405549c870d-- From nobody Tue Jul 18 13:01:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37ED12ECEF for ; Tue, 18 Jul 2017 13:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 CiE6HyieBeg0 for ; Tue, 18 Jul 2017 13:00:57 -0700 (PDT) Received: from mta01.svc.cra.dublin.eircom.net (mta01.svc.cra.dublin.eircom.net [159.134.118.222]) by ietfa.amsl.com (Postfix) with SMTP id D770412ECC1 for ; Tue, 18 Jul 2017 13:00:56 -0700 (PDT) Received: (qmail 14337 messnum 13635953 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 18 Jul 2017 20:00:53 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (HELO avas01) (213.94.190.12) by mta01.svc.cra.dublin.eircom.net (qp 14337) with SMTP; 18 Jul 2017 20:00:53 -0000 Received: from pool-ipv6-pd.agg2.bri.bbh-prp.eir.ie ([86.43.53.4]) by Cloudmark Gateway with SMTP id XYftdO4ENcTICXYftd1fLp; Tue, 18 Jul 2017 21:00:53 +0100 X-CNFS-Analysis: v=2.2 cv=DPn/22Fb c=1 sm=1 tr=0 a=zZBI1ub4HtZF72d7qw0iRw==:117 a=zZBI1ub4HtZF72d7qw0iRw==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=m3eTzytWDOrJSTv2xAYA:9 a=QEXdDO2ut3YA:10 a=CTMFJ6J7UbgA:10 a=xP97g4UPIlkA:10 a=gn4-OE6cEyAA:10 a=6mmCUxp3ftUA:10 a=uCloIGMIsF0A:10 a=PME_zkO_UDMA:10 a=EO1mO2Je1_fOxh9vOAYA:9 a=4aeB2dohUJI609AS:21 a=_W_S_7VecoQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22 From: Ross Chandler Message-Id: <0B85DC04-1DD6-4E64-919C-3464CB6A473A@eircom.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_D76A2FB7-D9C7-40DE-8A76-33535593F3A8" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) Date: Tue, 18 Jul 2017 21:00:52 +0100 In-Reply-To: <909a24c0-ea34-52b2-a0d4-73a7baef7a61@gmail.com> Cc: v6ops@ietf.org To: Alexandre Petrescu References: <596CF817.8040900@foobar.org> <27c2da26-630a-4cfc-3085-b33bdba53a8b@gmail.com> <4171F21D-A063-4173-8B9D-634DC360D891@eircom.net> <909a24c0-ea34-52b2-a0d4-73a7baef7a61@gmail.com> X-Mailer: Apple Mail (2.3439) X-CMAE-Envelope: MS4wfC6OKCaOMcR8YjuXVdT1w6ka31Hjtu1GT80asqKZ1rZeb+nuZ6KNyb2SQgRe1jsPNJXS3UWEHCrQQ9ly/TnvqF2eRtGax0+dZ57Q4BIYzd3VVugQO1vn RAwpcVUH4ZNNfMCpso8DAgq7LVlMI9uVIJ3vcY3U1gYzkSmXRJINruqb0EVJciJBfhWOVUld8fv0s1re8RnX0WYiBJEY+MzVVvAQ9kxVW/UwT5iBEnpbnbsZ Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 20:00:59 -0000 --Apple-Mail=_D76A2FB7-D9C7-40DE-8A76-33535593F3A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jul 2017, at 08:58, Alexandre Petrescu = wrote: >=20 > During these discussions of these draft it was often said that = DHCPv6-PD is the way to go, so let's go that way. (this suggestion is = independent of the 3GPP link discussion). >=20 >>>> Given the above two drafts DHCPv6-PD to hosts has an uphill = struggle to ever achieve widespread deployment. >>> I don=E2=80=99t think so. >> You=E2=80=99re more optimistic than me then. >>> I think DHCPv6-PD should be trialled at IETF WiFi and then we=E2=80=99= ll see. >> Yes, it should. The =E2=80=9Chost OS developers=E2=80=9D have repeatedly expressed = technical objections to DHCPv6. https://www.ietf.org/mail-archive/web/v6ops/current/msg26201.html = https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html = https://www.ietf.org/mail-archive/web/v6ops/current/msg26170.html = I could ask my fixed residential broadband CPE vendors to support prefix = delegation. Their question back would be which OSes support it and can = they prioritise other things in the list. But it doesn=E2=80=99t look like Android, iOS, and possibly also macOS = and Windows have any plans to support DHCPv6-PD. There is a draft = alternative way of doing it using RAs that appears to have more support = from the host OS developers. Ross --Apple-Mail=_D76A2FB7-D9C7-40DE-8A76-33535593F3A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 18 Jul 2017, at 08:58, Alexandre Petrescu <alexandru.petrescu@gmail.com> wrote:

During these discussions of these draft it was = often said that DHCPv6-PD is the way to go, so let's go that way. =  (this suggestion is independent of the 3GPP link discussion).

Given the = above two drafts DHCPv6-PD to hosts has an uphill struggle to ever = achieve widespread deployment.
I don=E2=80=99t = think so.
You=E2=80=99re more optimistic than = me then.
I think = DHCPv6-PD should be trialled at IETF WiFi and then we=E2=80=99ll see.
Yes, it should.


The =E2=80=9Chost OS developers=E2=80=9D have = repeatedly expressed technical objections to DHCPv6.


I could ask my fixed = residential broadband CPE vendors to support prefix delegation. Their = question back would be which OSes support it and can they prioritise = other things in the list.
But it doesn=E2=80=99t look like = Android, iOS, and possibly also macOS and Windows have any plans to = support DHCPv6-PD. There is a draft alternative way of doing it using = RAs that appears to have more support from the host OS = developers.


Ross
= --Apple-Mail=_D76A2FB7-D9C7-40DE-8A76-33535593F3A8-- From nobody Tue Jul 18 13:09:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5976012706D for ; Tue, 18 Jul 2017 13:09:55 -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 5Ink55dBxn8C for ; Tue, 18 Jul 2017 13:09: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 A936312702E for ; Tue, 18 Jul 2017 13:09:52 -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 v6IK9n9E086598; Tue, 18 Jul 2017 22:09:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CE21C20632B; Tue, 18 Jul 2017 22:09:49 +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 C0FDB20619E; Tue, 18 Jul 2017 22:09:49 +0200 (CEST) Received: from [132.166.84.102] ([132.166.84.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6IK9kF9026269; Tue, 18 Jul 2017 22:09:48 +0200 To: Ted Lemon Cc: IPv6 Ops WG References: <596CF817.8040900@foobar.org> From: Alexandre Petrescu Message-ID: <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> Date: Tue, 18 Jul 2017 22:09:45 +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: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 20:09:55 -0000 Le 18/07/2017 à 21:28, Ted Lemon a écrit : > Alexandre, it's a really important recommendation of the document > that the host be allowed to allocate /its own/ addresses, I dont understand how a host can allocate its own addresses. Or do you mean IID? (we are very far from Host deciding an address, suggesting it to the network, and the network update the routes - but I think you dont mean that either.) Alex > rather than having to rely on the correctness of the DHCP IA_NA > implementation. So the language you are proposing would completely > change that. > > On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu > > > wrote: > > I agree that in the past there may have existed a risk of cellular > networks assigning a single IPv6 address (w/o even a plen) to one UE. > So one wanted a recommendation against DHCPv6 single address per End > node. > > However, I still think this RFC is a mis-written recommendation. > > It would have been much simpler to RECOMMEND to allocate multiple > addresses per End node, as many as that End node requires, be them > individual addresses, or addresses aggregated into prefixes, or > multiple prefixes. > > But the current recommendation as it stands looks weird. > > Le 18/07/2017 à 17:23, Jen Linkova a écrit : > > I have read the draft and re-read rfc7934 and now I'm completely > confused. First of all, I can not see where rfc7934 says that DHCPv6 > is not recommended. > > > RFC7934: > > In order to avoid the problems described above and preserve the > Internet's ability to support new applications that use more than one > IPv6 address, it is RECOMMENDED that IPv6 network deployments provide > multiple IPv6 addresses from each prefix to general-purpose hosts. > > > What makes one think that some network deployment might block the > forming of multiple IPv6 addresses from each prefix? > > Or maybe the "from each prefix" is superfluous? > > Because I dont think there is any method that provides a prefix yet > restricts the use to just one address in that prefix. > > If a Router sends an RA to many Hosts then each of these Hosts may > configure many addresses within it. > > If a Router sends an RA unicast to a Host then that Host may > configure many addresses within it. > > If an address is delivered by a DHCP Server, then that is an address > without any prefix specified. > > If a prefix is delegated by a DHCP Server then a receiving Client may > configure many addresses within that prefix. > > To support future use cases, it is NOT RECOMMENDED to impose a hard > limit on the size of the address pool assigned to a host. > > > What do you mean? Is that pool a DHCP pool? What is an example of > someone imposing a hard limit on the size of that pool? > > Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 > address per prefix. > > > I did not see any place where there is such a restriction. I wonder > what is an example where a Host was limited to only one IPv6 address > formed out of a prefix. > > 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. 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. > > > This "either or" sounds like exclusive or. But on cellular networks > the Host is provided a dedicated prefix _and_ forms new addresses > autonomously. > > This is confusing. > > Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide > multiple addresses when the host connects (e.g., the approximately 30 > addresses that can fit into a single packet) > > > ? is there such a restriction in the DHCP spec? Is it that DHCP > Ack/Advertise could carry only 30 addresses? > > would accommodate current clients, but it sets a limit on the number > of addresses available to hosts when they attach and therefore limits > the development of future applications. > > > Yes, it would set a limit _if_ DHCP had such a limit. Do you think > DHCP has a limit in the number of addresses it could assign in an > Ack or Advertise? > > The maximum number of IPv6 addresses that can be provided in a single > DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is > approximately 30. > > > Do we have a packet dump showing this? I am asking because 30 > addresses make for 480bytes... > > Jen said: > > I had to use all my imagination and still not sure how the phrase 'it > is RECOMMENDED that the network give the host the ability to use new > addresses without requiring explicit requests.' can be read as > 'DHCPv6 is not recommended'. > > > Because SLAAC does not obtain addresses by using Requests. That's > DHCP who uses Requests to obtain addresses. > > That RECOMMENDation is clearly written by someone who has some deep > disapproval of DHCP. > > Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA > cannot use new addresses without requesting them from a DHCPv6 server > on the network.' does not seem to be accurate. As this statement > appears to be the key point of your document, I believe it needs to > be fixed before we can proceed. > > > On my side, I can agree. But that is your discussion. > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Tue Jul 18 14:01:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FC4129B2A for ; Tue, 18 Jul 2017 14:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 RdlT5GbTzeEG for ; Tue, 18 Jul 2017 14:01:48 -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 26073126C2F for ; Tue, 18 Jul 2017 14:01:48 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id o88so10512038pfk.3 for ; Tue, 18 Jul 2017 14:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gyAv1SN8ouKzLkKAiozVT7Q2nymFkFiYQ265MpZ1fTE=; b=uGnZSRDABWq2WWSNII13e5lzowZneIhm5vFNfJmDrvukZSluxkP3g0XVD2Dq3CmHPt /odcyiG/E4zrgnTJZoD9W6kFg1HOfXPE5W7dPni04gD2VJKj/aZ9r0dLzRX417AeJnyn 0s1FhYXjvt7rg8bIlfg57ggJOako4siqa9SifcmVZJx/7bCWri6NcKXxt5A6uaPyVjX+ lVz2JAvNpM+IBPJKuflbKgwBqXbQFF6QqFRiB+8duFZqjjNzCT2PBjN8l9geVoOpSKe9 aSmJTP28ZHYR7n5nO1al+6rE0JyiUMkg0Eofp2umSr3UWRueGevFsqJqHjVeQO4ckcf1 nMiw== 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=gyAv1SN8ouKzLkKAiozVT7Q2nymFkFiYQ265MpZ1fTE=; b=hHYPPDKfkQ+3+kBGpqwC3a6jqqOaAH3NEJpLJ/mfaHkfiSIcMMMLFeqsdU8CxskFPt 0U2ElvKHXBCB1NEpk4VAAyoMYi23tgOiZs3hDscV2asnak8+Q+0NiUV8SZUo4FmSD7eI KSpMhKkoOwyYp8+5Idl6i0mBijTobD0D222gR1o9G8Jf7d4Flch0vkpDkeFe6Watnbta yKVdcntz7sLUQBo3XMIxLKZGfgBrc6JLy0joFbtLBlKUxy98r9wYfpjP9Iq02+vPWoWk /1guCjlvDgAa4cT5hq7iprvPurPmiBuNQz3cR99/a88Qv+UvDMUZP3HSbtjvhecd7EQy gQfA== X-Gm-Message-State: AIVw110CdxM59yaA62QBEO9H8aER7e0jFYmN8k2Y/qOBRCld+wC7w8H/ o2LITueXgfVLMG873IuqpDAG0hZcszC3 X-Received: by 10.84.231.16 with SMTP id f16mr3732901plk.131.1500411707694; Tue, 18 Jul 2017 14:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 14:01:07 -0700 (PDT) In-Reply-To: <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> References: <596CF817.8040900@foobar.org> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> From: Ted Lemon Date: Tue, 18 Jul 2017 23:01:07 +0200 Message-ID: To: Alexandre Petrescu Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="f40304360182dab27a05549dd22c" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 21:01:51 -0000 --f40304360182dab27a05549dd22c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If a host gets a /64, it can allocate addresses out of it. If the prefix allows autoconfiguration, it can allocate its own addresses using SLAAC. On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit : > >> Alexandre, it's a really important recommendation of the document that >> the host be allowed to allocate /its own/ addresses, >> > > I dont understand how a host can allocate its own addresses. Or do you > mean IID? > > (we are very far from Host deciding an address, suggesting it to the > network, and the network update the routes - but I think you dont mean > that either.) > > Alex > > rather than having to rely on the correctness of the DHCP IA_NA >> implementation. So the language you are proposing would completely cha= nge >> that. >> >> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com > >> wrote: >> >> I agree that in the past there may have existed a risk of cellular >> networks assigning a single IPv6 address (w/o even a plen) to one UE. >> So one wanted a recommendation against DHCPv6 single address per End >> node. >> >> However, I still think this RFC is a mis-written recommendation. >> >> It would have been much simpler to RECOMMEND to allocate multiple >> addresses per End node, as many as that End node requires, be them >> individual addresses, or addresses aggregated into prefixes, or multiple >> prefixes. >> >> But the current recommendation as it stands looks weird. >> >> Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit : >> >> I have read the draft and re-read rfc7934 and now I'm completely >> confused. First of all, I can not see where rfc7934 says that DHCPv6 is = not >> recommended. >> >> >> RFC7934: >> >> In order to avoid the problems described above and preserve the >> Internet's ability to support new applications that use more than one >> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide >> multiple IPv6 addresses from each prefix to general-purpose hosts. >> >> >> What makes one think that some network deployment might block the formin= g >> of multiple IPv6 addresses from each prefix? >> >> Or maybe the "from each prefix" is superfluous? >> >> Because I dont think there is any method that provides a prefix yet >> restricts the use to just one address in that prefix. >> >> If a Router sends an RA to many Hosts then each of these Hosts may >> configure many addresses within it. >> >> If a Router sends an RA unicast to a Host then that Host may configure >> many addresses within it. >> >> If an address is delivered by a DHCP Server, then that is an address >> without any prefix specified. >> >> If a prefix is delegated by a DHCP Server then a receiving Client may >> configure many addresses within that prefix. >> >> To support future use cases, it is NOT RECOMMENDED to impose a hard limi= t >> on the size of the address pool assigned to a host. >> >> >> What do you mean? Is that pool a DHCP pool? What is an example of >> someone imposing a hard limit on the size of that pool? >> >> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 >> address per prefix. >> >> >> I did not see any place where there is such a restriction. I wonder >> what is an example where a Host was limited to only one IPv6 address >> formed out of a prefix. >> >> 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. 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. >> >> >> This "either or" sounds like exclusive or. But on cellular networks the >> Host is provided a dedicated prefix _and_ forms new addresses autonomous= ly. >> >> This is confusing. >> >> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide >> multiple addresses when the host connects (e.g., the approximately 30 >> addresses that can fit into a single packet) >> >> >> ? is there such a restriction in the DHCP spec? Is it that DHCP >> Ack/Advertise could carry only 30 addresses? >> >> would accommodate current clients, but it sets a limit on the number of >> addresses available to hosts when they attach and therefore limits >> the development of future applications. >> >> >> Yes, it would set a limit _if_ DHCP had such a limit. Do you think DHCP >> has a limit in the number of addresses it could assign in an >> Ack or Advertise? >> >> The maximum number of IPv6 addresses that can be provided in a single >> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is >> approximately 30. >> >> >> Do we have a packet dump showing this? I am asking because 30 addresses >> make for 480bytes... >> >> Jen said: >> >> I had to use all my imagination and still not sure how the phrase 'it >> is RECOMMENDED that the network give the host the ability to use new >> addresses without requiring explicit requests.' can be read as 'DHCPv6 i= s >> not recommended'. >> >> >> Because SLAAC does not obtain addresses by using Requests. That's DHCP >> who uses Requests to obtain addresses. >> >> That RECOMMENDation is clearly written by someone who has some deep >> disapproval of DHCP. >> >> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot >> use new addresses without requesting them from a DHCPv6 server >> on the network.' does not seem to be accurate. As this statement >> appears to be the key point of your document, I believe it needs to >> be fixed before we can proceed. >> >> >> On my side, I can agree. But that is your discussion. >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/l >> istinfo/v6ops >> >> >> --f40304360182dab27a05549dd22c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If a host gets a /64, it can allocate addresses out of it.= =C2=A0 If the prefix allows autoconfiguration, it can allocate its own add= resses using SLAAC.

On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu <a= lexandre.petrescu@gmail.com> wrote:


Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit :
Alexandre, it's a really important recommendation of the document that = the host be allowed to allocate /its own/ addresses,

I dont understand how a host can allocate its own addresses.=C2=A0 Or do yo= u
mean IID?

(we are very far from Host deciding an address, suggesting it to the
network, and the network update the routes - but I think you dont mean
that either.)

Alex

rather than having to rely on the correctness of the DHCP IA_NA implementat= ion.=C2=A0 =C2=A0So the language you are proposing would completely change = that.

On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com= <mailto:alexandre.petrescu@gmail.com>> wrote:

I agree that in the past there may have existed a risk of cellular networks= assigning a single IPv6 address (w/o even a plen) to one UE.
So one wanted a recommendation against DHCPv6 single address per End
node.

However, I still think this RFC is a mis-written recommendation.

It would have been much simpler to RECOMMEND to allocate multiple addresses= per End node, as many as that End node requires, be them individual addres= ses, or addresses aggregated into prefixes, or multiple prefixes.

But the current recommendation as it stands looks weird.

Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit :

I have read the draft and re-read rfc7934 and now I'm completely confus= ed. First of all, I can not see where rfc7934 says that DHCPv6 is not recom= mended.


RFC7934:

In order to avoid the problems described above and preserve the Internet= 9;s ability to support new applications that use more than one
IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
multiple IPv6 addresses from each prefix to general-purpose hosts.


What makes one think that some network deployment might block the forming o= f multiple IPv6 addresses from each prefix?

Or maybe the "from each prefix" is superfluous?

Because I dont think there is any method that provides a prefix yet restric= ts the use to just one address in that prefix.

If a Router sends an RA to many Hosts then each of these Hosts may configur= e many addresses within it.

If a Router sends an RA unicast to a Host then that Host may configure many= addresses within it.

If an address is delivered by a DHCP Server, then that is an address
=C2=A0without any prefix specified.

If a prefix is delegated by a DHCP Server then a receiving Client may
configure many addresses within that prefix.

To support future use cases, it is NOT RECOMMENDED to impose a hard limit o= n the size of the address pool assigned to a host.


What do you mean?=C2=A0 Is that pool a DHCP pool?=C2=A0 What is an example = of someone imposing a hard limit on the size of that pool?

Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6
=C2=A0address per prefix.


I did not see any place where there is such a restriction.=C2=A0 I wonder =C2=A0what is an example where a Host was limited to only one IPv6 address<= br> =C2=A0formed out of a prefix.

Due to the drawbacks imposed by requiring explicit requests for address spa= ce (see Section 4), it is RECOMMENDED that the network give the host the ab= ility to use new addresses without requiring explicit requests.=C2=A0 This = can be achieved either by allowing the host
=C2=A0to form new addresses autonomously (e.g., via SLAAC) or by providing<= br> =C2=A0the host with a dedicated /64 prefix.


This "either or" sounds like exclusive or.=C2=A0 But on cellular = networks the Host is provided a dedicated prefix _and_ forms new addresses = autonomously.

This is confusing.

Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide multip= le addresses when the host connects (e.g., the approximately 30
addresses that can fit into a single packet)


?=C2=A0 is there such a restriction in the DHCP spec?=C2=A0 Is it that DHCP= Ack/Advertise could carry only 30 addresses?

would accommodate current clients, but it sets a limit on the number of add= resses available to hosts when they attach and therefore limits
the development of future applications.


Yes, it would set a limit _if_ DHCP had such a limit.=C2=A0 Do you think DH= CP has a limit in the number of addresses it could assign in an
Ack or Advertise?

The maximum number of IPv6 addresses that can be provided in a single
DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is
approximately 30.


Do we have a packet dump showing this?=C2=A0 I am asking because 30 address= es make for 480bytes...

Jen said:

I had to use all my imagination and still not sure how the phrase 'it is RECOMMENDED that the network give the host the ability to use new
addresses without requiring explicit requests.' can be read as 'DHC= Pv6 is not recommended'.


Because SLAAC does not obtain addresses by using Requests.=C2=A0 That's= DHCP who uses Requests to obtain addresses.

That RECOMMENDation is clearly written by someone who has some deep disappr= oval of DHCP.

Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot= use new addresses without requesting them from a DHCPv6 server
on the network.' does not seem to be accurate.=C2=A0 As this statement<= br> appears to be the key point of your document, I believe it needs to
be fixed before we can proceed.


On my side, I can agree.=C2=A0 But that is your discussion.

Alex

_______________________________________________ v6ops mailing list v6ops@ietf.org <mai= lto:v6ops@ietf.org&= gt; https://www.ietf.org/mailman/listinfo/v6ops = <https://www.ietf.org/mailman/listinfo/v6ops&= gt;



--f40304360182dab27a05549dd22c-- From nobody Tue Jul 18 15:47:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1E6126CC4 for ; Tue, 18 Jul 2017 15:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 m5F3sqgg6flT for ; Tue, 18 Jul 2017 15:47:55 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C8F126C23 for ; Tue, 18 Jul 2017 15:47:55 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id e93so4053193ioi.3 for ; Tue, 18 Jul 2017 15:47: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; bh=XYYCJd2WITD2FXHG+PsLBjBv57FIGb+fPmA7B6ui/Xk=; b=HcSg4BajL2AzZ5eorrEd94PDFX1OcFt8yRCYCjOJXkzLxqtCvnV97u438OUI1F9yxM EJzKlrUwndZ4YpEc85VNEsGzlrDfk3EWzyVWpnehndPdK82G0HGF/Wy0hqj8uZ6X5vsc hBevLBJICkOMpIwBX0xbd+l935nEHhr8kZCB3b9aOCyFuWxyvRF5bZ0Xdq0crrYlBuBg RgTTx0BYvXeIHm+hEX6CKW1sKHgxOMI2kIb6Iie/wgm2rM6d3shDz/ou7pqKnb9mbWTb I2doat1e1Eei4DzR6eAArUU1gUUxkLxifydA+qvK/DltveEsCNFA1wFE9QTZKHmDqVMS rCww== 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=XYYCJd2WITD2FXHG+PsLBjBv57FIGb+fPmA7B6ui/Xk=; b=sKW1Y1AgQQ9eV6WGB0uiZk+AwGxRR2xTSyTOI3bTbSrNsV25K+ol+V3pi/w2qDiDFR JJ5TW8UuClvmz8c9z3zsVpANDSvZT3St+g/A2TkqXSWMkgTvSKU8teAPlcRY+Ojh+YL3 ysPe6cYPJNhg2XfesNCYzUOoY7cO1wABdCErm91/JWI2sGXxnVuX1Zs5hi6F2jelTcsg w1S4PEQScTP+vH/S4M7ruDDZQmKLrkSVPcl02MkAmnyY5I4qRqNdxqzU0ZXx7jd4z7Rp mc9H6KpNWVNNyuzyvVgPk8qDtGgUnn2pkcOmharOiEC2Xde/8qyN4wG4HMxAuTxhsyHp JswA== X-Gm-Message-State: AIVw113v06BQtcwqoLEOYntl638bwbBq6HZzF4qdR+T/V8fcI/uHvtNm +b8BBJLL7Kah8/v42Ka63PTtMc+o9g== X-Received: by 10.107.174.26 with SMTP id x26mr4118082ioe.24.1500418074822; Tue, 18 Jul 2017 15:47:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Tue, 18 Jul 2017 15:47:34 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Jen Linkova Date: Wed, 19 Jul 2017 08:47:34 +1000 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:47:56 -0000 On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu wrote: > Jen said: >> >> I had to use all my imagination and still not sure how the phrase 'it >> is RECOMMENDED that the network give the host the ability to use new >> addresses without requiring explicit requests.' can be read as 'DHCPv6 is >> not recommended'. > > > Because SLAAC does not obtain addresses by using Requests. That's DHCP > who uses Requests to obtain addresses. Let me give you an example. Imagine that we have apples and oranges. Then I say: 'It is recommended that children are given apples every day'. Does it mean "giving children oranges is not recommended'? No. False. However the statement 'giving children oranges (and oranges ONLY) is not recommended' is true. See the difference? ;) -- SY, Jen Linkova aka Furry From nobody Tue Jul 18 16:33:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4D5131B1F for ; Tue, 18 Jul 2017 16:33:39 -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 KD0i6TIQClz3 for ; Tue, 18 Jul 2017 16:33:38 -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 6D70B1317A1 for ; Tue, 18 Jul 2017 16:33:38 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v190so20677123pgv.2 for ; Tue, 18 Jul 2017 16:33: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=Hwc8D9LPU0juHUoeNiwRMd3+btps8/vXVZGQpyQHMHc=; b=KLWN8QV9kRB8Tiu3GA4uwLhRz8LXyj9g7vJR/LPc21AjVtq/qVsztM0u1DLZTvCIgT SNKTnjMjPAejlRhkCEdIXo8Hddll61U/8n4+L9I5ClMAoM+nzj2Mw+IpIdWgqEJFK2x/ T6uU9H5piXd08flgYj5FwJRkh0S/z4DXmHUF4KVg3gnvWLgUQv6zbJ84u05/7lWd57KM fkiWlhtihrkXDWH49Vl8fjW2TpkIupKv6JG3ND7atlhVfwzWCwTey4nNB5Ao8AgHPTT3 hmb+Cy7KZ5lGr+tWUdZaEH7B5+jw+bn02SaQGFzEvYjCoszOqgCjclkqY52SM/j1MYja WLWQ== 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=Hwc8D9LPU0juHUoeNiwRMd3+btps8/vXVZGQpyQHMHc=; b=cAWXQtuIdKaedqL2JC3GvKDgLXdfVtjJpJGu8W0QqE547ZUax8/DX79DGY1e6VZUCy 1wqsw/nV4WOxnUrxaumro8RgT0bbf/Wmr6csKRb6qm8e/N1qNovtTml+F92hPI3bDT6p wXop/tnsdFJL1/u+GfMTPcu3redPj4wwF7peCcmcojPGSIvNPNCQphmc7FGwb/xLi19F svKNLMzRUwNDO7L/J5E3O4RPXeL0YU35LeZpxkWJ77A5BDHpB72WvrBYxI352/HGW/Ap 8/8oAtQb+YZhJz+YhpT72pmUHpsYz2D4WARa6zxuB0H45ljV2kuu3tQU8cKK0ojkgPgK wWDw== X-Gm-Message-State: AIVw11321Fr5wG97NBiw92hcXXMu9iEf0FuodlRPXKboQV7iAvJzasZd SXnJoEBS+g/W1fFB X-Received: by 10.84.132.76 with SMTP id 70mr50382ple.7.1500420817897; Tue, 18 Jul 2017 16:33:37 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o29sm7656049pfa.60.2017.07.18.16.33.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 16:33:37 -0700 (PDT) To: Jen Linkova Cc: IPv6 Operations References: <596CF817.8040900@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 19 Jul 2017 11:33:37 +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: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 23:33:40 -0000 On 19/07/2017 03:23, Jen Linkova wrote: > I have read the draft and re-read rfc7934 and now I'm completely confused. > First of all, I can not see where rfc7934 says that DHCPv6 is not recommended. > > I had to use all my imagination and still not sure how the phrase 'it > is RECOMMENDED that the network > give the host the ability to use new addresses without requiring > explicit requests.' can be read as 'DHCPv6 is not recommended'. Yes. We still appear to be having an argument based on the idea that if something is not "RECOMMENDED" it is therefore "NOT RECOMMENDED". At least, that's the most sense I can make of it. Nothing in RFC7934 says that any part of DHCPv6 is NOT RECOMMENDED (or SHOULD NOT be used, which is the same thing). Specifically, there is no normative statement whatever about IA_NA or IA_TA. Brian From nobody Tue Jul 18 20:37:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6C312EB13 for ; Tue, 18 Jul 2017 20:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 nG6Wm1v7sJnx for ; Tue, 18 Jul 2017 20:37:38 -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 3718412EAA5 for ; Tue, 18 Jul 2017 20:37:38 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id u4so2364194uaa.1 for ; Tue, 18 Jul 2017 20:37:38 -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=7XHhgn9TZFeMlStxwazskQPeEjRUt7U0XxS/5zOCcpw=; b=ilW5Bvp2wXMA9vZx9eMgg6SvLCJ1BXI2vhetkA8bxUbxXgg7WM8fNkmn5/zT3jlsjH js3m7jzi/TV4FdvhLkXhpZfXNlzpTMg6KomYkJRrK94d0r+zUG/3++1Jwq7fMp3hG8mg t4RdHb++rRQRoE1uXrqoNSkL7LcxtTa9/59h1qvzw61+P0TOZeD2lDyzVlU+uqv4VxSy 8TUtC9BFR6rPBaE2FKbThezL+M2B5JAE3fqVKtMG6PaxTcjA0xYPEE172RdP2obCEOSD qSE4jb7TqP261FcQhMhZ8cDfkPQirc4/Yc9B8miQXWRc5RYREeA0EB1/78H7gj84iL8h q0og== 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=7XHhgn9TZFeMlStxwazskQPeEjRUt7U0XxS/5zOCcpw=; b=gUfDfHxyNwy31tlxnU3N2v3a5Z0st4tb4ZYgSWSpKIoq7Bdpfx0dHuavN6+1iVPddT 8OTvrxdVLcP0AYUkJds0rjMRcTQER+CUJDffHoFRgmNbP8irkjZXcBFkIXCu8p4F2ZC1 0UPjms6BAPa1FmsZ1Kew3vQAf3b0gho9KSphsK4Cy4vYrRdfPtWDn9FwDwj8y2bKqwu/ YFj5IoruA9ALOebMXXV3TEiNltJrmcUzwzr6QkM7ZiU/5c+ZaTQSeEUG9XKlQ9sijLOI DrUAtY4wnL3HzaI5Lh60ugzYPVQ4nQ3EtL+kXu24T3yP3rsyPEhV9/oi9rSbqMaGi+cf sNUg== X-Gm-Message-State: AIVw110l5TNCOoOOi/MBjskpjIAkCXbOeoU4DnEc3l3OqsKTyfOszHQr So4rvXdw4QIWDHL22NHWZ+eJ8WOkPw== X-Received: by 10.159.53.45 with SMTP id o42mr472856uao.84.1500435457221; Tue, 18 Jul 2017 20:37:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Tue, 18 Jul 2017 20:37:06 -0700 (PDT) In-Reply-To: <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> References: <596CF817.8040900@foobar.org> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> From: Mark Smith Date: Wed, 19 Jul 2017 13:37:06 +1000 Message-ID: To: Alexandre Petrescu Cc: Ted Lemon , IPv6 Ops WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 03:37:40 -0000 On 19 July 2017 at 06:09, Alexandre Petrescu wrote: > > > Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit : >> >> Alexandre, it's a really important recommendation of the document that t= he >> host be allowed to allocate /its own/ addresses, > > > I dont understand how a host can allocate its own addresses. Or do you > mean IID? > I'm sure that is what Ted fundamentally means, although it extends a bit beyond choosing just an IID. It also involves how many IIDs to generate and use with the received prefixes (one for all prefixes, one per prefix, or even mulitple IIDs per prefix) to create addresses. > (we are very far from Host deciding an address, suggesting it to the > network, and the network update the routes - but I think you dont mean > that either.) > > Alex > >> rather than having to rely on the correctness of the DHCP IA_NA >> implementation. So the language you are proposing would completely cha= nge >> that. >> >> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu >> > wro= te: >> >> I agree that in the past there may have existed a risk of cellular >> networks assigning a single IPv6 address (w/o even a plen) to one UE. >> So one wanted a recommendation against DHCPv6 single address per End >> node. >> >> However, I still think this RFC is a mis-written recommendation. >> >> It would have been much simpler to RECOMMEND to allocate multiple >> addresses per End node, as many as that End node requires, be them >> individual addresses, or addresses aggregated into prefixes, or multiple >> prefixes. >> >> But the current recommendation as it stands looks weird. >> >> Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit : >> >> I have read the draft and re-read rfc7934 and now I'm completely confuse= d. >> First of all, I can not see where rfc7934 says that DHCPv6 is not >> recommended. >> >> >> RFC7934: >> >> In order to avoid the problems described above and preserve the Internet= 's >> ability to support new applications that use more than one >> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide >> multiple IPv6 addresses from each prefix to general-purpose hosts. >> >> >> What makes one think that some network deployment might block the formin= g >> of multiple IPv6 addresses from each prefix? >> >> Or maybe the "from each prefix" is superfluous? >> >> Because I dont think there is any method that provides a prefix yet >> restricts the use to just one address in that prefix. >> >> If a Router sends an RA to many Hosts then each of these Hosts may >> configure many addresses within it. >> >> If a Router sends an RA unicast to a Host then that Host may configure >> many addresses within it. >> >> If an address is delivered by a DHCP Server, then that is an address >> without any prefix specified. >> >> If a prefix is delegated by a DHCP Server then a receiving Client may >> configure many addresses within that prefix. >> >> To support future use cases, it is NOT RECOMMENDED to impose a hard limi= t >> on the size of the address pool assigned to a host. >> >> >> What do you mean? Is that pool a DHCP pool? What is an example of >> someone imposing a hard limit on the size of that pool? >> >> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 >> address per prefix. >> >> >> I did not see any place where there is such a restriction. I wonder >> what is an example where a Host was limited to only one IPv6 address >> formed out of a prefix. >> >> 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. 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. >> >> >> This "either or" sounds like exclusive or. But on cellular networks the >> Host is provided a dedicated prefix _and_ forms new addresses autonomous= ly. >> >> This is confusing. >> >> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide >> multiple addresses when the host connects (e.g., the approximately 30 >> addresses that can fit into a single packet) >> >> >> ? is there such a restriction in the DHCP spec? Is it that DHCP >> Ack/Advertise could carry only 30 addresses? >> >> would accommodate current clients, but it sets a limit on the number of >> addresses available to hosts when they attach and therefore limits >> the development of future applications. >> >> >> Yes, it would set a limit _if_ DHCP had such a limit. Do you think DHCP >> has a limit in the number of addresses it could assign in an >> Ack or Advertise? >> >> The maximum number of IPv6 addresses that can be provided in a single >> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is >> approximately 30. >> >> >> Do we have a packet dump showing this? I am asking because 30 addresses >> make for 480bytes... >> >> Jen said: >> >> I had to use all my imagination and still not sure how the phrase 'it >> is RECOMMENDED that the network give the host the ability to use new >> addresses without requiring explicit requests.' can be read as 'DHCPv6 i= s >> not recommended'. >> >> >> Because SLAAC does not obtain addresses by using Requests. That's DHCP >> who uses Requests to obtain addresses. >> >> That RECOMMENDation is clearly written by someone who has some deep >> disapproval of DHCP. >> >> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot >> use new addresses without requesting them from a DHCPv6 server >> on the network.' does not seem to be accurate. As this statement >> appears to be the key point of your document, I believe it needs to >> be fixed before we can proceed. >> >> >> On my side, I can agree. But that is your discussion. >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 18 21:14:44 2017 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7FE126B6E for ; Tue, 18 Jul 2017 21:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snMsKvVJiHyD for ; Tue, 18 Jul 2017 21:14:42 -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 39A2C12783A for ; Tue, 18 Jul 2017 21:14:42 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w126so90377486wme.0 for ; Tue, 18 Jul 2017 21:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=D1JbrDaqh0/orS6eGLjXL58998kn/2jLxvSIPAqXcU8=; b=cvrCqghl9xpKbCxTJlZbWDO+rMC86goRTT0VuK2hRy0zB+hCfvpiPHNKZktJzxb1Hg AP+euzb2xUt9x//iCQ855g6qZ7ZPDo6XEmQNZBi1Kd/k78d5OaT7CFcYTAuRDgHUDyDe 8tLHfvGDQjkAqis4jvahBFf0qWMYskJ6SblYOpDaYnC1pKlybwkk0PA+RvoCNnO/kED4 kc+T0Y6Svg6gz6TyRkzZHKssAPybA3ZSS6+Z5V8yMWamd05PoY8UBj9ztpNcczU1nO2D 5dOPhzS6rJeYzSMqpljhxX/391MeD8EFM4Y9C9HeR5Gbg4DfDR6rNdUWZvQJhCRDdPQM LaHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=D1JbrDaqh0/orS6eGLjXL58998kn/2jLxvSIPAqXcU8=; b=jmfULn39OTd/3iFS73m57ClV2op25SrnFT/978TcU8jDhTwszHGfspP37EDEegn2d6 LSzLMuCT6v9rzHPIgw9SdaFaH+7KSy8HcuhjN0yW09iNM4CdWnEnvi9cJ2VjvcHx+9xA aCCNhUHgrdzCS0FaS6r/RAFMW8pwXt2sU1Y48Nbzjs9Gn8XTNsAuaLmeXQVC2jPTeDs9 pzA1+4ixGRnmNbt+TAhSWAz9eeaZgtBsMeHyTg9MlvKeL2TJfa5J7dQxebJvS9K+uuWD KkpF3g8CfBhlqMqYkgSKKYSOwaVvHoj4pTAmtRG0C+q0SBx/ZWwS7evSGhrAmbPcymCI AHHw== X-Gm-Message-State: AIVw113qn6saWcs/9e7y/E1PWvQyIlnEL+PmGe9MC5lB44JIkT0wC0A9 FTxKCOJMY1KV9g== X-Received: by 10.28.126.8 with SMTP id z8mr4328960wmc.46.1500437680730; Tue, 18 Jul 2017 21:14:40 -0700 (PDT) Received: from Russ ([88.208.89.131]) by smtp.gmail.com with ESMTPSA id v16sm4376358wrc.65.2017.07.18.21.14.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 21:14:40 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'james woodyatt'" , "'IPv6 Operations'" References: In-Reply-To: Date: Wed, 19 Jul 2017 00:14:38 -0400 Message-ID: <01e901d30045$8a502d10$9ef08730$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG6peZXN8/OQa2eYygfdBiuWfaUcaKLPy0g Archived-At: Subject: Re: [v6ops] I-D.ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 04:14:44 -0000 > As I just said at the microphone, I think it would be helpful to add = something to > this document that connects to Host Address Availability = Recommendations > [RFC 7934]. In simple terms, we need routers to be capable of making > addresses available to hosts without requiring them to make an = explicit > request for each one, and this draft should cite RFC 7934 accordingly. Thanks! I've added this to my list of things to do for the next = revision. =F0=9F=98=8A /r From nobody Tue Jul 18 22:19:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14A12783A for ; Tue, 18 Jul 2017 22:19:22 -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, 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=fugue-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 qXeoqUPnlXE0 for ; Tue, 18 Jul 2017 22:19:20 -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 000D81274D0 for ; Tue, 18 Jul 2017 22:19:19 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id q85so21834481pfq.1 for ; Tue, 18 Jul 2017 22:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oj4v8pcOqSi7nrd+s9vs+0E/R56ZZoigJOxR2cjh5P4=; b=WWFvEDFgzPL22qB8Z9vr1ej8nCGou9rZKXrXuXlWODtHmDhlbrOpE/pFjJycFr19Y3 T7W4paOK4p+hWjAVgblipR8pHmkPW39qwoMWTgcwDdo6QwLtCVk7MXGIksxEy0gP0uJh AUdKY/jm1UPjEVQ9IEOeKr0o2usAXUt9cg63w3p4DgBSvxvtBL445Lc60pz0smqTt2gU EnR8gIVKmW9W7NB1Pa/uuEnDVFRvPE38dmli5+1yTLUCFXG35u5zLMpcOQDK0Byf7RYT n4v+EfQX0CTfBrIYY4tvOwqGamu8RKiLlKu/wYRXF2rIF18StfCI9F75VR6hdYZIzRbs cZ7Q== 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=Oj4v8pcOqSi7nrd+s9vs+0E/R56ZZoigJOxR2cjh5P4=; b=bhsKpoly2mrW4AZH6PbGQVLdMqAJrt1BF12kauneTFF9U4G+U3YDrKA6BJZNxQMpeM wACFNyyWurvinFVUP+hH4L1BUJ4dLCSugYNxfgS1Xv5QHHCDi3geM/BLKYZOvuZLhSl+ 1YejaxnwEqFDfqZsAb+biDnBdukEOZKukZ58E5XVT/zpzP/erueG3h5mmItxwXqNgodQ pHU/41h8hVQgrD3xI8G9kdfKBIJc5hWSWrcbs7gsgFuXY7EGzjJ/pqJG/HCuxCnYk8ZV Tv4MKLQsJoKeCkm/OmN4PMYAq3rgQA0C7lbw9r9oSYik2edChj1CkKVAUkL3H5vYKEoP FMTw== X-Gm-Message-State: AIVw113nX9qozvhDPA4BcdjEMqehVX0dGf/wNCnvVcMINwMErd5mIb+6 YidEbbZ15pObEUIguzl0F+c7GqzHu1zM X-Received: by 10.84.231.16 with SMTP id f16mr1265761plk.131.1500441559525; Tue, 18 Jul 2017 22:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 22:19:18 -0700 (PDT) Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 22:19:18 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> From: Ted Lemon Date: Wed, 19 Jul 2017 07:19:18 +0200 Message-ID: To: Mark Smith Cc: IPv6 Ops WG , Alexandre Petrescu Content-Type: multipart/alternative; boundary="f40304360182297e430554a4c695" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 05:19:22 -0000 --f40304360182297e430554a4c695 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Prefix+iid=3Daddress. But iid is really a misnomer. On Jul 19, 2017 5:37 AM, "Mark Smith" wrote: > On 19 July 2017 at 06:09, Alexandre Petrescu > wrote: > > > > > > Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit : > >> > >> Alexandre, it's a really important recommendation of the document that > the > >> host be allowed to allocate /its own/ addresses, > > > > > > I dont understand how a host can allocate its own addresses. Or do you > > mean IID? > > > > I'm sure that is what Ted fundamentally means, although it extends a > bit beyond choosing just an IID. It also involves how many IIDs to > generate and use with the received prefixes (one for all prefixes, one > per prefix, or even mulitple IIDs per prefix) to create addresses. > > > (we are very far from Host deciding an address, suggesting it to the > > network, and the network update the routes - but I think you dont mean > > that either.) > > > > Alex > > > >> rather than having to rely on the correctness of the DHCP IA_NA > >> implementation. So the language you are proposing would completely > change > >> that. > >> > >> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu > >> > > wrote: > >> > >> I agree that in the past there may have existed a risk of cellular > >> networks assigning a single IPv6 address (w/o even a plen) to one UE. > >> So one wanted a recommendation against DHCPv6 single address per End > >> node. > >> > >> However, I still think this RFC is a mis-written recommendation. > >> > >> It would have been much simpler to RECOMMEND to allocate multiple > >> addresses per End node, as many as that End node requires, be them > >> individual addresses, or addresses aggregated into prefixes, or multip= le > >> prefixes. > >> > >> But the current recommendation as it stands looks weird. > >> > >> Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit : > >> > >> I have read the draft and re-read rfc7934 and now I'm completely > confused. > >> First of all, I can not see where rfc7934 says that DHCPv6 is not > >> recommended. > >> > >> > >> RFC7934: > >> > >> In order to avoid the problems described above and preserve the > Internet's > >> ability to support new applications that use more than one > >> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide > >> multiple IPv6 addresses from each prefix to general-purpose hosts. > >> > >> > >> What makes one think that some network deployment might block the > forming > >> of multiple IPv6 addresses from each prefix? > >> > >> Or maybe the "from each prefix" is superfluous? > >> > >> Because I dont think there is any method that provides a prefix yet > >> restricts the use to just one address in that prefix. > >> > >> If a Router sends an RA to many Hosts then each of these Hosts may > >> configure many addresses within it. > >> > >> If a Router sends an RA unicast to a Host then that Host may configure > >> many addresses within it. > >> > >> If an address is delivered by a DHCP Server, then that is an address > >> without any prefix specified. > >> > >> If a prefix is delegated by a DHCP Server then a receiving Client may > >> configure many addresses within that prefix. > >> > >> To support future use cases, it is NOT RECOMMENDED to impose a hard > limit > >> on the size of the address pool assigned to a host. > >> > >> > >> What do you mean? Is that pool a DHCP pool? What is an example of > >> someone imposing a hard limit on the size of that pool? > >> > >> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 > >> address per prefix. > >> > >> > >> I did not see any place where there is such a restriction. I wonder > >> what is an example where a Host was limited to only one IPv6 address > >> formed out of a prefix. > >> > >> Due to the drawbacks imposed by requiring explicit requests for addres= s > >> space (see Section 4), it is RECOMMENDED that the network give the hos= t > the > >> ability to use new addresses without requiring explicit requests. Thi= s > 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. > >> > >> > >> This "either or" sounds like exclusive or. But on cellular networks t= he > >> Host is provided a dedicated prefix _and_ forms new addresses > autonomously. > >> > >> This is confusing. > >> > >> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide > >> multiple addresses when the host connects (e.g., the approximately 30 > >> addresses that can fit into a single packet) > >> > >> > >> ? is there such a restriction in the DHCP spec? Is it that DHCP > >> Ack/Advertise could carry only 30 addresses? > >> > >> would accommodate current clients, but it sets a limit on the number o= f > >> addresses available to hosts when they attach and therefore limits > >> the development of future applications. > >> > >> > >> Yes, it would set a limit _if_ DHCP had such a limit. Do you think DH= CP > >> has a limit in the number of addresses it could assign in an > >> Ack or Advertise? > >> > >> The maximum number of IPv6 addresses that can be provided in a single > >> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is > >> approximately 30. > >> > >> > >> Do we have a packet dump showing this? I am asking because 30 address= es > >> make for 480bytes... > >> > >> Jen said: > >> > >> I had to use all my imagination and still not sure how the phrase 'it > >> is RECOMMENDED that the network give the host the ability to use new > >> addresses without requiring explicit requests.' can be read as 'DHCPv6 > is > >> not recommended'. > >> > >> > >> Because SLAAC does not obtain addresses by using Requests. That's DHC= P > >> who uses Requests to obtain addresses. > >> > >> That RECOMMENDation is clearly written by someone who has some deep > >> disapproval of DHCP. > >> > >> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA canno= t > >> use new addresses without requesting them from a DHCPv6 server > >> on the network.' does not seem to be accurate. As this statement > >> appears to be the key point of your document, I believe it needs to > >> be fixed before we can proceed. > >> > >> > >> On my side, I can agree. But that is your discussion. > >> > >> Alex > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > --f40304360182297e430554a4c695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Prefix+iid=3Daddress. But iid is really a misnomer.=C2=A0=

On Jul 19, = 2017 5:37 AM, "Mark Smith" <markzzzsmith@gmail.com> wrote:
On 19 July 2017 at 06:09, Alexandre Petrescu
<alexandre.petrescu@gmai= l.com> wrote:
>
>
> Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit :
>>
>> Alexandre, it's a really important recommendation of the docum= ent that the
>> host be allowed to allocate /its own/ addresses,
>
>
> I dont understand how a host can allocate its own addresses.=C2=A0 Or = do you
> mean IID?
>

I'm sure that is what Ted fundamentally means, although it extends a bit beyond choosing just an IID. It also involves how many IIDs to
generate and use with the received prefixes (one for all prefixes, one
per prefix, or even mulitple IIDs per prefix) to create addresses.

> (we are very far from Host deciding an address, suggesting it to the > network, and the network update the routes - but I think you dont mean=
> that either.)
>
> Alex
>
>> rather than having to rely on the correctness of the DHCP IA_NA >> implementation.=C2=A0 =C2=A0So the language you are proposing woul= d completely change
>> that.
>>
>> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu
>> <alexandre.petr= escu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
>>
>> I agree that in the past there may have existed a risk of cellular=
>> networks assigning a single IPv6 address (w/o even a plen) to one = UE.
>> So one wanted a recommendation against DHCPv6 single address per E= nd
>> node.
>>
>> However, I still think this RFC is a mis-written recommendation. >>
>> It would have been much simpler to RECOMMEND to allocate multiple<= br> >> addresses per End node, as many as that End node requires, be them=
>> individual addresses, or addresses aggregated into prefixes, or mu= ltiple
>> prefixes.
>>
>> But the current recommendation as it stands looks weird.
>>
>> Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit :
>>
>> I have read the draft and re-read rfc7934 and now I'm complete= ly confused.
>> First of all, I can not see where rfc7934 says that DHCPv6 is not<= br> >> recommended.
>>
>>
>> RFC7934:
>>
>> In order to avoid the problems described above and preserve the In= ternet's
>> ability to support new applications that use more than one
>> IPv6 address, it is RECOMMENDED that IPv6 network deployments prov= ide
>> multiple IPv6 addresses from each prefix to general-purpose hosts.=
>>
>>
>> What makes one think that some network deployment might block the = forming
>> of multiple IPv6 addresses from each prefix?
>>
>> Or maybe the "from each prefix" is superfluous?
>>
>> Because I dont think there is any method that provides a prefix ye= t
>> restricts the use to just one address in that prefix.
>>
>> If a Router sends an RA to many Hosts then each of these Hosts may=
>> configure many addresses within it.
>>
>> If a Router sends an RA unicast to a Host then that Host may confi= gure
>> many addresses within it.
>>
>> If an address is delivered by a DHCP Server, then that is an addre= ss
>>=C2=A0 without any prefix specified.
>>
>> If a prefix is delegated by a DHCP Server then a receiving Client = may
>> configure many addresses within that prefix.
>>
>> To support future use cases, it is NOT RECOMMENDED to impose a har= d limit
>> on the size of the address pool assigned to a host.
>>
>>
>> What do you mean?=C2=A0 Is that pool a DHCP pool?=C2=A0 What is an= example of
>> someone imposing a hard limit on the size of that pool?
>>
>> Particularly, it is NOT RECOMMENDED to limit a host to only one IP= v6
>>=C2=A0 address per prefix.
>>
>>
>> I did not see any place where there is such a restriction.=C2=A0 I= wonder
>>=C2=A0 what is an example where a Host was limited to only one IPv6= address
>>=C2=A0 formed out of a prefix.
>>
>> Due to the drawbacks imposed by requiring explicit requests for ad= dress
>> space (see Section 4), it is RECOMMENDED that the network give the= host the
>> ability to use new addresses without requiring explicit requests.= =C2=A0 This can
>> be achieved either by allowing the host
>>=C2=A0 to form new addresses autonomously (e.g., via SLAAC) or by p= roviding
>>=C2=A0 the host with a dedicated /64 prefix.
>>
>>
>> This "either or" sounds like exclusive or.=C2=A0 But on = cellular networks the
>> Host is provided a dedicated prefix _and_ forms new addresses auto= nomously.
>>
>> This is confusing.
>>
>> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provi= de
>> multiple addresses when the host connects (e.g., the approximately= 30
>> addresses that can fit into a single packet)
>>
>>
>> ?=C2=A0 is there such a restriction in the DHCP spec?=C2=A0 Is it = that DHCP
>> Ack/Advertise could carry only 30 addresses?
>>
>> would accommodate current clients, but it sets a limit on the numb= er of
>> addresses available to hosts when they attach and therefore limits=
>> the development of future applications.
>>
>>
>> Yes, it would set a limit _if_ DHCP had such a limit.=C2=A0 Do you= think DHCP
>> has a limit in the number of addresses it could assign in an
>> Ack or Advertise?
>>
>> The maximum number of IPv6 addresses that can be provided in a sin= gle
>> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is >> approximately 30.
>>
>>
>> Do we have a packet dump showing this?=C2=A0 I am asking because 3= 0 addresses
>> make for 480bytes...
>>
>> Jen said:
>>
>> I had to use all my imagination and still not sure how the phrase = 'it
>> is RECOMMENDED that the network give the host the ability to use n= ew
>> addresses without requiring explicit requests.' can be read as= 'DHCPv6 is
>> not recommended'.
>>
>>
>> Because SLAAC does not obtain addresses by using Requests.=C2=A0 T= hat's DHCP
>> who uses Requests to obtain addresses.
>>
>> That RECOMMENDation is clearly written by someone who has some dee= p
>> disapproval of DHCP.
>>
>> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_= TA cannot
>> use new addresses without requesting them from a DHCPv6 server
>> on the network.' does not seem to be accurate.=C2=A0 As this s= tatement
>> appears to be the key point of your document, I believe it needs t= o
>> be fixed before we can proceed.
>>
>>
>> On my side, I can agree.=C2=A0 But that is your discussion.
>>
>> Alex
>>
>> _______________________________________________ v6ops mailing= list
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/v6ops=
>> <https://www.ietf.org/mailman/listinfo/v= 6ops>
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=
--f40304360182297e430554a4c695-- From nobody Tue Jul 18 23:11:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DC012EB13 for ; Tue, 18 Jul 2017 23:11:04 -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 guohFNgvl_dz for ; Tue, 18 Jul 2017 23:11:03 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 1F9131242F5 for ; Tue, 18 Jul 2017 23:11:03 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 5so24710689iow.0 for ; Tue, 18 Jul 2017 23:11: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=iO+HqL2O8Uk4ec3wjpuLgljrmY/hRyIwmBiBS/JJfG8=; b=F/68WIy+rCgeb7aFAwvB9oQ+84oFGNHUhTotLB8rbKSX68/84+yB/X7u7UB4yl45H4 IubbyAq/OzfblgQbdU6j8E7rGWhPSy09wpfbTOAYKb3lSh3Fh3gMcvOlVgC/vB7zHQOQ jvEVm5yL8WW/aHnTfEoBvvaDR5n2dONYeRYRK+uwuTrl0tMfqdXKa9pD6FuGCkZWwjb5 MTBSknHsHnyORdhbBR3sCI+Vk9DWGdGzrwQicv6wXbH0eY7viZmu523ISHrsSqy68MB+ 6JZzsT3h71KW+X+csTAsDRUMeiyvEJq9sBbaC3Xed5yKuI6H6SZy5r5e/j322IqShs1h nvgQ== 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=iO+HqL2O8Uk4ec3wjpuLgljrmY/hRyIwmBiBS/JJfG8=; b=jvTtn5x5oVtOL6jHwS/GyeAZhJp2tqZL1aoe/pkHhCkBv/8Jo/iQl6II08TwSOTZKH 3iMVv1vRNyDl2f5GZjWRy0xVSGEouNWSrVAdThZeH7iFQ8HdzgCGav3HF9ZFHlXrLuLa pbeYbEtKwVhZ/HGFX1d3QfjzNEytWTERpOAPh33a5viXm/8SXtCbCrU8wIw6/BdjFsn5 4MFc+mrI4bOCd5267ax0IRzQqReLu1HNHBRAEXVExoc+RcV/Fcmgy4gzv0vRG78zDDUu t2ao9Q8hV33QDZ43rZSyNAahE5/4yGSgRffZ7ayddOqtadJMGVs4xJdfTz05J256+mbC 74Ug== X-Gm-Message-State: AIVw113SGEdKpUhDUVO5u+HbY9JAEofwrUAuwvG2odeOvKHKnGASyZhV q1zjJoicQ1hZNYADLpRcRmqIED7aWW4j X-Received: by 10.107.134.68 with SMTP id i65mr442743iod.218.1500444661967; Tue, 18 Jul 2017 23:11:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.164 with HTTP; Tue, 18 Jul 2017 23:11:00 -0700 (PDT) Received: by 10.107.130.164 with HTTP; Tue, 18 Jul 2017 23:11:00 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Lorenzo Colitti Date: Wed, 19 Jul 2017 08:11:00 +0200 Message-ID: To: "Brian E. Carpenter" Cc: Jen Linkova , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113ed2ac15918e0554a57f07" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:11:04 -0000 --001a113ed2ac15918e0554a57f07 Content-Type: text/plain; charset="UTF-8" On 19 Jul 2017 01:33, "Brian E Carpenter" wrote: Nothing in RFC7934 says that any part of DHCPv6 is NOT RECOMMENDED (or SHOULD NOT be used, which is the same thing). Specifically, there is no normative statement whatever about IA_NA or IA_TA. But it does make a normative recommendation against their exclusive use. Specifically, it says it is RECOMMENDED to give hosts the ability to form new addresses without explicit requests to the network. That recommendation cannot be met on a network that *only* provides addresses via IA_NA / IA_TA. So while it makes no normative recommendation about IA_NA / IA_TA themselves, it does make a normative recommendation against running a network that uses IA_NA / IA_TA as its only address assignment mechanism. --001a113ed2ac15918e0554a57f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 19 Jul 2017 01:33, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: Nothing in RFC7934 says that any part of DHCPv6 is NOT RECOMMENDED
(or SHOULD NOT be used, which is the same thing). Specifically,
there is no normative statement whatever about IA_NA or IA_TA.

But it = does make a normative recommendation against their exclusive use.

Specifically, it says it is RECOM= MENDED to give hosts the ability to form new addresses without explicit req= uests to the network. That recommendation cannot be met on a network that *= only* provides addresses via IA_NA / IA_TA.

So while it makes no normative recommendation about IA_= NA / IA_TA themselves, it does make a normative recommendation against runn= ing a network that uses=C2=A0IA_NA /= IA_TA as its only address assignment mechanism.
--001a113ed2ac15918e0554a57f07-- From nobody Tue Jul 18 23:24:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BD412EC0B for ; Tue, 18 Jul 2017 23:24:01 -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, 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=fugue-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 jWFT6Jfl_nww for ; Tue, 18 Jul 2017 23:23:59 -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 CD61A127369 for ; Tue, 18 Jul 2017 23:23:59 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 123so25498254pgj.1 for ; Tue, 18 Jul 2017 23:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gFPEvTJtOnl54cRZkjEXyyiCFQeH4a6YksMzpGhhOYY=; b=OkmzdKE+w5VxlSy5hVGHkg6ggropmNftbLy3AKy7ewDmgxI4Wl1jJuqbQhslRRwfnC rAxFOC7PSYQC2vZKQDaMqwvp+mn22JPvTv9WQIOLU5MyajGYmfRRYrUPkYWHclcUJ/vS psxTjf3J/M4f7f7VXxig9rFurD8n/jHv6HidLYek1J5JRAwrPMU43XsD2xjwEwYznWA5 jjIOTButCp3N5+vWjKcpEDrthP7EmyMN48FB9t008qmKE9JeNYRGWWzWR3n9xnA71DhX 4SPjinB85HKWkyOsTljyeAYvC9RuMoHWHsfd7D9XSleoY7xLrjkkOxHkJJXbYZtzTHgr XrXA== 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=gFPEvTJtOnl54cRZkjEXyyiCFQeH4a6YksMzpGhhOYY=; b=KPeIbYOsZjPAhsgRWpt0iRBlNpbVyM/w7GCYieoucIMLHjHzilMLxNenCinog5b2Ww lt7ZCPNJg79kE1cVxGcMNYk6yMqLoL7ydExjp8ij7iq5WrgidyNYdxS/TBl+Lbg2kXys yNmEIvahGq6WYFWd+ZItVZ7eeFIphV5t891nSkov8Hd1et4h5TgUuW3YvuOAyWMQIAPL piNAGay2ZI1MrBXOP80s6ZS81FczC6nWq+rDKw1V4WUjHb9ebnyGszEmvezfIGWQDnUW 2Zlj2uuNmDHkgwJY5Gi9EQGHGTtIYsiDnQqrTnzl8QoUHGYyOps2LSnH8bYwTyPzb8JT 108g== X-Gm-Message-State: AIVw11200L0HbZgPAj2sRysztgJp/D7dPFVepAAZdPFu4IKbY9uJilNz LddsacK03EO2M4cMW1PIHY+kkMT5nZ6k X-Received: by 10.99.62.65 with SMTP id l62mr1443166pga.220.1500445439241; Tue, 18 Jul 2017 23:23:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Tue, 18 Jul 2017 23:23:18 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Ted Lemon Date: Wed, 19 Jul 2017 08:23:18 +0200 Message-ID: To: Lorenzo Colitti Cc: "Brian E. Carpenter" , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c18ff6a6945560554a5ade6" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:24:02 -0000 --94eb2c18ff6a6945560554a5ade6 Content-Type: text/plain; charset="UTF-8" But, to be clear, if you do not follow the RECOMMENDation, you are still in spec, because it is a RECOMMENDation, not a REQUIREment. On Wed, Jul 19, 2017 at 8:11 AM, Lorenzo Colitti wrote: > On 19 Jul 2017 01:33, "Brian E Carpenter" > wrote: > > Nothing in RFC7934 says that any part of DHCPv6 is NOT RECOMMENDED > (or SHOULD NOT be used, which is the same thing). Specifically, > there is no normative statement whatever about IA_NA or IA_TA. > > > But it does make a normative recommendation against their exclusive use. > > Specifically, it says it is RECOMMENDED to give hosts the ability to form > new addresses without explicit requests to the network. That recommendation > cannot be met on a network that *only* provides addresses via IA_NA / IA_TA. > > So while it makes no normative recommendation about IA_NA / IA_TA > themselves, it does make a normative recommendation against running a > network that uses IA_NA / IA_TA as its only address assignment mechanism. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --94eb2c18ff6a6945560554a5ade6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But, to be clear, if you do not follow the RECOMMENDation,= you are still in spec, because it is a RECOMMENDation, not a REQUIREment.<= /div>

On Wed, Jul = 19, 2017 at 8:11 AM, Lorenzo Colitti <lorenzo@google.com> w= rote:
=
On 19 Jul 2017 0= 1:33, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: Nothing in RFC7934 says that any part of DHCPv6 is NOT RECOMMENDED
(or SHOULD NOT be used, which is the same thing). Specifically,
there is no normative statement whatever about IA_NA or IA_TA.

= But it does make a normative recommendation against their exclusive use.

Specifically, it says it i= s RECOMMENDED to give hosts the ability to form new addresses without expli= cit requests to the network. That recommendation cannot be met on a network= that *only* provides addresses via IA_NA / IA_TA.
<= br>
So while it makes no normative recommendation ab= out IA_NA / IA_TA themselves, it does make a normative recommendation again= st running a network that uses=C2=A0= IA_NA / IA_TA as its only address assignment mechanism.

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


--94eb2c18ff6a6945560554a5ade6-- From nobody Wed Jul 19 00:21:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221E131BFC for ; Wed, 19 Jul 2017 00:21:03 -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 jUzVaJ-dmPz1 for ; Wed, 19 Jul 2017 00:21:01 -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 D673B131BF4 for ; Wed, 19 Jul 2017 00:21:00 -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 v6J7Kw2e026773; Wed, 19 Jul 2017 09:20:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D26F206514; Wed, 19 Jul 2017 09:20:58 +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 5EC9C200F8D; Wed, 19 Jul 2017 09:20:58 +0200 (CEST) Received: from [132.166.84.70] ([132.166.84.70]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6J7KupL020029; Wed, 19 Jul 2017 09:20:57 +0200 To: Ted Lemon Cc: IPv6 Ops WG References: <596CF817.8040900@foobar.org> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 19 Jul 2017 09:20:55 +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: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:21:04 -0000 Maybe a better recommendation, in no particular order, is to give a Host DHCP-PD, many-DHCP-Address, and RA with A bit. Again, in no particular order and potentially all at the same time. Le 18/07/2017 à 23:01, Ted Lemon a écrit : > If a host gets a /64, it can allocate addresses out of it. If the > prefix allows autoconfiguration, it can allocate its own addresses > using SLAAC. Alex > > On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu > > > wrote: > > > > Le 18/07/2017 à 21:28, Ted Lemon a écrit : > > Alexandre, it's a really important recommendation of the document > that the host be allowed to allocate /its own/ addresses, > > > I dont understand how a host can allocate its own addresses. Or do > you mean IID? > > (we are very far from Host deciding an address, suggesting it to the > network, and the network update the routes - but I think you dont > mean that either.) > > Alex > > rather than having to rely on the correctness of the DHCP IA_NA > implementation. So the language you are proposing would completely > change that. > > On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu > > >> wrote: > > I agree that in the past there may have existed a risk of cellular > networks assigning a single IPv6 address (w/o even a plen) to one > UE. So one wanted a recommendation against DHCPv6 single address per > End node. > > However, I still think this RFC is a mis-written recommendation. > > It would have been much simpler to RECOMMEND to allocate multiple > addresses per End node, as many as that End node requires, be them > individual addresses, or addresses aggregated into prefixes, or > multiple prefixes. > > But the current recommendation as it stands looks weird. > > Le 18/07/2017 à 17:23, Jen Linkova a écrit : > > I have read the draft and re-read rfc7934 and now I'm completely > confused. First of all, I can not see where rfc7934 says that DHCPv6 > is not recommended. > > > RFC7934: > > In order to avoid the problems described above and preserve the > Internet's ability to support new applications that use more than > one IPv6 address, it is RECOMMENDED that IPv6 network deployments > provide multiple IPv6 addresses from each prefix to general-purpose > hosts. > > > What makes one think that some network deployment might block the > forming of multiple IPv6 addresses from each prefix? > > Or maybe the "from each prefix" is superfluous? > > Because I dont think there is any method that provides a prefix yet > restricts the use to just one address in that prefix. > > If a Router sends an RA to many Hosts then each of these Hosts may > configure many addresses within it. > > If a Router sends an RA unicast to a Host then that Host may > configure many addresses within it. > > If an address is delivered by a DHCP Server, then that is an address > without any prefix specified. > > If a prefix is delegated by a DHCP Server then a receiving Client > may configure many addresses within that prefix. > > To support future use cases, it is NOT RECOMMENDED to impose a hard > limit on the size of the address pool assigned to a host. > > > What do you mean? Is that pool a DHCP pool? What is an example of > someone imposing a hard limit on the size of that pool? > > Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 > address per prefix. > > > I did not see any place where there is such a restriction. I wonder > what is an example where a Host was limited to only one IPv6 address > formed out of a prefix. > > 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. 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. > > > This "either or" sounds like exclusive or. But on cellular networks > the Host is provided a dedicated prefix _and_ forms new addresses > autonomously. > > This is confusing. > > Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide > multiple addresses when the host connects (e.g., the approximately > 30 addresses that can fit into a single packet) > > > ? is there such a restriction in the DHCP spec? Is it that DHCP > Ack/Advertise could carry only 30 addresses? > > would accommodate current clients, but it sets a limit on the number > of addresses available to hosts when they attach and therefore > limits the development of future applications. > > > Yes, it would set a limit _if_ DHCP had such a limit. Do you think > DHCP has a limit in the number of addresses it could assign in an Ack > or Advertise? > > The maximum number of IPv6 addresses that can be provided in a > single DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, > is approximately 30. > > > Do we have a packet dump showing this? I am asking because 30 > addresses make for 480bytes... > > Jen said: > > I had to use all my imagination and still not sure how the phrase > 'it is RECOMMENDED that the network give the host the ability to use > new addresses without requiring explicit requests.' can be read as > 'DHCPv6 is not recommended'. > > > Because SLAAC does not obtain addresses by using Requests. That's > DHCP who uses Requests to obtain addresses. > > That RECOMMENDation is clearly written by someone who has some deep > disapproval of DHCP. > > Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA > cannot use new addresses without requesting them from a DHCPv6 > server on the network.' does not seem to be accurate. As this > statement appears to be the key point of your document, I believe it > needs to be fixed before we can proceed. > > > On my side, I can agree. But that is your discussion. > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > From nobody Wed Jul 19 00:24:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D712EE45 for ; Wed, 19 Jul 2017 00:24: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, 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=fugue-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 OTUUM9beY7fY for ; Wed, 19 Jul 2017 00:24:14 -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 7E643129B3A for ; Wed, 19 Jul 2017 00:24:14 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 125so3018599pgi.3 for ; Wed, 19 Jul 2017 00:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X4FFbq+j1BzSmZpLHl/rBT4Q9aJxjdJnxjEPChEqpGA=; b=ZTaDsPVqcwLvMvWd3lKbItCcHQ+ir7SBy4LQdWNdbAwt8OWRw+wUDMLzSC+wkNdjzX iAFay5ENKtiEzY7odpcuX9ADGv0188PiR0zkqyqaTIIPXxhOMo2oQWbpCZVxQfcrfKlx gJG4ipi6AQvQ9TzIam8a85EtoG+xLXBwkWTPLF1jrFM5ck0LvlTU7pUdtWZiwVgBiKLA +RtJOIe7SrDBQASNMpjvmzUpp8tXyzX6v3+O4IOWBQJx3jJkQEoffILDjYFF02sRgAYH U+RdmkDDlPRIPha6hUmLxyFtyU1tvrYmkd9CDhGZU+zKaLXevY8EnT3I4XikSwSosCBo yJJg== 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=X4FFbq+j1BzSmZpLHl/rBT4Q9aJxjdJnxjEPChEqpGA=; b=JB33GuJeHX44DLlMgVjBMBG/zL3slfcArCFX+lU8AKBT4heyW21rYG7heKj8I8LSBc lVxoZOFL3jQ2hVyuwQLi5I4cwE/KirASb/BsCQ9tVWuYVDDKETuYKyahLD+pVvBsie+S vH6nnT/xNHqvj/uo7Gg/puR52EJLdWZv8m9vRcKv2GwNk0GyM6lYWwVGYp+0X0/k8zn4 lIjPwEYmN0uNSBRFsuU3pMPtPSdEF6sNYrwOTj8pUFyeHbrd9nFWG6nsSHWHXA8qHhTR wJPwUUQO4Sv9+U9yBDbAcS2YXTZ5vwyffWmXb4l5ktgpUUs00n7rHubU2NG8+7oaK0Jp h1sQ== X-Gm-Message-State: AIVw112ej2C9uIQNvmgsFp8n2iMi+69w+CP0V8yw96Kj/Bu7eOi7A3Cy 57shlCgVko/0m9Jq84xUc8PAWsg0Bc5x X-Received: by 10.84.132.39 with SMTP id 36mr1691505ple.237.1500449054117; Wed, 19 Jul 2017 00:24:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 00:24:13 -0700 (PDT) Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 00:24:13 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> From: Ted Lemon Date: Wed, 19 Jul 2017 09:24:13 +0200 Message-ID: To: Alexandre Petrescu Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c12f714dfe6680554a68413" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:24:17 -0000 --94eb2c12f714dfe6680554a68413 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What would you state as the reason for giving a host all of these? On Jul 19, 2017 9:20 AM, "Alexandre Petrescu" wrote: > Maybe a better recommendation, in no particular order, is to give a Host > DHCP-PD, many-DHCP-Address, and RA with A bit. Again, in no particular > order and potentially all at the same time. > > Le 18/07/2017 =C3=A0 23:01, Ted Lemon a =C3=A9crit : > >> If a host gets a /64, it can allocate addresses out of it. If the >> prefix allows autoconfiguration, it can allocate its own addresses >> using SLAAC. >> > > Alex > > >> On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com > >> wrote: >> >> >> >> Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit : >> >> Alexandre, it's a really important recommendation of the document >> that the host be allowed to allocate /its own/ addresses, >> >> >> I dont understand how a host can allocate its own addresses. Or do >> you mean IID? >> >> (we are very far from Host deciding an address, suggesting it to the >> network, and the network update the routes - but I think you dont >> mean that either.) >> >> Alex >> >> rather than having to rely on the correctness of the DHCP IA_NA >> implementation. So the language you are proposing would completely >> change that. >> >> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com >> >> >> wrote: >> >> I agree that in the past there may have existed a risk of cellular >> networks assigning a single IPv6 address (w/o even a plen) to one >> UE. So one wanted a recommendation against DHCPv6 single address per >> End node. >> >> However, I still think this RFC is a mis-written recommendation. >> >> It would have been much simpler to RECOMMEND to allocate multiple >> addresses per End node, as many as that End node requires, be them >> individual addresses, or addresses aggregated into prefixes, or >> multiple prefixes. >> >> But the current recommendation as it stands looks weird. >> >> Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit : >> >> I have read the draft and re-read rfc7934 and now I'm completely >> confused. First of all, I can not see where rfc7934 says that DHCPv6 >> is not recommended. >> >> >> RFC7934: >> >> In order to avoid the problems described above and preserve the >> Internet's ability to support new applications that use more than >> one IPv6 address, it is RECOMMENDED that IPv6 network deployments provid= e >> multiple IPv6 addresses from each prefix to general-purpose >> hosts. >> >> >> What makes one think that some network deployment might block the >> forming of multiple IPv6 addresses from each prefix? >> >> Or maybe the "from each prefix" is superfluous? >> >> Because I dont think there is any method that provides a prefix yet >> restricts the use to just one address in that prefix. >> >> If a Router sends an RA to many Hosts then each of these Hosts may >> configure many addresses within it. >> >> If a Router sends an RA unicast to a Host then that Host may configure >> many addresses within it. >> >> If an address is delivered by a DHCP Server, then that is an address >> without any prefix specified. >> >> If a prefix is delegated by a DHCP Server then a receiving Client >> may configure many addresses within that prefix. >> >> To support future use cases, it is NOT RECOMMENDED to impose a hard >> limit on the size of the address pool assigned to a host. >> >> >> What do you mean? Is that pool a DHCP pool? What is an example of >> someone imposing a hard limit on the size of that pool? >> >> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 >> address per prefix. >> >> >> I did not see any place where there is such a restriction. I wonder wha= t >> is an example where a Host was limited to only one IPv6 address formed o= ut >> of a prefix. >> >> 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. This can be achieved either by allowing the host to >> form new addresses autonomously (e.g., via SLAAC) or by providing the ho= st >> with a dedicated /64 prefix. >> >> >> This "either or" sounds like exclusive or. But on cellular networks >> the Host is provided a dedicated prefix _and_ forms new addresses >> autonomously. >> >> This is confusing. >> >> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide >> multiple addresses when the host connects (e.g., the approximately >> 30 addresses that can fit into a single packet) >> >> >> ? is there such a restriction in the DHCP spec? Is it that DHCP >> Ack/Advertise could carry only 30 addresses? >> >> would accommodate current clients, but it sets a limit on the number >> of addresses available to hosts when they attach and therefore >> limits the development of future applications. >> >> >> Yes, it would set a limit _if_ DHCP had such a limit. Do you think >> DHCP has a limit in the number of addresses it could assign in an Ack >> or Advertise? >> >> The maximum number of IPv6 addresses that can be provided in a single >> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, >> is approximately 30. >> >> >> Do we have a packet dump showing this? I am asking because 30 addresses >> make for 480bytes... >> >> Jen said: >> >> I had to use all my imagination and still not sure how the phrase >> 'it is RECOMMENDED that the network give the host the ability to use >> new addresses without requiring explicit requests.' can be read as >> 'DHCPv6 is not recommended'. >> >> >> Because SLAAC does not obtain addresses by using Requests. That's >> DHCP who uses Requests to obtain addresses. >> >> That RECOMMENDation is clearly written by someone who has some deep >> disapproval of DHCP. >> >> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot >> use new addresses without requesting them from a DHCPv6 server on the >> network.' does not seem to be accurate. As this >> statement appears to be the key point of your document, I believe it >> needs to be fixed before we can proceed. >> >> >> On my side, I can agree. But that is your discussion. >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops < >> https://www.ietf.org/mailman/listinfo/v6ops> < >> https://www.ietf.org/mailman/listinfo/v6ops < >> https://www.ietf.org/mailman/listinfo/v6ops>> >> >> >> >> --94eb2c12f714dfe6680554a68413 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What would you state as the reason for giving a host all = of these?

On= Jul 19, 2017 9:20 AM, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote:<= br type=3D"attribution">
Maybe a better recom= mendation, in no particular order, is to give a Host
DHCP-PD, many-DHCP-Address, and RA with A bit.=C2=A0 Again, in no particula= r
order and potentially all at the same time.

Le 18/07/2017 =C3=A0 23:01, Ted Lemon a =C3=A9crit :
If a host gets a /64, it can allocate addresses out of it.=C2=A0 =C2=A0If t= he prefix allows autoconfiguration, it can allocate its own addresses
using SLAAC.

Alex


On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu <alexandre.petrescu@gmail.co= m <mailto:alexandre.petrescu@gmail.com>>
wrote:



Le 18/07/2017 =C3=A0 21:28, Ted Lemon a =C3=A9crit :

Alexandre, it's a really important recommendation of the document
that the host be allowed to allocate /its own/ addresses,


I dont understand how a host can allocate its own addresses.=C2=A0 Or do you mean IID?

(we are very far from Host deciding an address, suggesting it to the networ= k, and the network update the routes - but I think you dont
mean that either.)

Alex

rather than having to rely on the correctness of the DHCP IA_NA implementat= ion.=C2=A0 =C2=A0So the language you are proposing would completely
change that.

On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com= <mailto:alexandre.petrescu@gmail.com> <mailto:alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>> wrote:
I agree that in the past there may have existed a risk of cellular
networks assigning a single IPv6 address (w/o even a plen) to one
UE. So one wanted a recommendation against DHCPv6 single address per
End node.

However, I still think this RFC is a mis-written recommendation.

It would have been much simpler to RECOMMEND to allocate multiple
addresses per End node, as many as that End node requires, be them
individual addresses, or addresses aggregated into prefixes, or
multiple prefixes.

But the current recommendation as it stands looks weird.

Le 18/07/2017 =C3=A0 17:23, Jen Linkova a =C3=A9crit :

I have read the draft and re-read rfc7934 and now I'm completely confus= ed. First of all, I can not see where rfc7934 says that DHCPv6
is not recommended.


RFC7934:

In order to avoid the problems described above and preserve the Internet= 9;s ability to support new applications that use more than
one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide m= ultiple IPv6 addresses from each prefix to general-purpose
hosts.


What makes one think that some network deployment might block the
forming of multiple IPv6 addresses from each prefix?

Or maybe the "from each prefix" is superfluous?

Because I dont think there is any method that provides a prefix yet
restricts the use to just one address in that prefix.

If a Router sends an RA to many Hosts then each of these Hosts may
configure many addresses within it.

If a Router sends an RA unicast to a Host then that Host may configure many= addresses within it.

If an address is delivered by a DHCP Server, then that is an address withou= t any prefix specified.

If a prefix is delegated by a DHCP Server then a receiving Client
may configure many addresses within that prefix.

To support future use cases, it is NOT RECOMMENDED to impose a hard
limit on the size of the address pool assigned to a host.


What do you mean?=C2=A0 Is that pool a DHCP pool?=C2=A0 What is an example = of
someone imposing a hard limit on the size of that pool?

Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 addres= s per prefix.


I did not see any place where there is such a restriction.=C2=A0 I wonder w= hat is an example where a Host was limited to only one IPv6 address formed = out of a prefix.

Due to the drawbacks imposed by requiring explicit requests for address spa= ce (see Section 4), it is RECOMMENDED that the network
give the host the ability to use new addresses without requiring
explicit requests.=C2=A0 This can be achieved either by allowing the host t= o form new addresses autonomously (e.g., via SLAAC) or by providing the hos= t with a dedicated /64 prefix.


This "either or" sounds like exclusive or.=C2=A0 But on cellular = networks
the Host is provided a dedicated prefix _and_ forms new addresses
autonomously.

This is confusing.

Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
multiple addresses when the host connects (e.g., the approximately
30 addresses that can fit into a single packet)


?=C2=A0 is there such a restriction in the DHCP spec?=C2=A0 Is it that DHCP=
Ack/Advertise could carry only 30 addresses?

would accommodate current clients, but it sets a limit on the number
of addresses available to hosts when they attach and therefore
limits the development of future applications.


Yes, it would set a limit _if_ DHCP had such a limit.=C2=A0 Do you think DHCP has a limit in the number of addresses it could assign in an Ack
or Advertise?

The maximum number of IPv6 addresses that can be provided in a single DHCPv= 6 packet, given a typical MTU of 1500 bytes or smaller,
is approximately 30.


Do we have a packet dump showing this?=C2=A0 I am asking because 30 address= es make for 480bytes...

Jen said:

I had to use all my imagination and still not sure how the phrase
'it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests.' can be read as '= ;DHCPv6 is not recommended'.


Because SLAAC does not obtain addresses by using Requests. That's
DHCP who uses Requests to obtain addresses.

That RECOMMENDation is clearly written by someone who has some deep
disapproval of DHCP.

Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot= use new addresses without requesting them from a DHCPv6 server on the netw= ork.' does not seem to be accurate.=C2=A0 As this
statement appears to be the key point of your document, I believe it
needs to be fixed before we can proceed.


On my side, I can agree.=C2=A0 But that is your discussion.

Alex

_______________________________________________ v6ops mailing list
v6ops@ietf.org <= mailto:v6ops@ietf.org> <mailto:v6ops= @ietf.org
<mailto:v6ops@ietf.o= rg>> https://www.ietf.org/mailman/listinf= o/v6ops <https://www.ietf.org/mailman/listinf= o/v6ops> <https://www.ietf.org/mailman/lis= tinfo/v6ops <https://www.ietf.org/mailman/lis= tinfo/v6ops>>



--94eb2c12f714dfe6680554a68413-- From nobody Wed Jul 19 00:39:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C776C13170E for ; Wed, 19 Jul 2017 00:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_Rb9E9o0-Bs for ; Wed, 19 Jul 2017 00:39:39 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 7846D12ECC3 for ; Wed, 19 Jul 2017 00:39:39 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id v127so15824902itd.0 for ; Wed, 19 Jul 2017 00:39: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=0IC7kWFZ8+g7snT6GXO/6x7GaISi9ggPZJ76j4Bi7Vk=; b=Lf7nCfPI0XOy+u/DK4WTacnmTkRF0wgse9EOw8ud0qmQVvyzFCdLyVwGJhjRBtoM3u 2bQIrDflpRgSHzz/GD+UcVs9DHemeIPM0yaIafdYmoOGa8XF0h5uPlt77sTFHuUh7EAH 3aqesn/OKCZWjVHC0gBbs6F42DYM/lvVaBZnQzDvfEkm632Rbb1WCigXHgtKSMA2PNa5 uJiUUjvV+hPTEbwDQKd1agg7XpSOS/C2Y64DiGR3bddriypxBUBZBCMyQ9yRcbp0f6zt Ds7w1esjrrGIOp9olkasNSutpP1EdeSgiMOn9hHwPPgmUELMY3e7OLtHNY1QPZtBfshr noOg== 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=0IC7kWFZ8+g7snT6GXO/6x7GaISi9ggPZJ76j4Bi7Vk=; b=Vszg1Qalp8mqXQT7n/eGACxFyOwIQBkJCVgP6lg4EGVdlx59fiVS2sgCBxCjxEcw52 s7dgZIJtMWFkSSy5oBAwviaE6K3oD0EdZRRrHSG0SlzOqxD/4Z4MugxOo6/NpIgvi06K I4qTvspoxsT85Al+5alxHut93s+YbHYL0iJLb+TrEfdRyrh9YKmTqOulwW9nJbEZeIkJ fMMLP+W/qzRuGG3ERQpk61e/8P5q2/wqk5oSDBNG0uygZrK6uwmAI7jHPf5Rb6B1uI2t WWDIPi4bi5+OaU29lnEq2d9klJSwK2Ak/ZcFq2bdxhPCjW34Elol69RwyqsKEivW8WNb x/6g== X-Gm-Message-State: AIVw1122GnqsK6ORG/VPyN2e/QWXHnwSZrTpMthFRApt40lri8EDki+4 r+frDDNkbeRCiCzECeymZGqE615ADA== X-Received: by 10.36.196.67 with SMTP id v64mr1013064itf.89.1500449978787; Wed, 19 Jul 2017 00:39:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Wed, 19 Jul 2017 00:39:17 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> From: Jen Linkova Date: Wed, 19 Jul 2017 17:39:17 +1000 Message-ID: To: Brian E Carpenter Cc: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:39:41 -0000 On Wed, Jul 19, 2017 at 9:33 AM, Brian E Carpenter wrote: > On 19/07/2017 03:23, Jen Linkova wrote: >> I have read the draft and re-read rfc7934 and now I'm completely confused. >> First of all, I can not see where rfc7934 says that DHCPv6 is not recommended. >> >> I had to use all my imagination and still not sure how the phrase 'it >> is RECOMMENDED that the network >> give the host the ability to use new addresses without requiring >> explicit requests.' can be read as 'DHCPv6 is not recommended'. > > Yes. We still appear to be having an argument based on the idea that > if something is not "RECOMMENDED" it is therefore "NOT RECOMMENDED". > At least, that's the most sense I can make of it. Exactly my impression. I suggest we ask for a tutorial on the formal logic to be organized on Sunday before IETF100 so we all will be on the same page. (Unless we make 'almost everything is prohibited and everything not prohibited is mandatory' an official rule ;)) -- SY, Jen Linkova aka Furry From nobody Wed Jul 19 01:07:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B196D131C1D for ; Wed, 19 Jul 2017 01:07:33 -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 6YFrjJDk_N5j for ; Wed, 19 Jul 2017 01:07:32 -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 BCA2813167A for ; Wed, 19 Jul 2017 01:07:31 -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 v6J87TrS005485; Wed, 19 Jul 2017 10:07:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C0CCD20657B; Wed, 19 Jul 2017 10:07:29 +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 A917320652C; Wed, 19 Jul 2017 10:07:29 +0200 (CEST) Received: from [132.166.84.51] ([132.166.84.51]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6J87TLS032418; Wed, 19 Jul 2017 10:07:29 +0200 To: Jen Linkova Cc: "v6ops@ietf.org" References: <596CF817.8040900@foobar.org> From: Alexandre Petrescu Message-ID: <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> Date: Wed, 19 Jul 2017 10:07:28 +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: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:07:34 -0000 Le 19/07/2017 à 00:47, Jen Linkova a écrit : > On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu > wrote: >> Jen said: >>> >>> I had to use all my imagination and still not sure how the phrase >>> 'it is RECOMMENDED that the network give the host the ability to >>> use new addresses without requiring explicit requests.' can be >>> read as 'DHCPv6 is not recommended'. >> >> >> Because SLAAC does not obtain addresses by using Requests. That's >> DHCP who uses Requests to obtain addresses. > > Let me give you an example. Imagine that we have apples and oranges. > Then I say: 'It is recommended that children are given apples every > day'. Does it mean "giving children oranges is not recommended'? No. > False. However the statement 'giving children oranges (and oranges > ONLY) is not recommended' is true. See the difference? ;) Give children 3 apples and oranges a day. Alex > From nobody Wed Jul 19 01:26:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED6131C1E for ; Wed, 19 Jul 2017 01:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je09B-1jkjt0 for ; Wed, 19 Jul 2017 01:26:53 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 1722A12ECF0 for ; Wed, 19 Jul 2017 01:26:53 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 5so26109894iow.0 for ; Wed, 19 Jul 2017 01:26: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=XaamiIW7chfqKOxbfDmMM18mssxrmEp6MzgGv+vt5e0=; b=gLxiEo8iykhOnVggpCNAb21+QWZpuR6kCWKNP6Gom2tt6zslwkCYnl7r3QauYuX11M o2DsB1uJE/DPqlas+hBI9AS6EGbw8fU6mzXnMhtDyhlAuWY9dQ0GwVU8UHXqtm1sUZpM tPz/KRVzjr6RW37H2QqUtMA6gYmulsSFDJDvmiEOPsAmOb7/dJikexV+sCGEUT0Fs1jv ioa6D3UUMdwLlPA2/XpIM0egBwX4gHgaFtNu4zxOG419yMwE+eoxB3KNqabdHgs0UDZR mZY1v2O38ia8g5Vxg3FEldD63X0a/Wc5w9N59fQv+omO5Ce4EgDbKOhUlPt+buSoNuB8 +FTQ== 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=XaamiIW7chfqKOxbfDmMM18mssxrmEp6MzgGv+vt5e0=; b=pL4uTX8FMxE1z9XeNchgxxJSkh3Ugh/iTp6dI6ka1YSFFljAdDClzRhwhNCnLGZMaV aL14Uw/jH8r/OduFerU2z88AkZOA/+STamLhwyf1Eu7sEqwuMWAxRL/HgmTw2epWIge5 lFoivb5yTn+2C4Tzf1x27522nNcrJeWTzXDvU75O5wuO8Wf3NPBMCD89iSXcefXV7ySv WLTL7SqrnlGpMJgauYcXka7FtY1FdoIH7uJ0d+J9OR6mU+U6Uujm8YmTvzoY1J0JvxRJ Y/O+SWDrVkXNHJhkcflKRSsGtDEKvW7GnPp+UhxCqqHF7DZObjksTPebLajg8WRaSXIQ XCJQ== X-Gm-Message-State: AIVw113ZuG8lPpWiHbEGnsW9tw62AAE3REswWGs7pBXVnYzTmsi4sdFi nOPFIQGfYHrkEoGk9EWkWtRGRx9ddg== X-Received: by 10.107.197.4 with SMTP id v4mr1264919iof.124.1500452812423; Wed, 19 Jul 2017 01:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Wed, 19 Jul 2017 01:26:31 -0700 (PDT) In-Reply-To: <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> References: <596CF817.8040900@foobar.org> <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> From: Jen Linkova Date: Wed, 19 Jul 2017 18:26:31 +1000 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:26:54 -0000 On Wed, Jul 19, 2017 at 6:07 PM, Alexandre Petrescu wrote: >> Let me give you an example. Imagine that we have apples and oranges. >> Then I say: 'It is recommended that children are given apples every >> day'. Does it mean "giving children oranges is not recommended'? No. >> False. However the statement 'giving children oranges (and oranges >> ONLY) is not recommended' is true. See the difference? ;) > > > Give children 3 apples and oranges a day. Is it a question or a statement? ;) Obviously, the statement 'It is recommended that children are given apples every day' does not prohibit giving children 3 apples and oranges (neither it makes it 'not recommended'). (Please note that we are discussing the example above and this example ONLY, no conclusions about recommended number of IPv6 addresses on hosts can be made from the statement that it's OK to give children 3 apples'. However....Let's look at this example... If the Kids Nutrition Working Group agreed that ''It is recommended that children are given apples every day', then: - 'Give children 3 apples and oranges a day' is allowed and does not conflict with the recommendation. If the WG also agreed that 'it is NOT RECOMMENDED to impose a hard limit on how many apples children are allowed to have', then: - "Give children 3 apples and oranges a day." statement violates the recommendation if '3' is a hard limit and children are not allowed 4 apples. -- SY, Jen Linkova aka Furry From nobody Wed Jul 19 02:04:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FD2131C42 for ; Wed, 19 Jul 2017 02:04:19 -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 M0nmCxLBHi78 for ; Wed, 19 Jul 2017 02:04:17 -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 3FB7F131C3C for ; Wed, 19 Jul 2017 02:04:15 -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 v6J94Dt8024388 for ; Wed, 19 Jul 2017 11:04:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3D68E2066D1 for ; Wed, 19 Jul 2017 11:04:13 +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 2AA482066CF for ; Wed, 19 Jul 2017 11:04:13 +0200 (CEST) Received: from [132.166.84.51] ([132.166.84.51]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6J94BbL019854 for ; Wed, 19 Jul 2017 11:04:11 +0200 To: v6ops@ietf.org References: <596CF817.8040900@foobar.org> <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> From: Alexandre Petrescu Message-ID: <49f25b72-8709-0424-131f-8be72c85359d@gmail.com> Date: Wed, 19 Jul 2017 11:04:06 +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: <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:04:19 -0000 Ted, about losing face: I agree the RFC does not recommend against DHCP. Le 19/07/2017 à 10:07, Alexandre Petrescu a écrit : > > > Le 19/07/2017 à 00:47, Jen Linkova a écrit : >> On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu >> wrote: >>> Jen said: >>>> >>>> I had to use all my imagination and still not sure how the phrase >>>> 'it is RECOMMENDED that the network give the host the ability to >>>> use new addresses without requiring explicit requests.' can be >>>> read as 'DHCPv6 is not recommended'. >>> >>> >>> Because SLAAC does not obtain addresses by using Requests. That's >>> DHCP who uses Requests to obtain addresses. >> >> Let me give you an example. Imagine that we have apples and oranges. >> Then I say: 'It is recommended that children are given apples every >> day'. Does it mean "giving children oranges is not recommended'? No. >> False. However the statement 'giving children oranges (and oranges >> ONLY) is not recommended' is true. See the difference? ;) > > Give children 3 apples and oranges a day. Let me try to clarify. I find it to be a better RECOMMENDation to state clearly: please use DHCP-PD, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary order, and potentially all simultaneously. This recommendation is better than being silent about which protocol should be (or not be) used. Alex From nobody Wed Jul 19 02:08:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EFF12ECC0 for ; Wed, 19 Jul 2017 02:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2DKK7d7mHZ3 for ; Wed, 19 Jul 2017 02:08:38 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D500131A87 for ; Wed, 19 Jul 2017 02:08:38 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5B3AE41C17 for ; Wed, 19 Jul 2017 11:08:36 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 10DF641C13; Wed, 19 Jul 2017 11:08:36 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 02EA334335; Wed, 19 Jul 2017 11:08:36 +0200 (CEST) Date: Wed, 19 Jul 2017 11:08:35 +0200 From: Gert Doering To: james woodyatt Cc: IPv6 Operations Message-ID: <20170719090835.GC45648@Space.Net> References: <596CF817.8040900@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:08:40 -0000 Hi, On Tue, Jul 18, 2017 at 12:44:29AM -0700, james woodyatt wrote: > That would be a gross misinterpretation of the recommendation. > The recommendation in RFC 7934 is clearly written and does not need > updating to provide more clarity about the implications for usage > of DHCPv6. The clear implication of the recommendation is *NOT* > that networks SHOULD NOT provide DHCPv6 services. The clear implication > of the recommendation is that networks SHOULD NOT require hosts to > use DHCPv6 with IA_NA/IA_TA to obtain all their addresses. And this is not a "recommendation that networks SHOULD NOT provide DHCPv6 stateful addressing services"? Which is the point, isn't it? > >>> fact that a host which uses DHCPv6 IA_NA or IA_TA cannot use new > >>> addresses without requesting them from a DHCPv6 server on the > >>> network. > > That???s not a fact. In fact. Factually speaking, a host which uses > DHCPv6 IA_NA or IA_TA absolutely MAY use new addresses without requesting > them from a DHCPv6 server on the networks. How so, if SLAAC is not active? I can see the point that Nick is making: this document implicitly recommends that networks should not use DHCPv6 IA_NA (-only), without explicit WG consensus that this should be BCP. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jul 19 02:17:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543D0131C52 for ; Wed, 19 Jul 2017 02:16: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, 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 6xzlZ4t3Bz33 for ; Wed, 19 Jul 2017 02:16:55 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FA1131C51 for ; Wed, 19 Jul 2017 02:16:55 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id 5so26658611iow.0 for ; Wed, 19 Jul 2017 02:16:55 -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=MEdBv7yo/Q7ATM7E2F8F3gHXJsUMVloQMCjke42Zk2s=; b=GIS2mJnM0w4ojQesOCc2EsTK2ns0nQNZ1rNbYQpojTOQRbJzM66gokYMB1XxfJCNNO TtzX6pHM8nKGuaQn0ikP3FgVhz8WU/6o20H1kiX2o3RoWoluFh332hnIyA2a/DLEQmhH 1Ju49Jvt3Fq++Hecssb3b7IIPN1TuIxJHj+HDqPeZGHMKzCxX6Ondx5qLK6BJDwh1xuo nK0GPyZ8PTfsqCetVG7TwWAzlpZKxGRHxhAVmRWdP5vuX2zej2k2IzD7TXh9hpgOuUOX ojJqOZSHrFDnhu+OaMFvbeTQA+3OWr/z6g+ZFKY6iYPxsfcFHa/aCsvCyd5mU0qBZW+r PhqA== 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=MEdBv7yo/Q7ATM7E2F8F3gHXJsUMVloQMCjke42Zk2s=; b=IBPVi0M3scIXAVtSS3bwMozh5YXk62NO+Bw154objrBdqqPUkHVLqgeNrspAL6UQlr oz9spP3ovIEPgrRw2LzGN8WlQ8E60u2PvuEJP41tHpY6Rqbhb08YIO4/CLk8lBkLjX6e yZZ3xiV9xlS7A4P1hoU3xbNuHvMcV0L0I4Vo7FKHKKbdPs9t7ND1mmxl6XlNY41d9KCE pSpY4D2pVovvtwsCugFjGk213uzKZgi8v0qyqu3RN2scr2hDibG4kLIMwPvyD60PH6Q6 W2JgiJqBwbd7h8QFKfkiczK6uRnp2lhzIYI4rdEcFM7wxF/uRRBYlVyPi69Q+q2H0mwr MHbw== X-Gm-Message-State: AIVw111amBUNzdOpW88hqSE99kHaM9/mdLj8eAjYgjxGrab/xDyludV0 Ua/hWYsX0/pTgl+AKwkmSBrIvVG7NHP8 X-Received: by 10.107.168.164 with SMTP id e36mr1352178ioj.40.1500455814096; Wed, 19 Jul 2017 02:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.164 with HTTP; Wed, 19 Jul 2017 02:16:33 -0700 (PDT) In-Reply-To: <20170719090835.GC45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> From: Lorenzo Colitti Date: Wed, 19 Jul 2017 11:16:33 +0200 Message-ID: To: Gert Doering Cc: james woodyatt , IPv6 Operations Content-Type: multipart/alternative; boundary="001a11426e7ccd94be0554a81721" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:16:56 -0000 --001a11426e7ccd94be0554a81721 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 11:08 AM, Gert Doering wrote: > On Tue, Jul 18, 2017 at 12:44:29AM -0700, james woodyatt wrote: > > That would be a gross misinterpretation of the recommendation. > > The recommendation in RFC 7934 is clearly written and does not need > > updating to provide more clarity about the implications for usage > > of DHCPv6. The clear implication of the recommendation is *NOT* > > that networks SHOULD NOT provide DHCPv6 services. The clear implication > > of the recommendation is that networks SHOULD NOT require hosts to > > use DHCPv6 with IA_NA/IA_TA to obtain all their addresses. > > And this is not a "recommendation that networks SHOULD NOT provide DHCPv6 > stateful addressing services"? > There is no recommendation that networks SHOULD NOT provide stateful DHCPv6 addressing services. There is a recommendation that networks SHOULD NOT provide *only* stateful DHCPv6 addressing services (where "addressing services" currently means IA_NA / IA_TA, but more in general, means any addressing service that requires an explicit request to the network in order to obtain an address). --001a11426e7ccd94be0554a81721 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 19, 2017 at 11:08 AM, Gert Doering <gert@space.net> wro= te:
On Tue, Jul 18, 2017= at 12:44:29AM -0700, james woodyatt wrote:
> That would be a gross misinterpretation of the recommendation.
> The recommendation in RFC 7934 is clearly written and does not need > updating to provide more clarity about the implications for usage
> of DHCPv6. The clear implication of the recommendation is *NOT*
> that networks SHOULD NOT provide DHCPv6 services. The clear implicatio= n
> of the recommendation is that networks SHOULD NOT require hosts to
> use DHCPv6 with IA_NA/IA_TA to obtain all their addresses.

And this is not a "recommendation that networks SHOULD NOT prov= ide DHCPv6
stateful addressing services"?

The= re is no recommendation that networks SHOULD NOT provide stateful DHCPv6 ad= dressing services.

There is a recommendation that = networks SHOULD NOT provide *only* stateful DHCPv6 addressing services (whe= re "addressing services" currently means IA_NA / IA_TA, but more = in general, means any addressing service that requires an explicit request = to the network in order to obtain an address).
--001a11426e7ccd94be0554a81721-- From nobody Wed Jul 19 02:20:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BA7131C50 for ; Wed, 19 Jul 2017 02:20:08 -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 hGHUGNlUsvYk for ; Wed, 19 Jul 2017 02:20:06 -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 5CC6E131A85 for ; Wed, 19 Jul 2017 02:20:06 -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 v6J9K4rM031884; Wed, 19 Jul 2017 11:20:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 00FD0206719; Wed, 19 Jul 2017 11:20:04 +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 E7A5C2066F4; Wed, 19 Jul 2017 11:20:03 +0200 (CEST) Received: from [132.166.84.51] ([132.166.84.51]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6J9K2Ch003399; Wed, 19 Jul 2017 11:20:03 +0200 To: Ted Lemon Cc: IPv6 Ops WG References: <596CF817.8040900@foobar.org> <3d313591-d770-75db-8ce1-973f724d067a@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 19 Jul 2017 11:20:02 +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: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:20:09 -0000 Same reasons as are stated in the current document; and more, related to scalable growth at the edges of the network. Alex Le 19/07/2017 à 09:24, Ted Lemon a écrit : > What would you state as the reason for giving a host all of these? > > On Jul 19, 2017 9:20 AM, "Alexandre Petrescu" > > wrote: > > Maybe a better recommendation, in no particular order, is to give a Host > DHCP-PD, many-DHCP-Address, and RA with A bit. Again, in no particular > order and potentially all at the same time. > > Le 18/07/2017 à 23:01, Ted Lemon a écrit : > > If a host gets a /64, it can allocate addresses out of it. If > the prefix allows autoconfiguration, it can allocate its own > addresses > using SLAAC. > > > Alex > > > On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu > > >> > wrote: > > > > Le 18/07/2017 à 21:28, Ted Lemon a écrit : > > Alexandre, it's a really important recommendation of the document > that the host be allowed to allocate /its own/ addresses, > > > I dont understand how a host can allocate its own addresses. Or do > you mean IID? > > (we are very far from Host deciding an address, suggesting it to > the network, and the network update the routes - but I think you > dont > mean that either.) > > Alex > > rather than having to rely on the correctness of the DHCP IA_NA > implementation. So the language you are proposing would completely > change that. > > On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu > > > > > >>> wrote: > > I agree that in the past there may have existed a risk of cellular > networks assigning a single IPv6 address (w/o even a plen) to one > UE. So one wanted a recommendation against DHCPv6 single address per > End node. > > However, I still think this RFC is a mis-written recommendation. > > It would have been much simpler to RECOMMEND to allocate multiple > addresses per End node, as many as that End node requires, be them > individual addresses, or addresses aggregated into prefixes, or > multiple prefixes. > > But the current recommendation as it stands looks weird. > > Le 18/07/2017 à 17:23, Jen Linkova a écrit : > > I have read the draft and re-read rfc7934 and now I'm completely > confused. First of all, I can not see where rfc7934 says that DHCPv6 > is not recommended. > > > RFC7934: > > In order to avoid the problems described above and preserve the > Internet's ability to support new applications that use more than > one IPv6 address, it is RECOMMENDED that IPv6 network > deployments provide multiple IPv6 addresses from each prefix to > general-purpose > hosts. > > > What makes one think that some network deployment might block the > forming of multiple IPv6 addresses from each prefix? > > Or maybe the "from each prefix" is superfluous? > > Because I dont think there is any method that provides a prefix yet > restricts the use to just one address in that prefix. > > If a Router sends an RA to many Hosts then each of these Hosts may > configure many addresses within it. > > If a Router sends an RA unicast to a Host then that Host may > configure many addresses within it. > > If an address is delivered by a DHCP Server, then that is an > address without any prefix specified. > > If a prefix is delegated by a DHCP Server then a receiving Client > may configure many addresses within that prefix. > > To support future use cases, it is NOT RECOMMENDED to impose a hard > limit on the size of the address pool assigned to a host. > > > What do you mean? Is that pool a DHCP pool? What is an example of > someone imposing a hard limit on the size of that pool? > > Particularly, it is NOT RECOMMENDED to limit a host to only one > IPv6 address per prefix. > > > I did not see any place where there is such a restriction. I > wonder what is an example where a Host was limited to only one > IPv6 address formed out of a prefix. > > 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. 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. > > > This "either or" sounds like exclusive or. But on cellular networks > the Host is provided a dedicated prefix _and_ forms new addresses > autonomously. > > This is confusing. > > Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide > multiple addresses when the host connects (e.g., the approximately > 30 addresses that can fit into a single packet) > > > ? is there such a restriction in the DHCP spec? Is it that DHCP > Ack/Advertise could carry only 30 addresses? > > would accommodate current clients, but it sets a limit on the number > of addresses available to hosts when they attach and therefore > limits the development of future applications. > > > Yes, it would set a limit _if_ DHCP had such a limit. Do you think > DHCP has a limit in the number of addresses it could assign in > an Ack > or Advertise? > > The maximum number of IPv6 addresses that can be provided in a > single DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, > is approximately 30. > > > Do we have a packet dump showing this? I am asking because 30 > addresses make for 480bytes... > > Jen said: > > I had to use all my imagination and still not sure how the phrase > 'it is RECOMMENDED that the network give the host the ability to use > new addresses without requiring explicit requests.' can be read > as 'DHCPv6 is not recommended'. > > > Because SLAAC does not obtain addresses by using Requests. That's > DHCP who uses Requests to obtain addresses. > > That RECOMMENDation is clearly written by someone who has some deep > disapproval of DHCP. > > Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA > cannot use new addresses without requesting them from a DHCPv6 > server on the network.' does not seem to be accurate. As this > statement appears to be the key point of your document, I believe it > needs to be fixed before we can proceed. > > > On my side, I can agree. But that is your discussion. > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/v6ops > > > > > >> > > > From nobody Wed Jul 19 02:36:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C28131C60 for ; Wed, 19 Jul 2017 02:36:26 -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 NEehEqXE3sSk for ; Wed, 19 Jul 2017 02:36:24 -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 40981131C45 for ; Wed, 19 Jul 2017 02:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500456982; x=1501061782; 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=HqHZYAlYkKv9zMyuKYpRWurR5 V7JqriRDhAvYZEvfF8=; b=JgjEL/ji47oJT3Zo+7brzsGfeUOrbprRq75L2iWKB 54YHDzASo+8+xaBz/5+Wryt35kGmHdKdGjFlK8JNMt8RrTqMpdZvO/D55BdVsrA8 WsZ+a5mvtbdebn+nRHntr1Mj36VcuQG5TPXDtTH9XRU71AQewkDJsDt6ooDiplGv GI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=PGRSMpjJBTQdXBkE1IXLDLLcByr3mIsBBmavOeqbVRbAJORJ3OS46P6QIqCQ hTxSI4jD9lNrZGIQM3UZk3llpSxtKWS3HXM4BdFPKFBNteOJDMJLJyfdb VWnHqAO9TGyofTqtiOqpVbw95FFiQvYU9O+oiMeIrMcUvl8z6POF/8=; X-MDAV-Processed: mail.consulintel.es, Wed, 19 Jul 2017 11:36:22 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 19 Jul 2017 11:36:21 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005480564.msg for ; Wed, 19 Jul 2017 11:36:20 +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:170719:md50005480564::2UB3AngRXPhVVDhf:00006OIV X-MDRemoteIP: 31.133.159.135 X-Return-Path: prvs=13730b9fa8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Wed, 19 Jul 2017 11:36:16 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> Thread-Topic: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt References: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.com> In-Reply-To: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.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: Subject: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:36:26 -0000 Hi all, As announced in our session yesterday, here is the document =E2=80=A6. https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only I will love to have inputs today, so I can even post a new version and mayb= e we can have tomorrow 10 minutes in the agenda to present it if the chairs= agree! Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.tx= t =20 A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-ietf-v6ops-ipv6-only Revision: 00 Title: IPv6-only Terminology Definition Document date: 2017-07-18 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-palet-ietf-v= 6ops-ipv6-only-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops= -ipv6-only/ Htmlized: https://tools.ietf.org/html/draft-palet-ietf-v6ops-ipv6= -only-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-ietf-= v6ops-ipv6-only-00 =20 =20 Abstract: This document clarify the terminology regarding the usage of expressions such as "IPv6-only", ir order to avoid confusions when using them in IETF and other documents, in reference to what is the actual functionalities being used (not the actual protocol support). =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =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 Jul 19 02:37:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948BC12EAF7 for ; Wed, 19 Jul 2017 02:37:25 -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, 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=fugue-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 YxUhGWdChNuS for ; Wed, 19 Jul 2017 02:37:23 -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 8FC80131A86 for ; Wed, 19 Jul 2017 02:37:23 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id v190so28219963pgv.2 for ; Wed, 19 Jul 2017 02:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TOE/Wdvc17tQgj0Qsiz+M595PS7jIYB1gcRdYFBhI7Q=; b=MXdF2muu5qP/EZTiX07W3y4BnSRM3z4wEimQYFxgkdisLLCuGYnQZ64bDzKQ4rEQ/g LN44RXmnU5S2bNq56iHkveQrBwM4hvHr9tgGsjLuzCDikq6yPVkIx62Bw421bkqphO6t Pemc3k6fP/g2tlCrKm3DNTLwoi/BrbKleoHotsyfqkdMMdzW3uhpxta/OC7cRyIKzhAU lgySjjiYDKMrXqq9RF39av0JgkOpiFHkZ7Z71E4B8srn1JW46pkLIqWjVsSzSrZdHqFm Ei0/Dchf6l0dBW4UaGHsQaOEObfoZuuo0th0R7/SofFhqJ98QJKJZLgBp5iPMMpiyMmB lSWw== 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=TOE/Wdvc17tQgj0Qsiz+M595PS7jIYB1gcRdYFBhI7Q=; b=tw7aVs7ConheQKDsaWPso4hlBYilOZ75ET9tU3AcTTQdakgbkCzY3rR08gAabVzwBn B4lL9ZZN91edfuOgBhqRcEkLQEntTPWuDdWmNr/mOsi7bEl0hjTB2PYCtBXC+BX96roN Q8pNILvw4OPuMkEWOiQUzjnc4P0iKKwjFkbH+5YOjjXiU7vD7dYWhJ9i3cs0dn8xgHvW pAODfP/yE1mUe5Cee0bbk7hSJZya6+o2e5SCaULysAnBEek69wkEqcQVM6jCMTysh/K/ wu/Iz2Hjwj5wo7UiCoRn9eegs1IgbIph8wr1K8Qqo/eDMlFKE8yWgtEMZvv1KMc5K6yJ 0aaA== X-Gm-Message-State: AIVw112ItaXKzA2xYdRWrSAD4HTz+p2QhH72+vLC+Bbuq3/rVER3ehT2 ConCnxnZKopo4C9jxJGgYVTr9Ogmf0rh X-Received: by 10.98.67.147 with SMTP id l19mr2086419pfi.198.1500457043150; Wed, 19 Jul 2017 02:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Wed, 19 Jul 2017 02:36:42 -0700 (PDT) In-Reply-To: <49f25b72-8709-0424-131f-8be72c85359d@gmail.com> References: <596CF817.8040900@foobar.org> <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> <49f25b72-8709-0424-131f-8be72c85359d@gmail.com> From: Ted Lemon Date: Wed, 19 Jul 2017 11:36:42 +0200 Message-ID: To: Alexandre Petrescu Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c0c0f440edeef0554a8619e" Archived-At: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:37:26 -0000 --94eb2c0c0f440edeef0554a8619e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me restate my question then. Right now the document explicitly does not recommend DHCP IA_NA. It doesn't recommend it because it doesn't provide the privacy characteristics that the other options provide. Your suggestion essentially says that the document should recommend it. So you must have some reason why it should make this recommendation. Can you state that reason? On Wed, Jul 19, 2017 at 11:04 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Ted, about losing face: I agree the RFC does not recommend against DHCP. > > Le 19/07/2017 =C3=A0 10:07, Alexandre Petrescu a =C3=A9crit : > >> >> >> Le 19/07/2017 =C3=A0 00:47, Jen Linkova a =C3=A9crit : >> >>> On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu < >>> alexandre.petrescu@gmail.com> wrote: >>> >>>> Jen said: >>>> >>>>> >>>>> I had to use all my imagination and still not sure how the phrase >>>>> 'it is RECOMMENDED that the network give the host the ability to >>>>> use new addresses without requiring explicit requests.' can be >>>>> read as 'DHCPv6 is not recommended'. >>>>> >>>> >>>> >>>> Because SLAAC does not obtain addresses by using Requests. That's >>>> DHCP who uses Requests to obtain addresses. >>>> >>> >>> Let me give you an example. Imagine that we have apples and oranges. >>> Then I say: 'It is recommended that children are given apples every >>> day'. Does it mean "giving children oranges is not recommended'? No. >>> False. However the statement 'giving children oranges (and oranges >>> ONLY) is not recommended' is true. See the difference? ;) >>> >> >> Give children 3 apples and oranges a day. >> > > Let me try to clarify. > > I find it to be a better RECOMMENDation to state clearly: please use > DHCP-PD, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary order, and > potentially all simultaneously. > > This recommendation is better than being silent about which protocol > should be (or not be) used. > > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0c0f440edeef0554a8619e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let me restate my question then.

Right = now the document explicitly does not recommend DHCP IA_NA. =C2=A0 It doesn&= #39;t recommend it because it doesn't provide the privacy characteristi= cs that the other options provide. =C2=A0 Your suggestion essentially says = that the document should recommend it. =C2=A0 So you must have some reason = why it should make this recommendation. =C2=A0 Can you state that reason?

On Wed,= Jul 19, 2017 at 11:04 AM, Alexandre Petrescu <alexandre.petres= cu@gmail.com> wrote:
Ted, a= bout losing face: I agree the RFC does not recommend against DHCP.

Le 19/07/2017 =C3=A0 10:07, Alexandre Petrescu a =C3=A9crit :


Le 19/07/2017 =C3=A0 00:47, Jen Linkova a =C3=A9crit :
On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:
Jen said:

I had to use all my imagination and still not sure how the phrase
'it is RECOMMENDED that the network give the host the ability to
use new addresses without requiring explicit requests.' can be
read as 'DHCPv6 is not recommended'.


Because SLAAC does not obtain addresses by using Requests.=C2=A0 That's=
DHCP who uses Requests to obtain addresses.

Let me give you an example. Imagine that we have apples and oranges.
Then I say: 'It is recommended that children are given apples every
day'. Does it mean "giving children oranges is not recommended'= ;? No.
False. However the statement 'giving children oranges (and oranges
ONLY) is not recommended' is true. See the difference? ;)

Give children 3 apples and oranges a day.

 Let me try to clarify.

I find it to be a better RECOMMENDation to state clearly: please use DHCP-P= D, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary order, and potenti= ally all simultaneously.

This recommendation is better than being silent about which protocol should= be (or not be) used.


Alex

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

--94eb2c0c0f440edeef0554a8619e-- From nobody Wed Jul 19 05:47:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3901288B8 for ; Wed, 19 Jul 2017 05:47:24 -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=neo-co-tz.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 06N4v3goEYYL for ; Wed, 19 Jul 2017 05:47:21 -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 9F311131CEE for ; Wed, 19 Jul 2017 05:47:20 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id g127so14998184wmd.0 for ; Wed, 19 Jul 2017 05:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4AY/VDmVe3kNNJ4dMOtpG/ysOdvEHZVvscp4BX5E7wc=; b=RAXBfbM3b+IxDFOMKAiqKs89YedKGO6+CCL2//56TLF3jgYQXaCjfKIEAHyVtfmrMB LeD1zAVhT6TEjx4zjHdQX6EwtQgMfgQDU50F8VgCGiKU0NFj40/y0r0jWq6iUepjnwE/ crXzr/MVFQHwQo0+jyNyzEkGx5E/+kjSeDY4Big6SU3alYXGc1hbTrNATm4Z99nDW4Kp IftcCPSnOcqS2MYXcP03uh8xBIPQXTAEgfAtsU24pGwybG82G+bI5DpF77pq9Iv4bQ9j xIT2ZPKmwiiV+r/crvmFChiJNKHia5vJJVB2VnU4CkcA3KCJan/5NiWT+3f4D5TevOGn ukbQ== 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=4AY/VDmVe3kNNJ4dMOtpG/ysOdvEHZVvscp4BX5E7wc=; b=Q2JrBiZVORHK9DsJ2TyoF5WPpLx9d0Mc82GMoK0+QeP3hJbGlMK/Bwc0ImmvCWvfaK fHNCjRJZsBK3q1iE6IEc8+DccWI5vKXFAgSzcHSJOAWSSnSOmm4PVSayrdhTl9QvXuW5 G0W7ZgCjcfmX6VSX1kT/YCbejCTFberD0jHnJfqbKA0tyPzHvT9tOfqmkGsbw93zSGAL NJMGUxLTI6yLXqieV5qmRWsrJ6zPY/nvZ5yKLWoh42/HPCSq68mszArU2qD+JSwygm4s EiTfHdXWFLR1ULER2s+43bELGU+zPO2vkf9zI8xBAHeerl/bqiRt6w+KKHOX22iBCqwq MdqA== X-Gm-Message-State: AIVw111cpesucVSe9xfiwhy39exJeKAIDN6rLmySEilbD6XTnxG6N2N2 HQmVqy7ajq6FJUrc/el8uVcQELKLBT1kvzj7LA== X-Received: by 10.28.154.19 with SMTP id c19mr5579186wme.87.1500468438510; Wed, 19 Jul 2017 05:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.206.4 with HTTP; Wed, 19 Jul 2017 05:47:17 -0700 (PDT) X-Originating-IP: [105.28.32.9] In-Reply-To: <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> References: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.com> <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> From: Noah Date: Wed, 19 Jul 2017 15:47:17 +0300 Message-ID: To: Jordi Palet Martinez Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="001a114b2a144661e10554ab087a" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:47:24 -0000 --001a114b2a144661e10554ab087a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jordi Some corrections. 1. Introduction Note that *al* the references Update with =3D Note that *all* the references 2. Context It is not feasible for most of the operators *de* tell their customers "I can provide you IPv6 service, but you will not be able to access all Internet because some of the contents or applications still don't support it, so you will miss every content that it is IPv4-only". Can you update the the above with the below; "Its not feasible for internet service providers and operators to inform their customers that they can offer them IPv6 connectivity and transport to the internet but unfortunately, the customers would not be able to access some of the contents and applications on the Internet because not all content and applications have support for IPv6 and as such, the customers will fail to access content and applications that are IPv4-only." Noah On Wed, Jul 19, 2017 at 12:36 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi all, > > As announced in our session yesterday, here is the document =E2=80=A6. > > https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only > > I will love to have inputs today, so I can even post a new version and > maybe we can have tomorrow 10 minutes in the agenda to present it if the > chairs agree! > > Regards, > Jordi > > > -----Mensaje original----- > De: > Responder a: > Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34 > Para: Jordi Palet , Jordi Palet Martinez < > jordi.palet@consulintel.es> > Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6-on > ly-00.txt > > > A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-00.txt > has been successfully submitted by Jordi Palet Martinez and posted to > the > IETF repository. > > Name: draft-palet-ietf-v6ops-ipv6-only > Revision: 00 > Title: IPv6-only Terminology Definition > Document date: 2017-07-18 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet- > drafts/draft-palet-ietf-v6ops-ipv6-only-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-palet-ietf-v6ops-ipv6-only/ > Htmlized: https://tools.ietf.org/html/d > raft-palet-ietf-v6ops-ipv6-only-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-palet-ietf-v6ops-ipv6-only-00 > > > Abstract: > This document clarify the terminology regarding the usage of > expressions such as "IPv6-only", ir order to avoid confusions when > using them in IETF and other documents, in reference to what is th= e > actual functionalities being used (not the actual protocol support= ). > > > > > 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 > > > > > > > ********************************************** > 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 > confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *./noah* --001a114b2a144661e10554ab087a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jordi

Some corrections.
1.  Introduction
Note that al the references
Update = with =3D Note that all the references

<= br>
2.  Context
 It is not feasible for most of the =
operators de tell their
   customers "I can provide you IPv6 service, but you will not be able
   to access all Internet because some of the contents or applications
   still don't support it, so you will miss every content that it is
   IPv4-only".

Can you update the the a= bove with the below;

"Its not feasible for in= ternet service providers and operators to inform their customers that they = can offer them IPv6 connectivity and transport to the internet but unfortun= ately, the customers would not be able to access some of the contents and a= pplications on the Internet because not all content and applications have s= upport for IPv6 and as such, the customers will fail to access content and = applications that are IPv4-only."

Noah
<= div>


On Wed, Jul 19, 2017 at 12:36 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
Hi all,

As announced in our session yesterday, here is the document =E2=80=A6.

https://datatracker.ietf.org/d= oc/draft-palet-ietf-v6ops-ipv6-only

I will love to have inputs today, so I can even post a new version and mayb= e we can have tomorrow 10 minutes in the agenda to present it if the chairs= agree!

Regards,
Jordi


-----Mensaje original-----
De: <inter= net-drafts@ietf.org>
Responder a: <internet-drafts@ietf.org>
Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34
Para: Jordi Palet <jordi.palet@consulintel.es>, Jordi Palet Martinez <jordi.palet@c= onsulintel.es>
Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-= 00.txt


=C2=A0 =C2=A0 A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-0= 0.txt
=C2=A0 =C2=A0 has been successfully submitted by Jordi Palet Martinez and p= osted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-palet-ietf-v6ops-ipv6-only
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A000
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6-o= nly Terminology Definition
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-07-18
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-palet-ietf-v6ops-ipv6-only-00.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-palet-ietf= -v6ops-ipv6-only/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-palet-ietf-v6ops-ipv6-o= nly-00
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-pal= et-ietf-v6ops-ipv6-only-00


=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document clarify the terminology regarding = the usage of
=C2=A0 =C2=A0 =C2=A0 =C2=A0expressions such as "IPv6-only", ir or= der to avoid confusions when
=C2=A0 =C2=A0 =C2=A0 =C2=A0using them in IETF and other documents, in refer= ence to what is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0actual functionalities being used (not the actua= l protocol support).




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

=C2=A0 =C2=A0 The IETF Secretariat






**********************************************
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.



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



--
.= /noah
--001a114b2a144661e10554ab087a-- From nobody Wed Jul 19 05:59:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9904D12EBF7 for ; Wed, 19 Jul 2017 05:59:26 -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 ijnNDaymwQT7 for ; Wed, 19 Jul 2017 05:59:24 -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 EA362131B2F for ; Wed, 19 Jul 2017 05:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500469161; x=1501073961; 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=mK/IX+T8xD3aCjE/lDe/mwN08 AjPSpE7uiM8HKh3LLo=; b=tStxo9o7XYg/2hOHKHD/T2Hzz2kSUesaAHL7Rj9da FeMsZYnLqSG1w5nW9yA6s97pgKWyKvMrUdrcZ6UCNiFzKLfutJV4TF03UAPFJNDL 8CCDwoNCRhVJINjmlnFIcqS+LNNgKFfWLuX+45k6865rYBxGt+PMjoBnV3aJSXMP 9M= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=YYecHfepBRqnXkhdnqgw3OAXdAqKzI+KtkMs94uKXebBG1lHy8/XFOB3wQfR trL18ZMz/98reYpFvTxIv9tV0mptoAopt7SxVqKFxfImO2L8WlSxMTFuV lFOrbJI8p+aogz4L1jKo3fqWTZ312vOMHmChtHRwJYxAax/X66qiwk=; X-MDAV-Processed: mail.consulintel.es, Wed, 19 Jul 2017 14:59:21 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 19 Jul 2017 14:59:19 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005480759.msg for ; Wed, 19 Jul 2017 14:59:18 +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:170719:md50005480759::9EOhFd24eEhPmSYA:0000766B X-Return-Path: prvs=13730b9fa8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Wed, 19 Jul 2017 14:58:59 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt References: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.com> <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> 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: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:59:27 -0000 Hi Noah, Thanks a lot for your inputs! This is what happens when you write a draft, which even being =E2=80=9Csimp= le=E2=80=9D, you do it to quickly =E2=80=A6 I=E2=80=99ve already an internal -01 version and corrected your first point= . I=E2=80=99m not sure about your 2nd suggestions, I think is I prefer my fir= st text, but I=E2=80=99ve modified it a bit: It is not feasible for most of the operators to tell their customers "I can= provide you IPv6 service, but you will not be able to access all Internet = contents and apps, because some of them still don't support IPv6, so you w= ill miss every content that it is IPv4-only" Saludos, Jordi =20 -----Mensaje original----- De: Noah Responder a: Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 14:47 Para: Jordi Palet Martinez CC: IPv6 Operations Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops= -ipv6-only-00.txt Hi Jordi Some corrections. =20 1. Introduction Note that al the references Update with =3D Note that all the references =20 =20 =20 2. Context It is not feasible for most of the operators de tell their customers "I can provide you IPv6 service, but you will not be able to access all Internet because some of the contents or applications still don't support it, so you will miss every content that it is IPv4-only". =20 Can you update the the above with the below; =20 "Its not feasible for internet service providers and operators to infor= m their customers that they can offer them IPv6 connectivity and transport = to the internet but unfortunately, the customers would not be able to acces= s some of the contents and applications on the Internet because not all con= tent and applications have support for IPv6 and as such, the customers will= fail to access content and applications that are IPv4-only." =20 Noah =20 =20 =20 On Wed, Jul 19, 2017 at 12:36 PM, JORDI PALET MARTINEZ wrote: =20 Hi all, =20 As announced in our session yesterday, here is the document =E2=80=A6. =20 https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only =20 I will love to have inputs today, so I can even post a new version and = maybe we can have tomorrow 10 minutes in the agenda to present it if the ch= airs agree! =20 Regards, Jordi =20 =20 -----Mensaje original----- De: Responder a: Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-0= 0.txt =20 =20 A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-00.txt has been successfully submitted by Jordi Palet Martinez and posted = to the IETF repository. =20 Name: draft-palet-ietf-v6ops-ipv6-only Revision: 00 Title: IPv6-only Terminology Definition Document date: 2017-07-18 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-palet-ie= tf-v6ops-ipv6-only-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-ietf-v= 6ops-ipv6-only/ Htmlized: https://tools.ietf.org/html/draft-palet-ietf-v6ops-= ipv6-only-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-i= etf-v6ops-ipv6-only-00 =20 =20 Abstract: This document clarify the terminology regarding the usage of expressions such as "IPv6-only", ir order to avoid confusions wh= en using them in IETF and other documents, in reference to what is = the actual functionalities being used (not the actual protocol suppo= rt). =20 =20 =20 =20 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.org= . =20 The IETF Secretariat =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 --=20 ./noah =20 =20 =20 =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 Jul 19 06:14:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E55131B38 for ; Wed, 19 Jul 2017 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neo-co-tz.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 YwL3lIhikFeA for ; Wed, 19 Jul 2017 06:14:12 -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 7811F131748 for ; Wed, 19 Jul 2017 06:14:12 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id f21so1934725wrf.5 for ; Wed, 19 Jul 2017 06:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vEuU+oO9FkMZCANB7ZVuWVigNqlA1AqPLYSMFcgmaeo=; b=RznJK+OqQd7V+lq7lk7JObQf4I/3/MMmFPFyl6/7VbHK6uL3Narh9eLBt/OsENeQhy xqsySmpSwhGZbm7aXNuDe/oPy6xNDeABoHKM6zbMj4zaIvCgC8iu2mV8vjeFVtzIwKGA TZJi87k0SnmCdhs/8mF84CatzGYqoMZnkvc8lYT26AeN2qXgEapzeuOqs+e2vXOwzyw6 47MTeq4MRF1dIzk9ZO+bkMwEAhJOY+rwjHf7sjnr2o2lVJDueARrkmCDoFXdJQrxofbu 3CkD3OmubvAai5MYLT7uofwMQeSscFpDHyeck2WrhiI6jJzYhTWW145h8BsiR+n2zPYh QGhg== 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=vEuU+oO9FkMZCANB7ZVuWVigNqlA1AqPLYSMFcgmaeo=; b=jNQ4nvtXm181pHUuN0ZXE8hFJuWigO1xUFucpultz8BBz34zg30sVCbQrV3I+UbClj 0gIw7shkXDCZDxHCainL0NDwThMFLdWdOytY9HVno8F8drbsmZWhntgARqTAW+EVv1Rm C+xv05WJnAs2PtMih0nAazEP7svNvQVXhJUCORHY+wmO8ilQTVO3QfbxqlovRl34VYsY FjYQeHZp1opVWP2B/y93sSMV1g7AtF1wnDyTwQl33PlGohd+oQu4BwG7UwK3Ef2cUVmX 6HNV5Vm3EUPFQdA5oGepDcZxdNhMwEWKMyqCBDPUVYo4S5Y0yf/xTRJvecVviSNHKTec g1MQ== X-Gm-Message-State: AIVw113RDhHL6LZblrw8I1DEb5ZUdzUgnMKYY+yPsXONK7Qirvda5f1m TjQziOr2WBanJgOa8jQVMNbW0d2+0kyg X-Received: by 10.223.160.6 with SMTP id k6mr438984wrk.220.1500470051020; Wed, 19 Jul 2017 06:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.206.4 with HTTP; Wed, 19 Jul 2017 06:14:10 -0700 (PDT) X-Originating-IP: [105.28.32.9] In-Reply-To: References: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.com> <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> From: Noah Date: Wed, 19 Jul 2017 16:14:10 +0300 Message-ID: To: Michael Gooden Cc: Jordi Palet Martinez , IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c0677de637e540554ab68c9" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:14:14 -0000 --94eb2c0677de637e540554ab68c9 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 4:10 PM, Michael Gooden wrote: > Dear Jordi/Noah, > > Here is an alternate suggestion for that paragraph: > > * It is not feasible for most of the operators to tell their customers "I > can provide you with an IPv6 service, however you will not be able to > access any content that is IPv4-only from providers who do not or cannot > support IPv6"* > +1, Michael, this is more clearer. Jordi can use this hopefully. Cheers, Noah --94eb2c0677de637e540554ab68c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 19, 2017 at 4:10 PM, Michael Gooden <<= a href=3D"mailto:me@michaelgooden.net" target=3D"_blank">me@michaelgooden.n= et> wrote:
Dear Jordi/Noah,

Here is an alternate sugges= tion for that paragraph:

It is not feasible for most of the operators to tell their customers "= I=20 can provide you with an IPv6 service, however you will not be able to acces= s any content that is IPv4-only from providers who do not or cannot support= IPv6"

+1, Michael, th= is is more clearer.=C2=A0

Jordi can use this hopef= ully.=C2=A0

Cheers,
Noah
--94eb2c0677de637e540554ab68c9-- From nobody Wed Jul 19 06:26:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01801131C62 for ; Wed, 19 Jul 2017 06:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neo-co-tz.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 Pbm7ukL4SSej for ; Wed, 19 Jul 2017 06:26:39 -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 4E0B6131B10 for ; Wed, 19 Jul 2017 06:26:39 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id y43so58554848wrd.3 for ; Wed, 19 Jul 2017 06:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sTZdqKoEH9Hf1pAelYIjs/Jg9AXXPbAecP39CYQ47yQ=; b=oMydCsDP/Lz4iAoL4FMklsRfniBJKEHOXUt7WhBKm56e6ErcPyoMzBqT2ghFS0nyIA 7ID11VeGIadhOq+1zxHDxiolr8s8FdRCfwYv2xDypZGg/2ygJeOPsiGWV6A9w8YkHCbN 0ifPNp9zKWkhuquG8Nm2h0k+nVfjfbKdGzcZYJzSiZz+eyf6KfD3gfOYZd+FO0Dg9az7 k/9RrZpBc56hKPtFypgY0a2qgj8drzPKlhJIapHzfBU8DrSTe8Fqka91xx4d9jYQ4b1v hxU+BbLD0E6/lXsPIK2V5fpHWCv8PnGWFvzjU3SS5tryrd5sSJKJLppvDuA9AUC7xcnm ebJA== 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=sTZdqKoEH9Hf1pAelYIjs/Jg9AXXPbAecP39CYQ47yQ=; b=s2J5KgbnhX3DVzMOkndg2LdoIepB23ooqw3cBqw7wnsxV/IdS+PSt/IsxS50c5gYQL mnwPcOpkV9ZOwuxyqfKqmNQe9J/oMobz0RwNr4SNrSRHVZx1l9+uo0oaSlRF1EKUouey epyxAakfxSKXtoS4qOUHL6kl5nFhQ/S1BJtsDsS6GENHC3mMQM9BxY7JMl21hrns0k+G TEUHrh94yQCSWBbHOO1jyAfDEP+lMFe+STWfe3zbZ0GZ1eQs2ZxEePC72Uz0MvyHy0oF qSrHWTi73gMl4a8Tx5SqXlPZlQjrbK21rbIwgLAElURfcczd9WsT3d3IMwHplm0KGuHF oRog== X-Gm-Message-State: AIVw110yxtkzUVznNOePjT6gNTBU8wror5MKjSAieoK0txpGMbWx7tqy Pj0Ufwj227xg1C9PHAPbpySSovGZEKxB X-Received: by 10.28.154.19 with SMTP id c19mr34320wme.87.1500470797787; Wed, 19 Jul 2017 06:26:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.206.4 with HTTP; Wed, 19 Jul 2017 06:26:37 -0700 (PDT) X-Originating-IP: [105.28.32.9] In-Reply-To: <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> References: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.com> <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> From: Noah Date: Wed, 19 Jul 2017 16:26:37 +0300 Message-ID: To: Jordi Palet Martinez Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="001a114b2a14e60c860554ab9438" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:26:42 -0000 --001a114b2a14e60c860554ab9438 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jordi However, despite the IETF and vendor efforts to *get rid-off* IPv4 as soon as possible in every network or part of it, there are many devices, in both corporate and end-user networks (smartTV, IP cameras, security devices, etc.), which *are* IPv4-only and it is not feasible (vendors may even be out of the market, or devices *have no easy way to be* updated with new firmware, or *de* vendor have more interest in selling *a* new model, etc.), the "end-networks" in general, need to *keep* supporting IPv4. However, despite the IETF and vendor efforts to *reduce reliance* on legacy IPv4 as soon as possible in every network or part of it, there are many devices, in both corporate and end-user networks i.e. (smartTV, IP cameras, security devices, etc.), which *support* IPv4-only and it is not feasible ( *since* vendors may even be out of the market, or *IPv4-only *devices *can not be easily* updated with new firmware, or* the* vendor have more interest in selling *the* new models, etc.), and the "end-networks" in general, need to contineu supporting IPv4. The rest of the document is ok with me. Cheers, Noah On Wed, Jul 19, 2017 at 12:36 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi all, > > As announced in our session yesterday, here is the document =E2=80=A6. > > https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only > > I will love to have inputs today, so I can even post a new version and > maybe we can have tomorrow 10 minutes in the agenda to present it if the > chairs agree! > > Regards, > Jordi > > > -----Mensaje original----- > De: > Responder a: > Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34 > Para: Jordi Palet , Jordi Palet Martinez < > jordi.palet@consulintel.es> > Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6- > only-00.txt > > > A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-00.txt > has been successfully submitted by Jordi Palet Martinez and posted to > the > IETF repository. > > Name: draft-palet-ietf-v6ops-ipv6-only > Revision: 00 > Title: IPv6-only Terminology Definition > Document date: 2017-07-18 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet- > drafts/draft-palet-ietf-v6ops-ipv6-only-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-palet-ietf-v6ops-ipv6-only/ > Htmlized: https://tools.ietf.org/html/ > draft-palet-ietf-v6ops-ipv6-only-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-palet-ietf-v6ops-ipv6-only-00 > > > Abstract: > This document clarify the terminology regarding the usage of > expressions such as "IPv6-only", ir order to avoid confusions when > using them in IETF and other documents, in reference to what is th= e > actual functionalities being used (not the actual protocol support= ). > > > > > 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 > > > > > > > ********************************************** > 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 > confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *./noah* --001a114b2a14e60c860554ab9438 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jordi

How=
ever, despite the IETF and vendor efforts to get rid-off IPv4 as
   soon as possible in every network or part of it, there are many
   devices, in both corporate and end-user networks (smartTV, IP
   cameras, security devices, etc.), which are IPv4-only and it is n=
ot
   feasible (vendors may even be out of the market, or devices have no
   easy way to be updated with new firmware, or de vendor have m=
ore
   interest in selling a new model, etc.), the "end-networks&qu=
ot; in
   general, need to keep supporting IPv4.

=

However, despite the IETF and vendor efforts to redu= ce reliance on legacy IPv4 as soon as possible in every network or part= of it, there are many devices, in both corporate and end-user networks i.e= . (smartTV, IP cameras, security devices, etc.), which support IPv4-= only and it is not feasible (since vendors may even be out of the ma= rket, or IPv4-only=C2=A0devices can not be easily updated wit= h new firmware, or the vendor have more interest in selling the new models, etc.), and the "end-networks" in general, need to = contineu supporting IPv4.


The r= est of the document is ok with me.

Cheers,

Noah


On Wed, Jul 19, 2017 at 12:36 PM, JORDI PAL= ET MARTINEZ <jordi.palet@consulintel.es> wrote:
=
Hi all,

As announced in our session yesterday, here is the document =E2=80=A6.

https://datatracker.ietf.org/d= oc/draft-palet-ietf-v6ops-ipv6-only

I will love to have inputs today, so I can even post a new version and mayb= e we can have tomorrow 10 minutes in the agenda to present it if the chairs= agree!

Regards,
Jordi


-----Mensaje original-----
De: <internet-drafts@ietf.or= g>
Responder a: <internet-draft= s@ietf.org>
Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34
Para: Jordi Palet <jordi.p= alet@consulintel.es>, Jordi Palet Martinez <jordi.palet@consulintel.es>
Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-= 00.txt


=C2=A0 =C2=A0 A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-0= 0.txt
=C2=A0 =C2=A0 has been successfully submitted by Jordi Palet Martinez and p= osted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-palet-ietf-v6ops-ipv6-only
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A000
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6-o= nly Terminology Definition
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-07-18
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-palet-ietf-v6ops-ipv6-only-00.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-palet-ietf= -v6ops-ipv6-only/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-palet-ietf-v6ops-ipv6-<= wbr>only-00
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-pal= et-ietf-v6ops-ipv6-only-00


=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document clarify the terminology regarding = the usage of
=C2=A0 =C2=A0 =C2=A0 =C2=A0expressions such as "IPv6-only", ir or= der to avoid confusions when
=C2=A0 =C2=A0 =C2=A0 =C2=A0using them in IETF and other documents, in refer= ence to what is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0actual functionalities being used (not the actua= l protocol support).




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

=C2=A0 =C2=A0 The IETF Secretariat






**********************************************
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.



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



--
./noah
--001a114b2a14e60c860554ab9438-- From nobody Wed Jul 19 07:05:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6289131D29 for ; Wed, 19 Jul 2017 07:05:52 -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 hBWRSJcY6c0P for ; Wed, 19 Jul 2017 07:05:51 -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 DB48D131CBD for ; Wed, 19 Jul 2017 07:05:50 -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 v6JE5mSn117233; Wed, 19 Jul 2017 16:05:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F13A7206A07; Wed, 19 Jul 2017 16:05:47 +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 E36AF206A10; Wed, 19 Jul 2017 16:05:47 +0200 (CEST) Received: from [132.166.84.52] ([132.166.84.52]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6JE5l24013226; Wed, 19 Jul 2017 16:05:47 +0200 To: Ted Lemon Cc: IPv6 Ops WG References: <596CF817.8040900@foobar.org> <29e1e447-2dca-028f-87dc-6fab52ee4f00@gmail.com> <49f25b72-8709-0424-131f-8be72c85359d@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 19 Jul 2017 16:05:46 +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: Subject: Re: [v6ops] RFC7934 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:05:53 -0000 DHCPv6 has no more privacy risks than any other method like SLAAC or PPP has. If all a network can provide is DHCPv6-Address then make it multiple, because the Node needs more addresses for itself and for other nodes behind it. Even better - provide DHCPv6 PD. Alex Le 19/07/2017 à 11:36, Ted Lemon a écrit : > Let me restate my question then. > > Right now the document explicitly does not recommend DHCP IA_NA. It > doesn't recommend it because it doesn't provide the privacy > characteristics that the other options provide. Your suggestion > essentially says that the document should recommend it. So you must > have some reason why it should make this recommendation. Can you state > that reason? > > On Wed, Jul 19, 2017 at 11:04 AM, Alexandre Petrescu > > wrote: > > Ted, about losing face: I agree the RFC does not recommend against DHCP. > > Le 19/07/2017 à 10:07, Alexandre Petrescu a écrit : > > > > Le 19/07/2017 à 00:47, Jen Linkova a écrit : > > On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu > > wrote: > > Jen said: > > > I had to use all my imagination and still not sure > how the phrase > 'it is RECOMMENDED that the network give the host > the ability to > use new addresses without requiring explicit > requests.' can be > read as 'DHCPv6 is not recommended'. > > > > Because SLAAC does not obtain addresses by using > Requests. That's > DHCP who uses Requests to obtain addresses. > > > Let me give you an example. Imagine that we have apples and > oranges. > Then I say: 'It is recommended that children are given > apples every > day'. Does it mean "giving children oranges is not > recommended'? No. > False. However the statement 'giving children oranges (and > oranges > ONLY) is not recommended' is true. See the difference? ;) > > > Give children 3 apples and oranges a day. > > > Let me try to clarify. > > I find it to be a better RECOMMENDation to state clearly: please use > DHCP-PD, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary > order, and potentially all simultaneously. > > This recommendation is better than being silent about which protocol > should be (or not be) used. > > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Wed Jul 19 08:14:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F8131B76 for ; Wed, 19 Jul 2017 08:14:29 -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 zvfouYB48bCk for ; Wed, 19 Jul 2017 08:14:28 -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 DD2F2129B15 for ; Wed, 19 Jul 2017 08:14:27 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id l81so847615wmg.1 for ; Wed, 19 Jul 2017 08:14:27 -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=GHpHCcD/U32svJPowT5WmkHTvJtCqg8HwhQaRHVutvg=; b=Gdcd9I9j6ZaLJuJSYhUjAk1voNcXA8bivmRmHQlFB7IeIMQU8cVngmnHEfQMJYhV2x GazpxMXm/jmAInjQRPSVxVuB8i6JEVJ/UjAhQ6vO/hOi9YXSXYaLFe6ZGfZzD9sSWmpm O2X47M+etix3GE0V6waA8MJvNhCBVXVrygFFdpfq70t136UbOvos8i98LvFQIpaDc4XG QUrnG8iHXB/fwJavf/pti++Y+WnalA6CR+iyCpxtRsKrMWH8w4waS1sNpH/0UlA9ZT+E gfIvq+bqPeV8u4Y8+fj6qHVxJ11X8mRzIIkujSzqv6vHDM1hjMl7EeCwnBRHEXff1SaQ sjFw== 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=GHpHCcD/U32svJPowT5WmkHTvJtCqg8HwhQaRHVutvg=; b=UTO5a/emJw98IYude0ytm5ePe2IXkfp9yptSxKxb/gec6LQGP5CL7etQ5JdRBZlcdH 5KUiVFrt+5tCaVssEdrAtrzeBTX2C570t+Y+ScIYUjaZGotAqVbPjnRNYRqCQzpKXJxI dljXv8cZEGohccwGC7WfgWr6hVzhS4QdboFvLD/63xOKBZyBhUlk0EF4qwo+C/EyyTDi hRNXVFGEqf981s4Lru+fGTmwGNrIhA8Q+SXzIfEAdjGXr/gz/8gqpkc6G6VfCxRHy7+A fWwkO4GjSgvH/JjJwDSGs7/hzjGZjDuCs1SFn6TrAB0IB9iaH58gS2+cFzaOhMLS3y5X eTvQ== X-Gm-Message-State: AIVw111eXjEh5nLLWUiWVMnIJEftkobxQ2FK/tGx8UKbwt80PYYUlebK +rTn2s52dHgxO5S0 X-Received: by 10.28.173.6 with SMTP id w6mr246305wme.12.1500477266280; Wed, 19 Jul 2017 08:14:26 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:2dea:67ec:e0fa:d8b2? ([2001:67c:370:1998:2dea:67ec:e0fa:d8b2]) by smtp.gmail.com with ESMTPSA id c16sm172618wmh.41.2017.07.19.08.14.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 08:14:25 -0700 (PDT) From: james woodyatt Message-Id: <9D75D02D-4ABA-4E08-A7E8-0410275DD2CF@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D1F58B70-59B8-4FF0-AE6F-8D44DA3861F7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Jul 2017 17:14:24 +0200 In-Reply-To: <01e901d30045$8a502d10$9ef08730$@gmail.com> Cc: IPv6 Operations To: Russ White <7riw77@gmail.com> References: <01e901d30045$8a502d10$9ef08730$@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D.ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:14:29 -0000 --Apple-Mail=_D1F58B70-59B8-4FF0-AE6F-8D44DA3861F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 19, 2017, at 06:14, Russ White <7riw77@gmail.com> wrote: >=20 >=20 >> As I just said at the microphone, I think it would be helpful to add = something to >> this document that connects to Host Address Availability = Recommendations >> [RFC 7934]. In simple terms, we need routers to be capable of making >> addresses available to hosts without requiring them to make an = explicit >> request for each one, and this draft should cite RFC 7934 = accordingly. >=20 > Thanks! I've added this to my list of things to do for the next = revision. And another one is a RECOMMENDATION for configurable support for = =E2=80=9CReducing Energy Consumption of Router Advertisements=E2=80=9D = [RFC 7772]. --james woodyatt > --Apple-Mail=_D1F58B70-59B8-4FF0-AE6F-8D44DA3861F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 19, 2017, at = 06:14, Russ White <7riw77@gmail.com> wrote:


As I just = said at the microphone, I think it would be helpful to add something = to
this document that connects to Host Address = Availability Recommendations
[RFC 7934]. In simple terms, = we need routers to be capable of making
addresses = available to hosts without requiring them to make an explicit
request for each one, and this draft should cite RFC 7934 = accordingly.

Thanks! I've = added this to my list of things to do for the next revision.

And another one is a RECOMMENDATION for = configurable support for =E2=80=9CReducing Energy Consumption of Router = Advertisements=E2=80=9D [RFC 7772].

--james woodyatt <jhw@google.com>



= --Apple-Mail=_D1F58B70-59B8-4FF0-AE6F-8D44DA3861F7-- From me@michael-gooden.info Wed Jul 19 06:10:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85454131D0F for ; Wed, 19 Jul 2017 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1024-bit key) header.d=michael-gooden.info header.b=VbDaFvTb; dkim=pass (1024-bit key) header.d=michaelgooden.net header.b=KBjL2Y2A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F4oHQfutTw8 for ; Wed, 19 Jul 2017 06:10:21 -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 6CBB1131B42 for ; Wed, 19 Jul 2017 06:10:21 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id l81so87279wmg.1 for ; Wed, 19 Jul 2017 06:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=michael-gooden.info; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OTieTAEryoHPHD50VGg45/t9WnysxC+v35DtWc/bc9Y=; b=VbDaFvTbZdEUp+6Qyx5n6JiS/T6UXA3gxZx2sl1PaHTI87ll8uKXA6iVVP0XyIVWps hB2P+g6arTKfLt9ZF5JCdOO7c/TL+OGEWbG10bSrNH16Ne+mtNDrgtteP2Su+KJkfw92 ofuxw6uBDNKbFhlAI1QxupBWjaCIyOmPTiAf8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=michaelgooden.net; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OTieTAEryoHPHD50VGg45/t9WnysxC+v35DtWc/bc9Y=; b=KBjL2Y2Au0nZ8sXyRPKHfcpcyo6QfBgafHIG1O1KmREJorSNaEpi8XKrsshpwPBdOw Bk42kWcvB4QKw2jcPvgqSw6uY+9o2d9nVy48zovxq3lR57JVOH+7rj3S5UnjHZ+oL8B0 TrbKR6tipoO04OtgfKy/4upXH10cowhkLqVko= 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=OTieTAEryoHPHD50VGg45/t9WnysxC+v35DtWc/bc9Y=; b=XC0MziuuR0kpnbIoBOE9a/LiuoyL8DC3NkSROkuHXaSOrYGqul/3v0sFchripE8ARD fGrX6Abpamsef8gG+l/YXrtxoE/BDnHlNnC4F1eKHWliilBGLu0TOEgryGH5/uBZd3Z2 2ROTEb+yhgDZZzIgMCzVeCG2u1ty13OhqR1ABgX8YHZZPW2fN3ne7eGRFGgQaeesbWQU 7OxshW692cwuOFf4jYiNOvx1gAPDB+axp6fRHnXy/5vwEPR6zKw2vPjB0NJW3hAuTWkH dK6YcqZ6IwRgnw/mCxEapZRUL0PucKECeIf57Ra1WCBwPkitXLlfMNwSDFvUmHgb9hHS LtmQ== X-Gm-Message-State: AIVw113kGZtaF9XBQtnaIZFcSacl9tvT+Kszt6300jlMPaCH+U6HGE+h AxKZFxf8+OzH9EVoo5lstV0MQRrHrTZd X-Received: by 10.80.140.204 with SMTP id r12mr2703edr.123.1500469819826; Wed, 19 Jul 2017 06:10:19 -0700 (PDT) MIME-Version: 1.0 Sender: me@michael-gooden.info Received: by 10.80.138.70 with HTTP; Wed, 19 Jul 2017 06:10:04 -0700 (PDT) In-Reply-To: References: <150045683171.25205.418739468211175205.idtracker@ietfa.amsl.com> <3F3E6A8F-9139-4486-B926-2B478130BE37@consulintel.es> From: Michael Gooden Date: Wed, 19 Jul 2017 15:10:04 +0200 X-Google-Sender-Auth: D3GDBR5qGwfJu1vmKNJ1cc3bcvo Message-ID: To: jordi.palet@consulintel.es, Noah Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="f403045c2d1e9b7f740554ab5a84" Archived-At: X-Mailman-Approved-At: Wed, 19 Jul 2017 08:56:25 -0700 Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-ipv6-only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:12:32 -0000 --f403045c2d1e9b7f740554ab5a84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Jordi/Noah, Here is an alternate suggestion for that paragraph: It is not feasible for most of the operators to tell their customers "I can provide you with an IPv6 service, however you will not be able to access any content that is IPv4-only from providers who do not or cannot support IPv6" Kind Regards, *Michael Gooden* On 19 July 2017 at 14:58, JORDI PALET MARTINEZ wrote: > Hi Noah, > > Thanks a lot for your inputs! > > This is what happens when you write a draft, which even being =E2=80=9Csi= mple=E2=80=9D, > you do it to quickly =E2=80=A6 > > I=E2=80=99ve already an internal -01 version and corrected your first poi= nt. > > I=E2=80=99m not sure about your 2nd suggestions, I think is I prefer my f= irst > text, but I=E2=80=99ve modified it a bit: > > It is not feasible for most of the operators to tell their customers "I > can provide you IPv6 service, but you will not be able to access all > Internet contents and apps, because some of them still don't support IPv= 6, > so you will miss every content that it is IPv4-only" > > Saludos, > Jordi > > > -----Mensaje original----- > De: Noah > Responder a: > Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 14:47 > Para: Jordi Palet Martinez > CC: IPv6 Operations > Asunto: Re: [v6ops] FW: New Version Notification for > draft-palet-ietf-v6ops-ipv6-only-00.txt > > Hi Jordi > Some corrections. > > 1. Introduction > Note that al the references > Update with =3D Note that all the references > > > > 2. Context > It is not feasible for most of the operators de tell their > customers "I can provide you IPv6 service, but you will not be abl= e > to access all Internet because some of the contents or application= s > still don't support it, so you will miss every content that it is > IPv4-only". > > Can you update the the above with the below; > > "Its not feasible for internet service providers and operators to > inform their customers that they can offer them IPv6 connectivity and > transport to the internet but unfortunately, the customers would not be > able to access some of the contents and applications on the Internet > because not all content and applications have support for IPv6 and as suc= h, > the customers will fail to access content and applications that are > IPv4-only." > > Noah > > > > On Wed, Jul 19, 2017 at 12:36 PM, JORDI PALET MARTINEZ < > jordi.palet@consulintel.es> wrote: > > Hi all, > > As announced in our session yesterday, here is the document =E2=80=A6= . > > https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only > > I will love to have inputs today, so I can even post a new version an= d > maybe we can have tomorrow 10 minutes in the agenda to present it if the > chairs agree! > > Regards, > Jordi > > > -----Mensaje original----- > De: > Responder a: > Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34 > Para: Jordi Palet , Jordi Palet Martinez = < > jordi.palet@consulintel.es> > Asunto: New Version Notification for draft-palet-ietf-v6ops-ipv6- > only-00.txt > > > A new version of I-D, draft-palet-ietf-v6ops-ipv6-only-00.txt > has been successfully submitted by Jordi Palet Martinez and poste= d > to the > IETF repository. > > Name: draft-palet-ietf-v6ops-ipv6-only > Revision: 00 > Title: IPv6-only Terminology Definition > Document date: 2017-07-18 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet- > drafts/draft-palet-ietf-v6ops-ipv6-only-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-palet-ietf-v6ops-ipv6-only/ > Htmlized: https://tools.ietf.org/html/ > draft-palet-ietf-v6ops-ipv6-only-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-palet-ietf-v6ops-ipv6-only-00 > > > Abstract: > This document clarify the terminology regarding the usage of > expressions such as "IPv6-only", ir order to avoid confusions > when > using them in IETF and other documents, in reference to what i= s > the > actual functionalities being used (not the actual protocol > support). > > > > > 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 > > > > > > > ********************************************** > 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 confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > -- > ./noah > > > > > > > > > ********************************************** > 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 > confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045c2d1e9b7f740554ab5a84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jordi/Noah,

Here is an alternate suggestion for th= at paragraph:

It is not feasible for most of the operators to tell their customers "= I=20 can provide you with an IPv6 service, however you will not be able to acces= s any content that is IPv4-only from providers who do not or cannot support= IPv6"

=
<= /span>
Kind Regards,

Michael Gooden


On 19 July 2017 at 14:58, JORDI PALET MARTIN= EZ <jordi.palet@consulintel.es> wrote:
Hi Noah,

Thanks a lot for your inputs!

This is what happens when you write a draft, which even being =E2=80=9Csimp= le=E2=80=9D, you do it to quickly =E2=80=A6

I=E2=80=99ve already an internal -01 version and corrected your first point= .

I=E2=80=99m not sure about your 2nd suggestions, I think is I prefer my fir= st text, but I=E2=80=99ve modified it a bit:

It is not feasible for most of the operators to tell their customers "= I can provide you IPv6 service, but you will not be able to access all Inte= rnet contents and apps, because some=C2=A0 of them still don't support = IPv6, so you will miss every content that it is IPv4-only"

Saludos,
Jordi


-----Mensaje original-----
De: Noah <noah@neo.co.tz>
Responder a: <noah@neo.co.tz> Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 14:47
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: IPv6 Operations <v6ops@ietf.org>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops= -ipv6-only-00.txt

=C2=A0 =C2=A0 Hi Jordi
=C2=A0 =C2=A0 Some corrections.

=C2=A0 =C2=A0 1.=C2=A0 Introduction
=C2=A0 =C2=A0 Note that al the references
=C2=A0 =C2=A0 Update with =3D Note that all the references



=C2=A0 =C2=A0 2.=C2=A0 Context
=C2=A0 =C2=A0 =C2=A0It is not feasible for most of the operators de tell th= eir
=C2=A0 =C2=A0 =C2=A0 =C2=A0customers "I can provide you IPv6 service, = but you will not be able
=C2=A0 =C2=A0 =C2=A0 =C2=A0to access all Internet because some of the conte= nts or applications
=C2=A0 =C2=A0 =C2=A0 =C2=A0still don't support it, so you will miss eve= ry content that it is
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4-only".

=C2=A0 =C2=A0 Can you update the the above with the below;

=C2=A0 =C2=A0 "Its not feasible for internet service providers and ope= rators to inform their customers that they can offer them IPv6 connectivity= and transport to the internet but unfortunately, the customers would not b= e able to access some of the contents and applications on the Internet beca= use not all content and applications have support for IPv6 and as such, the= customers will fail to access content and applications that are IPv4-only.= "

=C2=A0 =C2=A0 Noah



=C2=A0 =C2=A0 On Wed, Jul 19, 2017 at 12:36 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es&= gt; wrote:

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 As announced in our session yesterday, here is the document = =E2=80=A6.

=C2=A0 =C2=A0 https://datatracker.i= etf.org/doc/draft-palet-ietf-v6ops-ipv6-only

=C2=A0 =C2=A0 I will love to have inputs today, so I can even post a new ve= rsion and maybe we can have tomorrow 10 minutes in the agenda to present it= if the chairs agree!

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Jordi


=C2=A0 =C2=A0 -----Mensaje original-----
=C2=A0 =C2=A0 De: <internet-= drafts@ietf.org>
=C2=A0 =C2=A0 Responder a: <= internet-drafts@ietf.org>
=C2=A0 =C2=A0 Fecha: mi=C3=A9rcoles, 19 de julio de 2017, 11:34
=C2=A0 =C2=A0 Para: Jordi Palet <jordi.palet@consulintel.es>, Jordi Palet Martinez <jordi.palet@consulintel.es> =C2=A0 =C2=A0 Asunto: New Version Notification for draft-palet-ietf-v6ops-i= pv6-only-00.txt


=C2=A0 =C2=A0 =C2=A0 =C2=A0 A new version of I-D, draft-palet-ietf-v6ops-ip= v6-only-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 has been successfully submitted by Jordi Palet = Martinez and posted to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-palet-ietf-v6ops-ipv6-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Revision:=C2=A0 =C2=A000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 IPv6-only Terminology Definition
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-07-18 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Individual Submission
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= a href=3D"https://www.ietf.org/internet-drafts/draft-palet-ietf-v6ops-ipv6-= only-00.txt" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/inte= rnet-drafts/draft-palet-ietf-v6ops-ipv6-only-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/dr= aft-palet-ietf-v6ops-ipv6-only/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-palet-iet= f-v6ops-ipv6-only-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/= html/draft-palet-ietf-v6ops-ipv6-only-00


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document clarify the terminol= ogy regarding the usage of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expressions such as "IPv6-onl= y", ir order to avoid confusions when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using them in IETF and other docum= ents, in reference to what is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actual functionalities being used = (not the actual protocol support).




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please note that it may take a couple of minute= s from the time of submission
=C2=A0 =C2=A0 =C2=A0 =C2=A0 until the htmlized version and diff= are available at tools.ietf.org <http://tools.ietf.org>.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The IETF Secretariat






=C2=A0 =C2=A0 **********************************************
=C2=A0 =C2=A0 IPv4 is over
=C2=A0 =C2=A0 Are you ready for the new Internet ?
=C2=A0 =C2=A0 http://www.consulintel.es
=C2=A0 =C2=A0 The IPv6 Company

=C2=A0 =C2=A0 This electronic message contains information which may be pri= vileged or confidential. The information is intended to be for the use of t= he individual(s) named above. If you are not the intended recipient be awar= e that any disclosure, copying, distribution or use of the contents of this= information, including attached files, is prohibited.



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






=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 ./noah








**********************************************
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.



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

--f403045c2d1e9b7f740554ab5a84-- From nobody Wed Jul 19 09:57:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DDD129482; Wed, 19 Jul 2017 09:57:11 -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 i7ioNHqf-Mv2; Wed, 19 Jul 2017 09:57:10 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E585213167D; Wed, 19 Jul 2017 09:57:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 38CFCA2; Wed, 19 Jul 2017 18:57:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1500483428; bh=UpyH9iTF6S3h3AsP98OG3F81U7Ll0k+fMXhpMhWn5bY=; h=Date:From:To:Subject:From; b=FdfEkXQ1Yy8CIYCI3DIBkReFWcVLFXJu8Zpv/0ZS9v/lZvZk18WsgXAu7gj78uwht yciSKuWOyOQQ1KxS457k0x5TJZ6VCKlR7b0tDe7CCEkaOaoyikno1/NsvWGNZXcVue smYGhqKR/FrluhnN5qaphKtyy7N3whKkiUGbvjUM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 215BEA1; Wed, 19 Jul 2017 18:57:08 +0200 (CEST) Date: Wed, 19 Jul 2017 18:57:08 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org, mboned@ietf.org, 6lowpan@ietf.org, 6lo@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] multicast over wifi discussion list X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:57:12 -0000 Hi, please forward this if there are other parties or WGs that might have valuable knowledge in this. 1.5 years ago there was an email list created to discuss the issue of L1/L2 multicast packets having different delivery characteristics compared to unicast, on 802.11 and potentially other places. http://www.ieee802.org/11/email/stds-802-11/msg01838.html If you're interested in discussion on possible solution space for this, please consider subscribing. Possible outcomes is that IETF will re-design protocols to do less multicast, and/or new mechanisms would be proposed to make 802.11 (and other similar technologies) handle multicast better. There was a side meeting today with 10 people where this was discussed, and we're trying to restart this discussion, as it has been kind of stale the past year. Link to the email I sent to that list: https://mailarchive.ietf.org/arch/msg/mcast-wifi/muf8GqcTRzQubgHI-uc90aIC2YY -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 19 18:57:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0389129B4C for ; Wed, 19 Jul 2017 18:57: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, 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 jBZQwuhcEoVb for ; Wed, 19 Jul 2017 18:57:35 -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 090DA126C2F for ; Wed, 19 Jul 2017 18:57:35 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id o88so6450376pfk.3 for ; Wed, 19 Jul 2017 18:57:35 -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=e+S6SokhrfpZ2H+mmKZzA7p3/Krtczm5wptXn0fWk3c=; b=vEH6z9ZWHisqZtY7RRQSIYA3f5cPVgK4HM5PAoEku5CW3ujuwNsTMped1ss8xmUnlp 2wnu5Cj4VlxAFYN2torD/GVRbGZ+lXxvhWweOmgnNsXADEmlFNzxUgYsA0m6jD126eg3 f5QYSeo9UlMWJap3BAQ9BD4rPeN9pa6Tw2gV5voPMluabDTZIuYuKt5Mg/EEA4/LSdNF 9A/oMdZNSNln/Eo/I2xh2Oy0uQnUVNvTBlV7nycb7m1NGKRRPilu/nDwI2wPqLkR3KxR T3vXyw0Y50MDMrn37CSneMaJyFai1PO1Ar82FXnUSSDX/jzSuQ5hLblARgF7OAsjmaZS ip5A== 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=e+S6SokhrfpZ2H+mmKZzA7p3/Krtczm5wptXn0fWk3c=; b=LoLq+mbqXOsJfDqIswJk9AZcxSMhr0pYMM4iueFHq2I9+h/WJMXd6kZNMRUHOkZnXY Y/n8DW9w2mBdBU88g3GwEVYo0VPjb63qRUuEs01Pn/K1hIH9D4rWQp0KkPWCPxVWkAc8 H+HpYpLyjJ8R4ST9zItqZ2ofotg3gZfqHXDVLBfafBALNQs5dGIynaEVeCBvo03FqtKb GBfHWe3rNmf/H361N8JDlT13W3uOY2iAliTe1jv69x7EKMOxjwqn4OPxpIbJP+w9YDnw 7r0bLOhSYHQjKPMOUpjGdWF9oI3uhh8cPZIBhaQK8FuhANzPam/L8Wu3Lk4LpQ8vvPpE bjyA== X-Gm-Message-State: AIVw1123T3KJs0PloXgbOBKZnSVdhGPzhxWZ07aRJg6JqexIC87/RvfF 2TuTSlAQGQHMx8Nt X-Received: by 10.98.7.204 with SMTP id 73mr2141881pfh.110.1500515854205; Wed, 19 Jul 2017 18:57:34 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c82sm1734562pfd.5.2017.07.19.18.57.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 18:57:33 -0700 (PDT) To: Lorenzo Colitti , Gert Doering Cc: james woodyatt , IPv6 Operations References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> Date: Thu, 20 Jul 2017 13:57:34 +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: 7bit Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 01:57:37 -0000 On 19/07/2017 21:16, Lorenzo Colitti wrote: > On Wed, Jul 19, 2017 at 11:08 AM, Gert Doering wrote: > >> On Tue, Jul 18, 2017 at 12:44:29AM -0700, james woodyatt wrote: >>> That would be a gross misinterpretation of the recommendation. >>> The recommendation in RFC 7934 is clearly written and does not need >>> updating to provide more clarity about the implications for usage >>> of DHCPv6. The clear implication of the recommendation is *NOT* >>> that networks SHOULD NOT provide DHCPv6 services. The clear implication >>> of the recommendation is that networks SHOULD NOT require hosts to >>> use DHCPv6 with IA_NA/IA_TA to obtain all their addresses. >> >> And this is not a "recommendation that networks SHOULD NOT provide DHCPv6 >> stateful addressing services"? >> > > There is no recommendation that networks SHOULD NOT provide stateful DHCPv6 > addressing services. > > There is a recommendation that networks SHOULD NOT provide *only* stateful > DHCPv6 addressing services (where "addressing services" currently means > IA_NA / IA_TA, but more in general, means any addressing service that > requires an explicit request to the network in order to obtain an address). But there *is not* what Gert said: "The clear implication of the recommendation is that networks SHOULD NOT require hosts to use DHCPv6 with IA_NA/IA_TA to obtain all their addresses." Once again, not saying that X is recommended is not the same as saying X SHOULD NOT** be done. Warning that X has consequences, as the RFC does, is not the same thing as saying X SHOULD NOT be done. Formally saying that something that we standardised SHOULD NOT be done is a major step and one that the IETF takes quite rarely, when there is a major operational or security issue. When we do it, the language is pretty explicit, e.g. https://tools.ietf.org/html/rfc7526#section-5 The language in RFC 7934 is not remotely comparable. ** and of course "SHOULD NOT" only means that "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed" [RFC2119]. In other words, even if 7934 did state the "SHOULD NOT", it doesn't mean "MUST NOT". Brian From nobody Wed Jul 19 23:24:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5096112783A for ; Wed, 19 Jul 2017 23:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2vRcoDxF69u for ; Wed, 19 Jul 2017 23:24:32 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18214124217 for ; Wed, 19 Jul 2017 23:24:31 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C8F3541C2B for ; Thu, 20 Jul 2017 08:24:28 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9E78B41C24; Thu, 20 Jul 2017 08:24:28 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 9036534A68; Thu, 20 Jul 2017 08:24:28 +0200 (CEST) Date: Thu, 20 Jul 2017 08:24:28 +0200 From: Gert Doering To: Lorenzo Colitti Cc: Gert Doering , james woodyatt , IPv6 Operations Message-ID: <20170720062428.GK45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zz1tkJZbfERTl/zK" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:24:34 -0000 --Zz1tkJZbfERTl/zK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 19, 2017 at 11:16:33AM +0200, Lorenzo Colitti wrote: > > And this is not a "recommendation that networks SHOULD NOT provide DHCP= v6 > > stateful addressing services"? >=20 > There is no recommendation that networks SHOULD NOT provide stateful DHCP= v6 > addressing services. >=20 > There is a recommendation that networks SHOULD NOT provide *only* stateful > DHCPv6 addressing services (where "addressing services" currently means > IA_NA / IA_TA, but more in general, means any addressing service that > requires an explicit request to the network in order to obtain an address= ). Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it effectively *is*, and no amount of word-weaseling is going to change this. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Zz1tkJZbfERTl/zK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAllwTJkACgkQ31bAZeTO f8UiCw//YqBPlfWTI4g6I2eh5xn2k8F0GM6J0MikEDvU2xo+U6OxlZcl0XIQtrlj BNUj1VKNUzo5+i1BfmzxaZVdl60/pFbyTil/b53X2zcq/sm4KH4slKNU/2sKQpZD lL03OdKeEGEe/hmKFyFCuqpUxrydav2jyaF5eytXk2TKYEfXI2K2S2DQsQfFjoXS Dike5x2+cILAFXqzZqhRB+Dh15/jMTSretmgqUOU4VP9HQ2TOSU7Rv8YS+HgQO+Y A5NghNCxogDih8odtL5c5AS3GTMKBi+O6MknAJMsSp9TkOTVesUM7/O5Z4lgC7+j 2xBurGPyunfV/ZNAU6vrNjmLdH7pMbpn61dnJyBZNoOUyjvffVtjjnjUeSpn9wiy zxmCumYs3QnqXggCgsnU4zgLFXQlVrOMbhl5ze1jm95nuIybji+atgKOT6kgwYOO wRkTon7rtrA3WuVPhhlrR2IO4oT80ElizmMZWH1p5Vp4QsrsuNsr+Mg+x7Z1e7iz sOIOrvqEueaKC45SOffqT77TvmPk0loKeHUwwgdaHwPslCefBz/DQErDogALOCdG mlC698+XLQ3zNXgXFeEu8t3F56TrwVEpVNYZ8UvvrgKphqwVuFzArlGhcnFAKEeD MO5APdLBMVbkBrY7lhl4srg7Ii5o6spDctIIfj7g77mjijIr3a0= =kLZt -----END PGP SIGNATURE----- --Zz1tkJZbfERTl/zK-- From nobody Wed Jul 19 23:27:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F541289B0 for ; Wed, 19 Jul 2017 23:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 4KOJkKJELKnC for ; Wed, 19 Jul 2017 23:27:37 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D27D124217 for ; Wed, 19 Jul 2017 23:27:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CD611A2; Thu, 20 Jul 2017 08:27:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1500532054; bh=datUEm9YFBLmbKoVDNqxAZIevPu5Pl/4Re+FGz2Sgpk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=ERJ9sKN77qKDcBJ1aNafnDtrfivdesiPvNSCTxdp6KrHLFAYiAFlNgxXfhd0336nG mCcZKoeRAXfs3/VphjMNzjGSH+lQXn5Gxm/Tv4ucrQdINmd7AlbI1jts64jAB77+lk p4qKjodQTxUz2pNek+lCqrnY6PXTiZ9p9ZRlCF10= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B3A35A1 for ; Thu, 20 Jul 2017 08:27:34 +0200 (CEST) Date: Thu, 20 Jul 2017 08:27:34 +0200 (CEST) From: Mikael Abrahamsson To: IPv6 Ops WG In-Reply-To: Message-ID: References: <7643C1DC-76A3-4652-9BB1-D0D42801F37E@consulintel.es> <9AF791E9-1E12-425E-93A4-2913E2D18CBA@consulintel.es> <0FAF1E05-DA4B-47BF-95F7-7EFCD1BED9B0@cable.comcast.com> <42188852-BBEB-4D75-967F-4BED79BBBCAE@consulintel.es> <2A639918-C6AC-44B8-8D66-5293EE13A7BD@consulintel.es> <10FFC885-81E1-45E6-B87D-5520C35FDE2C@consulintel.es> 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: Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:27:39 -0000 On Mon, 17 Jul 2017, Mikael Abrahamsson wrote: > My android and iOS devices work great on IPv6 only using the proposed > suggestion. My MacOS and Windows do not (because they don't have the 464XLAT > or bump-in-the-API that is available on the mobile platforms). I already know > this. I don't need to prove it to anyone. I need to qualify the above statement. MacOS does have bump-in-the-API the same way as iOS has, but it's for the high-level APIs only. So when I connect my macbook to NAT64 wifi, safari works to use IPv4 literals, but Chrome does not (presumably because it uses the socket api). So the problem is not that MacOS doesn't support NAT64 prefix synthesis, it's that most applications there don't use the APIs that actually do this. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 19 23:27:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB2C129B34 for ; Wed, 19 Jul 2017 23:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLCp4lsa9d5Q for ; Wed, 19 Jul 2017 23:27:53 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E62131803 for ; Wed, 19 Jul 2017 23:27:53 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EF0B341C2A for ; Thu, 20 Jul 2017 08:27:51 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C260141C24; Thu, 20 Jul 2017 08:27:51 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id B3A9934A95; Thu, 20 Jul 2017 08:27:51 +0200 (CEST) Date: Thu, 20 Jul 2017 08:27:51 +0200 From: Gert Doering To: Brian E Carpenter Cc: Lorenzo Colitti , Gert Doering , james woodyatt , IPv6 Operations Message-ID: <20170720062751.GL45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="87QVehOBmjk/UAy8" Content-Disposition: inline In-Reply-To: <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:27:55 -0000 --87QVehOBmjk/UAy8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 20, 2017 at 01:57:34PM +1200, Brian E Carpenter wrote: > Once again, not saying that X is recommended is not the same as > saying X SHOULD NOT** be done. Warning that X has consequences, > as the RFC does, is not the same thing as saying X SHOULD NOT be done. If X and Y are mutually exclusive, a document saying "X SHOULD BE DONE" is effectively implying "Y SHOULD NOT BE DONE". Right? (And do not tell me that people would do DHCPv6 IA_NA/IA_TA *and* SLAAC on the same network - technically you could, but nobody would do that, given that it voids the reason *why* IA_NA/IA_TA are used: control, DNS, etc - note I'm not saying "security") > The language in RFC 7934 is not remotely comparable. Yeah, it was nicely done. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --87QVehOBmjk/UAy8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAllwTWYACgkQ31bAZeTO f8XCPRAAldMX11qcO0Nzp2BYCRHrIsugQgJvtZOHxWmd0HJ+k1Qx8ZqSwtKfjWBt gVETe5J752cOyhRJwl6ATb7ugeL2+7lSFvVG2Z4eIjadbuMy2pHP+DWQ7tePIVQ1 GH4v5ySRQDtTrV4MBCG9nsQiHcmpIeqc/ZMPW9EuNkeUMwcqz5VUyeB4hA53v6xK SeEDLmklU8HLdj5N5yq6Dltmvh1Q4STPI80sJqIC7GeBEuvA9oS+FysAL6GrKjxz v+kD6vPmaGSj1yDgurcJV3akOTgy87LHPv6H0n/0DtAO7F6TmiBFB4eKjILMLL53 yo5+HdtbMMEqG8dDyihQGJNe0k8onsCHreNdjmn6E3HOyZXw3oc9Z8t1w/fmNfGG 5kSaUnjGOw7tDhq7+10K1SR2F7pVRltzjHk2/5yOZg6JDVA2pt1QXOyR5UY8WgXn SShdgu6zT3rybmbYXjcgwg38S3dkAa3w1Gfxk9Cklr25Mn1y9/L56kVQQ2ri+z70 JRiE3NRNhCs0Ew53g28MvqxSbx3FXZvkDeFUbI7DOm/yhZLC7ya5kY3HMwmxgzm8 MK2tuY53K3wLvNldFXgPyeyDcfAFgh1pNAJz/gtX3F7ECWi8me3fjtj7dPeoqa3y ctgcr3qo7clNTQTvRFP9yOqHM+qWcB6kG9YYb6yCjoYNBetufVc= =tQmj -----END PGP SIGNATURE----- --87QVehOBmjk/UAy8-- From nobody Wed Jul 19 23:30:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4881289B0 for ; Wed, 19 Jul 2017 23:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoQevCnxpGVX for ; Wed, 19 Jul 2017 23:30:01 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8327F12783A for ; Wed, 19 Jul 2017 23:30:01 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C479841C28 for ; Thu, 20 Jul 2017 08:29:59 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9A34F41C24; Thu, 20 Jul 2017 08:29:59 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8BC5C34AA2; Thu, 20 Jul 2017 08:29:59 +0200 (CEST) Date: Thu, 20 Jul 2017 08:29:59 +0200 From: Gert Doering To: Philip Homburg Cc: v6ops@ietf.org, Tore Anderson Message-ID: <20170720062959.GM45648@Space.Net> References: <20170717152345.GV45648@Space.Net> <29616c41-49d5-a960-8048-9441284fd171@fud.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] NAT64/DNS64 support in RIPE Atlas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:30:03 -0000 Hi, On Tue, Jul 18, 2017 at 09:48:06AM +0200, Philip Homburg wrote: > So what goes wrong. Currently unsolved is that measurements are either v4 > or v6. So if you measure a v4-only target with a v4 measurement then probes > on a NAT64 with never measure anything. You need a v6 measurement for that. This is exactly the thing we ran into with OpenVPN being "doubly single-stacked" - and yes, for a measuring environment where you do not want to rely on "use what getaddrinfo() is giving me", this is getting a bit tricky. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jul 19 23:53:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EB0126557 for ; Wed, 19 Jul 2017 23:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-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 gMjgMiiueq-Q for ; Wed, 19 Jul 2017 23:53:34 -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 345AA1242F5 for ; Wed, 19 Jul 2017 23:53:34 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id w126so15976662wme.0 for ; Wed, 19 Jul 2017 23:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language; bh=3lYznN37G0ippBGCJASlXPCCUkLCZvaEZsx0XuboR7c=; b=X7kO7fHcimCSJ/5OXRdhfKCdRx9We0vnzCAEFUAHAw6y5hHP0DWpmVPqNcI4cZswRy ZLx91A1Ull7qJ8Ok2M/Eo2fdnhO5VY1d2p8TexTnZtW3IG3uTqy6K7JR6rtkpwB49bO8 N0UXn6EGSsfacxTOHAkF5/OZWleOepX1XpTbC2CvXnrZJ4ZzB+qfJm1Gst1FGFTdymjh irqxMtpBr1CYUnGzbiCQfNYd8q5nPdngU+ozI0H4vbLOYQVMmE2Dds3nCZj5fRSYIeDN Ftkq9z730lFXAR0/hROalOQD7yBgz3mH46/XFsr1JUMEW1oHir5XDJ7BkekOSZvfVy+5 h9mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language; bh=3lYznN37G0ippBGCJASlXPCCUkLCZvaEZsx0XuboR7c=; b=AyVqcunXQJring3UXkUSEasmsj755INvd8MTT0Ekuj58btSgE6HSVlsUwbb32T4PYw ZSgmopBgxg9aiwSNOb0h5bx6IFNmHlmVnFG87C/Yakmt/DIcGnhcDlyhqMaCOFTgEw0P qE1fdSZ/YrPyyel7w6nrZ4iXjiV3qfMgji/zm27C55zq9o+pfk5s1Bnx8DVW3nmPpBwc DIlEgkDxywN22CbXImAeLLmSvwu6J6hrNraRGsg5r4VTkZgQo+HGkXFFAzPra5xyyU6f /zcpUqOQFy2KSjWIY8/RsvW1o935nDJv+ny6H8zWpsS6RfYHcmBgc3Zgbn9PvIgNdCqx hd4g== X-Gm-Message-State: AIVw110JVoseyRrBZALdHnFb17cMj3u2VgFo3F1PmvL5KY6i8hQZIX3e qyMfiyrVznSXC8JlZuI6xgm3/duc5jaFUsIndyxR4XxI6Uv/HdzU5eEFGKheeW8qwjWVkF0= X-Received: by 10.28.185.210 with SMTP id j201mr1501322wmf.52.1500533612607; Wed, 19 Jul 2017 23:53:32 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id h10sm1274528wme.30.2017.07.19.23.53.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 23:53:32 -0700 (PDT) To: RTGWG , V6 Ops List Cc: Olivier Tilmans From: Olivier Bonaventure Message-ID: Date: Thu, 20 Jul 2017 08:53:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: [v6ops] Eating our own dog food : students solving IPv6 entreprise multihoming X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:53:36 -0000 Hello, During v6ops and yesterday's plenary, John Brzozowski encouraged us to use our own technologies for the IETF network with NAT64. This argument is valid for those who teach computer networks and since RTGWG is working on enterprise IPv6 multihoming, you might be interested in a recent experiment we did with our students. When students learn networking, they should not learn the current state of affairs but be prepared for the future since they'll only graduate in a few years. Several years ago, when IPv6 deployment was burgeoning, I decided to remove IPv4 from my networking 101 open-source textbook ( http://cnp3book.info.ucl.ac.be ). Since then, our students only learn IPv6 and results are excellent. Once they've learned IPv6, they can quickly understand how IPv4 works. Hopefully they'll see sunset4 during their career. After networking 101, some of your students attend an advanced networking course. This course combines theory with practice and usually students do practice after theory to illustrate the theoratical concepts. This year, we decided to flip the course and start from a practical problem to see how groups of students can address this problem with an open mindset and based only on what they've learned from networking 101 and the information that they will find on the Internet. During their carreer, they will be forced to learn on the spot anyway and they should better start early to look at rfcs, internet drafts and open-source implementations. The project given to the students was very simple. One of the engineers responsible for our (IPv4 mainly :-() campus network explained the architecture and the basic openrational principles that they use. Olivier Tilmans prepared a virtual machine that mimics our compus network (basically six routers) and we attached a few virtual machines to act as servers and clients. The only constraint that we was that the campus network had two upstream providers each delegating a different prefix to the campus network. Then, the students had to : - define an IPv6 addressing plan for their network - select, install and configure a routing protocol and make sure that it was working correctly - install and configure dhcp servers/ra to distribute addresses - install and configure DNS servers and resolvers - install and configure Diffserv-like traffic control - install and configure ssh and http servers - install and configure firewall services to protect the network - think about a solution to monitor the network [the number of tasks was chosen based on the number of students in each group] All student teams had an operation network at the end of the project. Since we believe in automation and open-source, we required them to automate their network from day one and several groups have released their entire project in open-source. From a teaching viewpoint, entreprise IPv6 multihoming is a very nice problem. To encourage other educators (and maybe also network engineers willing to continue to learn) to experiment with IPv6 entreprise multihoming, we have released all the software developed to create this project in open-source. You can find all the details at : https://github.com/UCL-INGI/lingi2142 You only need a Linux virtual machine provided by Vagrant to reproduce the experiment. The barrier to experiment with IPv6 entreprise multihoming is very low. Selected students projects with reports and code are available from this repository as well https://github.com/UCL-INGI/lingi2142/tree/master/student_projects I encourage you to have a look at the students' reports to see their final results: https://github.com/UCL-INGI/lingi2142/blob/master/student_projects/Group1/report-group1.pdf https://github.com/UCL-INGI/lingi2142/blob/master/student_projects/Group2/LINGI2142___Rapport_Groupe_2.pdf https://github.com/UCL-INGI/lingi2142/blob/master/student_projects/Group3/report.pdf Comments and feedback are welcome although the IETF mailing lists may not be the best place for discussions on software or teaching projects... Olivier Tilmans and Olivier Bonaventure -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Thu Jul 20 00:15:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73557131CE4; Thu, 20 Jul 2017 00:15: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, 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 P1PuEbF9zkNK; Thu, 20 Jul 2017 00:15:25 -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 1B73B12EB2B; Thu, 20 Jul 2017 00:15:25 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id k71so13378633wrc.2; Thu, 20 Jul 2017 00:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=xBdyydK8L2NOQp5Jo0SIxG8n9Vw/b4ht3+eCVvNgAd4=; b=tY/2N6QEKSOIE5SDI2dz4rpqoK7y6/kmFczkYP0Q3xy2rgi9Stz0DXQvD4KNNwrhzJ vzMNxBvM1C1og74s0i2fej2asUQHKiue0TMI408NB9OajkMYiFqvowNa9ny+PKRXgrmB k2a4NHLl0//YfJmhsAzGx9Qt7cTmGF0KU8/Vby7Xsvg2W7JcgOLGNAJBgP3aiB98nHfv mmhNWQLC1HtL2O32E67Yz/Q+quNZeDRFsvkCKQnkqAAkN62rNTBb6QDDr71UUkyaDk1G NKwBfDWmMU8s6iUfMz7FuZqvJ4utWj4H9vqzrG109SLe1zR3z1z0MmLShliohWICmhAo 3EfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=xBdyydK8L2NOQp5Jo0SIxG8n9Vw/b4ht3+eCVvNgAd4=; b=eTdHWh179f24G5QLrHTaQ+d2hHba1VzlRSvXGEatLwZwV0jY7Ku0ikRNvBESuSYOIX xayG02migD7EYRiBw2ysTI/lBZ/JeDarn1D0C/bItlzs1w6Lnbh1WJuTNHNY1TgGjLsp bfO7aShEcTrNuN8GTEqcz2TGJDpEzSkBWNOZ+L4l5D7k3dHH+sHzMuMpKFyZTRTGmM4u nqGC4tbw2IQzDHLQtlKMNarm42MzL3bIEBrrwE9jf1WQwJHwX2ac22Fynw2QunbTzUSw wZDDvdIha3Shok4XgTijzYkq7CuVp8F6OJDvIt4z1eRDAebFDwSRtBxlKLTGuPQxKdwj wxTw== X-Gm-Message-State: AIVw111c8gY+p7lH1bkelc05wx7Qrczw3vfa7+7K3o7+RD+1doefQops nhp3YL3DD2hxIA== X-Received: by 10.223.168.110 with SMTP id l101mr2078535wrc.251.1500534923594; Thu, 20 Jul 2017 00:15:23 -0700 (PDT) Received: from [10.0.3.168] ([62.168.35.125]) by smtp.gmail.com with ESMTPSA id r199sm1287238wmd.11.2017.07.20.00.13.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 00:15:22 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 09:12:18 +0200 From: Jeff Tantsura To: Olivier Bonaventure , RTGWG , V6 Ops List Message-ID: <6C482CA8-5E8A-47B6-A76E-D3A47B7F70B3@gmail.com> Thread-Topic: Eating our own dog food : students solving IPv6 entreprise multihoming References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] Eating our own dog food : students solving IPv6 entreprise multihoming X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:15:27 -0000 Olivier, Thank you for sharing with RTGWG and looking forward to your future contributions! Cheers, Jeff -----Original Message----- From: rtgwg on behalf of Olivier Bonaventure Date: Thursday, July 20, 2017 at 08:54 To: RTGWG , V6 Ops List Subject: Eating our own dog food : students solving IPv6 entreprise multihoming Hello, During v6ops and yesterday's plenary, John Brzozowski encouraged us to use our own technologies for the IETF network with NAT64. This argument is valid for those who teach computer networks and since RTGWG is working on enterprise IPv6 multihoming, you might be interested in a recent experiment we did with our students. When students learn networking, they should not learn the current state of affairs but be prepared for the future since they'll only graduate in a few years. Several years ago, when IPv6 deployment was burgeoning, I decided to remove IPv4 from my networking 101 open-source textbook ( http://cnp3book.info.ucl.ac.be ). Since then, our students only learn IPv6 and results are excellent. Once they've learned IPv6, they can quickly understand how IPv4 works. Hopefully they'll see sunset4 during their career. After networking 101, some of your students attend an advanced networking course. This course combines theory with practice and usually students do practice after theory to illustrate the theoratical concepts. This year, we decided to flip the course and start from a practical problem to see how groups of students can address this problem with an open mindset and based only on what they've learned from networking 101 and the information that they will find on the Internet. During their carreer, they will be forced to learn on the spot anyway and they should better start early to look at rfcs, internet drafts and open-source implementations. The project given to the students was very simple. One of the engineers responsible for our (IPv4 mainly :-() campus network explained the architecture and the basic openrational principles that they use. Olivier Tilmans prepared a virtual machine that mimics our compus network (basically six routers) and we attached a few virtual machines to act as servers and clients. The only constraint that we was that the campus network had two upstream providers each delegating a different prefix to the campus network. Then, the students had to : - define an IPv6 addressing plan for their network - select, install and configure a routing protocol and make sure that it was working correctly - install and configure dhcp servers/ra to distribute addresses - install and configure DNS servers and resolvers - install and configure Diffserv-like traffic control - install and configure ssh and http servers - install and configure firewall services to protect the network - think about a solution to monitor the network [the number of tasks was chosen based on the number of students in each group] All student teams had an operation network at the end of the project. Since we believe in automation and open-source, we required them to automate their network from day one and several groups have released their entire project in open-source. From a teaching viewpoint, entreprise IPv6 multihoming is a very nice problem. To encourage other educators (and maybe also network engineers willing to continue to learn) to experiment with IPv6 entreprise multihoming, we have released all the software developed to create this project in open-source. You can find all the details at : https://github.com/UCL-INGI/lingi2142 You only need a Linux virtual machine provided by Vagrant to reproduce the experiment. The barrier to experiment with IPv6 entreprise multihoming is very low. Selected students projects with reports and code are available from this repository as well https://github.com/UCL-INGI/lingi2142/tree/master/student_projects I encourage you to have a look at the students' reports to see their final results: https://github.com/UCL-INGI/lingi2142/blob/master/student_projects/Group1/report-group1.pdf https://github.com/UCL-INGI/lingi2142/blob/master/student_projects/Group2/LINGI2142___Rapport_Groupe_2.pdf https://github.com/UCL-INGI/lingi2142/blob/master/student_projects/Group3/report.pdf Comments and feedback are welcome although the IETF mailing lists may not be the best place for discussions on software or teaching projects... Olivier Tilmans and Olivier Bonaventure -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From nobody Thu Jul 20 00:42:20 2017 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FDA126CD6 for ; Thu, 20 Jul 2017 00:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvGvEsrwhWh6 for ; Thu, 20 Jul 2017 00:42:19 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 C2505126557 for ; Thu, 20 Jul 2017 00:42:18 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id 33so10574445wrz.4 for ; Thu, 20 Jul 2017 00:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=BwTPWoRWNVLnLiB51RyQ4ueqjtFliBJfBnfy1CMQQSQ=; b=tIbsyr+UdMpdvlQY2LKqh+53bjvwDtBe0kvlhZYyyqUYi70clh86CF3r1i1p/VeYqi ESwi61/Lg/SUr79Ja+HN5JpLV1cJSsIo1/wwUVQ/BUhMh2mmTabOiInDsMmG/sh/xUpm Hbb8e8eb7a/csDzJJWmMQcvUrK+UDkcse8qke0eUopHFJLQnkliWXRl//V9ITlFBN6Eo hiBWJlkSlR4tRjqPP0rhH5XqKfrVXus0+Q9ZoY43ja5W2nKfbniF1WcddOJwcpWhIHR1 KfdhXCFKyN/Re4RsHmeJcL7Oyl6C0Ssd5fWDSA3MKhBCH3/fRDa74suBsusRi5uOxEFW gemw== 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:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=BwTPWoRWNVLnLiB51RyQ4ueqjtFliBJfBnfy1CMQQSQ=; b=gCBF6MGKAvCVwLmA3xeXV66ItFbfl4f0fKz2SuuvOtN2bXY78uJSG6mWUM2DzE1wP2 bngsirW9qXM4zIigeVbPDE2xcozRJeWDSmpenah/gbVyv3OFUXFYq5uv0hKpC2VolgMW uA3qR/nqrBub/eMEex9fGNaeBm4cxigL5c6YHWPbsNKCTYudnRZrrXETqOHvwyeEELAv yLMM/L5M6e9IYiZ2chWt8dXjNWN8Hig2BSdGIOgFYnQoXHf9oprRcwo2gpJqeiVUfnkY 81RAP5cw8TbFimToqkenWy6bHzEeGGvEOjEafabDoLkNlKxfPy+6PqWOPwl7Me2jxUFG EtrQ== X-Gm-Message-State: AIVw112faMY92GmfNIdeUMeEGxtaHKUhjOul3h3xIpFL0IYUhE1MNuag Y08IKsRtLXIrKw== X-Received: by 10.223.144.39 with SMTP id h36mr6594199wrh.114.1500536537384; Thu, 20 Jul 2017 00:42:17 -0700 (PDT) Received: from Russ ([88.208.89.131]) by smtp.gmail.com with ESMTPSA id 3sm4533749wrs.18.2017.07.20.00.42.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 00:42:17 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'james woodyatt'" Cc: "'IPv6 Operations'" References: <01e901d30045$8a502d10$9ef08730$@gmail.com> <9D75D02D-4ABA-4E08-A7E8-0410275DD2CF@google.com> In-Reply-To: <9D75D02D-4ABA-4E08-A7E8-0410275DD2CF@google.com> Date: Thu, 20 Jul 2017 03:42:14 -0400 Message-ID: <00a501d3012b$b4c3f900$1e4beb00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG6peZXN8/OQa2eYygfdBiuWfaUcQMz0jqHApuScHKiXpBiUA== Content-Language: en-us Archived-At: Subject: Re: [v6ops] I-D.ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:42:20 -0000 =20 > And another one is a RECOMMENDATION for configurable support for > =E2=80=9CReducing Energy Consumption of Router Advertisements=E2=80=9D = [RFC 7772]. Thanks! Will add... =F0=9F=98=8A Russ From nobody Thu Jul 20 01:21:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05699126557 for ; Thu, 20 Jul 2017 01:21: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 JLii39_g3slV for ; Thu, 20 Jul 2017 01:21:25 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFE4127337 for ; Thu, 20 Jul 2017 01:21:25 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id c74so9028492iod.4 for ; Thu, 20 Jul 2017 01:21: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=bzIcSr7GXGtOwtK1M8rzG/qO/gNQgKRZZC+PGt5FwHw=; b=KVOjIOyL4bhKLQ4493+fYMtd2hduZeBaM7PI9348DkwTm+MnU26j6n/FRpYDFhtgxx DtzHOTWu//JwJNiWrgrUIaSnEZdxHnggCblSs94PBuOgOTlx+0oLsmZ+xk//nzVIT21T WZ84A8UgYMOd9/WGdw95zcc0MGCm6c3tengMwlyPx7BniZGQa2ctbzWmsCiri1binN2g +SvWr2aAczL6vB/8kNPounMYWaeRazuBuo4EGjhsn7K+wwE4gHzO62Dbjzt+yLA4Po+r gnsFDdS/fNPxIUqixBKWsCdYknJxsJIgEaRRzz7L/hB/hipyHlz2HMDlPjjetHq0L77s 3kdA== 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=bzIcSr7GXGtOwtK1M8rzG/qO/gNQgKRZZC+PGt5FwHw=; b=EV1jEGtUBVvySZAQe8YQ5UThKjhKdH/v9NoNqR4l/5bksDkLvuqIPWFsZGO23R/UMD S9qj1QrTQXz87ftD4kumDDhISIvBZvijRh15gDThjeqLZZhFBL5LrSvtpMfNHMRjAl3x XpUK9CqZiyMF6/Dkzu1DyXRbyt61mKLAv5Lbr82pSaa1oXqUoggHJz9RNgq32fT9IR90 6BC9TiOQn4XPgnI+hnyHhFQHBJKB6yCqtZ1IHMNJzsZtinal3z/d5YgVcDvY8AgJVpoa igjUeGNhCLGFyJxDOqapl1S8QBqFxrSmXFK4s9gEKqjNrUxc6sGbltPWiNzPkWxbhNZj a1jQ== X-Gm-Message-State: AIVw113+lrEP2QdYl64IUOO8oSHXClfNXqQoZ7rAm5yEVKcs5hFXdR6S aQkuhxiJ9BEPF03wpHFc6wJP4bJo+YDJ X-Received: by 10.107.59.84 with SMTP id i81mr2728798ioa.72.1500538884769; Thu, 20 Jul 2017 01:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 01:21:03 -0700 (PDT) In-Reply-To: <20170720062751.GL45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 10:21:03 +0200 Message-ID: To: Gert Doering Cc: Brian E Carpenter , james woodyatt , IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c06537e33248d0554bb6fd2" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:21:27 -0000 --94eb2c06537e33248d0554bb6fd2 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 8:27 AM, Gert Doering wrote: > (And do not tell me that people would do DHCPv6 IA_NA/IA_TA *and* SLAAC > on the same network - technically you could, but nobody would do that, > given that it voids the reason *why* IA_NA/IA_TA are used: control, DNS, > etc - note I'm not saying "security") That's not true at all. There are (tens of) millions of home networks that do both IA_NA and SLAAC. SLAAC addresses provide ample address space and have robust privacy properties, and IA_NA addresses are can be useful for things like home servers that need stable addresses and dynamic DNS entries, such as home servers. --94eb2c06537e33248d0554bb6fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 8:27 AM, Gert Doering <gert@space.net> wrot= e:
(And do not tell me= that people would do DHCPv6 IA_NA/IA_TA *and* SLAAC
on the same network - technically you could, but nobody would do that,
given that it voids the reason *why* IA_NA/IA_TA are used: control, DNS, etc - note I'm not saying "security")

That's not true at all. There are (tens of) millions of home n= etworks that do both IA_NA and SLAAC.

SLAAC addres= ses provide ample address space and have robust privacy properties, and IA_= NA addresses are can be useful for things like home servers that need stabl= e addresses and dynamic DNS entries, such as home servers.
--94eb2c06537e33248d0554bb6fd2-- From nobody Thu Jul 20 01:30:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23D9127869 for ; Thu, 20 Jul 2017 01:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7YMAqbpEQIx for ; Thu, 20 Jul 2017 01:30:04 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC30C127337 for ; Thu, 20 Jul 2017 01:30:04 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 430DD41C2B for ; Thu, 20 Jul 2017 10:30:03 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0C7FF41C27; Thu, 20 Jul 2017 10:30:03 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 0973A35263; Thu, 20 Jul 2017 10:30:03 +0200 (CEST) Date: Thu, 20 Jul 2017 10:30:02 +0200 From: Gert Doering To: Lorenzo Colitti Cc: Gert Doering , Brian E Carpenter , james woodyatt , IPv6 Operations Message-ID: <20170720083002.GT45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RY95a4wZmkRDXyTc" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:30:07 -0000 --RY95a4wZmkRDXyTc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 20, 2017 at 10:21:03AM +0200, Lorenzo Colitti wrote: > On Thu, Jul 20, 2017 at 8:27 AM, Gert Doering wrote: >=20 > > (And do not tell me that people would do DHCPv6 IA_NA/IA_TA *and* SLAAC > > on the same network - technically you could, but nobody would do that, > > given that it voids the reason *why* IA_NA/IA_TA are used: control, DNS, > > etc - note I'm not saying "security") >=20 > That's not true at all. There are (tens of) millions of home networks that > do both IA_NA and SLAAC. That's an interesting statement. Which products do it that way today, out of the box? Those home network CPEs with v6 support I've seen so far do not do=20 IA_NA/IA_TA. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --RY95a4wZmkRDXyTc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAllwaggACgkQ31bAZeTO f8VBlxAAg+HQILjv5IXRWUL8lqvw6879GufoY7CTSLzTZNb4wfBgqkKOMjIYF78P 7YUb0lgjpawIR47rx0PFroA6w6blGcPVGRy359YfuCa7tEOes3kkd/SsySyDBYkQ E2JIMJUtKcR2awe5sz0Uk+g5ly3HQSlOtnLX+apnr4XwmBokJPgzzUpozP8QlTe+ 6onV9KzbymlvVMbEL9nugMqpAta5RGlQSPKm8p+nnHzKUyk48cela6WTd5GxwjfV oSVnbeglr/AcgdGegiXv6beIi+K6yhCyg2PD8t7HRGuB8GatGRGCyHjkXNqfA4kK CLNFYp7qbEPSYskB21iF94+QMDESs0NZ/CjuQy+FXMRHtWicUkflUfDJ7rdmTAI1 griXup+ulWdsbjjR/eARZIiInMqggf+P3AKU08KsNtquJV+HdCfUcNF62aqQ2ESA XlunnozG0baT8fKovMFIA8QZtY9mdmKOOQQca0r8zEm1rIhCapQIgLeZqJIiha/B tasjmFPmD8kwm3seQXzyWXuun6mgykZYSoWFixGnlzY/84XpSWQ7fM01drutqBxp OfZkthQlRa+xjRUn2yt8azd11aZ46ut7gSgHDmr53WEGaAK2JEjTTuT4IogcaUhj ouOJV3irIVCRbTaFD4q+ag5LUsGSEESNz8zuibUuQPwygitqf+4= =6htF -----END PGP SIGNATURE----- --RY95a4wZmkRDXyTc-- From nobody Thu Jul 20 01:33:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98647131B6A for ; Thu, 20 Jul 2017 01:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 Rtl01iONqMNV for ; Thu, 20 Jul 2017 01:33:40 -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 85A7D13147E for ; Thu, 20 Jul 2017 01:33:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 48DE3A2; Thu, 20 Jul 2017 10:33:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1500539618; bh=7R/JgcBQCx4rGWRPCbxfiqxQLllS/iuTBqRMbPpYGyo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UJWfb1VnFGf4b6gOzTUxrw4EWAt3gTihO46m4y9fxWCP7zbj5o8IZL/hR7sfcAM0v v8b9MUoQpqVlj2IoBjCN/UUlbMupl5VUFcjxOqF6+gzKUlA6z/sYuzraGR8aqn6a9o 7YJBsvKF/e1BBxsNAvq3lIzXDcBRZWqA50twCkx0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4640AA1; Thu, 20 Jul 2017 10:33:38 +0200 (CEST) Date: Thu, 20 Jul 2017 10:33:38 +0200 (CEST) From: Mikael Abrahamsson To: Gert Doering cc: IPv6 Operations In-Reply-To: <20170720062428.GK45648@Space.Net> Message-ID: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <20170720062428.GK45648@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:33:43 -0000 On Thu, 20 Jul 2017, Gert Doering wrote: > Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it This is not true. Deploying IA_NA gives you an address you can track and connect to the device on if you want to (if this is your device and you want to manage it for instance), then the device can use the SLAAC addresses for anything it needs more addresses for. I ran my home like this for a long time, when I had a router that actually supported DHCPv6 IA_NA. The one I currently use doesn't. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 20 01:46:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4C113150C for ; Thu, 20 Jul 2017 01:46: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 KOOXEK82oYhv for ; Thu, 20 Jul 2017 01:46:31 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 0B6FB131B38 for ; Thu, 20 Jul 2017 01:46:31 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id h199so12858420ith.0 for ; Thu, 20 Jul 2017 01:46: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=Co4uwmoNOvtESh7RsJsDCuXYULXvOalag6ljqtbN0bc=; b=MmO2s5jHjjWgi+kxjHM+fFfOl//b1WcrOgllfsXzrG3+Lpo6+rBN9uvfjfGStF8pSm swIdGb1chWxtNk4WUW/zv+xcpx8zoR7SG5+12r0gNVklhJigLbFW/AS5DFxAcS/ZhL8r NzjM5wPiC+F2o8YrFx6EUiVtZnOA1EDoYTwsnKJCvLX4cH8p0z6g7HeGwcYOIOGlK3Ye GvqXycJ8PSyEVMIRbKRThzaBsc4FIaEOASanrJAuiQXTGLH70lA0quIDtPQkoSnxLFRO vyhOSQ8Ws96PZE2YcwQFa28ms3vZ3C+QkgSfg7o0vS9IONeqazeGKnuUDT8K+n1RDI7y oWng== 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=Co4uwmoNOvtESh7RsJsDCuXYULXvOalag6ljqtbN0bc=; b=QjxfysFwMs+5n1jQYZJeVjklTWuUu/QDFPTTGlAQB8srosggz22uvY0GkChG+KAF2c Kueo0tuC+gj8l38Z9Edvzaf93T3Fbg3IsyFSdXGUWu26Q95kOBsymmWP1DzMlx8c7pFf bVUsIfdxEhkLvExttYPB/YaRCsAxmEt7YjpReV+HC38HBR+FaOCKry/sX6WIEfuG2jR5 +t2MqDdGxvFgEO3onVkSYWZDw24ZgZauX+LL13xhLmkTeZIzayq98gC2v8qtmtuU1MK6 6pYtRb8TdkcZyI5lfXiOEjK6isNNgRBZbb7O8aeOWsVV5s4LIHR+9oi+niEbB09hS52/ rkZg== X-Gm-Message-State: AIVw112jsBYOlCRTQcD1CkjwL3mF42UbqfKe+4jQIty6m9HCCbUjJW0E H2lG93HZoLVnEToYN1Sbg0u6TOlHiRiC X-Received: by 10.36.22.17 with SMTP id a17mr2673454ita.40.1500540390075; Thu, 20 Jul 2017 01:46:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 01:46:09 -0700 (PDT) In-Reply-To: <20170720083002.GT45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 10:46:09 +0200 Message-ID: To: Gert Doering Cc: Brian E Carpenter , james woodyatt , IPv6 Operations Content-Type: multipart/alternative; boundary="001a11437ea8ec88e20554bbc8ac" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:46:34 -0000 --001a11437ea8ec88e20554bbc8ac Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 10:30 AM, Gert Doering wrote: > That's an interesting statement. Which products do it that way today, > out of the box? > It depends on the vendor, of course. AIUI all of Comcast's home routers do DHCPv6 as well as SLAAC and DHCPv4. IIRC my off-the-shelf d-link home routers supported IA_NA as well. --001a11437ea8ec88e20554bbc8ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 10:30 AM, Gert Doering <gert@space.net> wro= te:
That's an interesting statement.= =C2=A0 Which products do it that way today,
out of the box?

It depends on the vendo= r, of course. AIUI all of Comcast's home routers do DHCPv6 as well as S= LAAC and DHCPv4. IIRC my off-the-shelf d-link home routers supported IA_NA = as well.
--001a11437ea8ec88e20554bbc8ac-- From nobody Thu Jul 20 01:49:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9689412ECC3 for ; Thu, 20 Jul 2017 01:49:21 -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 WMxzpLvriJMm for ; Thu, 20 Jul 2017 01:49:20 -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 99DEF129B40 for ; Thu, 20 Jul 2017 01:49:19 -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 v6K8nHCi038118 for ; Thu, 20 Jul 2017 10:49:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 482BB206EA8 for ; Thu, 20 Jul 2017 10:49:17 +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 359D12014D1 for ; Thu, 20 Jul 2017 10:49:17 +0200 (CEST) Received: from [132.166.84.225] ([132.166.84.225]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6K8nEFd029056 for ; Thu, 20 Jul 2017 10:49:15 +0200 To: v6ops@ietf.org References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> From: Alexandre Petrescu Message-ID: <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> Date: Thu, 20 Jul 2017 10:49:14 +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: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:49:22 -0000 Le 20/07/2017 à 10:21, Lorenzo Colitti a écrit : [...] > SLAAC addresses provide ample address space and have robust privacy > properties Do you mean DHCP-Address(IA_NA) does not have robust privacy properties? I think it does - it can deliver multiple addresses to Client, each from a distinct /64 prefix. That would be more privacy than SLAAC which does vary the 64 IID but within same prefix. Alex From nobody Thu Jul 20 01:50:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D0129B40 for ; Thu, 20 Jul 2017 01:50: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 6U_Q37mbrn7o for ; Thu, 20 Jul 2017 01:50:13 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D77127735 for ; Thu, 20 Jul 2017 01:50:13 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=42738 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dY79t-0007Wt-SP; Thu, 20 Jul 2017 10:50:09 +0200 Date: Thu, 20 Jul 2017 10:50:09 +0200 From: Tore Anderson To: Gert Doering Cc: Lorenzo Colitti , james woodyatt , IPv6 Operations Message-ID: <20170720105009.34003050@echo.ms.redpill-linpro.com> In-Reply-To: <20170720083002.GT45648@Space.Net> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:50:15 -0000 * Gert Doering > On Thu, Jul 20, 2017 at 10:21:03AM +0200, Lorenzo Colitti wrote: > > That's not true at all. There are (tens of) millions of home networks t= hat > > do both IA_NA and SLAAC. =20 >=20 > That's an interesting statement. Which products do it that way today, > out of the box? LEDE/OpenWrt/HomeWrt at least. =46rom what I've heard the DHCPv6 stuff is there mostly to support automatic host name discovery, but it also has the effect of facilitating prefixes longer than /64. At least HomeWrt will do that if there are too few /64s to number all the links in the Homenet. There are Norwegian ISPs that hand out /62s and /60s to their subscribers, so this can be a real concern. That said, for me having the additional DHCPv6-assigned address in addition to the SLAAC one has been a net negative, since it doesn't reconfigure along with the link prefix following a PD change (but nevertheless tends to be preferred for outbound traffic). Maybe this would have been better if it was a ULA rather than a GUA though, I don't know. When it comes to the enterprise data centre networks I operate, on the other hand, I do absolutely need DHCPv6 for network booting. However I do not really need it once the system has booted, SLAAC serves my needs fine then. So I'm actually considering setting up my DHCPv6 server so that (by default) only the PXE client arch types will get addresses assigned through DHCPv6. Tore From nobody Thu Jul 20 01:57:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4A0129562 for ; Thu, 20 Jul 2017 01:57:22 -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 4EX1DG4QRlln for ; Thu, 20 Jul 2017 01:57:20 -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 7EBC0126B72 for ; Thu, 20 Jul 2017 01:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500541038; x=1501145838; 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=ao9W/DWhqgR/DkUtKTYwb4O4z PsTL3uzRWONRrBwR8c=; b=KZm/IFp0YDHjx62CmcRRJqV+nUS8NjjwD2483cTgM CdD4fqtvO08tDoD3it2lBS2OzLcisfWQb2oa8gL1zZ/Q9SpikL6ACbuOoYjB4Itl veUThphCctnRaa2xScZV8l521WgkFVw3oUAwPm8VhnyKhsDG+77Ehf5VrMJX9bqH 6s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=PJoM4CVDvX2rwXFjTBe8XYaC3TpfE1mEg4smnit/Dww8mpXwEiSR5isGdCUC VEr/X1lhO5C6/GVJv3qH2AkHJLev/RqunjbENhGtuEtv9MJ1NiH43jjlU BEu0ZbWMVTIMW4bqQYLzaxvF9Ce/wDfqc6C49UDjnLkL12dPhZO1dA=; X-MDAV-Processed: mail.consulintel.es, Thu, 20 Jul 2017 10:57:18 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 20 Jul 2017 10:57:17 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005481575.msg for ; Thu, 20 Jul 2017 10:57:17 +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:170720:md50005481575::r2eq9h/yVyQNc8M0:00007FsU X-MDRemoteIP: 31.133.159.135 X-Return-Path: prvs=137477960e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 10:57:14 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> 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: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:57:23 -0000 I can confirm that. I=E2=80=99ve tested many CPE products/vendors with IPv6 support (in additio= n to OpenWRT and LEDE), and they have both enabled by default. I=E2=80=99ve not collected a =E2=80=9Clist=E2=80=9D of them, but probably t= he figures that I=E2=80=99ve on the top of my head (and guess most of us) i= s more than 12-15 different well-known vendors. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Lorenzo Colitti Responder a: Fecha: jueves, 20 de julio de 2017, 10:47 Para: Gert Doering CC: james woodyatt , IPv6 Operations Asunto: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-= addr-update-00.txt On Thu, Jul 20, 2017 at 10:30 AM, Gert Doering wrote: =20 That's an interesting statement. Which products do it that way today, out of the box? =20 =20 =20 It depends on the vendor, of course. AIUI all of Comcast's home routers= do DHCPv6 as well as SLAAC and DHCPv4. IIRC my off-the-shelf d-link home r= outers supported IA_NA as well. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 Jul 20 02:07:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE604131566 for ; Thu, 20 Jul 2017 02:07: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 mymA3kO3LzoF for ; Thu, 20 Jul 2017 02:07:53 -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 A3D7612ECF0 for ; Thu, 20 Jul 2017 02:07:53 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 123so12151858pgj.1 for ; Thu, 20 Jul 2017 02:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Gl5bxElcK0gh0M4Jwy8eJOngyMcXz938QSglSmI26g=; b=VRLEszziYHsSl0DejdnQ6wE94MBC748LxC/IUun9lOnNymOFwN4hxF/GhKWzQLzdBI pp/0+6bSLQn7zLU/81EXBSSjSgzKFy+u6R5Ksy4PKD7gqZ2nUkQBWFMgUVJK7p662/Vn vuhnUVBDQ5EH5U2y3MmJK2CBfS4cYkn8jaoHJ7yLwIK73qUHtaTLnyW/0TYSHlhWi7ih wWklb6BN69c7y6JEm7RvL1KKHD6jXe6I4SBqaDirLjBQAPXHz7hHgS6cHJfaQ6nxLrXt OvS+7BNZR9fSI54CZKg548UcXlP9bLFx3mlxNc2AsC5oFvJAORvv5J4fq6BEA+9Af8I5 S3fg== 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=7Gl5bxElcK0gh0M4Jwy8eJOngyMcXz938QSglSmI26g=; b=Gf+wIxbwaN1F+/dxtU1Jh0bdCENjDaXRCjfZoQbptYKLxYyNuTy6MRCJIb2nYzeZ0+ 4nmlYeFxO8Db2Ilm5KeVS/XQgWON6v0S6WVtDblv3ZZx6WcjDWGSQLn8z9PoktWKC4dM sf78kQcJgclGRESk4Hx6C95KQiBJTcKv8VxTIodY+g8zM39F4OV8udl8She6pQsgAOtp swtnbl7WZ26UBOeO4i+L7ZE7s9SKrlGjz6T5qgt12TIzklHVEzygVwi/nFeWqzqoIeQc /jd/I04AQjRU2DpA6p7Vltcb9+WVuc1lExmj7K7pRU9BEjQ2q+46UJHX2JOB2IffuVZX KgLQ== X-Gm-Message-State: AIVw113bYG0D8YKyMnJ8b8KwPg6SmfKlVAoUFo9xD6eBD0lI0jNDiwZe EPcEpfIIbh66dOGOGNKOQ+39uaBQTbot X-Received: by 10.98.7.87 with SMTP id b84mr3224982pfd.216.1500541673259; Thu, 20 Jul 2017 02:07:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 02:07:12 -0700 (PDT) In-Reply-To: <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> From: Ted Lemon Date: Thu, 20 Jul 2017 11:07:12 +0200 Message-ID: To: Alexandre Petrescu Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a1143ccc467d61d0554bc15b7" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:07:56 -0000 --001a1143ccc467d61d0554bc15b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alexandre, in order for that to be the case it must be true that the DHCP server is actively working to arrange for it to be the case that clients get addresses with good privacy characteristics. What we are seeing in the field is that addresses are being allocated out of very small ranges, with no concern given to privacy. So as a practical matter, the advice in the RFC is the correct advice. It's possible that we could change that, but I don't see the point. It's fine that DHCP servers work the way they do, as long as clients can also do SLAAC. DHCP simply does not address this use case, nor need it do so. On Thu, Jul 20, 2017 at 10:49 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 20/07/2017 =C3=A0 10:21, Lorenzo Colitti a =C3=A9crit : > [...] > >> SLAAC addresses provide ample address space and have robust privacy >> properties >> > > Do you mean DHCP-Address(IA_NA) does not have robust privacy properties? > I think it does - it can deliver multiple addresses to Client, each > from a distinct /64 prefix. That would be more privacy than SLAAC which > does vary the 64 IID but within same prefix. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1143ccc467d61d0554bc15b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alexandre, in order for that to be the case it must be tru= e that the DHCP server is actively working to arrange for it to be the case= that clients get addresses with good privacy characteristics. =C2=A0 What = we are seeing in the field is that addresses are being allocated out of ver= y small ranges, with no concern given to privacy. =C2=A0 So as a practical = matter, the advice in the RFC is the correct advice.

It&= #39;s possible that we could change that, but I don't see the point. = =C2=A0 It's fine that DHCP servers work the way they do, as long as cli= ents can also do SLAAC. =C2=A0 DHCP simply does not address this use case, = nor need it do so.

On Thu, Jul 20, 2017 at 10:49 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 20/07/2017 =C3=A0 10:21, Lorenzo Colitti a =C3=A9crit :
[...]
SLAAC addresses provide ample address space and have robust privacy propert= ies

Do you mean DHCP-Address(IA_NA) does not have robust privacy properties? =C2=A0 I think it does - it can deliver multiple addresses to Client, each<= br> from a distinct /64 prefix.=C2=A0 That would be more privacy than SLAAC whi= ch
does vary the 64 IID but within same prefix.

Alex

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

--001a1143ccc467d61d0554bc15b7-- From nobody Thu Jul 20 02:10:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A2F131A81 for ; Thu, 20 Jul 2017 02:10:16 -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 xHoPPoqSuhYx for ; Thu, 20 Jul 2017 02:10:10 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298EC131892 for ; Thu, 20 Jul 2017 02:10:10 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m88so837943iod.2 for ; Thu, 20 Jul 2017 02:10: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=/hnCHbvHHNPTxGBYFFn2hT3ta/lNIEQzUNQW/36kKi8=; b=oxBvOp/8gc4QOO3+ZZBV8OdHh+HuE1/Ee60d4cMPTtUyUgq/5v11vdpdw1yUESdBpf HTucGjbE5MBtqj8lcz2Gn9rTWnbvZ7ErroaebEPR75n6P7fWNWzpDkXgJ2Mtsn7+ZoMH V9yD3HvQao1mRBSDoT9Pi0PSKKAQmilP6yxeE/MVExO9LYJhUyNlq6IHYPUyZwhr/eHZ gq3YzO6iEMRU/Ho2PbsCNHS9TnH9t/5KOsSVpJzl+lhUrbi0Q3XwXNCK+Qtb/iarRUAF LuuTWjvQIaETuer9Osya2a4ks6SDDmu4vcOJzyYDSoHPreFLJCAW6+5qwPjKJKseYoGD Sfrg== 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=/hnCHbvHHNPTxGBYFFn2hT3ta/lNIEQzUNQW/36kKi8=; b=eT/lkfMvREGs6vPnzXuiKm8pAKYB82t/9mGGkB+0K1USzzhCA+hDX203ac2VDINstw LtGMaXNVeTNrqBwh2YrK4F3ZksQnRGlDzCQycybC5wIbyNoyMCziuMGbXVXwR+V4GgvQ RVb5Gb584JK7O2UlEwLCyXK0Use+Qm9ZvaLTsveaGZKGl27up8eSfkyVKGrumI476NWo su1jcuBFb5RBoYeL34HcJKHzYBD0JW14xmXwe8BS2ZPOP2sdcMWC7VSIPDKd7dz8zEOT BSqNzbo5+hr539al7rUBG9hxVHXjGJI/aNe2mGsTjQVws3JuVNkEAghbRLhS/HQb5aEe rYvQ== X-Gm-Message-State: AIVw112VPDAokY6DJOxHsSkcUKQ7yRGakXDz/R1KFcl8Mp+UF3c9Mzon Wlnr8LvCTN0bPBCV8fgON1WHgU73ZkjV X-Received: by 10.107.34.18 with SMTP id i18mr2618380ioi.185.1500541809099; Thu, 20 Jul 2017 02:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 02:09:48 -0700 (PDT) In-Reply-To: <20170720105009.34003050@echo.ms.redpill-linpro.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 11:09:48 +0200 Message-ID: To: Tore Anderson Cc: Gert Doering , james woodyatt , IPv6 Operations Content-Type: multipart/alternative; boundary="001a1140c2a8814f360554bc1d2a" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:10:16 -0000 --001a1140c2a8814f360554bc1d2a Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson wrote: > That said, for me having the additional DHCPv6-assigned address in > addition to the SLAAC one has been a net negative, since it doesn't > reconfigure along with the link prefix following a PD change (but > nevertheless tends to be preferred for outbound traffic). Maybe this > would have been better if it was a ULA rather than a GUA though, I > don't know. > That's an excellent point. More in general I'd say that IA_NA is a net loss in *any* network where addressing can unexpectedly change, such as a tethering hotspot, a small enterprise, or even a medium enterprise using PA addresses. For exactly this reason. (In fact - I don't think we even know how to make that sort of thing at all without NAT.) I'm sure many will just say that I'm biased, but think about it - if you can't tell the hosts that something has changed, then how do you deal with routing and renumbering changes? Even if hosts were to support DHCPv6 reconfigure, which they don't, how do you reconcile that with the assertion that the value proposition is that DHCPv6 provides centralized management? How do you do that at scale? Does the DHCPv6 server need to know about all topology changes so it can issue appropriate RECONFIGUREs? What if the topology change was such that the global address of the DHCPv6 server is no longer valid due to renumbering? And so on. --001a1140c2a8814f360554bc1d2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 10:50 AM, Tore Anderson <tore@fud.no> wrote:=
That said, for me having the additional = DHCPv6-assigned address in
addition to the SLAAC one has been a net negative, since it doesn't
reconfigure along with the link prefix following a PD change (but
nevertheless tends to be preferred for outbound traffic). Maybe this
would have been better if it was a ULA rather than a GUA though, I
don't know.

That's an excellent= point.

More in general I'd say that IA_NA is = a net loss in *any* network where addressing can unexpectedly change, such = as a tethering hotspot, a small enterprise, or even a medium enterprise usi= ng PA addresses. For exactly this reason. (In fact - I don't think we e= ven know how to make that sort of thing at all without NAT.)

=
I'm sure many will just say that I'm biased, but think a= bout it - if you can't tell the hosts that something has changed, then = how do you deal with routing and renumbering changes? Even if hosts were to= support DHCPv6 reconfigure, which they don't, how do you reconcile tha= t with the assertion that the value proposition is that DHCPv6 provides cen= tralized management? How do you do that at scale? Does the DHCPv6 server ne= ed to know about all topology changes so it can issue appropriate RECONFIGU= REs? What if the topology change was such that the global address of the DH= CPv6 server is no longer valid due to renumbering? And so on.=C2=A0
--001a1140c2a8814f360554bc1d2a-- From nobody Thu Jul 20 02:23:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD97D131897 for ; Thu, 20 Jul 2017 02:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Occs1YNwECT0 for ; Thu, 20 Jul 2017 02:23:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE6B126B72 for ; Thu, 20 Jul 2017 02:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5895; q=dns/txt; s=iport; t=1500542585; x=1501752185; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2RG6PqjAaiimliPLFpeCLpo3Xbx3gmMK0xoQIEWb9Bs=; b=e8TmcpJA4jj9E0lG3pNY0CWNVC2KuXATphGwtJbcgqNvnoPFmks5fDjt wJYy1ECiQAS+rXbIU+6vF4ic0B+M7TEPTzaQ7DD7RhsmWbx+yiZkbW2A6 tGZxB5WT5QQAYeyW5uvsZH8Rdp72AGWwuGKWtMpkfJxgipa9Sv0Dbb6Xk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAADodHBZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRSOC5FnkFmFLIEyA1whAQqFGwKDcj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEBAQIBAQFsAgcCEAIBCD8HJwsUEQIEDgWJS1wIELM1iyABAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYMohS0sgnmEVINZgjEFnz4ClBiCDJAoiUiMFQEfOEw+dRV?= =?us-ascii?q?JEgGFABwZgU52iXoBAQE?= X-IronPort-AV: E=Sophos;i="5.40,383,1496102400"; d="scan'208,217";a="272265221" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2017 09:23:04 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6K9N43Y007301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 09:23:04 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 04:23:03 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 04:23:03 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti CC: Tore Anderson , james woodyatt , "IPv6 Operations" Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt Thread-Index: AQHS/5m/vXdeJwPr90aX1hLwXQdtQqJbMdGAgAACOoCAAReuAIAAS4SAgAAfoYCAAAKDAIAABZ+AgAAFfQD//6/jEQ== Date: Thu, 20 Jul 2017 09:23:03 +0000 Message-ID: <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.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 Content-Type: multipart/alternative; boundary="_000_7776E80FEBBF4E3094A5E6570AB8B84Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:23:10 -0000 --_000_7776E80FEBBF4E3094A5E6570AB8B84Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> What if the topology change was such that the global address of the DHCP= v6 server is no longer valid due to renumbering? Address of DHCPv6 server does not matter - it can change. Clients generally= never directly address packets to its address. They multicast to fe02::1:2= . Also, 3315bis recommends that clients refresh information via dhcp when a n= etwork change occurs (such as new prefixes in an RA appear). - Bernie (from iPhone) On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti > wrote: On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson > wrote: That said, for me having the additional DHCPv6-assigned address in addition to the SLAAC one has been a net negative, since it doesn't reconfigure along with the link prefix following a PD change (but nevertheless tends to be preferred for outbound traffic). Maybe this would have been better if it was a ULA rather than a GUA though, I don't know. That's an excellent point. More in general I'd say that IA_NA is a net loss in *any* network where add= ressing can unexpectedly change, such as a tethering hotspot, a small enter= prise, or even a medium enterprise using PA addresses. For exactly this rea= son. (In fact - I don't think we even know how to make that sort of thing a= t all without NAT.) I'm sure many will just say that I'm biased, but think about it - if you ca= n't tell the hosts that something has changed, then how do you deal with ro= uting and renumbering changes? Even if hosts were to support DHCPv6 reconfi= gure, which they don't, how do you reconcile that with the assertion that t= he value proposition is that DHCPv6 provides centralized management? How do= you do that at scale? Does the DHCPv6 server need to know about all topolo= gy changes so it can issue appropriate RECONFIGUREs? What if the topology c= hange was such that the global address of the DHCPv6 server is no longer va= lid due to renumbering? And so on. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_7776E80FEBBF4E3094A5E6570AB8B84Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
>> Wha= t if the topology change was such that the global address of the DHCPv6 ser= ver is no longer valid due to renumbering?

Address of DHCPv6 server does not matter - i= t can change. Clients generally never directly address packets to its addre= ss. They multicast to fe02::1:2.


Also, 3315bis recommends that clients refres= h information via dhcp when a network change occurs (such as new prefixes i= n an RA appear).

- Bernie (from iPhone)

On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson = <tore@fud.no> wrote:
That said, for me having the additional DHCPv6-assigned address in
addition to the SLAAC one has been a net negative, since it doesn't
reconfigure along with the link prefix following a PD change (but
nevertheless tends to be preferred for outbound traffic). Maybe this
would have been better if it was a ULA rather than a GUA though, I
don't know.

That's an excellent point.

More in general I'd say that IA_NA is a net loss in *any* network wher= e addressing can unexpectedly change, such as a tethering hotspot, a small = enterprise, or even a medium enterprise using PA addresses. For exactly thi= s reason. (In fact - I don't think we even know how to make that sort of thing at all without NAT.)

I'm sure many will just say that I'm biased, but think about it - if y= ou can't tell the hosts that something has changed, then how do you deal wi= th routing and renumbering changes? Even if hosts were to support DHCPv6 re= configure, which they don't, how do you reconcile that with the assertion that the value proposition is tha= t DHCPv6 provides centralized management? How do you do that at scale? Does= the DHCPv6 server need to know about all topology changes so it can issue = appropriate RECONFIGUREs? What if the topology change was such that the global address of the DHCPv6 server = is no longer valid due to renumbering? And so on. 
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_7776E80FEBBF4E3094A5E6570AB8B84Aciscocom_-- From nobody Thu Jul 20 02:43:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A478A13157A for ; Thu, 20 Jul 2017 02:43: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, 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 G1vo68sGGHGv for ; Thu, 20 Jul 2017 02:43:18 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E2712ECCB for ; Thu, 20 Jul 2017 02:43:18 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h199so13442109ith.0 for ; Thu, 20 Jul 2017 02:43:18 -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=fSBADIPEMGm7xf4IUgfYgz7YTfdRTzoiYQN3s63lAkM=; b=XoyeHXWzcojhQ5m53n0Fj0i1ZZUbAcmfMBSunXpcgCepKB9MOvGTuoY/2cs/smfXA4 jS0eqajXU8ROQOP3TfW0tS8UZmU5n1aUaJmwuGFLMWymBAR+cH3GY035LB83tRQFBys7 5JFLujc/OVcboEaUxWZW4g8cfMa4L9UCrSl/pRfb0djXAOxeoTv5tdwRRIs+sw2R1RVh zCveq+0DhGTflaXeID9zRmXSuxgcAVu8HCDP3VU4QbdfgVgF5vuRarp6hO+W5AvFQLGl MWjC3rjiI+T9iuX1rDA0kMZW3sb1hUAj9zG7MHZLXj4gCnc97wlw6yxXaRawROHRUT8K BvZw== 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=fSBADIPEMGm7xf4IUgfYgz7YTfdRTzoiYQN3s63lAkM=; b=pTFvXbYzYgJzx7AbZ0LEvSg5OaL9uBn/64ESvdn2GW7Gzif38iYKIAia0Zt7eo4wt4 F4l3kvm/C2xi7c16hxV1utO1cbHE9rinJqfPtSzF+Y/0pxP0zkPEaDCG659iFCcY1n/P 7/trJLaMqSSTrr9SEyZCqduu8aPCMAGpgm9T5bVZDJDnXiahStJ2iG2OK/s35uiSN4cO /+zR/2rroEIphTCsr2tqRYYSWvSycQvNDIHfiHPyJ9s7fBP144pLpE3Bzw8B47Yjb38u frGwh+eQxzxL55iwWUCvBrKmluGsTG74XbiyZk1je30XViMgIRPw7/U1ajq/CXzbzhe4 song== X-Gm-Message-State: AIVw113UzfweO8DIbB6LCxbcCohuWEcfhdxfLfo6DVtysJr3IKsdPyPs hDsGUGDmFuaCmF5dG7uWGMgJ9ZQnh8k7 X-Received: by 10.36.198.133 with SMTP id j127mr2760940itg.142.1500543797302; Thu, 20 Jul 2017 02:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 02:42:56 -0700 (PDT) In-Reply-To: <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 11:42:56 +0200 Message-ID: To: "Bernie Volz (volz)" Cc: Tore Anderson , james woodyatt , IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c07dd0602ad4b0554bc94bc" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:43:19 -0000 --94eb2c07dd0602ad4b0554bc94bc Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 11:23 AM, Bernie Volz (volz) wrote: > >> What if the topology change was such that the global address of the > DHCPv6 server is no longer valid due to renumbering? > > Address of DHCPv6 server does not matter - it can change. Clients > generally never directly address packets to its address. They multicast to > fe02::1:2. > Surely the RECONFIGURE is not multicast, but unicast from server to client? > Also, 3315bis recommends that clients refresh information via dhcp when a > network change occurs (such as new prefixes in an RA appear). > 3315bis-09 does not recommend this, it says the client MAY do it and MUST rate-limit it (with an example rate-limit of one every 30 seconds). In any case, the server still needs to keep track of all topology changes in order to give a correct answer. --94eb2c07dd0602ad4b0554bc94bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 11:23 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
>> What if = the topology change was such that the global address of the DHCPv6 server i= s no longer valid due to renumbering?

Address of= DHCPv6 server does not matter - it can change. Clients generally never dir= ectly address packets to its address. They multicast to fe02::1:2.

Surely the RECONFIGURE is not multicast= , but unicast from server to client?
=C2=A0
Also, 3315bis rec= ommends that clients refresh information via dhcp when a network change occ= urs (such as new prefixes in an RA appear).
3315bis-09 does not recommend this, it says the client MAY do = it and MUST rate-limit it (with an example rate-limit of one every 30 secon= ds).

In any case, the server still needs = to keep track of all topology changes in order to give a correct answer.
--94eb2c07dd0602ad4b0554bc94bc-- From nobody Thu Jul 20 02:47:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E135E13157A for ; Thu, 20 Jul 2017 02:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szBp19VvDtXw for ; Thu, 20 Jul 2017 02:47:50 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55170129432 for ; Thu, 20 Jul 2017 02:47:50 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id h199so13261156ith.1 for ; Thu, 20 Jul 2017 02:47: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=R/dpDz9Vu2q8SpKd1MtiBTvFLd43vd4R1/aXGx0ncxU=; b=fTVyhDklGtzeb3+2WXq4Ra+3E4lp98QJr6diMcNXbBX/Hvv4ehdQNAGJBaZh94zB0t yM5D1+WX453cWtRAmnpHJr6xmFczQTK3xDsWKM0rarjdbIC4IAxJWMa1pQqmredqhIeN UOxIoFRkIpU05YnR6q4WClq88sWjVO5WWWIMbl+p2rBmucX9codHVeldiJrG9g+F5kWt 2eJlBIQUskoB+J5VF75VwmjsPkS5cuDkRM8kNYMqHW+8PnmFxd1NGiA2XhBWaKV/RV4c VWfWidV1xpQyFDB5nP2MLvYhUSGIafTOv2i4e39lwtM4bXaRQf5YedVNsggbDQ0SDBsm qZyQ== 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=R/dpDz9Vu2q8SpKd1MtiBTvFLd43vd4R1/aXGx0ncxU=; b=AYeLt77tRwoMiROdVw7U1r8jih7kqClmYmq8YIjseird59JCNki0nXFn4CjaTyNo0i Bffp9KBxy/oAtmtQi8J8Sqg+EWlTY2gAHJP4RuqQMOo3v608IooLASJJvrfrdQOhRUrE /2zKi0JL9SFu11ESaa7M7tz+Sdww9nDyZLDAQxxLfIPYoB2NqoWI90aaBaTmSdgU+yD7 x83cxogHvxhUj8ickeO+8/zDSMiss0trLhyyZP9pecH9jCqJRYu8eszQuekQ1I/MW+Z1 jri3GEQL/UGwkTRpVt9Va2wSFgXBfioyUFuM71v6YQudNM4Kt4I1idALo9pRJgwbm+IB LUVQ== X-Gm-Message-State: AIVw113CK8q+8B4LKOWvB4ILdoayaW//PqxJ+Zv3Qn2gExVmgOK/u9gt KXrbEVB/iMmlbz7cJFeqa7aP/g29pA== X-Received: by 10.36.95.131 with SMTP id r125mr2775165itb.36.1500544069728; Thu, 20 Jul 2017 02:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 02:47:28 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> From: Jen Linkova Date: Thu, 20 Jul 2017 19:47:28 +1000 Message-ID: To: Lorenzo Colitti Cc: Tore Anderson , james woodyatt , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:47:52 -0000 On Thu, Jul 20, 2017 at 7:09 PM, Lorenzo Colitti wrote: > On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson wrote: >> >> That said, for me having the additional DHCPv6-assigned address in >> addition to the SLAAC one has been a net negative, since it doesn't >> reconfigure along with the link prefix following a PD change (but >> nevertheless tends to be preferred for outbound traffic). Maybe this >> would have been better if it was a ULA rather than a GUA though, I >> don't know. > > > That's an excellent point. > > More in general I'd say that IA_NA is a net loss in *any* network where > addressing can unexpectedly change, such as a tethering hotspot, a small > enterprise, or even a medium enterprise using PA addresses. For exactly this > reason. (In fact - I don't think we even know how to make that sort of thing > at all without NAT.) Exactly. The section 4 of https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01 discusses in many details SLAAC vs DHCPv6 for various network topology change scenarios. It does not seem to be feasible to make DHCPv6-only work except for very specific case of 'the router is acting as DHCPv6 server' and I'm not sure it scales very well. -- SY, Jen Linkova aka Furry From nobody Thu Jul 20 03:02:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278613157A for ; Thu, 20 Jul 2017 03:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xek3Yh_vcQHi for ; Thu, 20 Jul 2017 03:02:12 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A6A127735 for ; Thu, 20 Jul 2017 03:02:11 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id a62so13724910itd.1 for ; Thu, 20 Jul 2017 03:02:11 -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=lEEjFDQ25YNdP0gt4OG4AVAfDhMFDryh142lbn3M0fg=; b=Q8A3BDwvGJbBHH0nuVqbN0/ksEXT71lqYWZGUiMdM8Vx8NpTv5HLfdF0LHYJOJw4Bb 4Xf6/CQNSaky8zc0/81eUTtMLbW8EmTgJJfq6Qi6zeHujt6thrFHd2Q4+uyvZ0NON4RN ylcdWp4rIWruesinITvIlD4w1tKqcxlSRzCWGpLPVJ4l+ITOfTuBvY2138xxTfshsh6t sn+5UGOfbrP+7PAVzgzziniBwHoK3efBTNNvcljyXcuX8p5o8pqyGa+Iifq2QHQpLnG/ zsjLede8KtCa/dyXgQaS97Wt6ttl9wb9FFbQfnxj3HqItTSS9tVG3h6PP0mmr6msSUZC HReA== 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=lEEjFDQ25YNdP0gt4OG4AVAfDhMFDryh142lbn3M0fg=; b=BobzBsUCFPcfOM8M0mKuSdiYJCfCttckV3OZr3pGPl3A5/3wWo+RoUkql6EEaQmEtP CYOO1ywm/K/mFoAPnh+pmGOhvKgwsN4//BGM+uavivVuO1ul0U1Jyt1hGafF0ZoR4iDk c8IydPTqmOTShNYMxaOvfGk5/R7r8c7Up+9mQykTi//DkvIfepgpLnu5k8hmnhsbJIs8 t//Sxixuhl6ZW+O4kBAJC4CSbT0y2ZEnms1tEdB5vDsbNGEE7Dzw9plvQsg6d9CCBSKa bBD91iSD5ZisC+osLe/MmH0A6/hY+Xdxwpf6FHa8k+oyMqEVOF2LdzMqPg4i/g2RxA/m IIJA== X-Gm-Message-State: AIVw110vswl0dr3ptd+7henK2h4sJXL1dJOzwF7Leont3l4ILx+0zgVA rMRvPNtIcbXjC7djspSkiGxGL3J64g== X-Received: by 10.36.58.8 with SMTP id m8mr2527596itm.103.1500544931301; Thu, 20 Jul 2017 03:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 03:01:50 -0700 (PDT) In-Reply-To: <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> From: Jen Linkova Date: Thu, 20 Jul 2017 20:01:50 +1000 Message-ID: To: "Bernie Volz (volz)" Cc: Lorenzo Colitti , james woodyatt , IPv6 Operations , Tore Anderson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:02:15 -0000 On Thu, Jul 20, 2017 at 7:23 PM, Bernie Volz (volz) wrote: >>> What if the topology change was such that the global address of the >>> DHCPv6 server is no longer valid due to renumbering? > Also, 3315bis recommends that clients refresh information via dhcp when a > network change occurs (such as new prefixes in an RA appear). Sorry if I missed smth in that 100+ pages draft hut the only thing I found says: ' The server MAY initiate a configuration exchange, by sending Reconfigure messages, to cause DHCP clients to obtain new addresses, prefixes and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered or when other configuration options are updated, perhaps because servers are moved, added, or removed. ' I'd rather avoid repeating the whole Section 4 of https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01 but: 1) it's quite possible that in the event of some network failure the client unicast address might be unreachable; 2) the delay caused by 'network change -> DHCPv6 server gets notified (by what mechanism, btw?) -> the whole reconfiguration process happens to ALL affected clients' seems to increase the recovery time. > On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti wrote: > > On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson wrote: >> >> That said, for me having the additional DHCPv6-assigned address in >> addition to the SLAAC one has been a net negative, since it doesn't >> reconfigure along with the link prefix following a PD change (but >> nevertheless tends to be preferred for outbound traffic). Maybe this >> would have been better if it was a ULA rather than a GUA though, I >> don't know. > > > That's an excellent point. > > More in general I'd say that IA_NA is a net loss in *any* network where > addressing can unexpectedly change, such as a tethering hotspot, a small > enterprise, or even a medium enterprise using PA addresses. For exactly this > reason. (In fact - I don't think we even know how to make that sort of thing > at all without NAT.) > > I'm sure many will just say that I'm biased, but think about it - if you > can't tell the hosts that something has changed, then how do you deal with > routing and renumbering changes? Even if hosts were to support DHCPv6 > reconfigure, which they don't, how do you reconcile that with the assertion > that the value proposition is that DHCPv6 provides centralized management? > How do you do that at scale? Does the DHCPv6 server need to know about all > topology changes so it can issue appropriate RECONFIGUREs? What if the > topology change was such that the global address of the DHCPv6 server is no > longer valid due to renumbering? And so on. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- SY, Jen Linkova aka Furry From nobody Thu Jul 20 03:02:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE38127735 for ; Thu, 20 Jul 2017 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_wuBvMWgNJ7 for ; Thu, 20 Jul 2017 03:02:48 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C1E131A81 for ; Thu, 20 Jul 2017 03:02:35 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 5so9966876iow.0 for ; Thu, 20 Jul 2017 03:02: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; bh=mVBLxuuYp4YWAW/wmeei556tkbs2KjF3Fr3fshlD28U=; b=lnoPTIEIwMBypLUNXBkf1m38YWN3v62FJyLF9dCbbXP3IxJE8MfYFaZtgegJgrbY4I XkI0vrkP5ihBA1Rg+AlNtnOPM4gseUD+VUcC/MGSrGN8PbGfpL+pAzOOL7a6yD39JUVL 5hItEK+UeoPMNG8aRc4kvgcv2WRrZ4PKW/b0SXf3NE+GZTfpVZvSqe3DieDAXNWbTisR Cdzsxi32+BH5CrMZaLfDsjpUsRtU6uS39aripy13YreUes7Xd1zG/Pfq5QMhiNH4th/a nCbKIBemuk7yrv0hYNChielDCITlp1OHwuhP8+k9c54fLwnaN+ql79oJT1UXI+Wq9Tkz M7xA== 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=mVBLxuuYp4YWAW/wmeei556tkbs2KjF3Fr3fshlD28U=; b=fT120sf7A9TWb7vvUvU+2Nx7ODUGsnuDSRBKYjHXUVXiKvkWaFN8DMYvc6gm0QPDeT /4YZBSV1JP6RL3UhoTprzuxDAHCiG2wy450CXc2N8H6lM+U6TpE/vgYiRVh+SRqghRcd FueCHjsQYFLH7TT68leYTVjiAPOscQmOw6o7+/HPMcgzdHVUQSoTSvDAvYu8Lc+RgY4j aNHsUNrr/RpaOWCnQ0M4wPEJb+zq7y0AClLtC6sqW5cAa0820e4y0vZjJ2p9cs+Qg6lu 7K1OPO+P12iZaSui2Kj/Q9M0DF5T+v/Cu5zjGoF3fYUgr2E2yQwoz1FKHu3I5oqGk8eU z+/w== X-Gm-Message-State: AIVw111szt4RthEL88WMChmUs9cj4TyYDGtnHzluHhpWjxDAjalXk6lO JvpHrE1FjdcBT78yV5juL3ASHnvk9T/A8Mg= X-Received: by 10.107.195.9 with SMTP id t9mr3130625iof.223.1500544955012; Thu, 20 Jul 2017 03:02:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 03:02:14 -0700 (PDT) In-Reply-To: <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com> From: Jen Linkova Date: Thu, 20 Jul 2017 20:02:14 +1000 Message-ID: To: "Bernie Volz (volz)" Cc: Lorenzo Colitti , james woodyatt , IPv6 Operations , Tore Anderson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:02:50 -0000 On Thu, Jul 20, 2017 at 7:23 PM, Bernie Volz (volz) wrote: >>> What if the topology change was such that the global address of the >>> DHCPv6 server is no longer valid due to renumbering? > Also, 3315bis recommends that clients refresh information via dhcp when a > network change occurs (such as new prefixes in an RA appear). Sorry if I missed smth in that 100+ pages draft hut the only thing I found says: ' The server MAY initiate a configuration exchange, by sending Reconfigure messages, to cause DHCP clients to obtain new addresses, prefixes and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered or when other configuration options are updated, perhaps because servers are moved, added, or removed. ' I'd rather avoid repeating the whole Section 4 of https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01 but: 1) it's quite possible that in the event of some network failure the client unicast address might be unreachable; 2) > - Bernie (from iPhone) > > On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti wrote: > > On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson wrote: >> >> That said, for me having the additional DHCPv6-assigned address in >> addition to the SLAAC one has been a net negative, since it doesn't >> reconfigure along with the link prefix following a PD change (but >> nevertheless tends to be preferred for outbound traffic). Maybe this >> would have been better if it was a ULA rather than a GUA though, I >> don't know. > > > That's an excellent point. > > More in general I'd say that IA_NA is a net loss in *any* network where > addressing can unexpectedly change, such as a tethering hotspot, a small > enterprise, or even a medium enterprise using PA addresses. For exactly this > reason. (In fact - I don't think we even know how to make that sort of thing > at all without NAT.) > > I'm sure many will just say that I'm biased, but think about it - if you > can't tell the hosts that something has changed, then how do you deal with > routing and renumbering changes? Even if hosts were to support DHCPv6 > reconfigure, which they don't, how do you reconcile that with the assertion > that the value proposition is that DHCPv6 provides centralized management? > How do you do that at scale? Does the DHCPv6 server need to know about all > topology changes so it can issue appropriate RECONFIGUREs? What if the > topology change was such that the global address of the DHCPv6 server is no > longer valid due to renumbering? And so on. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- SY, Jen Linkova aka Furry From nobody Thu Jul 20 03:06:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9E012F290 for ; Thu, 20 Jul 2017 03:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH7O3HPs_gIe for ; Thu, 20 Jul 2017 03:05:57 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BBB127735 for ; Thu, 20 Jul 2017 03:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1500545157; x=1501754757; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C0ozKbcCV13/75VMk2GQ0tPIimk4447RLCyu+AeIq+k=; b=NlS0hDsK7p5E7PNUkpw9AmJXVZ7BD+E9jHU3YFowroSLg60Y5w3p5Vsn YLGl/5lR3JFtKp1xNhKbBQtbWJslkHY3qSSVyGEfK/ZQHJrWqHRPk7KpV hbuyapcDhwtE1IiQeR1iYrKy+NtDOPjZUCAJVnmKZXkO2MGRY/E0dnq4D M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAAqgHBZ/4QNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeI4LkWiQWYUsgTIDXIVHAoNzPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBdwIQAgEIBBQnBzIUEQIEDgWJS1wIs2aLIAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2DKIUuK4J5hEcNg1mCMQWfPgKLE4kFggyQKIlIjBUBHzhMPnUVWwGFNYF?= =?us-ascii?q?Odoc7gj8BAQE?= X-IronPort-AV: E=Sophos;i="5.40,383,1496102400"; d="scan'208,217";a="457809323" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 10:05:53 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v6KA5qMM028939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 10:05:52 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 05:05:52 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 05:05:52 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti CC: Tore Anderson , james woodyatt , "IPv6 Operations" Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt Thread-Index: AQHS/5m/vXdeJwPr90aX1hLwXQdtQqJbMdGAgAACOoCAAReuAIAAS4SAgAAfoYCAAAKDAIAABZ+AgAAFfQD//6/jEYAAWV8A//+yl8c= Date: Thu, 20 Jul 2017 10:05:52 +0000 Message-ID: <294352E0-557F-495D-9D0E-46DD36BCD609@cisco.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_294352E0557F495D9D0E46DD36BCD609ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:05:58 -0000 --_000_294352E0557F495D9D0E46DD36BCD609ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are two ways to deliver Reconfigure: one is unicast, other is via Rel= ay-Reply through relays were link-local is used to reach client. - Bernie (from iPhone) On Jul 20, 2017, at 11:43 AM, Lorenzo Colitti > wrote: On Thu, Jul 20, 2017 at 11:23 AM, Bernie Volz (volz) > wrote: >> What if the topology change was such that the global address of the DHCP= v6 server is no longer valid due to renumbering? Address of DHCPv6 server does not matter - it can change. Clients generally= never directly address packets to its address. They multicast to fe02::1:2= . Surely the RECONFIGURE is not multicast, but unicast from server to client? Also, 3315bis recommends that clients refresh information via dhcp when a n= etwork change occurs (such as new prefixes in an RA appear). 3315bis-09 does not recommend this, it says the client MAY do it and MUST r= ate-limit it (with an example rate-limit of one every 30 seconds). In any case, the server still needs to keep track of all topology changes i= n order to give a correct answer. --_000_294352E0557F495D9D0E46DD36BCD609ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There are two ways to deliver Reconfigure: one is unicast, other is vi= a Relay-Reply through relays were link-local is used to reach client.

- Bernie (from iPhone)

On Jul 20, 2017, at 11:43 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Thu, Jul 20, 2017 at 11:23 AM, Bernie Volz (v= olz) <volz@cisco.com&= gt; wrote:
>> What if = the topology change was such that the global address of the DHCPv6 server i= s no longer valid due to renumbering?
Address of DHCPv6= server does not matter - it can change. Clients generally never directly a= ddress packets to its address. They multicast to fe02::1:2.

Surely the RECONFIGURE is not multicast, but unicast from server to cl= ient?
 
Also, 3315bis rec= ommends that clients refresh information via dhcp when a network change occ= urs (such as new prefixes in an RA appear).

3315bis-09 does not recommend this, it says the client MAY do it and M= UST rate-limit it (with an example rate-limit of one every 30 seconds).

In any case, the server still needs to keep track of all topology chan= ges in order to give a correct answer.
--_000_294352E0557F495D9D0E46DD36BCD609ciscocom_-- From nobody Thu Jul 20 03:29:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6632B12ECCB; Thu, 20 Jul 2017 03:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 ArE6xflvbFU9; Thu, 20 Jul 2017 03:28:55 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32793131C06; Thu, 20 Jul 2017 03:28:52 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6KACFPj023783; Thu, 20 Jul 2017 12:12:15 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707201012.v6KACFPj023783@givry.fdupont.fr> From: Francis Dupont To: Mikael Abrahamsson cc: v6ops@ietf.org, mboned@ietf.org, 6lowpan@ietf.org, 6lo@ietf.org In-reply-to: Your message of Wed, 19 Jul 2017 18:57:08 +0200. Date: Thu, 20 Jul 2017 12:12:15 +0200 Archived-At: Subject: Re: [v6ops] multicast over wifi discussion list X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:28:59 -0000 I agree I experimented poor delivery of multicast ND messages using IPv6 over 802.11. And it is a shame as multicast is builtin in L1. Unfortunately I can't see an easy solution, both on the IPv6 side which really requires it, or on the WiFi side which has its own reasons to be very bad on it... Perhaps it is why the ML stales? Regards Francis.Dupont@fdupont.fr PS: I remember well to have missed the first RA for years! (I can understand from time to time but here probability of loss was one). From nobody Thu Jul 20 04:25:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B17A12969E for ; Thu, 20 Jul 2017 04:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xyd4HyGudBp for ; Thu, 20 Jul 2017 04:25:10 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 68B371270B4 for ; Thu, 20 Jul 2017 04:25:10 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6K9F04P043102; Thu, 20 Jul 2017 05:19:35 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2bth1t1vwr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 05:19:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6K9JYQP005311; Thu, 20 Jul 2017 05:19:34 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6K9JQlN005230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Jul 2017 05:19:28 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 20 Jul 2017 09:19:03 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Thu, 20 Jul 2017 05:19:03 -0400 From: "STARK, BARBARA H" To: Gert Doering , Lorenzo Colitti CC: james woodyatt , IPv6 Operations Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt Thread-Index: AQHS/5m9OUisHJyfC0CF4hfBZVASSaJbIQ6AgAACOoCAAWJAAP//6ZIw Date: Thu, 20 Jul 2017 09:19:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBD3B89@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <20170720062428.GK45648@Space.Net> In-Reply-To: <20170720062428.GK45648@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.197.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200150 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:25:12 -0000 > Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it > effectively *is*, and no amount of word-weaseling is going to change this= . I've spoken to various ISPs who want to deploy their IPTV STBs or home auto= mation devices, in conjunction with their CE routers, in such a way that th= e STBs and home automation devices do both SLAAC and DHCPv6. The STBs/etc d= evices automatically request IA_NA without caring about values of bits in a= n RA (because M=3D0 may be used in RAs to prevent other devices from asking= ). The DHCPv6 server in the ISP CE router recognizes the ISP's host devices= and provides them (and only them) with DHCPv6 IA_NA addresses. Those addre= sses are used specifically to access the ISP service. For communicating wit= h other devices on the LAN or other Internet services, SLAAC addresses are = used. I think this is a perfectly valid use case. There is no reason to preclude = it. I don't see privacy implications. The ISP services don't tend to be del= ivered over "the Internet". The devices don't roam. Barbara From nobody Thu Jul 20 04:28:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D66131C0C for ; Thu, 20 Jul 2017 04:28: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-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 9ifcX9LddEz3 for ; Thu, 20 Jul 2017 04:28:24 -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 C3DD612EC30 for ; Thu, 20 Jul 2017 04:28:24 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id s4so13545752pgr.5 for ; Thu, 20 Jul 2017 04:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VQWkB8avPGKA6PUUjzSUWauoctGVIoX6vvIS3XmSJp0=; b=a31ckzJhvSupp37pa1Sqx49CWMgscdRswm4iWcPVHxuLe4PcuL+fq4fWyEwDf24vFq 5NXyI50BCfutoba6F6hvVqQwakxY8q+CWnqfupc1gVT9C40N1936UMvmhp7J2wEUi0pY gfNpNvqecbbTGRDYWSwEwLC9+AEuaD9KN/QQHZgTqI1kcu3sM3wPXhlkcrsgWrJiuPHU ed72QF+/pL9G7tlb7KKmI2l9pwwWzCDB2gWqZ33ccAGPd0m0nGzGblitxswOY7Xkb+2n omuK5YGjqro0HWMas+QFYFDu7WtSeWWT8q19qOB3QyuViq3Nbly1sLNQ9sBgGIiBiPJo YCWA== 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=VQWkB8avPGKA6PUUjzSUWauoctGVIoX6vvIS3XmSJp0=; b=g4XNoqc9wUJQwYtxZXMlS/z8TRBPMe412otA7NDfIOwinxHllGFKJSdWCabdEharnK I6s+oR2eQHuabNttwn0TExWesZHp21HfsjfXY2GT9uzWTR4iYcL8aubiA0FSqzfHVu44 zG/kndObHrmipx0AB37ykUvhK/CKbJRBlA12k/wul1cnjfxaJIJtaPUDM6cFrHdBuSiF oaIoxUT3fSpF5rGdTiLU0HEE3180YN2NOjlUvAe+9Aj8hXpvF8PO6krb250es/57ZzNc d+0K42gjjoyiMahncjS7oW/8fTj9k5eQLiONyS5xsy2E+1RVJApJLx1Ebpngz9NJ/vdZ 4NAA== X-Gm-Message-State: AIVw111z2OQ2mYawJKrs4MJYLByVL8RLjhiCfOomrVvoFw9payVNdgdX HSnPjNLtJGAbAsK7Jn5vr8vkEjYrtFyz X-Received: by 10.99.44.66 with SMTP id s63mr3571695pgs.302.1500550104426; Thu, 20 Jul 2017 04:28:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 04:28:23 -0700 (PDT) Received: by 10.100.181.42 with HTTP; Thu, 20 Jul 2017 04:28:23 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBD3B89@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <20170720062428.GK45648@Space.Net> <2D09D61DDFA73D4C884805CC7865E6114DBD3B89@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Ted Lemon Date: Thu, 20 Jul 2017 13:28:23 +0200 Message-ID: To: "STARK, BARBARA H" Cc: james woodyatt , Lorenzo Colitti , Gert Doering , IPv6 Operations Content-Type: multipart/alternative; boundary="001a113e48bcf142850554be0bc2" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:28:27 -0000 --001a113e48bcf142850554be0bc2 Content-Type: text/plain; charset="UTF-8" And, at the moment, it is not precluded, right? On Jul 20, 2017 1:25 PM, "STARK, BARBARA H" wrote: > > Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it > > effectively *is*, and no amount of word-weaseling is going to change > this. > > I've spoken to various ISPs who want to deploy their IPTV STBs or home > automation devices, in conjunction with their CE routers, in such a way > that the STBs and home automation devices do both SLAAC and DHCPv6. The > STBs/etc devices automatically request IA_NA without caring about values of > bits in an RA (because M=0 may be used in RAs to prevent other devices from > asking). The DHCPv6 server in the ISP CE router recognizes the ISP's host > devices and provides them (and only them) with DHCPv6 IA_NA addresses. > Those addresses are used specifically to access the ISP service. For > communicating with other devices on the LAN or other Internet services, > SLAAC addresses are used. > > I think this is a perfectly valid use case. There is no reason to preclude > it. I don't see privacy implications. The ISP services don't tend to be > delivered over "the Internet". The devices don't roam. > Barbara > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113e48bcf142850554be0bc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, at the moment, it is not precluded, right?

On Jul 20, 2017 1:25 = PM, "STARK, BARBARA H" <bs76= 52@att.com> wrote:
> Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC,= it
> effectively *is*, and no amount of word-weaseling is going to change t= his.

I've spoken to various ISPs who want to deploy their IPTV STBs or home = automation devices, in conjunction with their CE routers, in such a way tha= t the STBs and home automation devices do both SLAAC and DHCPv6. The STBs/e= tc devices automatically request IA_NA without caring about values of bits = in an RA (because M=3D0 may be used in RAs to prevent other devices from as= king). The DHCPv6 server in the ISP CE router recognizes the ISP's host= devices and provides them (and only them) with DHCPv6 IA_NA addresses. Tho= se addresses are used specifically to access the ISP service. For communica= ting with other devices on the LAN or other Internet services, SLAAC addres= ses are used.

I think this is a perfectly valid use case. There is no reason to preclude = it. I don't see privacy implications. The ISP services don't tend t= o be delivered over "the Internet". The devices don't roam. Barbara

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a113e48bcf142850554be0bc2-- From nobody Thu Jul 20 04:31:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270DE131C19 for ; Thu, 20 Jul 2017 04:31: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 pj0ruFGvQ8NR for ; Thu, 20 Jul 2017 04:31:44 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 20076131C0C for ; Thu, 20 Jul 2017 04:31:44 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l7so10629416iof.1 for ; Thu, 20 Jul 2017 04:31: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=NRGkTYxuXqp9dqidH+NDbEQOocbduMui3t2GMlBoXMg=; b=Hgzbve1SWxxzuObDLzG5zLN4PaC4gYTltB4N8wj1Rw/Q3TRk52utNFNF2QFMra3h3b 8OrYRGcKmcBlWb4U9CQUuC/XfdPC8Z5xZIbGj7czCsC/BBec5DUpItIhfK2B2bxr0fh/ iRRw5ek5L0Lwe1rhsTDysUO/TVIQ+56SnSXulf8EuW+BFdSrTO2DSSmJGnfZMi0/uNKA BnsMtpL0wzyK220qc+3nVuwMXz38DSkGR90AXqlAm7K8TOhKxe1I069d/+fpL9OhbycX U/lr2AF9ErcxMEGVXEfInWxEZbq0B8b142M6RGY+6BTi7j7LEWJXIQkcTFH7up3vshN5 FmPQ== 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=NRGkTYxuXqp9dqidH+NDbEQOocbduMui3t2GMlBoXMg=; b=XEjbThyyp3GLaZ4+cjoGcIZxZFmBt04rPo/9pM+PyA3nM5poGEyrBQzDNEbKQr0+8o HWlj51mA0Le7C01U5/fXy4BqkHzA967Ysd5RaagBknUQTraTAG1SlkHLJkLfi2sTVrR6 tzvQob5EGevecS2PKjkll2W7LgMesT/0kH/tf42TarQQCwbLWKzMbw4dd+x/IFBaRDcO ZtTiZPrh8aFGT2fxXaYsAJFpUlhrd0k00npqpGHwiELWO0rSW9O284nj0LDjJpNFT9wg Jiw4lTpZy67g92ryKPWz1XKd6ncL46h+xosZXbgK5Oq9W+IahA+R2SptqLOtNiA4Qdcb gHvw== X-Gm-Message-State: AIVw111hHv4nS7gQBsy7bD+8JrrUjP6sSrbwem++WSYpRQ5R18fQzqNn 25girrlYXKG+geJl+D780eeOKrUcuZG1 X-Received: by 10.107.133.155 with SMTP id p27mr3413894ioi.200.1500550303021; Thu, 20 Jul 2017 04:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 04:31:22 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <20170720062428.GK45648@Space.Net> <2D09D61DDFA73D4C884805CC7865E6114DBD3B89@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 13:31:22 +0200 Message-ID: To: Ted Lemon Cc: "STARK, BARBARA H" , james woodyatt , Gert Doering , IPv6 Operations Content-Type: multipart/alternative; boundary="001a113ea6dac844b30554be17c0" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:31:46 -0000 --001a113ea6dac844b30554be17c0 Content-Type: text/plain; charset="UTF-8" Running both IA_NA and SLAAC is certainly not precluded by RFC 7934. In the specific case of home routers, RFC 7084 says they MUST have a DHCPv6 server, either stateful or stateless. On Thu, Jul 20, 2017 at 1:28 PM, Ted Lemon wrote: > And, at the moment, it is not precluded, right? > > On Jul 20, 2017 1:25 PM, "STARK, BARBARA H" wrote: > >> > Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it >> > effectively *is*, and no amount of word-weaseling is going to change >> this. >> >> I've spoken to various ISPs who want to deploy their IPTV STBs or home >> automation devices, in conjunction with their CE routers, in such a way >> that the STBs and home automation devices do both SLAAC and DHCPv6. The >> STBs/etc devices automatically request IA_NA without caring about values of >> bits in an RA (because M=0 may be used in RAs to prevent other devices from >> asking). The DHCPv6 server in the ISP CE router recognizes the ISP's host >> devices and provides them (and only them) with DHCPv6 IA_NA addresses. >> Those addresses are used specifically to access the ISP service. For >> communicating with other devices on the LAN or other Internet services, >> SLAAC addresses are used. >> >> I think this is a perfectly valid use case. There is no reason to >> preclude it. I don't see privacy implications. The ISP services don't tend >> to be delivered over "the Internet". The devices don't roam. >> Barbara >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --001a113ea6dac844b30554be17c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Running both IA_NA and SLAAC is certainly not precluded by= RFC 7934. In the specific case of home routers, RFC 7084 says they MUST ha= ve a DHCPv6 server, either stateful or stateless.

On Thu, Jul 20, 2017 at 1:28 PM, Ted = Lemon <mellon@fugue.com> wrote:
And, at the moment, it is not precluded, right?

On Jul 20, 2017 1:25 PM, "STARK, BARBARA H" <bs7652@att.com> wrote:<= br type=3D"attribution">
> Since there is no reason to deploy both IA_NA/IA_TA *an= d* SLAAC, it
> effectively *is*, and no amount of word-weaseling is going to change t= his.

I've spoken to various ISPs who want to deploy their IPTV STBs or home = automation devices, in conjunction with their CE routers, in such a way tha= t the STBs and home automation devices do both SLAAC and DHCPv6. The STBs/e= tc devices automatically request IA_NA without caring about values of bits = in an RA (because M=3D0 may be used in RAs to prevent other devices from as= king). The DHCPv6 server in the ISP CE router recognizes the ISP's host= devices and provides them (and only them) with DHCPv6 IA_NA addresses. Tho= se addresses are used specifically to access the ISP service. For communica= ting with other devices on the LAN or other Internet services, SLAAC addres= ses are used.

I think this is a perfectly valid use case. There is no reason to preclude = it. I don't see privacy implications. The ISP services don't tend t= o be delivered over "the Internet". The devices don't roam. Barbara

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

--001a113ea6dac844b30554be17c0-- From nobody Thu Jul 20 05:04:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB7C131BF9 for ; Thu, 20 Jul 2017 05:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXZTnW1iM50n for ; Thu, 20 Jul 2017 05:04:38 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31886126E3A for ; Thu, 20 Jul 2017 05:04:38 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 5so10908553iow.0 for ; Thu, 20 Jul 2017 05:04:38 -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=W7lVVm7OL6dmTNWQj9o5abuffuGPwmcUiOB78ldOLu8=; b=CaNGBRAzcYzXgDTv/7ly5fugy8cKntX9oYPpZIuF2tI1BcYcEEg6xCQ8c32hmvcH7A DbWthPAENB7sp7bmPFZI7akVYjjgLay85QpWMipUKDg3Mi+wvln9SCgXyJ/trBvfmMhQ 4s3Jrbs30KNDNk4S9dwdH3sQ9i3wzx8nwNERXwL+3H1m1k32U/Ior69GaQhJWQN3BuSP tZrGZt2AI3oCXu7ydEHIbNGOpaxaV1uDJcmJK5JM/1rzru5Ml6vJjjmBGo3dieiDx9bw 4zcEbwrFgKkKZtBf9AZ+sQVPDTdvGx6GwTJdlupUWs80rmaSzlaGRqtcjgwX+6WAPkCH OK1w== 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=W7lVVm7OL6dmTNWQj9o5abuffuGPwmcUiOB78ldOLu8=; b=XDWow9Zk8cZ6YZhKUhFdWjdeTSnr/srnEjh5TEw7k9ZzIwOb+tFBPU8BrzHDMzOBEd sEBc959ehv2pwa4oIKjdwzktiS8/t1kInnMdcg6/tznqUlHt09lV4/Wq/KUHefJ10sAF 5GFnieJX8gswHBNhy6KSm+hxnvJ6qRHgpyvhxkUvfB+KhT7BS0BKfHjq/j0+UhvR+pUx n1whe27ebjZD9TPZKEeIPbopwIatk9DEOaJJ6OckBTwD8cEm2qpTA2iG2AJNXqf3ewjJ XWKU7hqew05JtTRERe/nnZyEFNJwjvL2FGP1yvcABiyUg2Vc5bK3R9EnSR/fyMrZTQ2n Jr6g== X-Gm-Message-State: AIVw112Pvl7lZr64qMxpmxorKKq/Xq+913x+jBvCEfiky/6oBer8pUml Nc6qApncwM+bA9jmcKcppTPlT1rFEA== X-Received: by 10.107.41.5 with SMTP id p5mr2994292iop.165.1500552275708; Thu, 20 Jul 2017 05:04:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 05:04:15 -0700 (PDT) In-Reply-To: <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> From: Jen Linkova Date: Thu, 20 Jul 2017 22:04:15 +1000 Message-ID: To: Jordi Palet Martinez Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:04:40 -0000 One thing I forgot to ask at the mic: how does the host know that syslog address (network prefix) changes/not valid anymore? Does the discovery process happens every time the interface state changes? Or....? On Tue, Jul 4, 2017 at 1:41 AM, JORDI PALET MARTINEZ wrote: > Following my inputs to the update of HE, I=E2=80=99ve summited a new draf= t: > > Reporting of Happy Eyeballs v2 Failures > > I think this could be part of the main document, but just in case, to avo= id missing the cut-off today =E2=80=A6 > > Hopefully I can get a few minutes in the next meeting agenda to discuss a= bout it, and as usual happy to get inputs, alternative suggestions, etc. > > Note that even if the title mentions v2, I think it can work the same wit= h the existing HE, but to me it makes sense to move on with the new version= and include this reporting procedure. > > Regards, > Jordi > > > -----Mensaje original----- > De: > Responder a: > Fecha: lunes, 3 de julio de 2017, 17:36 > Para: Jordi Palet , Jordi Palet Martinez > Asunto: New Version Notification for draft-palet-ietf-v6ops-he-reporting-= 00.txt > > > A new version of I-D, draft-palet-ietf-v6ops-he-reporting-00.txt > has been successfully submitted by Jordi Palet Martinez and posted to= the > IETF repository. > > Name: draft-palet-ietf-v6ops-he-reporting > Revision: 00 > Title: Reporting of Happy Eyeballs v2 Failures > Document date: 2017-07-03 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-palet-ietf= -v6ops-he-reporting-00.txt > Status: https://datatracker.ietf.org/doc/draft-palet-ietf-v6o= ps-he-reporting/ > Htmlized: https://tools.ietf.org/html/draft-palet-ietf-v6ops-he= -reporting-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-iet= f-v6ops-he-reporting-00 > > > Abstract: > This document describes an extension to Happy Eyeballs in order to > report IPv6 failures that force the fall-back to IPv4. > > > > > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > ********************************************** > 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 c= onfidential. The information is intended to be for the use of the individua= l(s) named above. If you are not the intended recipient be aware that any d= isclosure, copying, distribution or use of the contents of this information= , including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Thu Jul 20 05:16:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4653F129B43 for ; Thu, 20 Jul 2017 05:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HLHDXsEzPCV for ; Thu, 20 Jul 2017 05:16:29 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E094129468 for ; Thu, 20 Jul 2017 05:16:28 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E58E541C2E for ; Thu, 20 Jul 2017 14:16:26 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id AD1A741C24; Thu, 20 Jul 2017 14:16:26 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id AA13F35E91; Thu, 20 Jul 2017 14:16:26 +0200 (CEST) Date: Thu, 20 Jul 2017 14:16:26 +0200 From: Gert Doering To: Jen Linkova Cc: Jordi Palet Martinez , "v6ops@ietf.org" Message-ID: <20170720121626.GB45648@Space.Net> References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:16:31 -0000 Hi, On Thu, Jul 20, 2017 at 10:04:15PM +1000, Jen Linkova wrote: > One thing I forgot to ask at the mic: how does the host know that > syslog address (network prefix) changes/not valid anymore? > Does the discovery process happens every time the interface state > changes? Or....? We are turning in cycles. Obviously DHCPv6 is not a good match if you run it in a volatile environment, like "on an android phone used as a tethering CPE". Nobody is challenging that. OTOH, in a fully managed environment, syslog hosts, network prefixes, DNS recusors (<< the usual straw man) do not change "just so, and by surprise" - this is known beforehand, planned, old and new system exist in parallel (or old/new address, at least) and then you roll out the change to the clients. Which totally voids that argument. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jul 20 05:17:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E712EA7C for ; Thu, 20 Jul 2017 05:17:45 -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 uhtezIygi_og for ; Thu, 20 Jul 2017 05:17:43 -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 53CE9126E3A for ; Thu, 20 Jul 2017 05:17:43 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id f21so13559989wrf.5 for ; Thu, 20 Jul 2017 05:17:43 -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=H4W5rxWv6+SxaXvsTaLjkSIAgskd96V8N2WngaJm6Hc=; b=q34o6EasYqMDXiwNT9Xp0/dpyuyfwpfRgHrJttRm1A5IToKaYv5X0ZSOGadOUwgLIB qJYPNLNYp9JC4wN7Xmc4YL5VmXQ7Ejvv/FfZGZwgpRAaOEDsNztiVEbDvVq9gld1/Lyf otj2jN3ckk4R/ViA6IZG754lG/BBXYjjpbre5wdeTD1wuuKm27Naz7w0LuutXiK6O2on 3F5RJ/XBmxk41ui+TtUScRUNIc/HqiWABDbuoQ6vP3++MFX87BB6CZyH1enyyeX+jRZv ew1A16QpZenKfXhHYL5mjDEg9Yv7eqd1nMuuovfBaKi7sv1ZmwGJBISND97yg769l+GB JJxg== 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=H4W5rxWv6+SxaXvsTaLjkSIAgskd96V8N2WngaJm6Hc=; b=jnH5Hm8c2dgggqkD+FyjS2OUUaEDC+dCbQec1uc5EoEMxrRlw1tH2jl72M5nle8v5c kgdJyDtC+tL5fL/CuaWiaUNu9jbwdbUisfq7oomlGty97UQtY12inmjZhHxFO8o0m7yV wHV/Um+hQAmEiXgw3dwiioNxLityV+E9+lnbgz8rhV48AEZhXyOHtkoWJU8VsXGChrLD jJq72/GTQUdtgfojvgTVAuJSLayEOAmaPprtrIHLPep+Q4afCac5E0VdU8zYXB8YRRJo fmgzsQfJaGpj07LK/etwDGU1ZjkgUlfqYrAPf4Z0P5nv1/+m16PCXRjhVyEqAorQYu6y e0Ag== X-Gm-Message-State: AIVw111CsF1kki6cPZ/7dT9AJ41RaVgAl38ICzOa/QR5vz+p7fhuV4DS O6viogqcQ6V4Ld02+SxMke4V2slf65kMA7g= X-Received: by 10.223.130.102 with SMTP id 93mr2751895wrb.253.1500553061715; Thu, 20 Jul 2017 05:17:41 -0700 (PDT) MIME-Version: 1.0 References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> <20170720121626.GB45648@Space.Net> In-Reply-To: <20170720121626.GB45648@Space.Net> From: Job Snijders Date: Thu, 20 Jul 2017 12:17:31 +0000 Message-ID: To: Gert Doering , Jen Linkova Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3c4435fa480554bebc2b" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:17:46 -0000 --001a114b3c4435fa480554bebc2b Content-Type: text/plain; charset="UTF-8" Amen On Thu, 20 Jul 2017 at 14:16, Gert Doering wrote: > Hi, > > On Thu, Jul 20, 2017 at 10:04:15PM +1000, Jen Linkova wrote: > > One thing I forgot to ask at the mic: how does the host know that > > syslog address (network prefix) changes/not valid anymore? > > Does the discovery process happens every time the interface state > > changes? Or....? > > We are turning in cycles. > > Obviously DHCPv6 is not a good match if you run it in a volatile > environment, like "on an android phone used as a tethering CPE". Nobody > is challenging that. > > OTOH, in a fully managed environment, syslog hosts, network prefixes, > DNS recusors (<< the usual straw man) do not change "just so, and > by surprise" - this is known beforehand, planned, old and new system > exist in parallel (or old/new address, at least) and then you roll > out the change to the clients. Which totally voids that argument. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114b3c4435fa480554bebc2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Amen

On Thu= , 20 Jul 2017 at 14:16, Gert Doering <= gert@space.net> wrote:
Hi,
On Thu, Jul 20, 2017 at 10:04:15PM +1000, Jen Linkova wrote:
> One thing I=C2=A0 forgot to ask at the mic: how does the host know tha= t
> syslog address (network prefix) changes/not valid anymore?
> Does the discovery process happens every time the interface state
> changes? Or....?

We are turning in cycles.

Obviously DHCPv6 is not a good match if you run it in a volatile
environment, like "on an android phone used as a tethering CPE".= =C2=A0 Nobody
is challenging that.

OTOH, in a fully managed environment, syslog hosts, network prefixes,
DNS recusors (<< the usual straw man) do not change "just so, an= d
by surprise" - this is known beforehand, planned, old and new system exist in parallel (or old/new address, at least) and then you roll
out the change to the clients.=C2=A0 Which totally voids that argument.

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

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114b3c4435fa480554bebc2b-- From nobody Thu Jul 20 05:18:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D579131C1E for ; Thu, 20 Jul 2017 05:18:46 -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 eAvcJCOg64je for ; Thu, 20 Jul 2017 05:18:44 -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 E8C02126E3A for ; Thu, 20 Jul 2017 05:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500553119; x=1501157919; 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=ZwgBg1NMZl9kkUHbhnmMR4Oex af+cpO+JYdD+/JkFac=; b=Ibwm2YgZ3fR+SF7/4iozZlI2N9K6mcdkE7y7i9Vjo XVgrIIb9rLoXDC3Qxznh03mW3b4VNaKytBZ2xmaV9frENOMsM36S9x6P6V4LnFte 0t88nVGSKxXq7KFrm7SzoFPqYa/XjD3EykW9y8ZxxTjrsH551M4mZKpUi+ZD/j2e 6E= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=NKYmP8ciRe8Gluf5nnxM03sAkIWukOLXR6SE3RO5xBqr0zRWLYLhx/sPbTha 2IVO2Elas407aKp+1w83FZmt/oCeR/i/4WvaPLhDCeifYQfQYBuXjcevq TjhviJFeHLtOfvSILo+L+O5IMC3/kVFMVFD12Jut6dH1kb2EUMpzho=; X-MDAV-Processed: mail.consulintel.es, Thu, 20 Jul 2017 14:18:39 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 20 Jul 2017 14:18:38 +0200 Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005481773.msg for ; Thu, 20 Jul 2017 14:18:37 +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:170720:md50005481773::XmWNTXMbBCbdcWNg:00005ezz X-MDRemoteIP: 31.133.142.45 X-Return-Path: prvs=137477960e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 14:18:20 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> 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: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:18:46 -0000 The NSP prefix is something usually very stable in an operator network. Oth= erwise you have the same problem if the NSP used for the NAT64 if is change= d quite often. Anyway, we may specify some parameter such as lifetime, or something simila= r. Actually, looking to 7.1. IPv4 Address Literals from draft-ietf-v6ops-rfc6= 555bis, the problem is the same, I=E2=80=99m not sure if the authors have t= hought already about that issue? Regards, Jordi =20 -----Mensaje original----- De: Jen Linkova Responder a: Fecha: jueves, 20 de julio de 2017, 14:04 Para: Jordi Palet Martinez CC: "v6ops@ietf.org" Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops= -he-reporting-00.txt One thing I forgot to ask at the mic: how does the host know that syslog address (network prefix) changes/not valid anymore? Does the discovery process happens every time the interface state changes? Or....? =20 On Tue, Jul 4, 2017 at 1:41 AM, JORDI PALET MARTINEZ wrote: > Following my inputs to the update of HE, I=E2=80=99ve summited a new = draft: > > Reporting of Happy Eyeballs v2 Failures > > I think this could be part of the main document, but just in case, to= avoid missing the cut-off today =E2=80=A6 > > Hopefully I can get a few minutes in the next meeting agenda to discu= ss about it, and as usual happy to get inputs, alternative suggestions, etc= . > > Note that even if the title mentions v2, I think it can work the same= with the existing HE, but to me it makes sense to move on with the new ver= sion and include this reporting procedure. > > Regards, > Jordi > > > -----Mensaje original----- > De: > Responder a: > Fecha: lunes, 3 de julio de 2017, 17:36 > Para: Jordi Palet , Jordi Palet Martinez = > Asunto: New Version Notification for draft-palet-ietf-v6ops-he-report= ing-00.txt > > > A new version of I-D, draft-palet-ietf-v6ops-he-reporting-00.txt > has been successfully submitted by Jordi Palet Martinez and poste= d to the > IETF repository. > > Name: draft-palet-ietf-v6ops-he-reporting > Revision: 00 > Title: Reporting of Happy Eyeballs v2 Failures > Document date: 2017-07-03 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-palet-= ietf-v6ops-he-reporting-00.txt > Status: https://datatracker.ietf.org/doc/draft-palet-ietf= -v6ops-he-reporting/ > Htmlized: https://tools.ietf.org/html/draft-palet-ietf-v6op= s-he-reporting-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-palet= -ietf-v6ops-he-reporting-00 > > > Abstract: > This document describes an extension to Happy Eyeballs in orde= r to > report IPv6 failures that force the fall-back to IPv4. > > > > > 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.o= rg. > > The IETF Secretariat > > > > > > ********************************************** > 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 confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 --=20 SY, Jen Linkova aka Furry =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 Jul 20 05:21:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412A131C06 for ; Thu, 20 Jul 2017 05:21: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=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 s5V5KhEyu6Wm for ; Thu, 20 Jul 2017 05:21:42 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F4912EC30 for ; Thu, 20 Jul 2017 05:21:42 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id v127so14989311itd.0 for ; Thu, 20 Jul 2017 05:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WtDDF2tISolSHBc3DVsRMs3T3eR7FUCiTIl6EQHhv8E=; b=pjsPxDr1McoZ5cM41ufjgOpklQSKCrYiL9kTCa0zfiLDtSA44vBBlKXK9Pr7QldyZy yEmHjMHXSzJkr7gGBTWw3q2n89su1yQE5D/sTPERco8ZItKF9zbX5IpDC/hnXKjd6921 N/5zAJ/GVW+A8U6Gi9HxqBELq8QTKQtLabLloo3XGU7VWBFc85oKAKx6Zi2KClTYhHFE x2lYSz4DsvvkHdLs5X9paA/5GcLz3WSx3LO1+RVXFqg9FvDndzfwF2BDU5qGwxZFuVF2 38vM27xsjWi119xHKJowYbeY5zmWaf+G+sTSuUhm2ssB0ZBmQxylzJEEZYkmqQdj4LVn 2fVg== 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=WtDDF2tISolSHBc3DVsRMs3T3eR7FUCiTIl6EQHhv8E=; b=LluukWqkzUzVw7JyS368HQe5FNFzcdKYy0W2+oIlleuYw/50UFOCqwqVWKZRBx1lck oj0oniD0c5mJt9YOAYlUPDyNLzJplxxAnpcIGf4t4NlXU/aI8kEBFnL5SS6KZOqTS+HO xeE4zs0czEZ0inBCZPhFKFsPBYIYaOAS0vnfKJSRJatsr5mvBPSDqUXj2BUlBxP5Lpug GEhUf2MrCrClALrktbhkwu8Xq2ZPSQhod+noZjrBl1LwVbuzxSqUnxwJGiGwoSO3QNUP fgX0Ykb6kgUPePszoTRGy4ATYwmuBN7sQIxkBoI5bKjHGWiTdu18/tI5j8woxF8BTAtb 8M6A== X-Gm-Message-State: AIVw110RfeTHtip+xOZkX3rbg1Bb5RnsQejNzThTIvXzUb54Wg+emEHL 3LtL9fF6NggheYFrRx5qX5Ac3ZgRNKxcfJk= X-Received: by 10.36.4.139 with SMTP id 133mr3217168itb.142.1500553301148; Thu, 20 Jul 2017 05:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 05:21:20 -0700 (PDT) From: Lorenzo Colitti Date: Thu, 20 Jul 2017 14:21:20 +0200 Message-ID: To: "v6ops@ietf.org WG" Cc: draft-ietf-v6ops-ula-usage-considerations@ietf.org Content-Type: multipart/alternative; boundary="001a113fe1e27c05bc0554beca60" Archived-At: Subject: [v6ops] Comments on ULA draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:21:49 -0000 --001a113fe1e27c05bc0554beca60 Content-Type: text/plain; charset="UTF-8" Repeating the comments at the mike: 1. As clearly shown in the presentations slides, and as said by others, there will continue to be is substantial opposition to any document unless it says that ULA+NPTv6 deployments are NOT RECOMMENDED. The current text in section 4.3 is very far from making such a statement. 2. The document needs to be clear that because ULAs MUST be generated randomly (per RFC 4193), they are not aggregatable. Thus, developing ULA firewall policies is very complex because there is no way to ensure that /48s with similar security policies have adjacent address space. Even if ULA is initially deployed in a network that has only two zones ("public" and "private") network growth or mergers with other networks will cause firewall policies to become complex and have lots of holes. 3. The document should say that even though ULAs are typically not announced externally, any network that is adjacent to the ULA network can send and receive packets from ULA addresses unless there is a firewall rule that blocks such packets. For well-connected networks that have lots of peers, that can be a large attack surface. 4. Due to #2 and #3, it may well be simpler to use global space and just add a firewall. Regards, Lorenzo --001a113fe1e27c05bc0554beca60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Repeating the comments at the mike:
  1. As clearly= shown in the presentations slides, and as said by others, there will conti= nue to be is substantial opposition to any document unless it says that ULA= +NPTv6 deployments are NOT RECOMMENDED. The current text in section 4.3 is = very far from making such a statement.
  2. The document needs to be cle= ar that because ULAs MUST be generated randomly (per RFC 4193), they are no= t aggregatable. Thus, developing ULA firewall policies is very complex beca= use there is no way to ensure that /48s with similar security policies have= adjacent address space. Even if ULA is initially deployed in a network tha= t has only two zones ("public" and "private") network g= rowth or mergers with other networks will cause firewall policies to become= complex and have lots of holes.
  3. The document should say that even = though ULAs are typically not announced externally, any network that is adj= acent to the ULA network can send and receive packets from ULA addresses un= less there is a firewall rule that blocks such packets. For well-connected = networks that have lots of peers, that can be a large attack surface.
    4. <= li>Due to #2 and #3, it may well be simpler to use global space and just ad= d a firewall.

Regards,
Lorenzo=
--001a113fe1e27c05bc0554beca60-- From nobody Thu Jul 20 05:22:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7267E12EC30 for ; Thu, 20 Jul 2017 05:22: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 UN3G6gZQZmKy for ; Thu, 20 Jul 2017 05:22:43 -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 F400B131761 for ; Thu, 20 Jul 2017 05:22:29 -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 v6KCMSdX025097 for ; Thu, 20 Jul 2017 14:22:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 18C9E2071E9 for ; Thu, 20 Jul 2017 14:22: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 0FF50207035 for ; Thu, 20 Jul 2017 14:22:28 +0200 (CEST) Received: from [132.166.84.163] ([132.166.84.163]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6KCMRt0007108 for ; Thu, 20 Jul 2017 14:22:27 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <359de5ca-2106-0696-fb29-de19163dc0fd@gmail.com> Date: Thu, 20 Jul 2017 14:22:27 +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: Subject: Re: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:22:46 -0000 Jen, Per your presentation today, slide 11 asking "potential triggers", and slide 12 green and blue paths. The default route as a trigger. An obvious trigger is the presence of the default route. If the Router uses a default route towards ISP1 then it should prefer to advertise on its other interface defrouter capability together with the PIO containing the prefix it has for ISP1. If on the other hand the router uses a default route towards ISP2, then... Alex Le 03/07/2017 à 13:38, Jen Linkova a écrit : > I received some comments off-list, so -01 version has been submitted: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-conditional-ras/ > > - a co-author added; > - some clarification added to the "Topologies with Dedicated Border > Routers" section; > - a lot of typos, missing articles and commas fixed ;) > > > On Thu, Jun 15, 2017 at 4:14 PM, Jen Linkova wrote: >> Well, better late than never, right? So following the discussion on >> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00 >> and the sad fact that default address selection rule 5.5 is not widely >> implemented (yet), I've finally managed to write down how multihoming >> on PA address space could be done now in *some* cases: >> >> https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-00 >> >> Comments are highly appreciated. >> >> P.S. It's '00' version, far from being perfect, I'll keep polish it >> and -01 will be submitted before the IETF99 deadline. >> -- >> SY, Jen Linkova aka Furry > > > From nobody Thu Jul 20 05:23:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5405512EC30 for ; Thu, 20 Jul 2017 05:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0erjxvro6_Ph for ; Thu, 20 Jul 2017 05:22:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 19F8A1300BB for ; Thu, 20 Jul 2017 05:22:42 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6KCF7K3023498; Thu, 20 Jul 2017 08:22:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2bthy4mcdy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 08:22:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6KCMY6K004325; Thu, 20 Jul 2017 08:22:34 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6KCMTp8004150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Jul 2017 08:22:30 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 20 Jul 2017 12:22:17 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Thu, 20 Jul 2017 08:22:16 -0400 From: "STARK, BARBARA H" To: Lorenzo Colitti , Ted Lemon CC: james woodyatt , Gert Doering , "IPv6 Operations" Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt Thread-Index: AQHS/5m9OUisHJyfC0CF4hfBZVASSaJbIQ6AgAACOoCAAWJAAP//6ZIwgABrWICAAADVAP//yWIg Date: Thu, 20 Jul 2017 12:22:15 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBD43BF@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <20170720062428.GK45648@Space.Net> <2D09D61DDFA73D4C884805CC7865E6114DBD3B89@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.229.246] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200192 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:22:47 -0000 PiBSdW5uaW5nIGJvdGggSUFfTkEgYW5kIFNMQUFDIGlzIGNlcnRhaW5seSBub3QgcHJlY2x1ZGVk IGJ5IFJGQyA3OTM0LiBJbiB0aGUgDQo+IHNwZWNpZmljIGNhc2Ugb2YgaG9tZSByb3V0ZXJzLCBS RkMgNzA4NCBzYXlzIHRoZXkgTVVTVCBoYXZlIGEgREhDUHY2IHNlcnZlciwgDQo+IGVpdGhlciBz dGF0ZWZ1bCBvciBzdGF0ZWxlc3MuDQoNCkkgYWdyZWUgY29tcGxldGVseSB0aGF0IFJGQyA3OTM0 IGRvZXMgbm90IHByZWNsdWRlIElBX05BICsgU0xBQUMuIEkgd2FzIG1lcmVseSBvYmplY3Rpbmcg dG8gdGhlIHN0cm9uZ2x5IHdvcmRlZCBzdGF0ZW1lbnQgZnJvbSBHZXJ0IHRoYXQgdGhlcmUgd2Fz IG5vIHJlYXNvbiB0byBkbyBzby4gVGhlcmUgaXMuDQpJJ20gbm90IHN1cmUgb2YgdGhlIHJlbGV2 YW5jZSBvZiB0aGUgUkZDIDcwODQgcmVxdWlyZW1lbnQgaGVyZS4gVGhhdCBqdXN0IG1lYW5zIHRo YXQgc3VwcG9ydCBvZiBJQV9OQSBpcyBvcHRpb25hbCBpbiBDRSByb3V0ZXJzLg0KQmFyYmFyYQ0K From nobody Thu Jul 20 05:23:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62F612EC30 for ; Thu, 20 Jul 2017 05:23:43 -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 fhPV9q0Y9uLQ for ; Thu, 20 Jul 2017 05:23:41 -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 A5B6F1315FF for ; Thu, 20 Jul 2017 05:23:40 -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 v6KCNd8O025478 for ; Thu, 20 Jul 2017 14:23:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 14EEB2071E9 for ; Thu, 20 Jul 2017 14:23: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 025F520719F for ; Thu, 20 Jul 2017 14:23:39 +0200 (CEST) Received: from [132.166.84.163] ([132.166.84.163]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6KCNcEh008163 for ; Thu, 20 Jul 2017 14:23:38 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <2ffbac45-623f-b69d-0297-71a6f373e9eb@gmail.com> Date: Thu, 20 Jul 2017 14:23:38 +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: Subject: Re: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:23:44 -0000 For the case R1, R2, R3: if they are linked together on a single link where ICMP Redirect works then they may take advantage of that. Le 03/07/2017 à 13:38, Jen Linkova a écrit : > I received some comments off-list, so -01 version has been submitted: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-conditional-ras/ > > - a co-author added; > - some clarification added to the "Topologies with Dedicated Border > Routers" section; > - a lot of typos, missing articles and commas fixed ;) > > > On Thu, Jun 15, 2017 at 4:14 PM, Jen Linkova wrote: >> Well, better late than never, right? So following the discussion on >> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00 >> and the sad fact that default address selection rule 5.5 is not widely >> implemented (yet), I've finally managed to write down how multihoming >> on PA address space could be done now in *some* cases: >> >> https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-00 >> >> Comments are highly appreciated. >> >> P.S. It's '00' version, far from being perfect, I'll keep polish it >> and -01 will be submitted before the IETF99 deadline. >> -- >> SY, Jen Linkova aka Furry > > > From nobody Thu Jul 20 05:38:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52923131A5F for ; Thu, 20 Jul 2017 05:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOpdfwYU5Y-y for ; Thu, 20 Jul 2017 05:38:29 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.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 5832C131761 for ; Thu, 20 Jul 2017 05:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1500554304; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RT8Xy7j41mJ3Jinhof2dIMm3jBm9cp9Zs6Qb6atkyZY=; b=v6ozOLjVmyjbKYGBfRC4NsP/UbXS7CCRR3F5ZHPRoQa2PCio/lbFpgnDikzSObhg pnvdWb1bLPUiw+MVY8/kP4J6FzF8uttfnFykyLYavZHqO9A0x4jtqOALGwrFFMI7 MsdodhFT7gKYh1F2+R6lx7YwPmt4TGXmy7NS3AFarhFUAkOPeL7zqvtnfxBC1xnp qWH5NwrTdUNoCeZQlMOH1IDL7p14uZZ3M1WZ1ym7tc7fzHdpXQ9KYtE5dUC5wHkn FkAaJTrj9xGytO7sDxX16Nyf+KoZFJaflu2s0IKcLDvNMjT5RnunLAI5DAGRRHU6 f79dbivCdaNKAs9dkiG53w==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 1A.7C.06273.044A0795; Thu, 20 Jul 2017 13:38:24 +0100 (BST) X-AuditID: 1148940c-1926f9c000001881-f0-5970a440bba7 Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 12.AA.07255.044A0795; Thu, 20 Jul 2017 13:38:24 +0100 (BST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [IPv6:2001:67c:370:1998:a4e2:ef:8005:18a4] (nat64-60.meeting.ietf.org [31.130.238.96]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0OTE00EA433XG680@phonehome3.euro.apple.com>; Thu, 20 Jul 2017 13:38:24 +0100 (IST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Thu, 20 Jul 2017 14:38:20 +0200 Cc: "v6ops@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <9F61A6A1-1252-47BC-8FE5-0D0C6B75C600@apple.com> References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi6GTOo+uwpCDSYMVveYu/xz8zW5w+tpfZ gclj3f4AjyVLfjIFMEVx2aSk5mSWpRbp2yVwZcz9epGp4IFmxb2Ls9gbGBcpdjFyckgImEj0 L3zHCmILCWxnktj21xYmvuvvB6YuRi6g+CFGiW9nuxhBErwCghI/Jt9j6WLk4GAWUJeYMiUX qoZJounte7BBwgLSEl0X7kLZSRIn37cxg9SzCWhJHFhjBBLmFHCSWHVsCguIzSKgKnHz0Ewm EJsZyJ637hQLhK0t8eTdBVaQVl4BG4mjC3wgVrUwSey89ADsHBEBOYm7K1oZIW6Wlbg1+xIz SJGEQCObxJevk9knMArPQnL2LISzZyFZsYCReRWjeG5iZo5uZp6RXmppUb5eYkFBTqpecn7u JkZQeHtM4dnBePGg4SFGAQ5GJR7e2DjfSCHWxLLiylxg8HAwK4nwvplUECnEm5JYWZValB9f VJqTWnyIUZqDRUmc16RUPlJIID2xJDU7NbUgtQgmy8TBKdXAmJXztO2x4bGrn+pPW234K9b6 1Txxm+rpI5mny4S7nl/zfzHviF7x0QMuBpuKTkd03tSKncVRJcRXbb3rj8oKtxndSZ2mXSkz mW9f7Djx5NkX4YQz/F86GSvYT74UDni0YvO8A0sY26IN//7UL3iscilUUs6xMObEvNw/k9Tm lUbcezDtxmXxw0osxRmJhlrMRcWJAI0PiE9rAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi6NEarOuwpCDSYNspWYu/xz8zW5w+tpfZ gclj3f4AjyVLfjIFMEVx2aSk5mSWpRbp2yVwZcz9epGp4IFmxb2Ls9gbGBcpdjFyckgImEjs +vuBqYuRi0NI4BCjxLezXYwgCV4BQYkfk++xdDFycDALqEtMmZILVcMk0fT2PStIjbCAtETX hbtQdpLEyfdtzCD1bAJaEgfWGIGEOQWcJFYdm8ICYrMIqErcPDSTCcRmBrLnrTvFAmFrSzx5 d4EVpJVXwEbi6AIfiFUtTBI7Lz0AO0dEQE7i7opWRoibZSVuzb7EPIFRYBaSS2chXDoLydQF jMyrGEWLUnMSK430UkuL8vUSCwpyUvWS83M3MYIC0smcZwfjq4OGhxgFOBiVeHjXLy6IFGJN LCuuzAWGBwezkgjvm0lAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ry1mkApgfTEktTs1NSC1CKY LBMHp1QDY8OtntaObaV3bZaFzJt0ZeMlmZ5jhV9Da69/LLfhdbwRuSLxz6fbKtv4jEvqVxYI MJqEKK1L+xBw2fzYGynRXdGx83rW+v7hvds7e4FuuLqi0HSpALNepqhP7bHTDWYwdOj+TPtu qHzu/54eGw1HBtP7s2YbuZVO5fg+3Vk47u6U995Hu3N+KrEUZyQaajEXFScCAFmiQYJEAgAA Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:38:32 -0000 The NAT64 prefix acquired using the technique described in RFC7050 is = valid for as long as the DNS AAAA record for ipv4only.arpa. Our implementation respects the DNS timeout and queries the network = again if the prefix is needed after it has expired. David > On Jul 20, 2017, at 14:18, JORDI PALET MARTINEZ = wrote: >=20 > The NSP prefix is something usually very stable in an operator = network. Otherwise you have the same problem if the NSP used for the = NAT64 if is changed quite often. >=20 > Anyway, we may specify some parameter such as lifetime, or something = similar. >=20 > Actually, looking to 7.1. IPv4 Address Literals from = draft-ietf-v6ops-rfc6555bis, the problem is the same, I=E2=80=99m not = sure if the authors have thought already about that issue? >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: Jen Linkova > Responder a: > Fecha: jueves, 20 de julio de 2017, 14:04 > Para: Jordi Palet Martinez > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] FW: New Version Notification for = draft-palet-ietf-v6ops-he-reporting-00.txt >=20 > One thing I forgot to ask at the mic: how does the host know that > syslog address (network prefix) changes/not valid anymore? > Does the discovery process happens every time the interface state > changes? Or....? >=20 > On Tue, Jul 4, 2017 at 1:41 AM, JORDI PALET MARTINEZ > wrote: >> Following my inputs to the update of HE, I=E2=80=99ve summited a new = draft: >>=20 >> Reporting of Happy Eyeballs v2 Failures >>=20 >> I think this could be part of the main document, but just in case, to = avoid missing the cut-off today =E2=80=A6 >>=20 >> Hopefully I can get a few minutes in the next meeting agenda to = discuss about it, and as usual happy to get inputs, alternative = suggestions, etc. >>=20 >> Note that even if the title mentions v2, I think it can work the same = with the existing HE, but to me it makes sense to move on with the new = version and include this reporting procedure. >>=20 >> Regards, >> Jordi >>=20 >>=20 >> -----Mensaje original----- >> De: >> Responder a: >> Fecha: lunes, 3 de julio de 2017, 17:36 >> Para: Jordi Palet , Jordi Palet Martinez = >> Asunto: New Version Notification for = draft-palet-ietf-v6ops-he-reporting-00.txt >>=20 >>=20 >> A new version of I-D, draft-palet-ietf-v6ops-he-reporting-00.txt >> has been successfully submitted by Jordi Palet Martinez and posted = to the >> IETF repository. >>=20 >> Name: draft-palet-ietf-v6ops-he-reporting >> Revision: 00 >> Title: Reporting of Happy Eyeballs v2 Failures >> Document date: 2017-07-03 >> Group: Individual Submission >> Pages: 4 >> URL: = https://www.ietf.org/internet-drafts/draft-palet-ietf-v6ops-he-reporting-0= 0.txt >> Status: = https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-he-reporting/ >> Htmlized: = https://tools.ietf.org/html/draft-palet-ietf-v6ops-he-reporting-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-palet-ietf-v6ops-he-reporting-= 00 >>=20 >>=20 >> Abstract: >> This document describes an extension to Happy Eyeballs in order = to >> report IPv6 failures that force the fall-back to IPv4. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged = or confidential. 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 disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 > SY, Jen Linkova aka Furry >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. 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 disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 20 05:45:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5652C129B43 for ; Thu, 20 Jul 2017 05:45:18 -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 lVS_p2Oc1SLL for ; Thu, 20 Jul 2017 05:45:16 -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 7D910131471 for ; Thu, 20 Jul 2017 05:45:16 -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 v6KCjFBE027728; Thu, 20 Jul 2017 05:45:15 -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 v6KCj6Yg027528 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Thu, 20 Jul 2017 05:45: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; Thu, 20 Jul 2017 05:45:06 -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; Thu, 20 Jul 2017 05:45:06 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras Thread-Index: AQHTAVMPPvr63Iw1QE+kYBUP3DXDyaJcqM2w Date: Thu, 20 Jul 2017 12:45:06 +0000 Message-ID: References: <2ffbac45-623f-b69d-0297-71a6f373e9eb@gmail.com> In-Reply-To: <2ffbac45-623f-b69d-0297-71a6f373e9eb@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: Subject: Re: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:45:18 -0000 SGksIHNvbWVvbmUgYXQgdGhlIG1pa2UganVzdCBub3cgc3VnZ2VzdGVkIHRoZSBwb3NzaWJsZSB1 c2Ugb2YgUklPcyBmb3IgdGhpcy4NClBsZWFzZSBzZWUgb3VyIGRyYWZ0IG9uIHRoaXMgc3ViamVj dCBmcm9tIDZtYW46DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRl bXBsaW4tNm1hbi1yaW8tcmVkaXJlY3QvDQoNClRoYW5rcyAtIEZyZWQNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3UNCj4gU2VudDogVGh1cnNkYXks IEp1bHkgMjAsIDIwMTcgNToyNCBBTQ0KPiBUbzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFt2Nm9wc10gRW50ZXJwcmlzZSBtdWx0aWhvbWluZyAoYWdhaW4pOiBkcmFmdC1saW5rb3Zh LXY2b3BzLWNvbmRpdGlvbmFsLXJhcw0KPiANCj4gRm9yIHRoZSBjYXNlIFIxLCBSMiwgUjM6IGlm IHRoZXkgYXJlIGxpbmtlZCB0b2dldGhlciBvbiBhIHNpbmdsZSBsaW5rDQo+IHdoZXJlIElDTVAg UmVkaXJlY3Qgd29ya3MgdGhlbiB0aGV5IG1heSB0YWtlIGFkdmFudGFnZSBvZiB0aGF0Lg0KPiAN Cj4gTGUgMDMvMDcvMjAxNyDDoCAxMzozOCwgSmVuIExpbmtvdmEgYSDDqWNyaXQgOg0KPiA+IEkg cmVjZWl2ZWQgc29tZSBjb21tZW50cyBvZmYtbGlzdCwgc28gLTAxIHZlcnNpb24gaGFzIGJlZW4g c3VibWl0dGVkOg0KPiA+DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbGlua292YS12Nm9wcy1jb25kaXRpb25hbC1yYXMvDQo+ID4NCj4gPiAtIGEgY28tYXV0aG9y IGFkZGVkOw0KPiA+IC0gc29tZSBjbGFyaWZpY2F0aW9uIGFkZGVkIHRvIHRoZSAiVG9wb2xvZ2ll cyB3aXRoIERlZGljYXRlZCBCb3JkZXINCj4gPiBSb3V0ZXJzIiBzZWN0aW9uOw0KPiA+IC0gYSBs b3Qgb2YgdHlwb3MsIG1pc3NpbmcgYXJ0aWNsZXMgYW5kIGNvbW1hcyBmaXhlZCA7KQ0KPiA+DQo+ ID4NCj4gPiBPbiBUaHUsIEp1biAxNSwgMjAxNyBhdCA0OjE0IFBNLCBKZW4gTGlua292YSA8ZnVy cnkxM0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+PiBXZWxsLCBiZXR0ZXIgbGF0ZSB0aGFuIG5ldmVy LCByaWdodD8gU28gZm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIG9uDQo+ID4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLWVudGVycHJpc2UtcGEtbXVsdGlob21p bmctMDANCj4gPj4gYW5kIHRoZSBzYWQgZmFjdCB0aGF0IGRlZmF1bHQgYWRkcmVzcyBzZWxlY3Rp b24gcnVsZSA1LjUgaXMgbm90IHdpZGVseQ0KPiA+PiBpbXBsZW1lbnRlZCAoeWV0KSwgSSd2ZSBm aW5hbGx5IG1hbmFnZWQgdG8gd3JpdGUgZG93biBob3cgbXVsdGlob21pbmcNCj4gPj4gb24gUEEg YWRkcmVzcyBzcGFjZSBjb3VsZCBiZSBkb25lIG5vdyBpbiAqc29tZSogY2FzZXM6DQo+ID4+DQo+ ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5rb3ZhLXY2b3BzLWNvbmRp dGlvbmFsLXJhcy0wMA0KPiA+Pg0KPiA+PiBDb21tZW50cyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVk Lg0KPiA+Pg0KPiA+PiBQLlMuIEl0J3MgJzAwJyB2ZXJzaW9uLCBmYXIgZnJvbSBiZWluZyBwZXJm ZWN0LCBJJ2xsIGtlZXAgcG9saXNoIGl0DQo+ID4+IGFuZCAtMDEgd2lsbCBiZSBzdWJtaXR0ZWQg YmVmb3JlIHRoZSBJRVRGOTkgZGVhZGxpbmUuDQo+ID4+IC0tDQo+ID4+IFNZLCBKZW4gTGlua292 YSBha2EgRnVycnkNCj4gPg0KPiA+DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Jul 20 05:52:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA0131771 for ; Thu, 20 Jul 2017 05:52: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] 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 wiAKhWP0SjxD for ; Thu, 20 Jul 2017 05:52:27 -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 2CF181315FF for ; Thu, 20 Jul 2017 05:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500554494; x=1501159294; 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=R4pqkot83YX7vwKtpYuf4wynn rgg3IdRDGwHsayJJio=; b=RXCFHbFqqn22SSRx8KdGPNd17OGjsL40EyabV0OGj TLsDfaUfPxV6Kuj7bqwLfTDrfALJZ45YBein1cjHxuHC2MmRXDQjur/ZX5Mzt9Ct HzyqsW3IsEBhZuHb9Upf9DFDsnzsr8VRtVJWa6F3WpjAg8JCArcwMb9Pu0fzDJr+ YI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ArcX2+8jbgAJJzqNxF1VwjtfoLQ/UMBppK8DjgW9Bx319qk6QGOvGnppZbV4 0pA9kM0qMZ9XCEOdrsz2OIRjUg5flVBPvO1PpLC2vG2mN3Zt4bOwJDMNw iwt6kDWE7bVBcNyFawqICF1OwG9X0Lgho3JW9Xvt6OHmXbQzDhvhqQ=; X-MDAV-Processed: mail.consulintel.es, Thu, 20 Jul 2017 14:41:34 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 20 Jul 2017 14:41:33 +0200 Received: from [31.133.142.45] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005481792.msg for ; Thu, 20 Jul 2017 14:41:32 +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:170720:md50005481792::1UCKxUApJmIGcPVH:00003jF7 X-MDRemoteIP: 31.133.142.45 X-Return-Path: prvs=137477960e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 14:41:29 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> <9F61A6A1-1252-47BC-8FE5-0D0C6B75C600@apple.com> In-Reply-To: <9F61A6A1-1252-47BC-8FE5-0D0C6B75C600@apple.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: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:52:29 -0000 Right, and very obvious, being a DNS mechanism, the solution is already the= re =E2=80=A6 Thanks! Regards, Jordi =20 -----Mensaje original----- De: en nombre de David Schinazi Responder a: Fecha: jueves, 20 de julio de 2017, 14:38 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops= -he-reporting-00.txt The NAT64 prefix acquired using the technique described in RFC7050 is v= alid for as long as the DNS AAAA record for ipv4only.arpa. Our implementation respects the DNS timeout and queries the network aga= in if the prefix is needed after it has expired. =20 David =20 =20 > On Jul 20, 2017, at 14:18, JORDI PALET MARTINEZ wrote: >=20 > The NSP prefix is something usually very stable in an operator networ= k. Otherwise you have the same problem if the NSP used for the NAT64 if is = changed quite often. >=20 > Anyway, we may specify some parameter such as lifetime, or something = similar. >=20 > Actually, looking to 7.1. IPv4 Address Literals from draft-ietf-v6op= s-rfc6555bis, the problem is the same, I=E2=80=99m not sure if the authors = have thought already about that issue? >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: Jen Linkova > Responder a: > Fecha: jueves, 20 de julio de 2017, 14:04 > Para: Jordi Palet Martinez > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-ietf= -v6ops-he-reporting-00.txt >=20 > One thing I forgot to ask at the mic: how does the host know that > syslog address (network prefix) changes/not valid anymore? > Does the discovery process happens every time the interface state > changes? Or....? >=20 > On Tue, Jul 4, 2017 at 1:41 AM, JORDI PALET MARTINEZ > wrote: >> Following my inputs to the update of HE, I=E2=80=99ve summited a new= draft: >>=20 >> Reporting of Happy Eyeballs v2 Failures >>=20 >> I think this could be part of the main document, but just in case, t= o avoid missing the cut-off today =E2=80=A6 >>=20 >> Hopefully I can get a few minutes in the next meeting agenda to disc= uss about it, and as usual happy to get inputs, alternative suggestions, et= c. >>=20 >> Note that even if the title mentions v2, I think it can work the sam= e with the existing HE, but to me it makes sense to move on with the new ve= rsion and include this reporting procedure. >>=20 >> Regards, >> Jordi >>=20 >>=20 >> -----Mensaje original----- >> De: >> Responder a: >> Fecha: lunes, 3 de julio de 2017, 17:36 >> Para: Jordi Palet , Jordi Palet Martinez= >> Asunto: New Version Notification for draft-palet-ietf-v6ops-he-repor= ting-00.txt >>=20 >>=20 >> A new version of I-D, draft-palet-ietf-v6ops-he-reporting-00.txt >> has been successfully submitted by Jordi Palet Martinez and poste= d to the >> IETF repository. >>=20 >> Name: draft-palet-ietf-v6ops-he-reporting >> Revision: 00 >> Title: Reporting of Happy Eyeballs v2 Failures >> Document date: 2017-07-03 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-palet-= ietf-v6ops-he-reporting-00.txt >> Status: https://datatracker.ietf.org/doc/draft-palet-ietf= -v6ops-he-reporting/ >> Htmlized: https://tools.ietf.org/html/draft-palet-ietf-v6op= s-he-reporting-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-palet= -ietf-v6ops-he-reporting-00 >>=20 >>=20 >> Abstract: >> This document describes an extension to Happy Eyeballs in orde= r to >> report IPv6 failures that force the fall-back to IPv4. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of= submission >> until the htmlized version and diff are available at tools.ietf.o= rg. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged= or confidential. The information is intended to be for the use of the indi= vidual(s) named above. If you are not the intended recipient be aware that = any disclosure, copying, distribution or use of the contents of this inform= ation, including attached files, is prohibited. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 > SY, Jen Linkova aka Furry >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =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 Jul 20 05:56:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CCD1317E3; Thu, 20 Jul 2017 05:56: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 coHT-TNMHZuz; Thu, 20 Jul 2017 05:56:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2FE12EBFA; Thu, 20 Jul 2017 05:56:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRQ35177; Thu, 20 Jul 2017 12:56:23 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 13:56:21 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 20 Jul 2017 20:56:09 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , "v6ops@ietf.org WG" CC: "draft-ietf-v6ops-ula-usage-considerations@ietf.org" Thread-Topic: Comments on ULA draft Thread-Index: AdMBV42m3ihfTVs+RlaPYFuXOnBmuw== Date: Thu, 20 Jul 2017 12:56:09 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2@nkgeml514-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.76.208] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5970A877.00CB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1743d57c20dee54244f48e944840cebe Archived-At: Subject: Re: [v6ops] Comments on ULA draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:56:28 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2nkgeml514mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhhbmtzIG11Y2ggZm9yIHlvdXIgc3VtbWFyeSBpbiB0aGUgbWFpbGlu ZyBsaXN0LiBSZXBsaWVzIGlubGluZS4NCg0K5Y+R5Lu25Lq6OiBMb3JlbnpvIENvbGl0dGkgW21h aWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ35pyIMjDml6Ug MTQ6MjENCuaUtuS7tuS6ujogdjZvcHNAaWV0Zi5vcmcgV0cgPHY2b3BzQGlldGYub3JnPg0K5oqE 6YCBOiBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1jb25zaWRlcmF0aW9uc0BpZXRmLm9yZw0K 5Li76aKYOiBDb21tZW50cyBvbiBVTEEgZHJhZnQNCg0KUmVwZWF0aW5nIHRoZSBjb21tZW50cyBh dCB0aGUgbWlrZToNCg0KICAxLiAgQXMgY2xlYXJseSBzaG93biBpbiB0aGUgcHJlc2VudGF0aW9u cyBzbGlkZXMsIGFuZCBhcyBzYWlkIGJ5IG90aGVycywgdGhlcmUgd2lsbCBjb250aW51ZSB0byBi ZSBpcyBzdWJzdGFudGlhbCBvcHBvc2l0aW9uIHRvIGFueSBkb2N1bWVudCB1bmxlc3MgaXQgc2F5 cyB0aGF0IFVMQStOUFR2NiBkZXBsb3ltZW50cyBhcmUgTk9UIFJFQ09NTUVOREVELiBUaGUgY3Vy cmVudCB0ZXh0IGluIHNlY3Rpb24gNC4zIGlzIHZlcnkgZmFyIGZyb20gbWFraW5nIHN1Y2ggYSBz dGF0ZW1lbnQuDQpbQmluZ10gTm8gcHJvYmxlbSBmb3IgbWUgaWYgaXQgZG9lc27igJl0IGV4Y2Vl ZCB0aGUgbGV2ZWwgb2YgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC4NCg0KICAxLiAgVGhlIGRv Y3VtZW50IG5lZWRzIHRvIGJlIGNsZWFyIHRoYXQgYmVjYXVzZSBVTEFzIE1VU1QgYmUgZ2VuZXJh dGVkIHJhbmRvbWx5IChwZXIgUkZDIDQxOTMpLCB0aGV5IGFyZSBub3QgYWdncmVnYXRhYmxlLiBU aHVzLCBkZXZlbG9waW5nIFVMQSBmaXJld2FsbCBwb2xpY2llcyBpcyB2ZXJ5IGNvbXBsZXggYmVj YXVzZSB0aGVyZSBpcyBubyB3YXkgdG8gZW5zdXJlIHRoYXQgLzQ4cyB3aXRoIHNpbWlsYXIgc2Vj dXJpdHkgcG9saWNpZXMgaGF2ZSBhZGphY2VudCBhZGRyZXNzIHNwYWNlLiBFdmVuIGlmIFVMQSBp cyBpbml0aWFsbHkgZGVwbG95ZWQgaW4gYSBuZXR3b3JrIHRoYXQgaGFzIG9ubHkgdHdvIHpvbmVz ICgicHVibGljIiBhbmQgInByaXZhdGUiKSBuZXR3b3JrIGdyb3d0aCBvciBtZXJnZXJzIHdpdGgg b3RoZXIgbmV0d29ya3Mgd2lsbCBjYXVzZSBmaXJld2FsbCBwb2xpY2llcyB0byBiZWNvbWUgY29t cGxleCBhbmQgaGF2ZSBsb3RzIG9mIGhvbGVzLg0KW0JpbmddIEkgZ3Vlc3MgdGhlIGZpcmV3YWxs IGF0IHRoZSBlZGdlIG9mIHB1YmxpYyBhbmQgcHJpdmF0ZSBjYW4gc2ltcGx5IGJsb2NrIGFsbCBG RDo6LyBwcmVmaXg/IEZvciBpbnRlcm5hbCBmaXJld2FsbHMsIGlmIGl0IG5lZWRzIHRvIGJsb2Nr IHNvbWUgc3BlY2lmaWMgYWRkcmVzc2VzL3ByZWZpeGVzLCBlaXRoZXIgdXNpbmcgVUxBcyBvciBQ QXMsIGFkbWlucyBib3RoIG5lZWQgdG8gY29uZmlndXJlIHNwZWNpZmljIHJ1bGVzLCBzbyBJIHRo aW5rIFVMQXMgYW5kIFBBcyBhcmUganVzdCBlcXVhbCBvbiB0aGlzIHBvaW50Pw0KQnR3LCB0aGUg YWRtaW5zIGNvdWxkIHJhbmRvbWx5IGdlbmVyYXRlZCBhIHNpbmdsZSBvbmUgNDgvIFVMQSBwcmVm aXgsIGFuZCBhbm5vdW5jZSBpdCBpbnRlcm5hbGx5LCB0aGVyZSBhcmUgc3RpbGwgMTZiaXQgZm9y IHN1Yi1vcmdhbml6YXRpb24uIFNvLCB0aGlzIGNvdWxkIGJlIGNvbnNpZGVyZWQgYXMga2luZCBv ZiBhZ2dyZWdhdGlvbj8uDQoNCiAgMS4gIFRoZSBkb2N1bWVudCBzaG91bGQgc2F5IHRoYXQgZXZl biB0aG91Z2ggVUxBcyBhcmUgdHlwaWNhbGx5IG5vdCBhbm5vdW5jZWQgZXh0ZXJuYWxseSwgYW55 IG5ldHdvcmsgdGhhdCBpcyBhZGphY2VudCB0byB0aGUgVUxBIG5ldHdvcmsgY2FuIHNlbmQgYW5k IHJlY2VpdmUgcGFja2V0cyBmcm9tIFVMQSBhZGRyZXNzZXMgdW5sZXNzIHRoZXJlIGlzIGEgZmly ZXdhbGwgcnVsZSB0aGF0IGJsb2NrcyBzdWNoIHBhY2tldHMuIEZvciB3ZWxsLWNvbm5lY3RlZCBu ZXR3b3JrcyB0aGF0IGhhdmUgbG90cyBvZiBwZWVycywgdGhhdCBjYW4gYmUgYSBsYXJnZSBhdHRh Y2sgc3VyZmFjZS4NCltCaW5nXSBPaywgdGhhbmtzLg0KDQogIDEuICBEdWUgdG8gIzIgYW5kICMz LCBpdCBtYXkgd2VsbCBiZSBzaW1wbGVyIHRvIHVzZSBnbG9iYWwgc3BhY2UgYW5kIGp1c3QgYWRk IGEgZmlyZXdhbGwuDQpbQmluZ10gVUxBcyBhcmUgbW9zdGx5IGZvcg0KDQoxKSAgICAgICBhdXRv bWF0aW9uLCB0aGF0IHNvbWUgbWVjaGFuaXNtcyBjYW4gc2VsZi1nZW5lcmF0ZSB2YWxpZCBJUHY2 IGFkZHJlc3NlcyB3aXRob3V0IGFueSBwcm92aXNpb25pbmcuIEUuZy4gQlRNTShodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjI4MSNzZWN0aW9uLTYuMyksIGFuZCBBbmltYSBBQ1AgYWRk cmVzc2luZyhodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1hdXRv bm9taWMtY29udHJvbC1wbGFuZS0wOCNzZWN0aW9uLTYuMTApLg0KDQoyKSAgICAgICBJbnN0YW50 IHVzYWdlIHdpdGhvdXQgYXBwbHlpbmcgdG8gTElSL1JJUi4NCiAgICAgICAgICAgICAgVUxBcyBk b27igJl0IGhhdmUgYW55IHNlY3VyaXR5IGFkdmFudGFnZXMgdGhhbiBQQSBhZGRyZXNzZXMuIEZv ciBmaXJld2FsbCBwb2xpY2llcywgSSBzZWUgbm8gZXh0cmEgYnVyZGVuIGFjY29yZGluZyB0byBt eSBwb29yIGV4cGVyaWVuY2UuIElmIHRoZXJlIGlzLCBJ4oCZZCBsaWtlIHRvIGluY2x1ZGUgaXQg aW4gdGhlIGRvY3VtZW50LiBUaGFua3MuDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNClJlZ2FyZHMs DQpMb3JlbnpvDQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2nkgeml514mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5k ZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA5ODM1NTI2NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTY5MzgzMzkzNDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRleHQ6IiUyXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgbXVjaCBmb3IgeW91ciBz dW1tYXJ5IGluIHRoZSBtYWlsaW5nIGxpc3QuIFJlcGxpZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0K PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVT Ij43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+DQogMTQ6MjE8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gdjZvcHNAaWV0Zi5vcmcgV0cgJmx0O3Y2 b3BzQGlldGYub3JnJmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2Fn ZS1jb25zaWRlcmF0aW9uc0BpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBDb21tZW50cyBvbiBVTEEg ZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVwZWF0aW5nIHRoZSBjb21t ZW50cyBhdCB0aGUgbWlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPG9sIHN0YXJ0 PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkFzIGNsZWFybHkgc2hvd24gaW4gdGhlIHByZXNl bnRhdGlvbnMgc2xpZGVzLCBhbmQgYXMgc2FpZCBieSBvdGhlcnMsIHRoZXJlIHdpbGwgY29udGlu dWUgdG8gYmUgaXMgc3Vic3RhbnRpYWwgb3Bwb3NpdGlvbiB0byBhbnkgZG9jdW1lbnQgdW5sZXNz IGl0IHNheXMgdGhhdCBVTEEmIzQzO05QVHY2IGRlcGxveW1lbnRzIGFyZSBOT1QgUkVDT01NRU5E RUQuIFRoZSBjdXJyZW50IHRleHQgaW4gc2VjdGlvbiA0LjMgaXMgdmVyeQ0KIGZhciBmcm9tIG1h a2luZyBzdWNoIGEgc3RhdGVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bQmluZ10gTm8gcHJvYmxlbSBmb3IgbWUgaWYgaXQg ZG9lc27igJl0IGV4Y2VlZCB0aGUgbGV2ZWwgb2YgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+VGhlIGRvY3VtZW50IG5lZWRzIHRvIGJlIGNsZWFyIHRoYXQgYmVjYXVzZSBVTEFzIE1VU1Qg YmUgZ2VuZXJhdGVkIHJhbmRvbWx5IChwZXIgUkZDIDQxOTMpLCB0aGV5IGFyZSBub3QgYWdncmVn YXRhYmxlLiBUaHVzLCBkZXZlbG9waW5nIFVMQSBmaXJld2FsbCBwb2xpY2llcyBpcyB2ZXJ5IGNv bXBsZXggYmVjYXVzZSB0aGVyZSBpcyBubyB3YXkgdG8gZW5zdXJlIHRoYXQgLzQ4cyB3aXRoIHNp bWlsYXIgc2VjdXJpdHkNCiBwb2xpY2llcyBoYXZlIGFkamFjZW50IGFkZHJlc3Mgc3BhY2UuIEV2 ZW4gaWYgVUxBIGlzIGluaXRpYWxseSBkZXBsb3llZCBpbiBhIG5ldHdvcmsgdGhhdCBoYXMgb25s eSB0d28gem9uZXMgKCZxdW90O3B1YmxpYyZxdW90OyBhbmQgJnF1b3Q7cHJpdmF0ZSZxdW90Oykg bmV0d29yayBncm93dGggb3IgbWVyZ2VycyB3aXRoIG90aGVyIG5ldHdvcmtzIHdpbGwgY2F1c2Ug ZmlyZXdhbGwgcG9saWNpZXMgdG8gYmVjb21lIGNvbXBsZXggYW5kIGhhdmUgbG90cyBvZiBob2xl cy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W0JpbmddIEkgZ3Vlc3MgdGhlIGZpcmV3YWxsIGF0IHRoZSBlZGdlIG9mIHB1YmxpYyBh bmQgcHJpdmF0ZSBjYW4gc2ltcGx5IGJsb2NrIGFsbCBGRDo6LyBwcmVmaXg/IEZvciBpbnRlcm5h bCBmaXJld2FsbHMsIGlmIGl0IG5lZWRzIHRvIGJsb2NrIHNvbWUgc3BlY2lmaWMgYWRkcmVzc2Vz L3ByZWZpeGVzLA0KIGVpdGhlciB1c2luZyBVTEFzIG9yIFBBcywgYWRtaW5zIGJvdGggbmVlZCB0 byBjb25maWd1cmUgc3BlY2lmaWMgcnVsZXMsIHNvIEkgdGhpbmsgVUxBcyBhbmQgUEFzIGFyZSBq dXN0IGVxdWFsIG9uIHRoaXMgcG9pbnQ/ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdHcsIHRoZSBhZG1pbnMgY291bGQgcmFuZG9t bHkgZ2VuZXJhdGVkIGEgc2luZ2xlIG9uZSA0OC8gVUxBIHByZWZpeCwgYW5kIGFubm91bmNlIGl0 IGludGVybmFsbHksIHRoZXJlIGFyZSBzdGlsbCAxNmJpdCBmb3Igc3ViLW9yZ2FuaXphdGlvbi4g U28sIHRoaXMgY291bGQgYmUgY29uc2lkZXJlZA0KIGFzIGtpbmQgb2YgYWdncmVnYXRpb24/Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdGFydD0iMyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGUgZG9jdW1lbnQgc2hvdWxkIHNheSB0aGF0IGV2ZW4gdGhvdWdoIFVMQXMgYXJlIHR5cGlj YWxseSBub3QgYW5ub3VuY2VkIGV4dGVybmFsbHksIGFueSBuZXR3b3JrIHRoYXQgaXMgYWRqYWNl bnQgdG8gdGhlIFVMQSBuZXR3b3JrIGNhbiBzZW5kIGFuZCByZWNlaXZlIHBhY2tldHMgZnJvbSBV TEEgYWRkcmVzc2VzIHVubGVzcyB0aGVyZSBpcyBhIGZpcmV3YWxsIHJ1bGUgdGhhdCBibG9ja3Mg c3VjaCBwYWNrZXRzLg0KIEZvciB3ZWxsLWNvbm5lY3RlZCBuZXR3b3JrcyB0aGF0IGhhdmUgbG90 cyBvZiBwZWVycywgdGhhdCBjYW4gYmUgYSBsYXJnZSBhdHRhY2sgc3VyZmFjZS48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0Jpbmdd IE9rLCB0aGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSI0IiB0eXBlPSIx Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNw YW4gbGFuZz0iRU4tVVMiPkR1ZSB0byAjMiBhbmQgIzMsIGl0IG1heSB3ZWxsIGJlIHNpbXBsZXIg dG8gdXNlIGdsb2JhbCBzcGFjZSBhbmQganVzdCBhZGQgYSBmaXJld2FsbC48bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0JpbmddIFVM QXMgYXJlIG1vc3RseSBmb3INCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5hdXRvbWF0aW9uLCB0aGF0IHNvbWUgbWVjaGFuaXNtcyBjYW4gc2VsZi1nZW5lcmF0ZSB2YWxp ZCBJUHY2IGFkZHJlc3NlcyB3aXRob3V0IGFueSBwcm92aXNpb25pbmcuIEUuZy4gQlRNTShodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI4MSNzZWN0aW9uLTYuMyksDQogYW5kIEFuaW1h IEFDUCBhZGRyZXNzaW5nKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFu aW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTA4I3NlY3Rpb24tNi4xMCkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluc3RhbnQgdXNhZ2Ugd2l0aG91dCBhcHBseWlu ZyB0byBMSVIvUklSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVUxBcyBkb27igJl0IGhhdmUgYW55IHNlY3VyaXR5IGFkdmFudGFnZXMgdGhh biBQQSBhZGRyZXNzZXMuIEZvciBmaXJld2FsbA0KIHBvbGljaWVzLCBJIHNlZSBubyBleHRyYSBi dXJkZW4gYWNjb3JkaW5nIHRvIG15IHBvb3IgZXhwZXJpZW5jZS4gSWYgdGhlcmUgaXMsIEnigJlk IGxpa2UgdG8gaW5jbHVkZSBpdCBpbiB0aGUgZG9jdW1lbnQuIFRoYW5rcy4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxvcmVuem88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2nkgeml514mbxchi_-- From nobody Thu Jul 20 06:04:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAFE126E3A for ; Thu, 20 Jul 2017 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xB7d2OjELCe for ; Thu, 20 Jul 2017 06:04:40 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FD6131761 for ; Thu, 20 Jul 2017 06:04:37 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id h199so15411659ith.1 for ; Thu, 20 Jul 2017 06:04:37 -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=ltrVFushlBB89bWIYP3AtrMFfOd0xY3yZYLfzDVVWTk=; b=AN1B9NTtOnpxLb8jZPKVMd9nD/wKAsttsecKyCG10Il+jD4XHNWCVB1dAu+/m+h0Se PvfOPLCydYDmjdq3okKnq6RSlEpB4UMCUE+JaQnr0ibO6F4RYXHy82x6bTXMkn/8SbHz 2ZiJafv+qHWw1ASJD1tNByICPQVIZjyx3bi0te8zrHvN7ZhXYBTCUQ2n7ck8ox5LJi95 Fccxws8Jn2Xocs4V9i7NqLd8L7rv8kpi9cvJYRtMFM6Duj9wZInU7NlkErno0OZiTfA1 i7Z2vNzWxYM16Yml5hrkIowjHSCiYHYMFdwSQe3Qlnr6B45NLOYBAgA5eplGQqSbYtds PTBQ== 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=ltrVFushlBB89bWIYP3AtrMFfOd0xY3yZYLfzDVVWTk=; b=gVWeA77bN2j5OAD+673AxAzp2Tk1/x0YdnQRWNeXsz+j9fPiB31Ctyct6pGuXqfe8J N/+ipYJnB1oQH0H5/GbMvVYFcvjeOy4l5vTEwqFxqUCrDmYpd7N1KocPqHVowurErk97 yD0xKB3decC43e6xKKgI2hiftGU06oVEo0aPEAwoMQJnaHTtK5Qf3fRMtvLw/1yw8iQ9 kLy72WSMlT9AKMQG4ga6EMAkGkhn/VJAXEVm72KeF9v3ijN9SmNIQ1/nyzZIyPhkXj04 b1eVfemWqT/BjEiFUUJDOt0JdzasDgAgMApFRjrv/lAce6LXsYlEJlCOc1M7F8KpOlwN 5S2A== X-Gm-Message-State: AIVw112I24hmREZ/1OJTknzd0YY8b/xRriokyH3K78pk1Unq2uB7RbtE hLaj63upoXQAbw/R0c5kUdFhCTV5B1at X-Received: by 10.36.87.5 with SMTP id u5mr2974691ita.151.1500555876946; Thu, 20 Jul 2017 06:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 06:04:15 -0700 (PDT) In-Reply-To: <20170720121626.GB45648@Space.Net> References: <149909620825.22739.6235807821692098805.idtracker@ietfa.amsl.com> <8D581E5F-2BD5-4007-B5AE-2CB78F8E18DE@consulintel.es> <20170720121626.GB45648@Space.Net> From: Jen Linkova Date: Thu, 20 Jul 2017 23:04:15 +1000 Message-ID: To: Gert Doering Cc: Jordi Palet Martinez , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:04:42 -0000 On Thu, Jul 20, 2017 at 10:16 PM, Gert Doering wrote: > On Thu, Jul 20, 2017 at 10:04:15PM +1000, Jen Linkova wrote: >> One thing I forgot to ask at the mic: how does the host know that >> syslog address (network prefix) changes/not valid anymore? >> Does the discovery process happens every time the interface state >> changes? Or....? > > We are turning in cycles. > > Obviously DHCPv6 is not a good match if you run it in a volatile > environment, like "on an android phone used as a tethering CPE". Nobody > is challenging that. Wait, what? Does Gmail (or some intermediate SMTP server) keep corrupting my emails? It looks like the text I sent is very different from the text you received....I was talking about Jordi's proposal to use DNS to discover the syslog server. Did you receive an email about DCHPv6? Or did my email ended up in the wrong thread about another draft?? ;) > OTOH, in a fully managed environment, syslog hosts, network prefixes, > DNS recusors (<< the usual straw man) do not change "just so, and > by surprise" - this is known beforehand, planned, old and new system > exist in parallel (or old/new address, at least) and then you roll > out the change to the clients. Which totally voids that argument. I was actually talking about the scenario when I have two ISP connections at home. Or move from the corporate network to my home one. -- SY, Jen Linkova aka Furry From nobody Thu Jul 20 06:09:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9812EBFA for ; Thu, 20 Jul 2017 06:09:55 -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 5Ul7mHydflaX for ; Thu, 20 Jul 2017 06:09:54 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B8E126E3A for ; Thu, 20 Jul 2017 06:09:53 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id a62so15861704itd.1 for ; Thu, 20 Jul 2017 06:09:53 -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=eZUTdh9bHeMFMgK4Aq08RPpr7XgBEB8YDmcQcubeBnI=; b=XaOK/vBMCGSxyAcYnpAlnwJ2PYjJCuc4Kg042NF8m1aWNQeNuHB1qMOM4+1JZfEPNm tW/UghpxmjCSZl9dyU7+TFi5NiOQOQ9+UUUJyw2LyMDqK0JjYUGzMckb/KY0bmkGQoXm SJZJazKCG2iHGxiFp47U3vBnN3CPre5kqPChE1q0Vun5uQv5+6cJ0V2Rbfqly1MItimr 3p3yDlpJPfI3M5Xj92IB7f7YsEtbH8JhA6Wj9xjIq9P47OiAD4l7rAIwJoN1SDn5Ruva FZgZWar4xm4WRNRGCLsk/Aptt7l3J9q27fJ+mRzajeCg7TKR8WxNd/A4TJSqOJfqlbbQ lHVw== 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=eZUTdh9bHeMFMgK4Aq08RPpr7XgBEB8YDmcQcubeBnI=; b=IkOE23PgqpEP0l+dmuMUxLua+IbusOj6YbLka0ZSbrDkmnY7SyDecniQAj2/+lDn3u 5BnkdqtMAW5mokqqH0kvnfZ9GiPnEEJl4+3GA+pCr9TXU4S/R+ByyyoPnpXE5NSsSWZT DnFs0m6mprPL0EoIDUnGD2ZH6laEp7XAR7qTMPfAGXxU4p2orQkjJi0vQo1t5wC8NNh3 KjfdtfmfbdyiBmJBzVl6xrtq9IgmlWhrxXBaVyt7hycd+wxD+xrzTpEStcOxhHNhlssk RWxGeshlPcEWexcptISfzv5fyXDoDRzsBF63OvAp8KZucnV/DqGJzrygvmdzyZx6zOtO aNRw== X-Gm-Message-State: AIVw112Onl/97z7/+KLAx01wS8I5hGwmY4zzx6Qf2TiG5BgfxR+Zg4OK WAEud2lD0hXHlwWbjMMJ6I7BrCOUm8+F X-Received: by 10.36.198.133 with SMTP id j127mr3345419itg.142.1500556192734; Thu, 20 Jul 2017 06:09:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 06:09:32 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2@nkgeml514-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1DF2@nkgeml514-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 15:09:32 +0200 Message-ID: To: "Liubing (Leo)" Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-considerations@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07dd06d642920554bf760f" Archived-At: Subject: Re: [v6ops] Comments on ULA draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:09:55 -0000 --94eb2c07dd06d642920554bf760f Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 2:56 PM, Liubing (Leo) wrote: > > [Bing] I guess the firewall at the edge of public and private can simply > block all FD::/ prefix? > That only works if there are exactly two zones: public and private. As soon as you have a third zone (e.g., if there is a merger, or a different type of network), every /48 needs to have its own security policy. > For internal firewalls, if it needs to block some specific > addresses/prefixes, either using ULAs or PAs, admins both need to configure > specific rules, so I think ULAs and PAs are just equal on this point? > They're not equal because with global space, multiple /48s that have the same security policy can be grouped into a single shorter prefix that only requires one firewall rule. > Btw, the admins could randomly generated a single one 48/ ULA prefix, and > announce it internally, there are still 16bit for sub-organization. So, > this could be considered as kind of aggregation?. > Yes, but only for a small network. --94eb2c07dd06d642920554bf760f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 2:56 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:


[Bing] I guess the firewall at the edge of public and = private can simply block all FD::/ prefix?


That only works if there are exactly two= zones: public and private. As soon as you have a third zone (e.g., if ther= e is a merger, or a different type of network), every /48 needs to have its= own security policy.
=C2=A0
=

For internal firewalls, if it= needs to block some specific addresses/prefixes, either using ULAs or PAs, admins both need to configure specific rules, so= I think ULAs and PAs are just equal on this point?

<= /div>

They're not equal because w= ith global space, multiple /48s that have the same security policy can be g= rouped into a single shorter prefix that only requires one firewall rule.
=C2=A0

Btw, the admins could randomly generated a si= ngle one 48/ ULA prefix, and announce it internally, there are still 16bit = for sub-organization. So, this could be considered as kind of aggregation?.


Yes, but only for a small network.
--94eb2c07dd06d642920554bf760f-- From nobody Thu Jul 20 07:06:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8D5131461 for ; Thu, 20 Jul 2017 07:06: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 oNizelGo8XFK for ; Thu, 20 Jul 2017 07:06:26 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 2F81912704A for ; Thu, 20 Jul 2017 07:06:26 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1dYC5q-0027J1-Ll; Thu, 20 Jul 2017 16:06:23 +0200 Date: Thu, 20 Jul 2017 16:06:18 +0200 From: David Lamparter To: Jen Linkova Cc: "v6ops@ietf.org" Message-ID: <20170720140618.GA773745@eidolon> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [v6ops] Implementation: draft-linkova-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:06:29 -0000 I've pushed a very minimal implementation to https://github.com/opensourcerouting/frr/tree/cond-ra It just does the bare minimum by setting the preferred lifetime to 0 if, when sending an RA anyway, the prefix can't reach the configured test destination. (Changes do not trigger out-of-schedule RAs yet.) An example config would be: interface dummy0 ipv6 nd prefix 2001:db8:1234:5678::/64 86400 7200 conditional ::/0 first prefix is the prefix advertised, 86400 is valid-lft, 7200 is preferred-lft, conditional ::/0 is the destination to test in the routing table for reachability. This does a lookup with src=2001:db8:1234:5678::/64 dst=::/0 and sets preferred lifetime to zero if no (possibly less specific) route is found. It does not implement any of the other test conditions in the draft (e.g. VRRP status); I think checking route availability should be sufficient. Cheers, -David On Mon, Jul 03, 2017 at 09:38:23PM +1000, Jen Linkova wrote: > I received some comments off-list, so -01 version has been submitted: > > https://datatracker.ietf.org/doc/draft-linkova-v6ops-conditional-ras/ > > - a co-author added; > - some clarification added to the "Topologies with Dedicated Border > Routers" section; > - a lot of typos, missing articles and commas fixed ;) > > > On Thu, Jun 15, 2017 at 4:14 PM, Jen Linkova wrote: > > Well, better late than never, right? So following the discussion on > > https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00 > > and the sad fact that default address selection rule 5.5 is not widely > > implemented (yet), I've finally managed to write down how multihoming > > on PA address space could be done now in *some* cases: > > > > https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-00 > > > > Comments are highly appreciated. > > > > P.S. It's '00' version, far from being perfect, I'll keep polish it > > and -01 will be submitted before the IETF99 deadline. > > -- > > SY, Jen Linkova aka Furry > > > > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 20 07:23:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895A312704A; Thu, 20 Jul 2017 07:23: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 w09TLvetl_rr; Thu, 20 Jul 2017 07:23:03 -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 E3CC6120725; Thu, 20 Jul 2017 07:22:59 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id y43so71452786wrd.3; Thu, 20 Jul 2017 07:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=LV3ZPW+3NdG7BQH3LQdUqBdoECgfOPgVcpp5dJ8SglI=; b=E87cmHA5Hyj6t6XJhpM1rEMRgmAMfhpGjDneX6r9u/Plnv/bbmN3dhLLNwV0oWQ3lu 9c6+SieUMSyiuyPSoSPDLRi0hXQ7pPKUVTny2waozM9cn2LMpU5o0Dc3TCGDgvrZwD/T T4AFpvC7j1ZTL49w+ZSyXRJqufQLWVOPcBpItWsDBmCFS3fuFhYmIHac5Fq3z8Wp24AB /2JvvzHqv2/+UBBRtgD8dUGCg+FOgOEMrOY3kjPXN/z3tZtpmomVPnccDN6f55ohViUa DS1MgyArfkszq6rZf/gsMCVB0wN/8GBOiJYRmaLSO5ByYvIHYYZBQ/zbrevsgVxlrqQn ntLA== 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:message-id:date:cc:to; bh=LV3ZPW+3NdG7BQH3LQdUqBdoECgfOPgVcpp5dJ8SglI=; b=DdKwwIkWNxxE5gTrlsmuu/ynoQHzDZRaKjNZZe+ryWCv+RzhD/LfkE72gR2ZCV/dh9 +HL6+EOBlCURCpdvPvRSTIta11xysO82CiUjqC/MJgzlT2d3Nfa8VBt1bhbFrY/JpP+L yIQNvoi3wxLN/PcxT7A1J+qLB3j01s35OFXB7rRXIlKQlo5gDVOjuumhTdKi/Q9o1rf+ CNcJ+VFI5TPkVNA2v2CYNwCtnl1jCayaFmKtz3RJwaQyJmAWBXQmIjkEAV5RcYgGUnYZ Q9WSI9AAd4gtnBIlWqNqDh7HuDuv4ahvUy/C5OG+DEFb1gik8ltnYczxA9pN5fagjpRw g43g== X-Gm-Message-State: AIVw113O6EfQqUlLu+YEpOu6UYdT0JNlKWzBBEEaQX1uSdalmHreOB8e jxcyMLt+gJ7RGunKDjI= X-Received: by 10.223.153.234 with SMTP id y97mr7151884wrb.41.1500560578322; Thu, 20 Jul 2017 07:22:58 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:799c:671e:be9d:c1b3? ([2001:67c:1232:144:799c:671e:be9d:c1b3]) by smtp.gmail.com with ESMTPSA id 9sm2704684wmo.35.2017.07.20.07.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 07:22:57 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) Message-Id: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> Date: Thu, 20 Jul 2017 16:22:56 +0200 Cc: 6man WG , IPv6 Ops WG To: draft-ietf-6man-rfc6434-bis@ietf.org X-Mailer: Apple Mail (2.3439) Archived-At: Subject: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:23:04 -0000 I write as co-chair of v6ops, under our charter element "comment to = other working groups when it seems appropriate".=20 One outcome from at least v6ops and I think a couple of other WGs and = RGs this week - may I suggest a change to Node Requirements and a = corresponding change to the IPv6 Ready Logo? General Category: "Good grief, it's 2017 for goodness' sake!" Something that would be helpful in IPv6 deployment would be to turn IPv6 = on by default in residential routers. Note that this is not the general = case. I can think of routers, whose vendors have C's and J's, and = probably H's, in their names, whose default configuration is as an = Internet Host. The following would apply to devices that are configured = by default as an IP router with routing enabled. Please add a requirement of the general form: "If IPv4 router operation is enabled by default, enable IPv6 router = operation by default." Note that this is not as simple as it might sound. There are at least = three configurations that must be allowed for upstream: bridging the ISP = downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, = and address allocation via SLAAC, and on the CPE downstream LAN(s), = address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a = flowchart for this or RFC 7084 defines the algorithms. The = implementation is going to have to enable all three, see which works, = and act accordingly. There may also be considerations for PPPOE: if IPv4 is configured for = PPPOE, turn it on for IPv6. Good Grief. This is 2017 for goodness' sake, and there are = implementations that turn IPv6 on by default and work. Do it. Just do = it.= From nobody Thu Jul 20 07:54:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFE9131746 for ; Thu, 20 Jul 2017 07:54:07 -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 E9Hj9GOPMbKh for ; Thu, 20 Jul 2017 07:54:05 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E1212EB99 for ; Thu, 20 Jul 2017 07:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500562443; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=6hhb+B4A7qF4XsYofZHci4DANJJk+6Uqf+K+oz9NkYo=; b=dxxHCyygW87oPM4CMtuszAJI+r9DhYeE3N65UFvJXpc667gfBhKNbJ3Yoy8fqXPXIE2iIo2UFRZ2xG6P31E8gqm4NMNEbE+LfwK09b/gJEthYeciVoLxBLJw97EzaicPiBneuI1bmFTFhtlfCkXuBLrmiC2xdd3fpOST2XWYSM4= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-53-4-QU-IyPMBmALoybCYSVuA-1; Thu, 20 Jul 2017 15:54:00 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0760.eurprd07.prod.outlook.com (10.160.6.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 14:53:58 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 14:53:58 +0000 From: Tim Chown To: Fred Baker CC: "draft-ietf-6man-rfc6434-bis@ietf.org" , 6man WG , IPv6 Ops WG Thread-Topic: Turning on IPv6 Routers Thread-Index: AQHTAWO3srz2b9wieU6bc38h1/dUM6JczT+A Date: Thu, 20 Jul 2017 14:53:58 +0000 Message-ID: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> In-Reply-To: <28757A47-53D8-459E-B76D-D5D5DE3D5897@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: [2001:67c:370:128:5ce6:fe4e:7dfd:1781] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0760; 20:JKUtDm0oacJ6L6yD/2cQ3Vc9pAu8Eipa/aHffWEVqFcWZAxoK5Ke1R79L5QmwD7yfnzhGuwH/u564MC7qmM5PlFWIXy3FhQ49gqmn8Eg/TYDkbUGGY/gsL0RS9MajcUrD8ve9ghdk2be1rJB/UGVx8OiaMCTVFvZZmZyLCHcedk= x-ms-office365-filtering-correlation-id: 9ecdcacf-6d19-4e01-d313-08d4cf7f26d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0760; x-ms-traffictypediagnostic: AM3PR07MB0760: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0760; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0760; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(72206003)(6116002)(39060400002)(189998001)(102836003)(110136004)(305945005)(229853002)(7736002)(50226002)(99286003)(54906002)(83716003)(53546010)(6512007)(53936002)(6246003)(8676002)(8936002)(38730400002)(81166006)(14454004)(6436002)(5250100002)(74482002)(2900100001)(25786009)(3660700001)(3280700002)(86362001)(478600001)(36756003)(82746002)(2950100002)(2906002)(4326008)(6486002)(42882006)(6506006)(5660300001)(76176999)(57306001)(6916009)(50986999)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0760; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9FE214AB107F9C4F8C614A9039B46AFC@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 14:53:58.4397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0760 X-MC-Unique: 4-QU-IyPMBmALoybCYSVuA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:54:08 -0000 SGkgRnJlZCwNCg0KPiBPbiAyMCBKdWwgMjAxNywgYXQgMTU6MjIsIEZyZWQgQmFrZXIgPGZyZWRi YWtlci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBJIHdyaXRlIGFzIGNvLWNoYWlyIG9m IHY2b3BzLCB1bmRlciBvdXIgY2hhcnRlciBlbGVtZW50ICJjb21tZW50IHRvIG90aGVyIHdvcmtp bmcgZ3JvdXBzIHdoZW4gaXQgc2VlbXMgYXBwcm9wcmlhdGUiLiANCj4gDQo+IE9uZSBvdXRjb21l IGZyb20gYXQgbGVhc3QgdjZvcHMgYW5kIEkgdGhpbmsgYSBjb3VwbGUgb2Ygb3RoZXIgV0dzIGFu ZCBSR3MgdGhpcyB3ZWVrIC0gbWF5IEkgc3VnZ2VzdCBhIGNoYW5nZSB0byBOb2RlIFJlcXVpcmVt ZW50cyBhbmQgYSBjb3JyZXNwb25kaW5nIGNoYW5nZSB0byB0aGUgSVB2NiBSZWFkeSBMb2dvPw0K PiANCj4gR2VuZXJhbCBDYXRlZ29yeTogIkdvb2QgZ3JpZWYsIGl0J3MgMjAxNyBmb3IgZ29vZG5l c3MnIHNha2UhIg0KPiANCj4gU29tZXRoaW5nIHRoYXQgd291bGQgYmUgaGVscGZ1bCBpbiBJUHY2 IGRlcGxveW1lbnQgd291bGQgYmUgdG8gdHVybiBJUHY2IG9uIGJ5IGRlZmF1bHQgaW4gcmVzaWRl bnRpYWwgcm91dGVycy4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IHRoZSBnZW5lcmFsIGNhc2UuIEkg Y2FuIHRoaW5rIG9mIHJvdXRlcnMsIHdob3NlIHZlbmRvcnMgaGF2ZSBDJ3MgYW5kIEoncywgYW5k IHByb2JhYmx5IEgncywgaW4gdGhlaXIgbmFtZXMsIHdob3NlIGRlZmF1bHQgY29uZmlndXJhdGlv biBpcyBhcyBhbiBJbnRlcm5ldCBIb3N0LiBUaGUgZm9sbG93aW5nIHdvdWxkIGFwcGx5IHRvIGRl dmljZXMgdGhhdCBhcmUgY29uZmlndXJlZCBieSBkZWZhdWx0IGFzIGFuIElQIHJvdXRlciB3aXRo IHJvdXRpbmcgZW5hYmxlZC4NCj4gDQo+IFBsZWFzZSBhZGQgYSByZXF1aXJlbWVudCBvZiB0aGUg Z2VuZXJhbCBmb3JtOg0KPiANCj4gIklmIElQdjQgcm91dGVyIG9wZXJhdGlvbiBpcyBlbmFibGVk IGJ5IGRlZmF1bHQsIGVuYWJsZSBJUHY2IHJvdXRlciBvcGVyYXRpb24gYnkgZGVmYXVsdC4iDQo+ IA0KPiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYXMgc2ltcGxlIGFzIGl0IG1pZ2h0IHNvdW5kLiBU aGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUgY29uZmlndXJhdGlvbnMgdGhhdCBtdXN0IGJlIGFsbG93 ZWQgZm9yIHVwc3RyZWFtOiBicmlkZ2luZyB0aGUgSVNQIGRvd25zdHJlYW0gYW5kIENQRSBkb3du c3RyZWFtIExBTnMsIEFkZHJlc3MgYWxsb2NhdGlvbiB2aWEgREhDUCBJQV9OQSwgYW5kIGFkZHJl c3MgYWxsb2NhdGlvbiB2aWEgU0xBQUMsIGFuZCBvbiB0aGUgQ1BFIGRvd25zdHJlYW0gTEFOKHMp LCBhZGRyZXNzIGFsbG9jYXRpb24gdmlhIERIQ1AgSUFfTkEgYW5kIFNMQUFDLiBCQkYgVFItMTI0 IGdpdmVzIGEgZmxvd2NoYXJ0IGZvciB0aGlzIG9yIFJGQyA3MDg0IGRlZmluZXMgdGhlIGFsZ29y aXRobXMuIFRoZSBpbXBsZW1lbnRhdGlvbiBpcyBnb2luZyB0byBoYXZlIHRvIGVuYWJsZSBhbGwg dGhyZWUsIHNlZSB3aGljaCB3b3JrcywgYW5kIGFjdCBhY2NvcmRpbmdseS4NCj4gDQo+IFRoZXJl IG1heSBhbHNvIGJlIGNvbnNpZGVyYXRpb25zIGZvciBQUFBPRTogaWYgSVB2NCBpcyBjb25maWd1 cmVkIGZvciBQUFBPRSwgdHVybiBpdCBvbiBmb3IgSVB2Ni4NCj4gDQo+IEdvb2QgR3JpZWYuIFRo aXMgaXMgMjAxNyBmb3IgZ29vZG5lc3MnIHNha2UsIGFuZCB0aGVyZSBhcmUgaW1wbGVtZW50YXRp b25zIHRoYXQgdHVybiBJUHY2IG9uIGJ5IGRlZmF1bHQgYW5kIHdvcmsuIERvIGl0LiBKdXN0IGRv IGl0Lg0KDQpOb3RlZCBmb3IgNjQzNC1iaXMsIGFuZCB3ZeKAmWxsIGRyYWZ0IHNvbWUgd29yZHMs IHRob3VnaCA2NDM0LWJpcyBpcyBtb3JlIGdlbmVyYWxseSBhaW1lZCBhdCBob3N0cywgZm9yIHdo aWNoIEkgdGhpbmsgYSBzaW1pbGFyIHN0YXRlbWVudCBzaG91bGQgYXBwbHksIHRob3VnaCB0aGlz IGlzIGZhciBtb3JlIGNvbW1vbiBwcmFjdGljZS4NCg0KU2ltaWxhciB0ZXh0IHNob3VsZCBiZSBh cHBsaWVkIHRvIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzLTAwLg0KDQpUaW0NCg0K From nobody Thu Jul 20 08:25:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A8E131CE6; Thu, 20 Jul 2017 08:25: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 TfhtlHfVTN5x; Thu, 20 Jul 2017 08:25:10 -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 D0F1C131C43; Thu, 20 Jul 2017 08:25:09 -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 v6KFP5Yx088569 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2017 16:25:06 +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: <5970CB51.3090806@foobar.org> Date: Thu, 20 Jul 2017 16:25:05 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: Fred Baker CC: draft-ietf-6man-rfc6434-bis@ietf.org, IPv6 Ops WG , 6man WG References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> In-Reply-To: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:25:12 -0000 Fred Baker wrote: > "If IPv4 router operation is enabled by default, enable IPv6 router > operation by default." this is undoubtedly well-intentioned, and the idealist bit in me sympathises with the principal. However with my enable hat on, a recommendation like this isn't going to fix any problem associated with ipv6 adoption. The problems with ipv6 adoption revolve entirely around cost/benefit. Pressing problems still include things that should have been resolved years ago, e.g. vendors charging extra for ipv6 support (today's bugbear: provisioning system vendors, please note that charging extra for basic ipv6 functionality is destructive in the long term and corrosive for your customer relationships) As a separate issue, from an operational point of view, implicit enabling of functionality in one area when it's explicitly enabled in another is something that needs to be handled carefully because otherwise you can end up violating the principal of least astonishment. Nick From nobody Thu Jul 20 08:32:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B69131B11; Thu, 20 Jul 2017 08:32: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kOrhf8MFAAqt; Thu, 20 Jul 2017 08:31:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE25131473; Thu, 20 Jul 2017 08:31:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRQ60594; Thu, 20 Jul 2017 15:31:55 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 16:31:54 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 20 Jul 2017 23:31:49 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti CC: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-considerations@ietf.org" Thread-Topic: Comments on ULA draft Thread-Index: AdMBao5fmh7aobAAS9+r844FjcqjQQ== Date: Thu, 20 Jul 2017 15:31:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0C@nkgeml514-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.68.63] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0Cnkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5970CCEC.0007, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1743d57c20dee54244f48e944840cebe Archived-At: Subject: Re: [v6ops] Comments on ULA draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:32:06 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0Cnkgeml514mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIExvcmVuem8sIHBscyBzZWUgaW5saW5lIFtCaW5nMl0u DQoNCuWPkeS7tuS6ujogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29t XQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0N+aciDIw5pelIDE1OjEwDQrmlLbku7bkuro6IExpdWJp bmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20+DQrmioTpgIE6IHY2b3BzQGlldGYub3Jn IFdHIDx2Nm9wc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLWNvbnNpZGVy YXRpb25zQGlldGYub3JnDQrkuLvpopg6IFJlOiBDb21tZW50cyBvbiBVTEEgZHJhZnQNCg0KT24g VGh1LCBKdWwgMjAsIDIwMTcgYXQgMjo1NiBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdA aHVhd2VpLmNvbTxtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpbQmlu Z10gSSBndWVzcyB0aGUgZmlyZXdhbGwgYXQgdGhlIGVkZ2Ugb2YgcHVibGljIGFuZCBwcml2YXRl IGNhbiBzaW1wbHkgYmxvY2sgYWxsIEZEOjovIHByZWZpeD8NCg0KVGhhdCBvbmx5IHdvcmtzIGlm IHRoZXJlIGFyZSBleGFjdGx5IHR3byB6b25lczogcHVibGljIGFuZCBwcml2YXRlLiBBcyBzb29u IGFzIHlvdSBoYXZlIGEgdGhpcmQgem9uZSAoZS5nLiwgaWYgdGhlcmUgaXMgYSBtZXJnZXIsIG9y IGEgZGlmZmVyZW50IHR5cGUgb2YgbmV0d29yayksIGV2ZXJ5IC80OCBuZWVkcyB0byBoYXZlIGl0 cyBvd24gc2VjdXJpdHkgcG9saWN5Lg0KW0JpbmcyXTogSWYgem9uZXMgYXJlIGNvbm5lY3RlZCB0 aHJvdWdoIHRoZSBwdWJsaWMgbmV0d29yaywgdGhlIHpvbmVzIGNvbW11bmljYXRpb24gc2hvdWxk IG5vdCBvdmVyIFVMQSBwYWNrZXQsIHNpbmNlIHRoZSBwdWJsaWMgbmV0d29yayB3b3VsZCBkcm9w IHRoZSBVTEEgcGFja2V0cyBpbiBhbnkgY2FzZS4gSWYgYWRtaW5zIHdhbnQgdG8gZG8gVUxBIHBh Y2tldHMgYWNyb3NzIGRvbWFpbnMsIHRoZXkgbmVlZCB0byBtYWtlIHRoZSBwYWNrZXRzIG92ZXIg c29tZSBMMy9MMiB0dW5uZWxzOyBvciBqdXN0IGFkZCBhIFBBIHByZWZpeC4gVGh1cywgdGhlIGVk Z2UgZmlyZXdhbGxzIGJldHdlZW4gZWFjaCB6b25lIGFuZCB0aGUgcHVibGljIHpvbmUsIGNhbiBz dGlsbCBhcHBseSB0aGUgYmxvY2tpbmcgRkQ6Oi8gcnVsZS4NCkZvciBpbnRlcm5hbCBmaXJld2Fs bHMsIGlmIGl0IG5lZWRzIHRvIGJsb2NrIHNvbWUgc3BlY2lmaWMgYWRkcmVzc2VzL3ByZWZpeGVz LCBlaXRoZXIgdXNpbmcgVUxBcyBvciBQQXMsIGFkbWlucyBib3RoIG5lZWQgdG8gY29uZmlndXJl IHNwZWNpZmljIHJ1bGVzLCBzbyBJIHRoaW5rIFVMQXMgYW5kIFBBcyBhcmUganVzdCBlcXVhbCBv biB0aGlzIHBvaW50Pw0KDQpUaGV5J3JlIG5vdCBlcXVhbCBiZWNhdXNlIHdpdGggZ2xvYmFsIHNw YWNlLCBtdWx0aXBsZSAvNDhzIHRoYXQgaGF2ZSB0aGUgc2FtZSBzZWN1cml0eSBwb2xpY3kgY2Fu IGJlIGdyb3VwZWQgaW50byBhIHNpbmdsZSBzaG9ydGVyIHByZWZpeCB0aGF0IG9ubHkgcmVxdWly ZXMgb25lIGZpcmV3YWxsIHJ1bGUuDQpbQmluZzJdOiBZZXMuIFRoYXTigJlzIHNvbWV0aGluZyBJ IGNhbiBhZGQgaW50byB0aGUgZG9jdW1lbnQuDQoNCkJ0dywgdGhlIGFkbWlucyBjb3VsZCByYW5k b21seSBnZW5lcmF0ZWQgYSBzaW5nbGUgb25lIDQ4LyBVTEEgcHJlZml4LCBhbmQgYW5ub3VuY2Ug aXQgaW50ZXJuYWxseSwgdGhlcmUgYXJlIHN0aWxsIDE2Yml0IGZvciBzdWItb3JnYW5pemF0aW9u LiBTbywgdGhpcyBjb3VsZCBiZSBjb25zaWRlcmVkIGFzIGtpbmQgb2YgYWdncmVnYXRpb24/Lg0K DQpZZXMsIGJ1dCBvbmx5IGZvciBhIHNtYWxsIG5ldHdvcmsuDQpbQmluZzJdIEkgZG9u4oCZdCBx dWl0ZSB1bmRlcnN0YW5kIHdoeSBvbmx5IGZvciBzbWFsbCBuZXR3b3Jrcz8gSXMgaXQgYmVjYXVz ZSB0aGUgMTZiaXQgaXMgbm90IGVub3VnaCBmb3IgYSBsYXJnZSBvcmdhbml6YXRpb24gdG8gZGl2 aWRlIHN1Yi1uZXR3b3Jrcz8NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0Cnkgeml514mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91 ciByZXNwb25zZSBMb3JlbnpvLCBwbHMgc2VlIGlubGluZSBbQmluZzJdLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0K PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVT Ij43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+DQogMTU6MTA8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gTGl1YmluZyAoTGVvKSAmbHQ7bGVvLmxp dWJpbmdAaHVhd2VpLmNvbSZndDs8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gdjZvcHNAaWV0Zi5vcmcgV0cgJmx0 O3Y2b3BzQGlldGYub3JnJmd0OzsgZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtY29uc2lkZXJh dGlvbnNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IENvbW1lbnRzIG9uIFVMQSBkcmFmdDxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgSnVs IDIwLCAyMDE3IGF0IDI6NTYgUE0sIExpdWJpbmcgKExlbykgJmx0OzxhIGhyZWY9Im1haWx0bzps ZW8ubGl1YmluZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGVvLmxpdWJpbmdAaHVhd2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pjxicj4NCltCaW5nXSBJIGd1ZXNzIHRoZSBmaXJld2FsbCBhdCB0aGUgZWRnZSBvZiBwdWJsaWMg YW5kIHByaXZhdGUgY2FuIHNpbXBseSBibG9jayBhbGwgRkQ6Oi8gcHJlZml4Pzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGF0IG9ubHkg d29ya3MgaWYgdGhlcmUgYXJlIGV4YWN0bHkgdHdvIHpvbmVzOiBwdWJsaWMgYW5kIHByaXZhdGUu IEFzIHNvb24gYXMgeW91IGhhdmUgYSB0aGlyZCB6b25lIChlLmcuLCBpZiB0aGVyZSBpcyBhIG1l cmdlciwgb3IgYSBkaWZmZXJlbnQgdHlwZSBvZiBuZXR3b3JrKSwgZXZlcnkgLzQ4IG5lZWRzIHRv IGhhdmUgaXRzIG93biBzZWN1cml0eSBwb2xpY3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bQmluZzJdOiBJZiB6b25lcyBhcmUgY29ubmVjdGVkIHRocm91Z2ggdGhlIHB1YmxpYyBu ZXR3b3JrLCB0aGUgem9uZXMgY29tbXVuaWNhdGlvbiBzaG91bGQgbm90IG92ZXIgVUxBIHBhY2tl dCwgc2luY2UgdGhlIHB1YmxpYyBuZXR3b3JrIHdvdWxkIGRyb3ANCiB0aGUgVUxBIHBhY2tldHMg aW4gYW55IGNhc2UuIElmIGFkbWlucyB3YW50IHRvIGRvIFVMQSBwYWNrZXRzIGFjcm9zcyBkb21h aW5zLCB0aGV5IG5lZWQgdG8gbWFrZSB0aGUgcGFja2V0cyBvdmVyIHNvbWUgTDMvTDIgdHVubmVs czsgb3IganVzdCBhZGQgYSBQQSBwcmVmaXguIFRodXMsIHRoZSBlZGdlIGZpcmV3YWxscyBiZXR3 ZWVuIGVhY2ggem9uZSBhbmQgdGhlIHB1YmxpYyB6b25lLCBjYW4gc3RpbGwgYXBwbHkgdGhlIGJs b2NraW5nIEZEOjovDQogcnVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkZvciBpbnRlcm5hbCBmaXJld2FsbHMsIGlmIGl0IG5lZWRzIHRvIGJsb2NrIHNv bWUgc3BlY2lmaWMgYWRkcmVzc2VzL3ByZWZpeGVzLCBlaXRoZXIgdXNpbmcgVUxBcyBvciBQQXMs IGFkbWlucyBib3RoIG5lZWQgdG8gY29uZmlndXJlIHNwZWNpZmljIHJ1bGVzLCBzbyBJIHRoaW5r IFVMQXMNCiBhbmQgUEFzIGFyZSBqdXN0IGVxdWFsIG9uIHRoaXMgcG9pbnQ/PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXkncmUgbm90 IGVxdWFsIGJlY2F1c2Ugd2l0aCBnbG9iYWwgc3BhY2UsIG11bHRpcGxlIC80OHMgdGhhdCBoYXZl IHRoZSBzYW1lIHNlY3VyaXR5IHBvbGljeSBjYW4gYmUgZ3JvdXBlZCBpbnRvIGEgc2luZ2xlIHNo b3J0ZXIgcHJlZml4IHRoYXQgb25seSByZXF1aXJlcyBvbmUgZmlyZXdhbGwgcnVsZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltCaW5nMl06IFllcy4gVGhhdOKAmXMgc29tZXRoaW5n IEkgY2FuIGFkZCBpbnRvIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdHcsIHRoZSBh ZG1pbnMgY291bGQgcmFuZG9tbHkgZ2VuZXJhdGVkIGEgc2luZ2xlIG9uZSA0OC8gVUxBIHByZWZp eCwgYW5kIGFubm91bmNlIGl0IGludGVybmFsbHksIHRoZXJlIGFyZSBzdGlsbCAxNmJpdCBmb3Ig c3ViLW9yZ2FuaXphdGlvbi4gU28sIHRoaXMgY291bGQgYmUgY29uc2lkZXJlZA0KIGFzIGtpbmQg b2YgYWdncmVnYXRpb24/Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5ZZXMsIGJ1dCBvbmx5IGZvciBhIHNtYWxsIG5ldHdvcmsuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bQmluZzJdIEkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0 YW5kIHdoeSBvbmx5IGZvciBzbWFsbCBuZXR3b3Jrcz8gSXMgaXQgYmVjYXVzZSB0aGUgMTZiaXQg aXMgbm90IGVub3VnaCBmb3IgYSBsYXJnZSBvcmdhbml6YXRpb24gdG8gZGl2aWRlIHN1Yi1uZXR3 b3Jrcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0Cnkgeml514mbxchi_-- From nobody Thu Jul 20 08:33:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C84126CB6; Thu, 20 Jul 2017 08:33: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 aDfmOvkQKHdW; Thu, 20 Jul 2017 08:33:37 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 F198E128BC8; Thu, 20 Jul 2017 08:33:36 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id 184so1396377wmo.3; Thu, 20 Jul 2017 08:33: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=ZydrDn7HXvtuZTSsoacZiGNWZ/7i9WFpKhKzZ2482Gg=; b=Wx2MKYVvGrDmKpcEg7GJE8dKmofIy1rv7Rrq9YSoZIwW0IJ6wVw1x7Xe0dFJn96Whv SbQ/llETC7mk01uXiMAtzWr3477rNsTu5KgeF6BnXaOQApx5hYdlf66wDKr18rmCDxDX 5vfLNxnNI3JmO7cvS96e4E2xfmEzawdA0+OYfL6i23I3wIjaeTXflYH1EtJkY/02cimR dvJgX1VvfVy84T6QQ72QgyPQNBZbl+Rq2UG4NMja4KJFmZEQrsuM5qvjC85CtOzMI4+Y e62jfVd4u5Lsjs4Ev7KG24/AU96BzuxgA6CB722kP5+a38SI5rt1FxRmiCGQsBP9glhY Q/bg== 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=ZydrDn7HXvtuZTSsoacZiGNWZ/7i9WFpKhKzZ2482Gg=; b=dfOlL1YkQ7mP4K46qs7LZWjcaicTjtWDpFP6VuNLkKUBMPqfad1Q0ySb40Pwxhh58e lPUPaNmOarPmFSI98vnBR8oDh9zCIo1ytXYIWCfuW5/D8Qgkjut9AFf1GHkFky+EY0or 6H/NpbWrIP/Owlc/Kl6LgWB4MisOvTKSW6efp6Pxp6Ehx2mjCZtb5q82K5E0yBFgPgMh hKnjS4PpmIny/1TlFsSXd2iXC3iYGF32r+bIIoPyLxI+tqJWTg3KiFYgZAKZC5C1qADJ Lq0EcRS8Me/YJaAL1UYnSXLQDkNXSqzx2nsGjxxkGuV0gLTKyU+OolrIt5L99D7fOtrj SrDQ== X-Gm-Message-State: AIVw11015V5SDXKsl6pUTI5OMK9Pjvjy7v+Nz9NjX6EB+Vl0TvBhY3g2 OxPTrLfcisZzhg== X-Received: by 10.28.165.207 with SMTP id o198mr2683008wme.154.1500564815530; Thu, 20 Jul 2017 08:33:35 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:cd1:34c:a97d:4a84? ([2001:67c:1232:144:cd1:34c:a97d:4a84]) by smtp.gmail.com with ESMTPSA id 46sm8594158wrz.8.2017.07.20.08.33.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:33:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) From: Fred Baker In-Reply-To: Date: Thu, 20 Jul 2017 17:33:33 +0200 Cc: "draft-ietf-6man-rfc6434-bis@ietf.org" , 6man WG , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> To: Tim Chown , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org, JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3439) Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:33:40 -0000 I'd guess 7084bis before one targeting big iron, but yes in concept. > On Jul 20, 2017, at 4:53 PM, Tim Chown wrote: >=20 > Hi Fred, >=20 >> On 20 Jul 2017, at 15:22, Fred Baker = wrote: >>=20 >> I write as co-chair of v6ops, under our charter element "comment to = other working groups when it seems appropriate".=20 >>=20 >> One outcome from at least v6ops and I think a couple of other WGs and = RGs this week - may I suggest a change to Node Requirements and a = corresponding change to the IPv6 Ready Logo? >>=20 >> General Category: "Good grief, it's 2017 for goodness' sake!" >>=20 >> Something that would be helpful in IPv6 deployment would be to turn = IPv6 on by default in residential routers. Note that this is not the = general case. I can think of routers, whose vendors have C's and J's, = and probably H's, in their names, whose default configuration is as an = Internet Host. The following would apply to devices that are configured = by default as an IP router with routing enabled. >>=20 >> Please add a requirement of the general form: >>=20 >> "If IPv4 router operation is enabled by default, enable IPv6 router = operation by default." >>=20 >> Note that this is not as simple as it might sound. There are at least = three configurations that must be allowed for upstream: bridging the ISP = downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, = and address allocation via SLAAC, and on the CPE downstream LAN(s), = address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a = flowchart for this or RFC 7084 defines the algorithms. The = implementation is going to have to enable all three, see which works, = and act accordingly. >>=20 >> There may also be considerations for PPPOE: if IPv4 is configured for = PPPOE, turn it on for IPv6. >>=20 >> Good Grief. This is 2017 for goodness' sake, and there are = implementations that turn IPv6 on by default and work. Do it. Just do = it. >=20 > Noted for 6434-bis, and we=E2=80=99ll draft some words, though = 6434-bis is more generally aimed at hosts, for which I think a similar = statement should apply, though this is far more common practice. >=20 > Similar text should be applied to draft-ietf-v6ops-ipv6rtr-reqs-00. >=20 > Tim >=20 From nobody Thu Jul 20 08:42:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4191252BA for ; Thu, 20 Jul 2017 08:42:51 -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=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 t1agF3Bm_llI for ; Thu, 20 Jul 2017 08:42:49 -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 4FAAD126CB6 for ; Thu, 20 Jul 2017 08:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500565367; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=H/EbdTid2m0sAySxsEHkiT1gbbhY3v1yq6CslGyqSDY=; b=XtvytxUxR5FCAfvXsOoZlLKQe9fnBrWkitbDr1LCbaV+e74waRYf3QwLutLRWWFcNimnmwPSfvKFpTOJGNB5amhXchTR6J9RnRPt60xGrzZdjEjGyYDsU/adCQC2/96EMsbstR5BFWpnwupfIdvs6nZVLXMHQWI6E7HrabgFV4I= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0212.outbound.protection.outlook.com [213.199.154.212]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-2-h4PneDS0OaGIJWS_cavaHg-1; Thu, 20 Jul 2017 16:42:43 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0630.eurprd07.prod.outlook.com (10.160.3.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 15:42:41 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 15:42:41 +0000 From: Tim Chown To: Ted Lemon CC: Alexandre Petrescu , IPv6 Ops WG Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties Thread-Index: AQHTATUji5KtLICoVEuRVVY8txHTcaJcbLsAgABueoA= Date: Thu, 20 Jul 2017 15:42:41 +0000 Message-ID: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:67c:370:128:5ce6:fe4e:7dfd:1781] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0630; 20:hUGRVt5lgN1tO8rMDoCtOeiIJw8f+GQCEsFpiFF3eYvuM/EP7DtN5sJEQ5KES5WGIml3ig2fUJ8yJ2o8MBX7rh0RSG8uYymzcaIeDyczlVM8Q5WLvSiuy6rqB3CToSYsHxu8LwEU/cWMjlej3QKNkYnStm4BWRnLDyhYevNCADc= x-ms-office365-filtering-correlation-id: db3502c8-9769-4b37-b130-08d4cf85f503 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0630; x-ms-traffictypediagnostic: AM3PR07MB0630: x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(236129657087228)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0630; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0630; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(377454003)(24454002)(50226002)(8676002)(305945005)(86362001)(81166006)(229853002)(14454004)(5250100002)(3280700002)(50986999)(6246003)(38730400002)(83716003)(7736002)(76176999)(6486002)(110136004)(74482002)(6506006)(3660700001)(39060400002)(53936002)(4326008)(2906002)(189998001)(6436002)(6916009)(42882006)(2900100001)(2950100002)(57306001)(82746002)(8936002)(478600001)(230783001)(102836003)(6116002)(25786009)(72206003)(53546010)(99286003)(93886004)(54906002)(6306002)(33656002)(36756003)(5660300001)(6512007)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0630; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9D676D460EB8634DB40810D18242F81E@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 15:42:41.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0630 X-MC-Unique: h4PneDS0OaGIJWS_cavaHg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:42:52 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTA6MDcsIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4g d3JvdGU6DQo+IA0KPiBBbGV4YW5kcmUsIGluIG9yZGVyIGZvciB0aGF0IHRvIGJlIHRoZSBjYXNl IGl0IG11c3QgYmUgdHJ1ZSB0aGF0IHRoZSBESENQIHNlcnZlciBpcyBhY3RpdmVseSB3b3JraW5n IHRvIGFycmFuZ2UgZm9yIGl0IHRvIGJlIHRoZSBjYXNlIHRoYXQgY2xpZW50cyBnZXQgYWRkcmVz c2VzIHdpdGggZ29vZCBwcml2YWN5IGNoYXJhY3RlcmlzdGljcy4gICBXaGF0IHdlIGFyZSBzZWVp bmcgaW4gdGhlIGZpZWxkIGlzIHRoYXQgYWRkcmVzc2VzIGFyZSBiZWluZyBhbGxvY2F0ZWQgb3V0 IG9mIHZlcnkgc21hbGwgcmFuZ2VzLCB3aXRoIG5vIGNvbmNlcm4gZ2l2ZW4gdG8gcHJpdmFjeS4g ICBTbyBhcyBhIHByYWN0aWNhbCBtYXR0ZXIsIHRoZSBhZHZpY2UgaW4gdGhlIFJGQyBpcyB0aGUg Y29ycmVjdCBhZHZpY2UuDQo+IA0KPiBJdCdzIHBvc3NpYmxlIHRoYXQgd2UgY291bGQgY2hhbmdl IHRoYXQsIGJ1dCBJIGRvbid0IHNlZSB0aGUgcG9pbnQuICAgSXQncyBmaW5lIHRoYXQgREhDUCBz ZXJ2ZXJzIHdvcmsgdGhlIHdheSB0aGV5IGRvLCBhcyBsb25nIGFzIGNsaWVudHMgY2FuIGFsc28g ZG8gU0xBQUMuICAgREhDUCBzaW1wbHkgZG9lcyBub3QgYWRkcmVzcyB0aGlzIHVzZSBjYXNlLCBu b3IgbmVlZCBpdCBkbyBzby4NCg0KV2VsbCwgdGhlcmUgaXMgcHVibGlzaGVkIGFkdmljZSBhZ2Fp bnN0IHRoYXQgREhDUHY2IGFkZHJlc3MgcG9vbCBiZWhhdmlvdXIuDQoNClVsdGltYXRlbHkgaXTi gJlzIHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvIHRoYXQgbWF0dGVycywgSSB0aGluay4gIEZvciBh biBlbnRlcnByaXNlIGVudmlyb25tZW50IHdoZXJlIGFsbCBkZXZpY2VzIGFyZSB1bmRlciBhZG1p bmlzdHJhdGl2ZSBjb250cm9sLCBpdCBzZWVtcyBESENQdjYgaXMgbW9yZSBsaWtlbHkgdG8gYmUg cHJlZmVycmVkLCBhbmQgd2hlcmUgU0xBQUMgaXMgdXNlZCwgcHJpdmFjeSBhZGRyZXNzIGdlbmVy YXRpb24gd291bGQgbGlrZWx5IGJlIGRpc2FibGVkLiBZb3UgbWF5IGV2ZW4gc2VlIHByZWZlcmVu Y2UgZm9yIGNsYXNzaWMgU0xBQUMgcmF0aGVyIHRoYW4gUkZDNzIxNywgaWYgT1NlcyBzdGlsbCBz dXBwb3J0IHRoYXQgbW9kZS4NCg0KRm9yIGhvbWUgbmV0d29ya3MsIGhvdHNwb3RzLCBjYW1wdXMg V2lGaSwgZXRjLCBJ4oCZZCBleHBlY3QgU0xBQUMgdG8gYmUgYXZhaWxhYmxlLiAgUGVyc29uYWxs eSwgbXkgZXhwZWN0YXRpb25zIG9mIHByaXZhY3kgd291bGQgZGlmZmVyIGJldHdlZW4gbXkgd29y a3BsYWNlIGFuZCBuZXR3b3JrcyBJIHVzZSB3aGVuIG5vdCBhdCB3b3JrLg0KDQpUaW0NCg0KPiBP biBUaHUsIEp1bCAyMCwgMjAxNyBhdCAxMDo0OSBBTSwgQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4 YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPiBMZSAyMC8wNy8yMDE3 IMOgIDEwOjIxLCBMb3JlbnpvIENvbGl0dGkgYSDDqWNyaXQgOg0KPiBbLi4uXQ0KPiBTTEFBQyBh ZGRyZXNzZXMgcHJvdmlkZSBhbXBsZSBhZGRyZXNzIHNwYWNlIGFuZCBoYXZlIHJvYnVzdCBwcml2 YWN5IHByb3BlcnRpZXMNCj4gDQo+IERvIHlvdSBtZWFuIERIQ1AtQWRkcmVzcyhJQV9OQSkgZG9l cyBub3QgaGF2ZSByb2J1c3QgcHJpdmFjeSBwcm9wZXJ0aWVzPw0KPiAgIEkgdGhpbmsgaXQgZG9l cyAtIGl0IGNhbiBkZWxpdmVyIG11bHRpcGxlIGFkZHJlc3NlcyB0byBDbGllbnQsIGVhY2gNCj4g ZnJvbSBhIGRpc3RpbmN0IC82NCBwcmVmaXguICBUaGF0IHdvdWxkIGJlIG1vcmUgcHJpdmFjeSB0 aGFuIFNMQUFDIHdoaWNoDQo+IGRvZXMgdmFyeSB0aGUgNjQgSUlEIGJ1dCB3aXRoaW4gc2FtZSBw cmVmaXguDQo+IA0KPiBBbGV4DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFp bGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Thu Jul 20 08:53:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AF11252BA for ; Thu, 20 Jul 2017 08:53:47 -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 Ijrj4lWuTPd3 for ; Thu, 20 Jul 2017 08:53:45 -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 16EF712EC32 for ; Thu, 20 Jul 2017 08:53:38 -0700 (PDT) X-Envelope-To: v6ops@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 v6KFrZN0091930 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2017 16:53:36 +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: <5970D1FF.2090707@foobar.org> Date: Thu, 20 Jul 2017 16:53:35 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: Tim Chown CC: Ted Lemon , IPv6 Ops WG References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:53:48 -0000 Tim Chown wrote: > For home networks, hotspots, campus WiFi, etc, I’d expect SLAAC to be available. home networks probably yes. hotspots and campus wifi are a different kettle of fish though, due to policy and/or legal requirements to put steps in place for end-to-end traceability (regardless of how easy it might be to work around these things). Note that in cases like hotspots and campus wifi, you would be well advised not to have any expectations of privacy to start with, so in the general case, it would be questionable as to whether these networks would be bcp204 compliant to start with. This isn't a blanket statement or a position of intent, btw - just an observation that if you use someone else's network resources, you are subject to their policies. Nick From nobody Thu Jul 20 09:22:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46517127B60 for ; Thu, 20 Jul 2017 09:22:11 -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=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 EejCdblsJGop for ; Thu, 20 Jul 2017 09:22:09 -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 EF645127136 for ; Thu, 20 Jul 2017 09:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500567727; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=GnHDwalo8pkgOcEyrly2z2z+iLMxP+2eExrFWsCEXf8=; b=CTK1MMRBW4SmNqn9U0UnYYR5dYSFqMVslQxlCqTVtgwJ4Rdutp3ashPsfM2fGHDdsFo80ntolMHm2aXiTi/+l219zdVOIWWfKm6AOj8Hm/tJlz5k/CwTa+O0unQaK56J6BCW3X/efNqnJ826cETatmXT3qqK4gn9dExUfnupEWM= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-48-5YqOg3pqPbOljaC_pBeFOQ-1; Thu, 20 Jul 2017 17:22:02 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0647.eurprd07.prod.outlook.com (10.160.4.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 16:22:01 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 16:22:01 +0000 From: Tim Chown To: Nick Hilliard CC: Ted Lemon , IPv6 Ops WG Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties Thread-Index: AQHTATUji5KtLICoVEuRVVY8txHTcaJcbLsAgABueoCAAAMQgIAAB+oA Date: Thu, 20 Jul 2017 16:22:01 +0000 Message-ID: <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> In-Reply-To: <5970D1FF.2090707@foobar.org> 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:67c:370:128:7164:5a94:6ee1:4c3b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0647; 20:y/aEo3D9AJDTB+MkwlfkT/V7RKmzIrnqVJi+Gavrsfkas3a5Bsi7Ax/Io7EBfkFeKaIlJZB4zJdPLgEn+vdVDmx9LazfuEpZJh2xD8ja2hkd88WUK70BZkLG4HeTej+ZNoVh9kXgwOwcTURi9y5qmMVQmcEWodI8Y5o6AgwJg1g= x-ms-office365-filtering-correlation-id: b1246db0-0456-41a7-785d-08d4cf8b7396 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0647; x-ms-traffictypediagnostic: AM3PR07MB0647: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0647; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0647; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(24454002)(2950100002)(230783001)(3280700002)(5660300001)(14454004)(6116002)(102836003)(6436002)(36756003)(99286003)(72206003)(93886004)(82746002)(6512007)(15650500001)(189998001)(74482002)(83716003)(53546010)(54906002)(81166006)(25786009)(4326008)(478600001)(57306001)(6506006)(6486002)(33656002)(2900100001)(50226002)(110136004)(229853002)(7736002)(38730400002)(305945005)(2906002)(53936002)(42882006)(5250100002)(8936002)(6916009)(86362001)(3660700001)(76176999)(8676002)(6246003)(50986999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0647; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 16:22:01.1789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0647 X-MC-Unique: 5YqOg3pqPbOljaC_pBeFOQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:22:11 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTY6NTMsIE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9y Zz4gd3JvdGU6DQo+IA0KPiBUaW0gQ2hvd24gd3JvdGU6DQo+PiBGb3IgaG9tZSBuZXR3b3Jrcywg aG90c3BvdHMsIGNhbXB1cyBXaUZpLCBldGMsIEnigJlkIGV4cGVjdCBTTEFBQyB0byBiZSBhdmFp bGFibGUuDQo+IA0KPiBob21lIG5ldHdvcmtzIHByb2JhYmx5IHllcy4NCj4gDQo+IDx5bW12Pg0K PiBob3RzcG90cyBhbmQgY2FtcHVzIHdpZmkgYXJlIGEgZGlmZmVyZW50IGtldHRsZSBvZiBmaXNo IHRob3VnaCwgZHVlIHRvDQo+IHBvbGljeSBhbmQvb3IgbGVnYWwgcmVxdWlyZW1lbnRzIHRvIHB1 dCBzdGVwcyBpbiBwbGFjZSBmb3IgZW5kLXRvLWVuZA0KPiB0cmFjZWFiaWxpdHkgKHJlZ2FyZGxl c3Mgb2YgaG93IGVhc3kgaXQgbWlnaHQgYmUgdG8gd29yayBhcm91bmQgdGhlc2UNCj4gdGhpbmdz KS4NCg0KRm9yIGNhbXB1cyBuZXR3b3JrIHdpZmksIHlvdSBnZXQgYWNjb3VudGFiaWxpdHkgdGhy b3VnaCBlZHVyb2FtLg0KDQpNYW55IGhvdHNwb3RzIGhhdmUgemVybyBhdXRoZW50aWNhdGlvbi4N Cg0KPiBOb3RlIHRoYXQgaW4gY2FzZXMgbGlrZSBob3RzcG90cyBhbmQgY2FtcHVzIHdpZmksIHlv dSB3b3VsZCBiZSB3ZWxsDQo+IGFkdmlzZWQgbm90IHRvIGhhdmUgYW55IGV4cGVjdGF0aW9ucyBv ZiBwcml2YWN5IHRvIHN0YXJ0IHdpdGgsIHNvIGluIHRoZQ0KPiBnZW5lcmFsIGNhc2UsIGl0IHdv dWxkIGJlIHF1ZXN0aW9uYWJsZSBhcyB0byB3aGV0aGVyIHRoZXNlIG5ldHdvcmtzDQo+IHdvdWxk IGJlIGJjcDIwNCBjb21wbGlhbnQgdG8gc3RhcnQgd2l0aC4gIFRoaXMgaXNuJ3QgYSBibGFua2V0 IHN0YXRlbWVudA0KPiBvciBhIHBvc2l0aW9uIG9mIGludGVudCwgYnR3IC0ganVzdCBhbiBvYnNl cnZhdGlvbiB0aGF0IGlmIHlvdSB1c2UNCj4gc29tZW9uZSBlbHNlJ3MgbmV0d29yayByZXNvdXJj ZXMsIHlvdSBhcmUgc3ViamVjdCB0byB0aGVpciBwb2xpY2llcy4NCj4gPC95bW12Pg0KDQpZZWFo IHRoaW5ncyBsaWtlIEdEUFIgd291bGQgY29tZSBpbnRvIHBsYXkuIEJ1dCBsZXTigJlzIG5vdCBn byBkb3duIHRoaXMgcmF0aG9sZTsgdGhlIHBvaW50IGlzIHRoYXQgZGlmZmVyZW50IHNjZW5hcmlv cyB3aWxsIGhhdmUgZGlmZmVyZW50IGV4cGVjdGF0aW9ucyBhbmQgcmVxdWlyZW1lbnRzLiAgQW5k IEnigJlkIGFyZ3VlIGFkbWluaXN0cmF0aXZlbHkgbWFuYWdlZCBlbnRlcnByaXNlcyBhcmUgdGhl IHRoZSBtb3N0IGxpa2VseSB0byBwdXQgYSByZXF1aXJlbWVudCBvbiBESENQdjYsIG9yIHRvIHJ1 biBTTEFBQyB3aXRoIDQ5NDEgZGlzYWJsZWQuDQoNClRpbQ== From nobody Thu Jul 20 09:45:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E1513192B for ; Thu, 20 Jul 2017 09:45:09 -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 y8smlo74MElc for ; Thu, 20 Jul 2017 09:45:08 -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 AC3C9131714 for ; Thu, 20 Jul 2017 09:45:07 -0700 (PDT) X-Envelope-To: v6ops@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 v6KGj5L6098111 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2017 17:45:05 +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: <5970DE11.5070001@foobar.org> Date: Thu, 20 Jul 2017 17:45:05 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: Tim Chown CC: IPv6 Ops WG References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> In-Reply-To: <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:45:10 -0000 Tim Chown wrote: > For campus network wifi, you get accountability through eduroam. s/campus network/eduroam campus network/ There are lots of different types of campus, and campus type networks. > Many hotspots have zero authentication. Sadly, there is an increasing number of situations which refuse hotspot connectivity without authentication, depending on a variety of situations. >> Note that in cases like hotspots and campus wifi, you would be >> well advised not to have any expectations of privacy to start with, >> so in the general case, it would be questionable as to whether >> these networks would be bcp204 compliant to start with. This isn't >> a blanket statement or a position of intent, btw - just an >> observation that if you use someone else's network resources, you >> are subject to their policies. > > Yeah things like GDPR would come into play. But let’s not go down > this rathole; the point is that different scenarios will have > different expectations and requirements. indeed, and the ietf needs to acknowledge this explicitly. Nick From nobody Thu Jul 20 09:52:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9586D131C74 for ; Thu, 20 Jul 2017 09:52:23 -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 UQyp97GEcigO for ; Thu, 20 Jul 2017 09:52:22 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CDD131714 for ; Thu, 20 Jul 2017 09:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500569539; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=dxGSetfIeGP5c61CeOPDKNI//ImwDaenfmT+FpuhhLw=; b=DB0JxmH+ytQOcF/uViuRSxOQeraPSfjQImUFdkMrvnT+L9C8zTyaiaUmpYNTLbDOviESvsHGvJqhqMrWBQmDl2jQRr90pbvPhsWLeJa0otbkb4Yd2HAuyBkZRiwPjU0Lc+xZjYx0GujRlcOMXxCYKVeVuDwhpcXB2WghvEhU8Vw= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0111.outbound.protection.outlook.com [213.199.154.111]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-21-FN1lw7DaOUS8e5rheAr5kg-1; Thu, 20 Jul 2017 17:52:15 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 16:52:14 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 16:52:14 +0000 From: Tim Chown To: Nick Hilliard CC: IPv6 Ops WG Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties Thread-Index: AQHTATUji5KtLICoVEuRVVY8txHTcaJcbLsAgABueoCAAAMQgIAAB+oAgAAGeoCAAAH9AA== Date: Thu, 20 Jul 2017 16:52:14 +0000 Message-ID: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> <5970DE11.5070001@foobar.org> In-Reply-To: <5970DE11.5070001@foobar.org> 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:67c:370:128:7164:5a94:6ee1:4c3b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB292; 20:DXl/wJobh2T2Z2Q7MZ5CXDbPoBDyzinQOyWsRL62sAJvsooo5pvkWGo6TzdxXJWWID/DanuW14FaC/6GItmZlRz8HNORj+286FfMQXqDDVRL8iJf/aBqYok4x3irpGkMChgOwvOD+yFWwUhsQQUT3jFPLiys4jj8OQ4SvD8F0cc= x-ms-office365-filtering-correlation-id: 7c0bd857-2f61-4023-a449-08d4cf8fac51 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB292; x-ms-traffictypediagnostic: AM3PR07MB292: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910075)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB292; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB292; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(24454002)(6436002)(25786009)(230783001)(6506006)(53546010)(82746002)(2906002)(14454004)(3280700002)(478600001)(81166006)(8936002)(36756003)(50226002)(8676002)(83716003)(74482002)(189998001)(57306001)(5660300001)(99286003)(15650500001)(4326008)(6512007)(110136004)(6246003)(5250100002)(86362001)(3660700001)(38730400002)(53936002)(229853002)(42882006)(2950100002)(2900100001)(7736002)(93886004)(76176999)(6916009)(102836003)(6116002)(50986999)(33656002)(72206003)(6486002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB292; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6CAE7ED0B6C8BE439A1EFB5C5B569160@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 16:52:14.3293 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB292 X-MC-Unique: FN1lw7DaOUS8e5rheAr5kg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:52:24 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTc6NDUsIE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9y Zz4gd3JvdGU6DQo+IA0KPiBUaW0gQ2hvd24gd3JvdGU6DQo+PiBGb3IgY2FtcHVzIG5ldHdvcmsg d2lmaSwgeW91IGdldCBhY2NvdW50YWJpbGl0eSB0aHJvdWdoIGVkdXJvYW0uDQo+IA0KPiBzL2Nh bXB1cyBuZXR3b3JrL2VkdXJvYW0gY2FtcHVzIG5ldHdvcmsvDQo+IA0KPiBUaGVyZSBhcmUgbG90 cyBvZiBkaWZmZXJlbnQgdHlwZXMgb2YgY2FtcHVzLCBhbmQgY2FtcHVzIHR5cGUgbmV0d29ya3Mu DQoNCldlbGwsIHRoZSBkaXNjdXNzaW9uIHdhcyBhcm91bmQgYmVzdCBwcmFjdGljZSBkaXNjdXNz aW9uLCBhbmQgaW4gdGhhdCBsaWdodCBlZHVyb2FtIHNob3VsZCBiZSBhc3BpcmF0aW9uYWwuIEl0 4oCZcyBkZXBsb3llZCBpbiA3MC04MCBjb3VudHJpZXMsIGJ1dCB0aGUgdW5kZXJseWluZyA4MDIu MXggY2FuIGJlIHVzZWQgaW4gYW55IGNhbXB1cywgYW5kIG9uIHdpcmVkIGxpbmtzIGFzIHdlbGwu DQoNCj4+IE1hbnkgaG90c3BvdHMgaGF2ZSB6ZXJvIGF1dGhlbnRpY2F0aW9uLg0KPiANCj4gU2Fk bHksIHRoZXJlIGlzIGFuIGluY3JlYXNpbmcgbnVtYmVyIG9mIHNpdHVhdGlvbnMgd2hpY2ggcmVm dXNlIGhvdHNwb3QNCj4gY29ubmVjdGl2aXR5IHdpdGhvdXQgYXV0aGVudGljYXRpb24sIGRlcGVu ZGluZyBvbiBhIHZhcmlldHkgb2Ygc2l0dWF0aW9ucy4NCj4gDQo+Pj4gTm90ZSB0aGF0IGluIGNh c2VzIGxpa2UgaG90c3BvdHMgYW5kIGNhbXB1cyB3aWZpLCB5b3Ugd291bGQgYmUNCj4+PiB3ZWxs IGFkdmlzZWQgbm90IHRvIGhhdmUgYW55IGV4cGVjdGF0aW9ucyBvZiBwcml2YWN5IHRvIHN0YXJ0 IHdpdGgsDQo+Pj4gc28gaW4gdGhlIGdlbmVyYWwgY2FzZSwgaXQgd291bGQgYmUgcXVlc3Rpb25h YmxlIGFzIHRvIHdoZXRoZXINCj4+PiB0aGVzZSBuZXR3b3JrcyB3b3VsZCBiZSBiY3AyMDQgY29t cGxpYW50IHRvIHN0YXJ0IHdpdGguICBUaGlzIGlzbid0DQo+Pj4gYSBibGFua2V0IHN0YXRlbWVu dCBvciBhIHBvc2l0aW9uIG9mIGludGVudCwgYnR3IC0ganVzdCBhbg0KPj4+IG9ic2VydmF0aW9u IHRoYXQgaWYgeW91IHVzZSBzb21lb25lIGVsc2UncyBuZXR3b3JrIHJlc291cmNlcywgeW91DQo+ Pj4gYXJlIHN1YmplY3QgdG8gdGhlaXIgcG9saWNpZXMuIDwveW1tdj4NCj4+IA0KPj4gWWVhaCB0 aGluZ3MgbGlrZSBHRFBSIHdvdWxkIGNvbWUgaW50byBwbGF5LiBCdXQgbGV04oCZcyBub3QgZ28g ZG93bg0KPj4gdGhpcyByYXRob2xlOyB0aGUgcG9pbnQgaXMgdGhhdCBkaWZmZXJlbnQgc2NlbmFy aW9zIHdpbGwgaGF2ZQ0KPj4gZGlmZmVyZW50IGV4cGVjdGF0aW9ucyBhbmQgcmVxdWlyZW1lbnRz Lg0KPiANCj4gaW5kZWVkLCBhbmQgdGhlIGlldGYgbmVlZHMgdG8gYWNrbm93bGVkZ2UgdGhpcyBl eHBsaWNpdGx5Lg0KDQpGZWVsIGZyZWUgdG8gc3VnZ2VzdCB0ZXh0IGZvciBOb2RlIFJlcXVpcmVt ZW50cyAtYmlzLi4uDQoNClRpbQ== From nobody Thu Jul 20 10:08:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA1C131945 for ; Thu, 20 Jul 2017 10:08: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, 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 Ktjs3qlLpThS for ; Thu, 20 Jul 2017 10:08:12 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 2A2FC127B60 for ; Thu, 20 Jul 2017 10:08:12 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id a62so19518361itd.1 for ; Thu, 20 Jul 2017 10:08:12 -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=QwXTBB2lipM1ZQBjXhVytrrbX0enDbHeFwZDDaTuifk=; b=skhL0gSKx4mYkd9nuxcRXCe+9KbmyWOjsd6jmzucJnjzPDOEfYh2NlLXQchB7J1Vb/ +PJD2XWCKWev+oJeufL/Y58VYIIHkpPo6eCiDElUvCmuCENKo3iwbppYWl5OvppvufLZ 6DP6sh/a3dfYHHUckC4P9H6LvB15onJg+BU6H8UCXgKMSDQLUoX2WfXCne6CR6RPDZzl vUUfBEPY9ZgYZWJiL0CmSQIMTqYP+Zbhm65upYar6iqnT8Nk8W6GegU0ca0j/BvXfcmf BgOE28uHfaVKJgsDgcwFDd3UkAG6Aqlqzd3sfivyt1VhaDNiQ1cqlDUPc3SdX2153JRT R3MQ== 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=QwXTBB2lipM1ZQBjXhVytrrbX0enDbHeFwZDDaTuifk=; b=KDsto/W918xKCTO8Zrwg+WC2DemfeOPEX2V45oPwwBOS9RzCCuDHqgpi0WKTq3S6M/ ftc5GqQKND6dTfPypByjZck5iEnWv1vzHmRnhNHsmMKYIZXeibyAIBvlGUBjCOwg4Iwo 24uilIwqNPnRUhijM7WkbN2h6nIjtOZOjj2ZYRyuk1ntoiAiPnUNFDj6wVYnpgOgPgc7 eZ2+JK7Lx00T6Xkvpj46GZ1D6H3Le8sRo5dSFKjYBE78uYbv57lWKbuh92vQwbuPo0jY Dj4MyGkwCoT/Ae1MjtMFhjnYX5WnpB4rc5P5FBQuMbCzUzQh1pPtkGjLgv5KhewWgleP 4V5A== X-Gm-Message-State: AIVw111m2lXRuRens1khB/QbfrqhOlzoQsFbdBUoutdU4cDL/dMhklXY rTB8XsLKCGWjxDh2HJHHy7ok2Di0B0MYfRo= X-Received: by 10.36.22.17 with SMTP id a17mr4263265ita.40.1500570491228; Thu, 20 Jul 2017 10:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 10:07:50 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> <5970DE11.5070001@foobar.org> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 19:07:50 +0200 Message-ID: To: Tim Chown Cc: Nick Hilliard , IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a11437ea81790270554c2cbfa" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:08:13 -0000 --001a11437ea81790270554c2cbfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 6:52 PM, Tim Chown wrote: > > There are lots of different types of campus, and campus type networks. > > Well, the discussion was around best practice discussion, and in that > light eduroam should be aspirational. It=E2=80=99s deployed in 70-80 coun= tries, but > the underlying 802.1x can be used in any campus, and on wired links as we= ll. > Which is, of course, technically a much better solution than relying on insecure DHCPv6. Additionally, there's the option of doing /64 per host (via RAs) in the enterprise. Same tracking and authorization properties, but no limitation on the number of addresses that can be used. --001a11437ea81790270554c2cbfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 6:52 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> There a= re lots of different types of campus, and campus type networks.

Well, the discussion was around best practice discussion, and in tha= t light eduroam should be aspirational. It=E2=80=99s deployed in 70-80 coun= tries, but the underlying 802.1x can be used in any campus, and on wired li= nks as well.

Which is, of course, techn= ically a much better solution than relying on insecure DHCPv6.
Additionally, there's the option of doing /64 per host (vi= a RAs) in the enterprise. Same tracking and authorization properties, but n= o limitation on the number of addresses that can be used.
=
--001a11437ea81790270554c2cbfa-- From nobody Thu Jul 20 10:21:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A88C131C60 for ; Thu, 20 Jul 2017 10:21:45 -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=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 7397K87DnsbB for ; Thu, 20 Jul 2017 10:21:43 -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 78D44131C31 for ; Thu, 20 Jul 2017 10:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500571301; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=c8m9IOdYi0zNQVzHo4rjDlX75ESAYcgRX3AhX6nk6PE=; b=QVEYEAcxFiEdK6lxf9cQ47+f+UstjBNYoXBtuxRQyT+lDw23zMYbWnD9oWvhK9uMjNeEwiiboVz3Vl635QagxdZ7Vu1I/YgVG8ibaiRYhWiB8CGZ14sgqPf8iM3gkEFCI2ZYUceKTCxWHXExuFxnqANToTJidjhl67YF9wECubM= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-112-_lEFLtMSMoKmrpkKNjX5Zw-1; Thu, 20 Jul 2017 18:21:39 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0693.eurprd07.prod.outlook.com (10.160.6.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 17:21:38 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 17:21:37 +0000 From: Tim Chown To: Lorenzo Colitti CC: Nick Hilliard , IPv6 Ops WG Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties Thread-Index: AQHTATUji5KtLICoVEuRVVY8txHTcaJcbLsAgABueoCAAAMQgIAAB+oAgAAGeoCAAAH9AIAABF4AgAAD2oA= Date: Thu, 20 Jul 2017 17:21:37 +0000 Message-ID: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> <5970DE11.5070001@foobar.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:67c:370:128:7164:5a94:6ee1:4c3b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0693; 20:wfevVN5j/+bhnk4ly8S7m3ntOlHI0TuWXZW4ZnokDtK2+iZGbjoBsaXzeapxX87UR7Px0qbzDCJobHMuwtc+aiVOQmgOzKENaWC7EoG2W/n+jRhl9SqXlhhbkr0R3twNXFmY/aVeOwQRffvrpStwCOJfzTr+E3/aY/s7cWlqvhA= x-ms-office365-filtering-correlation-id: d8da9b8b-7580-4176-8363-08d4cf93c775 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0693; x-ms-traffictypediagnostic: AM3PR07MB0693: x-exchange-antispam-report-test: UriScan:(274715658323672)(151999592597050)(236129657087228)(211936372134217)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(920507026)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0693; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0693; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39840400002)(39450400003)(39400400002)(377454003)(24454002)(110136004)(6246003)(76176999)(189998001)(38730400002)(230783001)(50986999)(229853002)(5250100002)(74482002)(2950100002)(14454004)(53546010)(2900100001)(36756003)(42882006)(6916009)(5660300001)(478600001)(33656002)(93886004)(53936002)(4326008)(50226002)(54906002)(81166006)(99286003)(25786009)(72206003)(8676002)(6116002)(6436002)(86362001)(3660700001)(305945005)(6506006)(3280700002)(7736002)(57306001)(2906002)(6486002)(82746002)(8936002)(102836003)(6512007)(83716003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0693; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9DFF7983BCE0334FA93B821A485C1F0E@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 17:21:37.8341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0693 X-MC-Unique: _lEFLtMSMoKmrpkKNjX5Zw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:21:46 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTg6MDcsIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29n bGUuY29tPiB3cm90ZToNCj4gDQo+IE9uIFRodSwgSnVsIDIwLCAyMDE3IGF0IDY6NTIgUE0sIFRp bSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KPiA+IFRoZXJlIGFyZSBsb3Rz IG9mIGRpZmZlcmVudCB0eXBlcyBvZiBjYW1wdXMsIGFuZCBjYW1wdXMgdHlwZSBuZXR3b3Jrcy4N Cj4gDQo+IFdlbGwsIHRoZSBkaXNjdXNzaW9uIHdhcyBhcm91bmQgYmVzdCBwcmFjdGljZSBkaXNj dXNzaW9uLCBhbmQgaW4gdGhhdCBsaWdodCBlZHVyb2FtIHNob3VsZCBiZSBhc3BpcmF0aW9uYWwu IEl04oCZcyBkZXBsb3llZCBpbiA3MC04MCBjb3VudHJpZXMsIGJ1dCB0aGUgdW5kZXJseWluZyA4 MDIuMXggY2FuIGJlIHVzZWQgaW4gYW55IGNhbXB1cywgYW5kIG9uIHdpcmVkIGxpbmtzIGFzIHdl bGwuDQo+IA0KPiBXaGljaCBpcywgb2YgY291cnNlLCB0ZWNobmljYWxseSBhIG11Y2ggYmV0dGVy IHNvbHV0aW9uIHRoYW4gcmVseWluZyBvbiBpbnNlY3VyZSBESENQdjYuDQo+IA0KPiBBZGRpdGlv bmFsbHksIHRoZXJlJ3MgdGhlIG9wdGlvbiBvZiBkb2luZyAvNjQgcGVyIGhvc3QgKHZpYSBSQXMp IGluIHRoZSBlbnRlcnByaXNlLiBTYW1lIHRyYWNraW5nIGFuZCBhdXRob3JpemF0aW9uIHByb3Bl cnRpZXMsIGJ1dCBubyBsaW1pdGF0aW9uIG9uIHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIHRoYXQg Y2FuIGJlIHVzZWQuDQoNClllcCwgYW5kIEkgbWVudGlvbiB0aGF0IHdoZW4gc3BlYWtpbmcgdG8g dW5pdmVyc2l0eSBhZG1pbnMsIGFkIHRoZXkgbGlrZSBhbmQgdW5kZXJzdGFuZCB0aGUgaWRlYS4g IFRob3VnaCBJIGhhdmUgYSBmZWVsaW5nIHRoZXkgbWF5IHNvb24gcmVhbGlzZSB0aGV54oCZbGwg d2FudCBtb3JlIHRoYW4gYSAvNDggdG8gc2VydmUgdGhlaXIgY2FtcHVzZXPigKYgYW5kIHRoYXTi gJlzIGFuIGlzc3VlIGZvciBjYW1wdXNlcyB0aGF0IHdhbnQgdG8gZm9sbG93IDc5MzQgYW5kIEpK QuKAmXMgZHJhZnQuICBXZSBoYXZlIHRocmVlIFVLIHVuaXZlcnNpdGllcyB0aGF0IGhhdmUgbm93 IGdvbmUgZm9yIExJUiBzdGF0dXMgdG8gb2J0YWluIHRoZWlyIG93biAvMzIuDQoNCkFzIGFuIGFz aWRlLCB3ZSBhbG1vc3Qgd2VudCB3aXRoIC82NCBwZXIgb2ZmaWNlIGluIG91ciBpbml0aWFsIGNh bXB1cyByb2xsb3V0OyB0aGUgaXNzdWUgdGhlbiB3YXMgdGhlIGV4dHJhIGNvc3Qgb2YgdGhlIHJv dXRpbmcgaW1hZ2Ugb24gJHZlbmRvcuKAmXMgaGFyZHdhcmUuDQoNClRpbQ== From nobody Thu Jul 20 10:25:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2684812F3CB for ; Thu, 20 Jul 2017 10:25: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 dfuhILkmG6TE for ; Thu, 20 Jul 2017 10:25:34 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64452126B6D for ; Thu, 20 Jul 2017 10:25:34 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q2so14082932ioe.3 for ; Thu, 20 Jul 2017 10: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=0FMxFqdNtJAHDch+P+ZoXmXNmpRf+iBPkQRBYGUI3/8=; b=Y0mzjKUNdwjMyqjsbpLTM/W0gVMM6tVv+/F9yS/cXRZ73om3a3xCSZgiCHWGCn0hWe ZE6erPMtrRqsjFjPVhZqiCniGej+DYIO2KhY6dt49Wk2hPj4k0BMdcMYp4wzA2iVvdzA LbeNy6nCJcxeRXXoDKg2FY3GtTo7ibsl6YYqaE8ZLCY7y54hv5c0AHVlnnoHmxI+FHLF iWXeIblIHbX0mtvN/2U1oVOA87bedTU6jfUg+M82mZW6dKsPOH0IxH1gZPy0NrkS3Dxz be3+4CzBnJ4QKBZg9ZCQORMnhps2oDP7179GBqm5DCejEztEwqO92/dNCfFkCDrywlJi dGyg== 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=0FMxFqdNtJAHDch+P+ZoXmXNmpRf+iBPkQRBYGUI3/8=; b=f6MEwS4Bg1k/QUeCFMe33miLbwcPcFV772Ql6uk2wMRRcvdBgIO7xcw0dspvegJroZ dcQkKo2BVZ3EmNdlT9YEp5TCj+e+BP2QBdHHMjKBpe8q/vwEXDKoBYL2LA2HH0SOz420 lw/xW5yzvhzcJnPIfFyeYJk8mq4ELqMM5FPH5rVHyqvHUzCn6KgtDc0ITZ/6WM8gAbgw byCSiNSAg+SDZBkdjjhu9ktGZJxN8IZ6nIQhub72m+bXaCHCbafsud9tocv3OoIZaE+b McLbMwTwc1m0LNieKNIo8H5Uvq7wLkmdalM1rKnknvO6w59axMtXuLAC6haLhqeHyeNw p4Rg== X-Gm-Message-State: AIVw113uY3pWzuRvMAG4y+YHE00Bic+UeVK0MFleaTcR6RIOfUt5FL+r agV8udiCdcHEzmnTEcg0an7NOuiS35Wdh/4= X-Received: by 10.107.59.84 with SMTP id i81mr4382687ioa.72.1500571533282; Thu, 20 Jul 2017 10:25:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 10:25:12 -0700 (PDT) In-Reply-To: References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> <5970DE11.5070001@foobar.org> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 19:25:12 +0200 Message-ID: To: Tim Chown Cc: Nick Hilliard , IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c06537e344ead0554c309ed" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:25:36 -0000 --94eb2c06537e344ead0554c309ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tim, when you say /64 per office for your initial campus rollout, did you mean /64 per host? On Thu, Jul 20, 2017 at 7:21 PM, Tim Chown wrote: > > On 20 Jul 2017, at 18:07, Lorenzo Colitti wrote: > > > > On Thu, Jul 20, 2017 at 6:52 PM, Tim Chown wrote= : > > > There are lots of different types of campus, and campus type networks= . > > > > Well, the discussion was around best practice discussion, and in that > light eduroam should be aspirational. It=E2=80=99s deployed in 70-80 coun= tries, but > the underlying 802.1x can be used in any campus, and on wired links as we= ll. > > > > Which is, of course, technically a much better solution than relying on > insecure DHCPv6. > > > > Additionally, there's the option of doing /64 per host (via RAs) in the > enterprise. Same tracking and authorization properties, but no limitation > on the number of addresses that can be used. > > Yep, and I mention that when speaking to university admins, ad they like > and understand the idea. Though I have a feeling they may soon realise > they=E2=80=99ll want more than a /48 to serve their campuses=E2=80=A6 and= that=E2=80=99s an issue > for campuses that want to follow 7934 and JJB=E2=80=99s draft. We have t= hree UK > universities that have now gone for LIR status to obtain their own /32. > > As an aside, we almost went with /64 per office in our initial campus > rollout; the issue then was the extra cost of the routing image on > $vendor=E2=80=99s hardware. > > Tim --94eb2c06537e344ead0554c309ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tim, when you say /64 per office for your initial campus r= ollout, did you mean /64 per host?

On Thu, Jul 20, 2017 at 7:21 PM, Tim Chown <Tim.= Chown@jisc.ac.uk> wrote:
> On 20 Jul 2017, at 18:07, Lorenz= o Colitti <lorenzo@google.com&= gt; wrote:
>
> On Thu, Jul 20, 2017 at 6:52 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> > There are lots of different types of campus, and campus type netw= orks.
>
> Well, the discussion was around best practice discussion, and in that = light eduroam should be aspirational. It=E2=80=99s deployed in 70-80 countr= ies, but the underlying 802.1x can be used in any campus, and on wired link= s as well.
>
> Which is, of course, technically a much better solution than relying o= n insecure DHCPv6.
>
> Additionally, there's the option of doing /64 per host (via RAs) i= n the enterprise. Same tracking and authorization properties, but no limita= tion on the number of addresses that can be used.

Yep, and I mention that when speaking to university admins, ad = they like and understand the idea.=C2=A0 Though I have a feeling they may s= oon realise they=E2=80=99ll want more than a /48 to serve their campuses=E2= =80=A6 and that=E2=80=99s an issue for campuses that want to follow 7934 an= d JJB=E2=80=99s draft.=C2=A0 We have three UK universities that have now go= ne for LIR status to obtain their own /32.

As an aside, we almost went with /64 per office in our initial campus rollo= ut; the issue then was the extra cost of the routing image on $vendor=E2=80= =99s hardware.

Tim

--94eb2c06537e344ead0554c309ed-- From nobody Thu Jul 20 10:53:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F75129B5E for ; Thu, 20 Jul 2017 10:53:54 -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 GUjBvLQG5ujm for ; Thu, 20 Jul 2017 10:53:52 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920CD128C81 for ; Thu, 20 Jul 2017 10:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500573230; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=QYbTEWl3CIT6voJtWtBv9YwBkQP/Cu5Nny6nfzf0IQo=; b=XCkkHsDehvV0W5215u8lkLMI7fxgZauzGo1+7Mve+kRNsVBvvpr+/yt7sschAH756T0dhs3Dk723wXU/KNmDnRuDKHvcPQ0nCW+qMt6B30WIaVAqR5lsKWCihnB1/EDpjMrEbL9lsxjJqyIiEr+E0ZASLnrgJxbpHYed2uGmdtE= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0212.outbound.protection.outlook.com [213.199.154.212]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-9-8KcsiQIiPbKTcWx8LOSFzA-1; Thu, 20 Jul 2017 18:53:46 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB468.eurprd07.prod.outlook.com (10.242.113.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 17:53:44 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 17:53:44 +0000 From: Tim Chown To: Lorenzo Colitti CC: Nick Hilliard , IPv6 Ops WG Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties Thread-Index: AQHTATUji5KtLICoVEuRVVY8txHTcaJcbLsAgABueoCAAAMQgIAAB+oAgAAGeoCAAAH9AIAABF4AgAAD2oCAAAEAAIAAB/aA Date: Thu, 20 Jul 2017 17:53:44 +0000 Message-ID: <3035C384-BAD4-44A3-8DCE-1F3A6EB9A380@jisc.ac.uk> References: <596CF817.8040900@foobar.org> <20170719090835.GC45648@Space.Net> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <52ed5fcd-8af5-5b6b-4328-002a431977b6@gmail.com> <5970D1FF.2090707@foobar.org> <6C5C7F6F-0503-47CA-9C28-D0F405340EC2@jisc.ac.uk> <5970DE11.5070001@foobar.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: [31.133.146.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB468; 20:SU8lQs4RCreR6/P4CAB1jruvKqvBb/awvfvC4xx5LAx/Hl2nBUBZRFnwWmNKDJZyQ765GIAUFFDm2fVa2DsyYvooxRPn6L42rN0EHDRCpfDcZ5Ru5Hu67cSx53UWMmQqSDswiiJFQe7yCjGCuiwxoADRHtLEHwc3nw9rc8VED4A= x-ms-office365-filtering-correlation-id: 49e3a193-2619-4a1e-6ae6-08d4cf9843e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB468; x-ms-traffictypediagnostic: AM3PR07MB468: x-exchange-antispam-report-test: UriScan:(274715658323672)(151999592597050)(236129657087228)(48057245064654)(211936372134217)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(920507026)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB468; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB468; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(24454002)(377454003)(230783001)(2900100001)(54906002)(99286003)(5660300001)(50226002)(14454004)(57306001)(33656002)(82746002)(6436002)(36756003)(53546010)(66066001)(50986999)(76176999)(6506006)(25786009)(3280700002)(72206003)(83716003)(4326008)(6116002)(8936002)(305945005)(102836003)(81166006)(3660700001)(478600001)(5250100002)(3846002)(229853002)(93886004)(6512007)(15650500001)(7736002)(38730400002)(6246003)(8676002)(6916009)(86362001)(42882006)(110136004)(6486002)(2950100002)(74482002)(2906002)(53936002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB468; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 17:53:44.6126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB468 X-MC-Unique: 8KcsiQIiPbKTcWx8LOSFzA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt - Privacy Properties X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:53:54 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTg6MjUsIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29n bGUuY29tPiB3cm90ZToNCj4gDQo+IFRpbSwgd2hlbiB5b3Ugc2F5IC82NCBwZXIgb2ZmaWNlIGZv ciB5b3VyIGluaXRpYWwgY2FtcHVzIHJvbGxvdXQsIGRpZCB5b3UgbWVhbiAvNjQgcGVyIGhvc3Q/ DQoNCk5vLCB0aGlzIHdhcyBiYWNrIGluIGFyb3VuZCAyMDAzLzQtaXNoIGR1cmluZyBhIHByb2pl Y3QgY2FsbGVkIDZORVQsIHdoZW4gd2UgaGFkIGVkZ2UgZGV2aWNlcyB0aGF0IHdvdWxkIGhhdmUg YmVlbiBjYXBhYmxlIG9mIGJlaW5nIGNvbmZpZ3VyZWQgdG8gcm91dGUgYSAvNjQgcGVyIG9mZmlj ZSwgYW5kIGhhZCBnb29kIHY2IHN1cHBvcnQuIFRoZXJlIHdlcmUgdmFyaW91cyByZWFzb25zIGRp c2N1c3NlZCBhcm91bmQgaXNvbGF0aW9uLCBhY2NvdW50YWJpbGl0eSwgZXRjLiAgTXVjaCBvZiB0 aGUgc2FtZSByYXRpb25hbGUgb2YgdGhlIHByZWZpeC1wZXItaG9zdCBkcmFmdC4gIA0KDQpBbmQg dGhhdCB3YXMgc3RpbGwgZWFybHkgd2lyZWxlc3MgZGF5cywgYW5kIGNlcnRhaW5seSBwcmUtODAy LjF4IGJlaW5nIGFueXdoZXJlIG5lYXIgbWFpbnN0cmVhbSAod2Ugc3RhcnRlZCB3b3JrIG9uIGVk dXJvYW0gYSB5ZWFyIG9yIHR3byBiZWZvcmUsIGJ1dCB0aGVyZSB3ZXJlIG9ubHkgdmVyeSBlYXJs eSBvcGVuIHNvdXJjZSBzdXBwbGljYW50cyBhbmQgc29tZSBub3QtY2hlYXAgM3JkIHBhcnR5IG9u ZXMuICBTbyBkaWZmZXJlbnQgbm93IDopLg0KDQpUaW0NCg0KPiBPbiBUaHUsIEp1bCAyMCwgMjAx NyBhdCA3OjIxIFBNLCBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCj4g PiBPbiAyMCBKdWwgMjAxNywgYXQgMTg6MDcsIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29n bGUuY29tPiB3cm90ZToNCj4gPg0KPiA+IE9uIFRodSwgSnVsIDIwLCAyMDE3IGF0IDY6NTIgUE0s IFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KPiA+ID4gVGhlcmUgYXJl IGxvdHMgb2YgZGlmZmVyZW50IHR5cGVzIG9mIGNhbXB1cywgYW5kIGNhbXB1cyB0eXBlIG5ldHdv cmtzLg0KPiA+DQo+ID4gV2VsbCwgdGhlIGRpc2N1c3Npb24gd2FzIGFyb3VuZCBiZXN0IHByYWN0 aWNlIGRpc2N1c3Npb24sIGFuZCBpbiB0aGF0IGxpZ2h0IGVkdXJvYW0gc2hvdWxkIGJlIGFzcGly YXRpb25hbC4gSXTigJlzIGRlcGxveWVkIGluIDcwLTgwIGNvdW50cmllcywgYnV0IHRoZSB1bmRl cmx5aW5nIDgwMi4xeCBjYW4gYmUgdXNlZCBpbiBhbnkgY2FtcHVzLCBhbmQgb24gd2lyZWQgbGlu a3MgYXMgd2VsbC4NCj4gPg0KPiA+IFdoaWNoIGlzLCBvZiBjb3Vyc2UsIHRlY2huaWNhbGx5IGEg bXVjaCBiZXR0ZXIgc29sdXRpb24gdGhhbiByZWx5aW5nIG9uIGluc2VjdXJlIERIQ1B2Ni4NCj4g Pg0KPiA+IEFkZGl0aW9uYWxseSwgdGhlcmUncyB0aGUgb3B0aW9uIG9mIGRvaW5nIC82NCBwZXIg aG9zdCAodmlhIFJBcykgaW4gdGhlIGVudGVycHJpc2UuIFNhbWUgdHJhY2tpbmcgYW5kIGF1dGhv cml6YXRpb24gcHJvcGVydGllcywgYnV0IG5vIGxpbWl0YXRpb24gb24gdGhlIG51bWJlciBvZiBh ZGRyZXNzZXMgdGhhdCBjYW4gYmUgdXNlZC4NCj4gDQo+IFllcCwgYW5kIEkgbWVudGlvbiB0aGF0 IHdoZW4gc3BlYWtpbmcgdG8gdW5pdmVyc2l0eSBhZG1pbnMsIGFkIHRoZXkgbGlrZSBhbmQgdW5k ZXJzdGFuZCB0aGUgaWRlYS4gIFRob3VnaCBJIGhhdmUgYSBmZWVsaW5nIHRoZXkgbWF5IHNvb24g cmVhbGlzZSB0aGV54oCZbGwgd2FudCBtb3JlIHRoYW4gYSAvNDggdG8gc2VydmUgdGhlaXIgY2Ft cHVzZXPigKYgYW5kIHRoYXTigJlzIGFuIGlzc3VlIGZvciBjYW1wdXNlcyB0aGF0IHdhbnQgdG8g Zm9sbG93IDc5MzQgYW5kIEpKQuKAmXMgZHJhZnQuICBXZSBoYXZlIHRocmVlIFVLIHVuaXZlcnNp dGllcyB0aGF0IGhhdmUgbm93IGdvbmUgZm9yIExJUiBzdGF0dXMgdG8gb2J0YWluIHRoZWlyIG93 biAvMzIuDQo+IA0KPiBBcyBhbiBhc2lkZSwgd2UgYWxtb3N0IHdlbnQgd2l0aCAvNjQgcGVyIG9m ZmljZSBpbiBvdXIgaW5pdGlhbCBjYW1wdXMgcm9sbG91dDsgdGhlIGlzc3VlIHRoZW4gd2FzIHRo ZSBleHRyYSBjb3N0IG9mIHRoZSByb3V0aW5nIGltYWdlIG9uICR2ZW5kb3LigJlzIGhhcmR3YXJl Lg0KPiANCj4gVGltDQo+IA0KDQo= From nobody Thu Jul 20 21:52:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4224F127010; Thu, 20 Jul 2017 21:52: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, 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 JZiK5tVX7Wne; Thu, 20 Jul 2017 21:52:43 -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 E14D9126C23; Thu, 20 Jul 2017 21:52:42 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q85so19818689pfq.1; Thu, 20 Jul 2017 21:52:42 -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=HtofZF462sVyUPp+mjwpF4lNp3lbMIeIF8cMLFRSvT0=; b=F+hOMwU3CDQ0rfHwsq2mgN2MLFyQRKhBGxYXNo93oLDXo8DXXI6OtCWjrVARkEalCc 6232RhOoSki1nTJxop4MCSWDW6ECONQHmCg94s4PpUA0HMNyIz+txRW+QlVMeel8GXwz lFDDCcmIqRPCJZ3E6w8FTnjJxnsJI8wlzYjHTq4J6K9t3tGnADnGFS50EhZ8Uha/MJHa 9eEs/e0zt2SZQ+kCC+nl1JGnZ5boa2Wjh59rilsAfdkgwtDnIwig8uT7wKqLAHDZz4a0 BzszGd1Vn/SHAZVMyv6A/U3f1xLAtrA8yq61gbFIk+VEzRy+mA4dOsG3HThDjMcP85x3 lOEg== 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=HtofZF462sVyUPp+mjwpF4lNp3lbMIeIF8cMLFRSvT0=; b=m/IhVVMWDGb4J9wmpKbu3KsGybyt01M/Vm940XAdYlJaR8V6i/S+63ACZ7EnHIBhxM 34TjnVvtdp7zy7k0J0J0/wFYjCVxMsluiMUgjLraNPN0SU/jHhoI7SWEeFKscuWelw9z botccnSZYjH95SH+xzeMp9rrS/KzUgmzmHV7nfGaZCYTSGYY4mzrQTNUStDuXPJfYKpc UMj7Q2YXu7J05AeRqMx+3O8Isa7Hp3cwQRm3J1GN2fpj7AFKz4nXBZUu7bYKspyHb/fS OaGcSk7Y1Axm3tbqOa1imGZGsvKXG3/Wygh1j7I6aVCU5EZycKUlGO6jaj/K0ICviI2z ygEQ== X-Gm-Message-State: AIVw112xfzOgr/sFQWqbN95pq9VMQ/sfvD/m5cHpUXVmxF8dGjTRt6FK LRJB2un8g/Jnmo7l X-Received: by 10.98.17.84 with SMTP id z81mr6299045pfi.38.1500612762331; Thu, 20 Jul 2017 21:52:42 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id a6sm7396718pfj.136.2017.07.20.21.52.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 21:52:41 -0700 (PDT) To: "Liubing (Leo)" , Lorenzo Colitti Cc: "draft-ietf-v6ops-ula-usage-considerations@ietf.org" , "v6ops@ietf.org WG" References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0C@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <35c02598-2f26-a38a-6c31-75b5c47bd308@gmail.com> Date: Fri, 21 Jul 2017 16:52:46 +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: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0C@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comments on ULA draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 04:52:44 -0000 On 21/07/2017 03:31, Liubing (Leo) wrote: =2E.. > Btw, the admins could randomly generated a single one 48/ ULA prefix, a= nd announce it internally, there are still 16bit for sub-organization. So= , this could be considered as kind of aggregation?. >=20 > Yes, but only for a small network. > [Bing2] I don=E2=80=99t quite understand why only for small networks? I= s it because the 16bit is not enough for a large organization to divide s= ub-networks? With 16 routing bits to play with, the admin has basically the equivalent= of an IPv6 Class A (which contains 2**16 /24s). So yes, campus or regional based aggregation is entirely possible: to exactly the same extent as wit= h a GUA /48, of course. In fact, in a network running both a GUA and a ULA prefix, I'd expect the same aggregation plan to be used for both. Brian Brian From nobody Thu Jul 20 23:44:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A24B1250B8; Thu, 20 Jul 2017 23:44:58 -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, 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 cOrqcr_7ssWa; Thu, 20 Jul 2017 23:44:56 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 BA973124D85; Thu, 20 Jul 2017 23:44:56 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id q2so19280201ioe.3; Thu, 20 Jul 2017 23:44:56 -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=i5M99Pim2gKNvEvQ9mDprE/I4DLv9GykDVhdqX+qvug=; b=NXWhaMbgC1WajT3B87jUCQPRWTdkpc8yuNQ9ffiegu8JknJjB3svUaPtipa4oHo+ui iaYOiHw8UsxBzLTlQ5nsWfsOy0J3genpbM7v0priTkBc6awqvXcBk2vOkBi5UndG+cPi yuja6yl0RaGActBo1nalY/p7ChANShUs+m+gC11RUMHwjkzxEhkP/pRW0dUMKc4GkNfx qS2Y+gd5FmnQ84kKhQ91pv8hhi5RUFVW0sdiG45d3n7nJpz/M9T9BUmSmuJHsLE6jbF1 VREIXwEHZtwfljkFqlyDhC346c2wwJh3hHuEILPooG5zkWboZbx/1rcB2Y+dg9c+6ksV 7piQ== 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=i5M99Pim2gKNvEvQ9mDprE/I4DLv9GykDVhdqX+qvug=; b=Gqz9vvUVilm91kdVtn0O/TbdJ+cjjzr4KYGDFpUMD11u6vEVJ7Vmq4NjCmvtXxyq0O kJUdSEFxdPxw7EtG6ZoogdvDVuXZ78uRxEkJSIf1LqaSHNivw9jEqqDWpNTC9k/cLllI HqqwDrzNYfUHdWzHoAadHrFGat2mNMclqMHaaIFydjJgT5AdZO/fvBILpGs/J6RA8pt1 9vE+Gf/NaWCQpPaY7SK88qToXpUZl4izdYQ/rket7ZhlUr2KDJOnAWIS1JAax13hxg+3 1uw7BzFKH10xh0vJkNR/bBOlCIHT9vBgDOQQcNoHd6wbIOIYpC4vDEkTkKMlFXcSX4nL DX2g== X-Gm-Message-State: AIVw113I4ksWN+cdlUJjDnkHuhC4XpQlzhTHJAeENUU48khSIRiL0IDj MgfmeKeIZPGzCRMx8KE3v2nS7+PKl+TaAKs= X-Received: by 10.107.41.5 with SMTP id p5mr5765785iop.165.1500619496182; Thu, 20 Jul 2017 23:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 23:44:35 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Fri, 21 Jul 2017 16:44:35 +1000 Message-ID: To: Olivier Bonaventure Cc: RTGWG , V6 Ops List , Olivier Tilmans Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Eating our own dog food : students solving IPv6 entreprise multihoming X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 06:44:58 -0000 Thanks a lot for sharing those results, Olivier! On Thu, Jul 20, 2017 at 4:53 PM, Olivier Bonaventure wrote: > Since then, our students only learn IPv6 > and results are excellent. Once they've learned IPv6, they can quickly > understand how IPv4 works. Hopefully they'll see sunset4 during their > career. Amen! -- SY, Jen Linkova aka Furry From nobody Fri Jul 21 00:07:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F612127076 for ; Fri, 21 Jul 2017 00:06:59 -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 yo1DnL2M3BGK for ; Fri, 21 Jul 2017 00:06: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 C900D126DFF for ; Fri, 21 Jul 2017 00:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500620816; x=1501225616; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=XL4Z0QG00mjlqECgxjB3AEm/6SUWMpw6VrJmT6k4vrs=; b=fWQ9Cm9FxkKDw PBLdWczuz7DYmK6aNqGh0Uf8rJWc3WCDbjZMwnJdiy0GUsNSq5QLxvi9SSEtFVEc JR/JYoA7W7NnLg8ZojE17JX4th6Ac+rDOsnUUPPseun4cRBZxsII+C6gfmWYqmax hkn1A1ndB6okRqt0fd+PKybb1qz/2s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VvrYMAmEdivpljWu0Dw1qSqQlrtBhGMA3g9W6yl50sgQ1Mnmg/LssMHlO+sT vsOXlFd6Imo9AZtqCeMqiDJbIcv8WCr/YHYdNUb/uj63J3qShwzVO5TkX XxkzguKwnaRwt19MLgMvBMyWeUiHfH8oq3tIIpjzVXPRzo36oIAg/o=; X-MDAV-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:06:56 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:06:55 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005482554.msg for ; Fri, 21 Jul 2017 09:06:55 +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:170721:md50005482554::UWOdwcGvm3qOpQyU:0000373A X-MDRemoteIP: 31.133.159.135 X-Return-Path: prvs=13753e1d62=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Fri, 21 Jul 2017 09:06:54 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <0DD4D67C-3BD5-4AAD-BC5E-BB3948BD35C0@consulintel.es> Thread-Topic: draft-palet-ietf-v6ops-he-reporting-00.txt: privacy and other issues Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] draft-palet-ietf-v6ops-he-reporting-00.txt: privacy and other issues X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:06:59 -0000 Hi all, I=E2=80=99ve been thinking about this and talking to other folks, so I will= like to get more feedback from the WG. 1) Privacy: I think just reporting the destination address that fallback to IPv4 becaus= e HE2, is enough to provide the operator a signal, so they can consider the= re is an issue with that path. It may be an operator issue, or maybe somebo= dy in the path or the destination itself. It is up to the local operator to= decide if they want to do anything about that or tell the other parties. If we also keep in the syslog report the origin prefix or address, it looks= like there is a privacy issue, however, because we are reporting it to our= OWN ISP, he has already that information and much more, and in many cases,= they have the obligation to keep such records for months/years, by local r= egulations. The privacy issue comes not for keeping that data, but for disclosing it. In fact, is not true that both, desktop and cellular OSs, do a lot of repor= ting/telemetry to their makers and even operators? At least I=E2=80=99d tha= t idea in mind, maybe I=E2=80=99m wrong =E2=80=A6 2) Implementing in hosts vs CE: >From my view point, it is much easier to implement a very simple UDP 514 me= ssage in HE2, which is detecting the failure and falling back, that asking = the host to signal the local CE (or ask the CE somehow to detect it for bro= ken destinations) and ask the CE vendors to provide firmware updates to imp= lement it: It will NOT happen! 3) Alternatives to hosts reporting the failure: I think was David who suggested =E2=80=9Cscrape DNS and NAT44 logs=E2=80=9D= . I=E2=80=99m sure there are other options as well. BUT, this means that th= e operator need to have =E2=80=9Csomething new=E2=80=9D in their network, a= nd what I=E2=80=99m trying to do is to reuse something already available (m= aybe syslog, maybe something else), so it is a matter not of =E2=80=9Cinsta= lling=E2=80=9D something, but just configuring and existing syslog collecto= r with one more address that match the one that we decide to use for it (ri= ght now NSP::192.88.99.1). Toughs? Regards, Jordi =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 Jul 21 00:48:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B202129A92 for ; Fri, 21 Jul 2017 00:48:26 -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 16TqaUphUqTc for ; Fri, 21 Jul 2017 00:48:24 -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 56CF112714F for ; Fri, 21 Jul 2017 00:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500623302; x=1501228102; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=Trr+WNmuCOb/ExZA1pUnedSBQQ5tdWX5tEeMgxSR6RQ=; b=OND LPrxls48N4zcmSS+VRyi/MWHI2m0RzUve3aS9krKmcuczsQyLxbxqvpeLIkXHJT9 RMM6rniLJo7nYOM2R8i9MBZ9zJn4EN8+1z1TDxWk+D/AxOjx4gBAiFqwIIyc5am1 +WBW/iZpKAxJkGRVu+L7ndfOSa3Cz0LsqIufMNlk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=afKe9eXAeSu1B0ZFH4iv9p+LnYfaFLvX5ZeQX8qYn5JDSIR4RCG2fmcpBjcb y5KPjBSkMe/qUyzSHTJNjEfDBqyLz4JNFTLrHxWZhty3DzN942UIQkaZw x25krLxnpBcaKU54RYOgC3N20fQ3Dc1U7S6e+RABE+Fb+OZ0dh8wC0=; X-MDAV-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:48:22 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:48:20 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005482596.msg for ; Fri, 21 Jul 2017 09:48: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:170721:md50005482596::D1lbT8YJgDMgiG9D:00003K9a X-Return-Path: prvs=13753e1d62=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Fri, 21 Jul 2017 09:48:15 +0200 From: JORDI PALET MARTINEZ To: CC: Tim Chown , "STARK, BARBARA H" , james woodyatt Message-ID: <1AE6D99E-DA24-486E-9735-5E42F60CE5A0@consulintel.es> Thread-Topic: possible path forward with RFC7084 and transition/other stuff X-Priority: 2 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es X-Spam-Prev-Subject: possible path forward with RFC7084 and transition/other stuff Archived-At: Subject: [v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:48:26 -0000 Hi all, We will like to know the WG opinions on this. (I=E2=80=99m sending this email after checking with the WG chairs if they a= gree on it) Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), ha= ve a chat about a possible path forward with the RFC7084-bis and related do= cs. If I understood correctly, we somehow agreed that a possible path is (let= =E2=80=99s call this CHOICE 1): 1) Not change/update the existing RFC7084. 2) Use my =E2=80=9CTransition Requirements for IPv6 Customer Edge Routers= =E2=80=9D document (draft-palet-v6ops-rfc7084-bis-transition-00) as a start= ing point, which =E2=80=9Cextend=E2=80=9D the requirements of RFC7084 towar= ds supporting actual world transition requirements. 3) In this updated document, the transition requirements can then be a MUST= , so vendors take it seriously. 4) I will include the reference to RFC8026 (some more text, as this referen= ce is already in all my docs regarding this topic), so there is a =E2=80=9C= flow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can get working IPv6= and then IPv4 if it is available from the ISP =E2=80=9Cas a service=E2=80= =9D. I think this can have also what Fred was suggesting as =E2=80=9CIPv6 m= ust be on by default=E2=80=9D, right? CHOICE 2 (to make it clear, my own toughs after waking up this morning, not= discussed with the other folks yesterday): Same as choice 1 above, but include also support for HNCP and may be someth= ing else if we believe it is required during the development of this docume= nt (for example it seems clear that if we offer IPv4 as a service, because = actual multicast-based IPTV services run on IPv4, we need to keep supportin= g that on top of an IPv6-only access). So then the document will be renamed to something such as =E2=80=9CTransiti= on and extended requirements for IPv6 CE routers=E2=80=9D. Tim, Barbara, James, can you confirm if I got right choice 1, or misunderst= ood/missed anything? WG participants, could you provide your view on those two options? Tim (Winters), could you tell from the perspective of the IPv6 Ready Logo P= rogram your view on those two approaches? It will be nice to be able to double check all the inputs from yesterday v6= ops sessions, but looking at the etherpad I can=E2=80=99t see them, so may = be the note takers were using something else. It is possible to access the = minutes already someway? I will like to start working on this immediately = =E2=80=A6 Thanks! Regards, Jordi =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 Jul 21 00:51:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173E1316E2 for ; Fri, 21 Jul 2017 00:51: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, 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 AFcJxlQXTJbr for ; Fri, 21 Jul 2017 00:51: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 8866C131E06 for ; Fri, 21 Jul 2017 00:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500623504; x=1501228304; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=e/9rS3HDUHc/ktpQ1NfdxmEmqeso8hLYSC3oLFbt9/c=; b=tyc eXgbJoDFM5cT9n0gcLzAEb2JVAYOFN6dLTBeAR+mr6PYADnRVPyc0zDDwyrFTF4S z2oFv/7tgbscMM5vPXyqYn+VcbEmNH45TXBqrNN+Am+0Jf0MUxy+81J98EnJYk93 g025PAWEnylUjyzyLlVmq1EMezOnPzJp8WOdbyKQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=hdMQhE+HTwrG1kyouTNGaae8lyjpuRNJijlvFGxO8Q+LgjyF4pTfDGz9UuCE buLnqs9CTVlfOH0pQNTYW0aAQ9jDD8gIz6tx/y74xWQOh5o1bHRmrYxgN 5dCqfltTXryWtBExJAD6lvo+LxqIyb0jP5mJdIzzplOa4jXyGg2+2s=; X-MDAV-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:51:44 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005482599.msg for ; Fri, 21 Jul 2017 09:51:44 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 21 Jul 2017 09:51:44 +0200 (not processed: spam filter heuristic analysis disabled) 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:170721:md50005482599::RVjl6mz8FRCtoIw1:00000odv X-Return-Path: prvs=13753e1d62=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Fri, 21 Jul 2017 09:51:40 +0200 From: JORDI PALET MARTINEZ To: CC: Tim Chown , "STARK, BARBARA H" , james woodyatt Message-ID: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> Thread-Topic: possible path forward with RFC7084 and transition/other stuff Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:51:51 -0000 Hi all, We will like to know the WG opinions on this. (I=E2=80=99m sending this email after checking with the WG chairs if they a= gree on it) Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), ha= ve a chat about a possible path forward with the RFC7084-bis and related do= cs. If I understood correctly, we somehow agreed that a possible path is (let= =E2=80=99s call this CHOICE 1): 1) Not change/update the existing RFC7084. 2) Use my =E2=80=9CTransition Requirements for IPv6 Customer Edge Routers= =E2=80=9D document (draft-palet-v6ops-rfc7084-bis-transition-00) as a start= ing point, which =E2=80=9Cextend=E2=80=9D the requirements of RFC7084 towar= ds supporting actual world transition requirements. 3) In this updated document, the transition requirements can then be a MUST= , so vendors take it seriously. 4) I will include the reference to RFC8026 (some more text, as this referen= ce is already in all my docs regarding this topic), so there is a =E2=80=9C= flow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can get working IPv6= and then IPv4 if it is available from the ISP =E2=80=9Cas a service=E2=80= =9D. I think this can have also what Fred was suggesting as =E2=80=9CIPv6 m= ust be on by default=E2=80=9D, right? CHOICE 2 (to make it clear, my own toughs after waking up this morning, not= discussed with the other folks yesterday): Same as choice 1 above, but include also support for HNCP and may be someth= ing else if we believe it is required during the development of this docume= nt (for example it seems clear that if we offer IPv4 as a service, because = actual multicast-based IPTV services run on IPv4, we need to keep supportin= g that on top of an IPv6-only access). So then the document will be renamed to something such as =E2=80=9CTransiti= on and extended requirements for IPv6 CE routers=E2=80=9D. Tim, Barbara, James, can you confirm if I got right choice 1, or misunderst= ood/missed anything? WG participants, could you provide your view on those two options? Tim (Winters), could you tell from the perspective of the IPv6 Ready Logo P= rogram your view on those two approaches? It will be nice to be able to double check all the inputs from yesterday v6= ops sessions, but looking at the etherpad I can=E2=80=99t see them, so may = be the note takers were using something else. It is possible to access the = minutes already someway? I will like to start working on this immediately = =E2=80=A6 Thanks! Regards, Jordi =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 Jul 21 01:00:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9615C129B34 for ; Fri, 21 Jul 2017 01:00:19 -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, 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=fugue-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 pycTpRRIeTfx for ; Fri, 21 Jul 2017 01:00:13 -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 E6CE9131AA9 for ; Fri, 21 Jul 2017 01:00:05 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id q85so21443360pfq.1 for ; Fri, 21 Jul 2017 01:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dN9cPwd6Ol6bxhP8gqs6ehhkxYLdzmq/rEpNqDw3Rbs=; b=dXiSlwJ+5XtKPrnTWzmW1GcFUB8CstI2jAnSuSDzritS9dat+RCmOSAmDRj3ugfCSb 0glyvlhM7W5QnnLIz3+h9NTyuRevdW1zWOyEGJHr/3m6QOpKOEcJh+TMO62pWFk9IPJI gFSA3PzEZRsVqqAQEQ7IrBpI+yyAoAheEaBLenJyq0+UwRoU0QMdEhKY+ICbi3TZZfIB Stt0QKaO+OYmSwAEi6LoK5dV0YdaJ4iFZwCYJ1/6Z7PW0AEcewLVez8jQPveCt2RH77g E/xwMspfVcYqtqdTtJvSlz0wFalll68BX3lyF+O6heb5LpXF6KbYCOLbghjpMv8fHZZt Pw/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=dN9cPwd6Ol6bxhP8gqs6ehhkxYLdzmq/rEpNqDw3Rbs=; b=BmXV1EqtdS/c6j63pg8UcyocVsoDd2EyORdK7uzO6A7JwN3k0AxOBs/9IL0VK2ifgd UxEoDivZrZYrvIjM6k3Ttq6la5lk/LxFSXnKmrPv6emGCLgiavI2OEg9bHYP08O1w14o KjuzIFDs/cC/hcJwiW9ul1ha0Dve2XgOBVz+5q9UyhZ3XY1h8watpTZ9xWHYPOvELhOh 6gOhHGPQO0Jk2fxHD6dCzRQ6vuBti1dCAEnNCBgjOxhck8mIgOb+SyfWKg0wp22mzdP+ iLJuN8OxKrcxMdgb5ee3ssEskz9L60DIpWq1vgoXERo7LyCEK5nrR7w+GiT+G/P9y2jj YCbA== X-Gm-Message-State: AIVw110oW3Ko9Ldk6Ypd3BPSQThjnMiRbqLxu509ry+/NPkq1kHURZAq grNBPf7Et9Ho+XGCtO6c4eomoPoF4T3K X-Received: by 10.99.56.68 with SMTP id h4mr6601605pgn.52.1500624005521; Fri, 21 Jul 2017 01:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.130 with HTTP; Fri, 21 Jul 2017 00:59:25 -0700 (PDT) In-Reply-To: <1AE6D99E-DA24-486E-9735-5E42F60CE5A0@consulintel.es> References: <1AE6D99E-DA24-486E-9735-5E42F60CE5A0@consulintel.es> From: Ted Lemon Date: Fri, 21 Jul 2017 09:59:25 +0200 Message-ID: To: JORDI PALET MARTINEZ Cc: IPv6 Ops WG , james woodyatt Content-Type: multipart/alternative; boundary="f403045d33f2ca7ca20554cf40a8" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:00:20 -0000 --f403045d33f2ca7ca20554cf40a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not enthusiastic about making changes at this time, first because I think there's no urgency, and second because I do not know what "require HNCP" means. Can you elaborate? On Fri, Jul 21, 2017 at 9:48 AM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi all, > > We will like to know the WG opinions on this. > > (I=E2=80=99m sending this email after checking with the WG chairs if they= agree on > it) > > Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), > have a chat about a possible path forward with the RFC7084-bis and relate= d > docs. > > If I understood correctly, we somehow agreed that a possible path is > (let=E2=80=99s call this CHOICE 1): > 1) Not change/update the existing RFC7084. > 2) Use my =E2=80=9CTransition Requirements for IPv6 Customer Edge Routers= =E2=80=9D > document (draft-palet-v6ops-rfc7084-bis-transition-00) as a starting > point, which =E2=80=9Cextend=E2=80=9D the requirements of RFC7084 towards= supporting actual > world transition requirements. > 3) In this updated document, the transition requirements can then be a > MUST, so vendors take it seriously. > 4) I will include the reference to RFC8026 (some more text, as this > reference is already in all my docs regarding this topic), so there is a > =E2=80=9Cflow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can get w= orking IPv6 and then IPv4 if it is > available from the ISP =E2=80=9Cas a service=E2=80=9D. I think this can h= ave also what Fred > was suggesting as =E2=80=9CIPv6 must be on by default=E2=80=9D, right? > > CHOICE 2 (to make it clear, my own toughs after waking up this morning, > not discussed with the other folks yesterday): > Same as choice 1 above, but include also support for HNCP and may be > something else if we believe it is required during the development of thi= s > document (for example it seems clear that if we offer IPv4 as a service, > because actual multicast-based IPTV services run on IPv4, we need to keep > supporting that on top of an IPv6-only access). > So then the document will be renamed to something such as =E2=80=9CTransi= tion and > extended requirements for IPv6 CE routers=E2=80=9D. > > Tim, Barbara, James, can you confirm if I got right choice 1, or > misunderstood/missed anything? > > WG participants, could you provide your view on those two options? > > Tim (Winters), could you tell from the perspective of the IPv6 Ready Logo > Program your view on those two approaches? > > It will be nice to be able to double check all the inputs from yesterday > v6ops sessions, but looking at the etherpad I can=E2=80=99t see them, so = may be the > note takers were using something else. It is possible to access the minut= es > already someway? I will like to start working on this immediately =E2=80= =A6 > > Thanks! > > Regards, > Jordi > > > > > ********************************************** > 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 > confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045d33f2ca7ca20554cf40a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not enthusiastic about making changes at this time, f= irst because I think there's no urgency, and second because I do not kn= ow what "require HNCP" means. =C2=A0 Can you elaborate?

On Fri, Jul 21, 2017 = at 9:48 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es&= gt; wrote:
Hi all,

We will like to know the WG opinions on this.

(I=E2=80=99m sending this email after checking with the WG chairs if they a= gree on it)

Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), ha= ve a chat about a possible path forward with the RFC7084-bis and related do= cs.

If I understood correctly, we somehow agreed that a possible path is (let= =E2=80=99s call this CHOICE 1):
1) Not change/update the existing RFC7084.
2) Use my =E2=80=9CTransition Requirements for IPv6 Customer Edge Routers= =E2=80=9D document (draft-palet-v6ops-rfc7084-bis-transition-00) as a = starting point, which =E2=80=9Cextend=E2=80=9D the requirements of RFC7084 = towards supporting actual world transition requirements.
3) In this updated document, the transition requirements can then be a MUST= , so vendors take it seriously.
4) I will include the reference to RFC8026 (some more text, as this referen= ce is already in all my docs regarding this topic), so there is a =E2=80=9C= flow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can get working IPv6= and then IPv4 if it is available from the ISP =E2=80=9Cas a service=E2=80= =9D. I think this can have also what Fred was suggesting as =E2=80=9CIPv6 m= ust be on by default=E2=80=9D, right?

CHOICE 2 (to make it clear, my own toughs after waking up this morning, not= discussed with the other folks yesterday):
Same as choice 1 above, but include also support for HNCP and may be someth= ing else if we believe it is required during the development of this docume= nt (for example it seems clear that if we offer IPv4 as a service, because = actual multicast-based IPTV services run on IPv4, we need to keep supportin= g that on top of an IPv6-only access).
So then the document will be renamed to something such as =E2=80=9CTransiti= on and extended requirements for IPv6 CE routers=E2=80=9D.

Tim, Barbara, James, can you confirm if I got right choice 1, or misunderst= ood/missed anything?

WG participants, could you provide your view on those two options?

Tim (Winters), could you tell from the perspective of the IPv6 Ready Logo P= rogram your view on those two approaches?

It will be nice to be able to double check all the inputs from yesterday v6= ops sessions, but looking at the etherpad I can=E2=80=99t see them, so may = be the note takers were using something else. It is possible to access the = minutes already someway? I will like to start working on this immediately = =E2=80=A6

Thanks!

Regards,
Jordi




**********************************************
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.



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

--f403045d33f2ca7ca20554cf40a8-- From nobody Fri Jul 21 01:05:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731D112EB2B for ; Fri, 21 Jul 2017 01:05: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, 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 OGOFpIONV1xm for ; Fri, 21 Jul 2017 01:05:38 -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 6F6B4131BC3 for ; Fri, 21 Jul 2017 01:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1500624336; x=1501229136; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=JxPafyTCfi4LgVbdSO244ua/Jv1Jds6JbBjNrUxYke8=; b=US3ytVlptMDbA iPvvG6Ua/oUNJwCFnd1BihTWuvF3hAeMFPhf2AWpdzjm/fv5cPeqPbpEYoytBtog KmTkmrteEswt39HgQ9xPzhc9v8CWDZ7qmkT1q+uliNNsXfrNMYhtQ46MAHbkRhB7 WBV5MqmIRMpUxa1pqdpd+Y2hWn0ZXY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=JR096lV5YcjE60WRXa4YeLHUPqUwo1y10e+xrTPwWiRUErEOUrmYQe/sNkG8 D5jCVeCdApzNR4ZO0X4C+8klpf4vqgBmhFeFX+v8QV69PkcJndDq6+axz 2tLm4ZnchXuk2YHuFpGX36fWdUB8tCSa7ASM5ho02y8+tWMAZGwjQk=; X-MDAV-Processed: mail.consulintel.es, Fri, 21 Jul 2017 10:05:36 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 21 Jul 2017 10:05:35 +0200 Received: from [31.133.159.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005482611.msg for ; Fri, 21 Jul 2017 10:05:35 +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:170721:md50005482611::NZkXKhwoUp8RIEQV:00003WYa X-MDRemoteIP: 31.133.159.135 X-Return-Path: prvs=13753e1d62=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Fri, 21 Jul 2017 10:05:32 +0200 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <95CE57F2-8DED-40FB-B19C-565F47E215AC@consulintel.es> Thread-Topic: [v6ops] possible path forward with RFC7084 and transition/other stuff Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:05:40 -0000 Hi Ted, I=E2=80=99m not sure to parse =E2=80=9Cmaking changes at this time=E2=80=9D= . Either we accept calling for consensus on =E2=80=9Cdraft-ietf-v6ops-rfc70= 84-bis-04=E2=80=9D, or we choose among the two options I mention above, or = something else =E2=80=A6=20 HNCP support as per RFC7788, was already included in draft-ietf-v6ops-rfc70= 84-bis-04 and I think got support from the WG. Regards, Jordi =20 -----Mensaje original----- De: Ted Lemon Responder a: Fecha: viernes, 21 de julio de 2017, 10:00 Para: JORDI PALET MARTINEZ CC: IPv6 Ops WG , james woodyatt Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward with = RFC7084 and transition/other stuff I am not enthusiastic about making changes at this time, first because = I think there's no urgency, and second because I do not know what "require = HNCP" means. Can you elaborate? =20 On Fri, Jul 21, 2017 at 9:48 AM, JORDI PALET MARTINEZ wrote: =20 Hi all, =20 We will like to know the WG opinions on this. =20 (I=E2=80=99m sending this email after checking with the WG chairs if th= ey agree on it) =20 Yesterday during the bits-N-bytes here in Prague, a few of us (in copy)= , have a chat about a possible path forward with the RFC7084-bis and relate= d docs. =20 If I understood correctly, we somehow agreed that a possible path is (l= et=E2=80=99s call this CHOICE 1): 1) Not change/update the existing RFC7084. 2) Use my =E2=80=9CTransition Requirements for IPv6 Customer Edge Route= rs=E2=80=9D document (draft-palet-v6ops-rfc7084-bis-transition-00) as a sta= rting point, which =E2=80=9Cextend=E2=80=9D the requirements of RFC7084 tow= ards supporting actual world transition requirements. 3) In this updated document, the transition requirements can then be a = MUST, so vendors take it seriously. 4) I will include the reference to RFC8026 (some more text, as this ref= erence is already in all my docs regarding this topic), so there is a =E2= =80=9Cflow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can get workin= g IPv6 and then IPv4 if it is available from the ISP =E2=80=9Cas a service= =E2=80=9D. I think this can have also what Fred was suggesting as =E2=80=9C= IPv6 must be on by default=E2=80=9D, right? =20 CHOICE 2 (to make it clear, my own toughs after waking up this morning,= not discussed with the other folks yesterday): Same as choice 1 above, but include also support for HNCP and may be so= mething else if we believe it is required during the development of this do= cument (for example it seems clear that if we offer IPv4 as a service, beca= use actual multicast-based IPTV services run on IPv4, we need to keep suppo= rting that on top of an IPv6-only access). So then the document will be renamed to something such as =E2=80=9CTran= sition and extended requirements for IPv6 CE routers=E2=80=9D. =20 Tim, Barbara, James, can you confirm if I got right choice 1, or misund= erstood/missed anything? =20 WG participants, could you provide your view on those two options? =20 Tim (Winters), could you tell from the perspective of the IPv6 Ready Lo= go Program your view on those two approaches? =20 It will be nice to be able to double check all the inputs from yesterda= y v6ops sessions, but looking at the etherpad I can=E2=80=99t see them, so = may be the note takers were using something else. It is possible to access = the minutes already someway? I will like to start working on this immediate= ly =E2=80=A6 =20 Thanks! =20 Regards, Jordi =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =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 Fri Jul 21 01:35:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951841317C1 for ; Fri, 21 Jul 2017 01:35:46 -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, 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=fugue-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 vwK3ufTCWlxT for ; Fri, 21 Jul 2017 01:35:44 -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 E69231317A1 for ; Fri, 21 Jul 2017 01:35:43 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id r76so4726689pfj.2 for ; Fri, 21 Jul 2017 01:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SWp3Yc6+/kKeERS1TRCOXgTGYYhYj/MuYvJwoU6pXFQ=; b=EqEwTG8NfPAG2gg+99LWPGXD/KAQ2u+hYF0bZbfiTcY5afg5KwYcuI+IcJiBWMNjwj 2EdcU4rq9NESs9SQ0nvoTpPxF0f0DNO2wNANHqc/dsf52LqtUCdigayR+8Wzud50JQ0E Akn2SHeRiNPwwfUBNofKK5YFHN1pyCWNkkG50pDA65BqmIncKMqnHWllUujIy2m3XEbf ZmYoNAbAvn3kqa0BB2XUHbp1pzAf0mMnzyfOM/r1DCykTnl3CSa3KBWB8UR5RinCrD9g B8PPFhJLboYqzl+lmamZumgRB1aGTFPara9qmoO9vwR3No3FzOSGT6YIPbGbC515Sm54 ZcOQ== 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=SWp3Yc6+/kKeERS1TRCOXgTGYYhYj/MuYvJwoU6pXFQ=; b=LnnjuDvsVqerCRVjaf7US6+htQarhrdk5uE2Ll/B/1+LRty6pcdnpswEPDnY0Vno0a grK79jhwHc7u7XzpHo39MoYP/2bXJ3AWJYx+9GHwUUIv8JjFz3ZggckbpoBTR1htZ0Nu 9Br0iqv6gYVrKxUqRJQF6d6iL72DeotrsS0/ZrDuBqHkMzaWmZFxfwjcBSycmMKyEtwB 7CiEnh+dF87DdIDVooRGbJeh4qP9UWxoTwpqiUTw8Eoq9g0dYihFA6XqeGfR/+nfxhyg 3kT4XkGhZqlPLQyWGYI9KC+tANMfDa8wEH4JBeVIW+koH6hgvOiS2FjiYxyVwEkTkpWP ZqBg== X-Gm-Message-State: AIVw113a8aUgNroKCdssmeqHWWI38X8nHGV12sMiJFfayXbs+DJf9vhQ zyfk8eI2WIKasC0ORkpIU89i6aDzJPjo X-Received: by 10.99.107.193 with SMTP id g184mr6617927pgc.167.1500626143527; Fri, 21 Jul 2017 01:35:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.130 with HTTP; Fri, 21 Jul 2017 01:35:03 -0700 (PDT) In-Reply-To: <95CE57F2-8DED-40FB-B19C-565F47E215AC@consulintel.es> References: <95CE57F2-8DED-40FB-B19C-565F47E215AC@consulintel.es> From: Ted Lemon Date: Fri, 21 Jul 2017 10:35:03 +0200 Message-ID: To: JORDI PALET MARTINEZ Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c14088a39dd0c0554cfc0cb" Archived-At: Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 08:35:47 -0000 --94eb2c14088a39dd0c0554cfc0cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, I got a bit of mental crosstalk between this discussion and another one. My main concern is that I don't think the HNCP text is practicable right now. If we are going to require HNCP, we need to say what requiring HNCP means in practice. I don't have a strong opinion on the actual question you asked--sorry about that. On Fri, Jul 21, 2017 at 10:05 AM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi Ted, > > I=E2=80=99m not sure to parse =E2=80=9Cmaking changes at this time=E2=80= =9D. Either we accept > calling for consensus on =E2=80=9Cdraft-ietf-v6ops-rfc7084-bis-04=E2=80= =9D, or we choose > among the two options I mention above, or something else =E2=80=A6 > > HNCP support as per RFC7788, was already included in > draft-ietf-v6ops-rfc7084-bis-04 and I think got support from the WG. > > Regards, > Jordi > > > -----Mensaje original----- > De: Ted Lemon > Responder a: > Fecha: viernes, 21 de julio de 2017, 10:00 > Para: JORDI PALET MARTINEZ > CC: IPv6 Ops WG , james woodyatt > Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward wit= h > RFC7084 and transition/other stuff > > I am not enthusiastic about making changes at this time, first becaus= e > I think there's no urgency, and second because I do not know what "requir= e > HNCP" means. Can you elaborate? > > On Fri, Jul 21, 2017 at 9:48 AM, JORDI PALET MARTINEZ < > jordi.palet@consulintel.es> wrote: > > Hi all, > > We will like to know the WG opinions on this. > > (I=E2=80=99m sending this email after checking with the WG chairs if = they > agree on it) > > Yesterday during the bits-N-bytes here in Prague, a few of us (in > copy), have a chat about a possible path forward with the RFC7084-bis and > related docs. > > If I understood correctly, we somehow agreed that a possible path is > (let=E2=80=99s call this CHOICE 1): > 1) Not change/update the existing RFC7084. > 2) Use my =E2=80=9CTransition Requirements for IPv6 Customer Edge Rou= ters=E2=80=9D > document (draft-palet-v6ops-rfc7084-bis-transition-00) as a starting > point, which =E2=80=9Cextend=E2=80=9D the requirements of RFC7084 towards= supporting actual > world transition requirements. > 3) In this updated document, the transition requirements can then be = a > MUST, so vendors take it seriously. > 4) I will include the reference to RFC8026 (some more text, as this > reference is already in all my docs regarding this topic), so there is a > =E2=80=9Cflow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can get w= orking IPv6 and then IPv4 if it is > available from the ISP =E2=80=9Cas a service=E2=80=9D. I think this can h= ave also what Fred > was suggesting as =E2=80=9CIPv6 must be on by default=E2=80=9D, right? > > CHOICE 2 (to make it clear, my own toughs after waking up this > morning, not discussed with the other folks yesterday): > Same as choice 1 above, but include also support for HNCP and may be > something else if we believe it is required during the development of thi= s > document (for example it seems clear that if we offer IPv4 as a service, > because actual multicast-based IPTV services run on IPv4, we need to keep > supporting that on top of an IPv6-only access). > So then the document will be renamed to something such as =E2=80=9CTr= ansition > and extended requirements for IPv6 CE routers=E2=80=9D. > > Tim, Barbara, James, can you confirm if I got right choice 1, or > misunderstood/missed anything? > > WG participants, could you provide your view on those two options? > > Tim (Winters), could you tell from the perspective of the IPv6 Ready > Logo Program your view on those two approaches? > > It will be nice to be able to double check all the inputs from > yesterday v6ops sessions, but looking at the etherpad I can=E2=80=99t see= them, so > may be the note takers were using something else. It is possible to acces= s > the minutes already someway? I will like to start working on this > immediately =E2=80=A6 > > Thanks! > > Regards, > Jordi > > > > > ********************************************** > 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 confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > ********************************************** > 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 > confidential. 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 disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c14088a39dd0c0554cfc0cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I got a bit of mental crosstalk between this discus= sion and another one. =C2=A0 My main concern is that I don't think the = HNCP text is practicable right now. =C2=A0 If we are going to require HNCP,= we need to say what requiring HNCP means in practice. =C2=A0 =C2=A0I don&#= 39;t have a strong opinion on the actual question you asked--sorry about th= at.

On Fri, = Jul 21, 2017 at 10:05 AM, JORDI PALET MARTINEZ <jordi.palet@consu= lintel.es> wrote:
Hi Ted,<= br>
I=E2=80=99m not sure to parse =E2=80=9Cmaking changes at this time=E2=80=9D= . Either we accept calling for consensus on =E2=80=9Cdraft-ietf-v6ops-rfc70= 84-bis-04=E2=80=9D, or we choose among the two options I mention above= , or something else =E2=80=A6

HNCP support as per RFC7788, was already included in draft-ietf-v6ops-rfc70= 84-bis-04 and I think got support from the WG.

Regards,
Jordi


-----Mensaje original-----
De: Ted Lemon <mellon@fugue.com&= gt;
Responder a: <mellon@fugue.com&g= t;
Fecha: viernes, 21 de julio de 2017, 10:00
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: IPv6 Ops WG <v6ops@ietf.org>= ;, james woodyatt <jhw@google.com&= gt;
Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.5/3.3] possible path forward with = RFC7084 and transition/other stuff

=C2=A0 =C2=A0 I am not enthusiastic about making changes at this time, firs= t because I think there's no urgency, and second because I do not know = what "require HNCP" means.=C2=A0 =C2=A0Can you elaborate?

=C2=A0 =C2=A0 On Fri, Jul 21, 2017 at 9:48 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es&g= t; wrote:

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 We will like to know the WG opinions on this.

=C2=A0 =C2=A0 (I=E2=80=99m sending this email after checking with the WG ch= airs if they agree on it)

=C2=A0 =C2=A0 Yesterday during the bits-N-bytes here in Prague, a few of us= (in copy), have a chat about a possible path forward with the RFC7084-bis = and related docs.

=C2=A0 =C2=A0 If I understood correctly, we somehow agreed that a possible = path is (let=E2=80=99s call this CHOICE 1):
=C2=A0 =C2=A0 1) Not change/update the existing RFC7084.
=C2=A0 =C2=A0 2) Use my =E2=80=9CTransition Requirements for IPv6 Customer = Edge Routers=E2=80=9D document (draft-palet-v6ops-rfc7084-bis-transiti= on-00) as a starting point, which =E2=80=9Cextend=E2=80=9D the requirements= of RFC7084 towards supporting actual world transition requirements.
=C2=A0 =C2=A0 3) In this updated document, the transition requirements can = then be a MUST, so vendors take it seriously.
=C2=A0 =C2=A0 4) I will include the reference to RFC8026 (some more text, a= s this reference is already in all my docs regarding this topic), so there = is a =E2=80=9Cflow=E2=80=9D of how the pair =E2=80=9CISP-CE=E2=80=9D can ge= t working IPv6 and then IPv4 if it is available from the ISP =E2=80=9Cas a = service=E2=80=9D. I think this can have also what Fred was suggesting as = =E2=80=9CIPv6 must be on by default=E2=80=9D, right?

=C2=A0 =C2=A0 CHOICE 2 (to make it clear, my own toughs after waking up thi= s morning, not discussed with the other folks yesterday):
=C2=A0 =C2=A0 Same as choice 1 above, but include also support for HNCP and= may be something else if we believe it is required during the development = of this document (for example it seems clear that if we offer IPv4 as a ser= vice, because actual multicast-based IPTV services run on IPv4, we need to = keep supporting that on top of an IPv6-only access).
=C2=A0 =C2=A0 So then the document will be renamed to something such as =E2= =80=9CTransition and extended requirements for IPv6 CE routers=E2=80=9D.
=C2=A0 =C2=A0 Tim, Barbara, James, can you confirm if I got right choice 1,= or misunderstood/missed anything?

=C2=A0 =C2=A0 WG participants, could you provide your view on those two opt= ions?

=C2=A0 =C2=A0 Tim (Winters), could you tell from the perspective of the IPv= 6 Ready Logo Program your view on those two approaches?

=C2=A0 =C2=A0 It will be nice to be able to double check all the inputs fro= m yesterday v6ops sessions, but looking at the etherpad I can=E2=80=99t see= them, so may be the note takers were using something else. It is possible = to access the minutes already someway? I will like to start working on this= immediately =E2=80=A6

=C2=A0 =C2=A0 Thanks!

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Jordi




=C2=A0 =C2=A0 **********************************************
=C2=A0 =C2=A0 IPv4 is over
=C2=A0 =C2=A0 Are you ready for the new Internet ?
=C2=A0 =C2=A0 http://www.consulintel.es
=C2=A0 =C2=A0 The IPv6 Company

=C2=A0 =C2=A0 This electronic message contains information which may be pri= vileged or confidential. The information is intended to be for the use of t= he individual(s) named above. If you are not the intended recipient be awar= e that any disclosure, copying, distribution or use of the contents of this= information, including attached files, is prohibited.



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









**********************************************
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.



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

--94eb2c14088a39dd0c0554cfc0cb-- From nobody Fri Jul 21 02:25:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8D13150C for ; Fri, 21 Jul 2017 02:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng40qyw_x8ol for ; Fri, 21 Jul 2017 02:25:50 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E2120127869 for ; Fri, 21 Jul 2017 02:25:50 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6L9P9C9044213; Fri, 21 Jul 2017 05:25:43 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2bu7q084gc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 05:25:42 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6L9Pfh8008366; Fri, 21 Jul 2017 05:25:41 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6L9PYe3008260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jul 2017 05:25:35 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 21 Jul 2017 09:25:14 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 21 Jul 2017 05:25:14 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" CC: Tim Chown , james woodyatt Thread-Topic: possible path forward with RFC7084 and transition/other stuff Thread-Index: AQHTAfY6d5+T2L4jnUmXzScWDzQp/6JeACKw Date: Fri, 21 Jul 2017 09:25:13 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBD5815@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> In-Reply-To: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.252.246] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210147 Archived-At: Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:25:52 -0000 DQoNCj4gMSkgTm90IGNoYW5nZS91cGRhdGUgdGhlIGV4aXN0aW5nIFJGQzcwODQuDQo+IDIpIFVz ZSBteSDigJxUcmFuc2l0aW9uIFJlcXVpcmVtZW50cyBmb3IgSVB2NiBDdXN0b21lciBFZGdlIFJv dXRlcnPigJ0NCj4gZG9jdW1lbnQgKGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzcwODQtYmlzLXRyYW5z aXRpb24tMDApIGFzIGEgc3RhcnRpbmcgcG9pbnQsDQo+IHdoaWNoIOKAnGV4dGVuZOKAnSB0aGUg cmVxdWlyZW1lbnRzIG9mIFJGQzcwODQgdG93YXJkcyBzdXBwb3J0aW5nIGFjdHVhbA0KPiB3b3Js ZCB0cmFuc2l0aW9uIHJlcXVpcmVtZW50cy4NCj4gMykgSW4gdGhpcyB1cGRhdGVkIGRvY3VtZW50 LCB0aGUgdHJhbnNpdGlvbiByZXF1aXJlbWVudHMgY2FuIHRoZW4gYmUgYQ0KPiBNVVNULCBzbyB2 ZW5kb3JzIHRha2UgaXQgc2VyaW91c2x5Lg0KPiA0KSBJIHdpbGwgaW5jbHVkZSB0aGUgcmVmZXJl bmNlIHRvIFJGQzgwMjYgKHNvbWUgbW9yZSB0ZXh0LCBhcyB0aGlzIHJlZmVyZW5jZQ0KPiBpcyBh bHJlYWR5IGluIGFsbCBteSBkb2NzIHJlZ2FyZGluZyB0aGlzIHRvcGljKSwgc28gdGhlcmUgaXMg YSDigJxmbG934oCdIG9mIGhvdyB0aGUNCj4gcGFpciDigJxJU1AtQ0XigJ0gY2FuIGdldCB3b3Jr aW5nIElQdjYgYW5kIHRoZW4gSVB2NCBpZiBpdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgSVNQDQo+ IOKAnGFzIGEgc2VydmljZeKAnS4gSSB0aGluayB0aGlzIGNhbiBoYXZlIGFsc28gd2hhdCBGcmVk IHdhcyBzdWdnZXN0aW5nIGFzIOKAnElQdjYNCj4gbXVzdCBiZSBvbiBieSBkZWZhdWx04oCdLCBy aWdodD8NCg0KSSB3b3VsZCBzdXBwb3J0IHRoaXMuIElmIHlvdXIgZ29hbCByZWFsbHkgaXMgZW5j b3VyYWdpbmcgdGhlIGF2YWlsYWJpbGl0eSBvZiBDRSByb3V0ZXJzIHdpdGggdGhlc2UgdjQgb3Zl ciB2NiB0ZWNobm9sb2dpZXMsIHRoaXMgaXMgdGhlIGFwcHJvYWNoIEkgd291bGQgcmVjb21tZW5k Lg0KDQo+IENIT0lDRSAyICh0byBtYWtlIGl0IGNsZWFyLCBteSBvd24gdG91Z2hzIGFmdGVyIHdh a2luZyB1cCB0aGlzIG1vcm5pbmcsIG5vdA0KPiBkaXNjdXNzZWQgd2l0aCB0aGUgb3RoZXIgZm9s a3MgeWVzdGVyZGF5KToNCj4gU2FtZSBhcyBjaG9pY2UgMSBhYm92ZSwgYnV0IGluY2x1ZGUgYWxz byBzdXBwb3J0IGZvciBITkNQIGFuZCBtYXkgYmUNCj4gc29tZXRoaW5nIGVsc2UgaWYgd2UgYmVs aWV2ZSBpdCBpcyByZXF1aXJlZCBkdXJpbmcgdGhlIGRldmVsb3BtZW50IG9mIHRoaXMNCj4gZG9j dW1lbnQgKGZvciBleGFtcGxlIGl0IHNlZW1zIGNsZWFyIHRoYXQgaWYgd2Ugb2ZmZXIgSVB2NCBh cyBhIHNlcnZpY2UsDQo+IGJlY2F1c2UgYWN0dWFsIG11bHRpY2FzdC1iYXNlZCBJUFRWIHNlcnZp Y2VzIHJ1biBvbiBJUHY0LCB3ZSBuZWVkIHRvIGtlZXANCj4gc3VwcG9ydGluZyB0aGF0IG9uIHRv cCBvZiBhbiBJUHY2LW9ubHkgYWNjZXNzKS4NCj4gU28gdGhlbiB0aGUgZG9jdW1lbnQgd2lsbCBi ZSByZW5hbWVkIHRvIHNvbWV0aGluZyBzdWNoIGFzIOKAnFRyYW5zaXRpb24gYW5kDQo+IGV4dGVu ZGVkIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBDRSByb3V0ZXJz4oCdLg0KDQpJIHdvdWxkIG5vdCBz dXBwb3J0IHRoaXMuIEkgdGhpbmsgaXQgd291bGQgbWFrZSB0aGUgZG9jdW1lbnQgbGVzcyBmb2N1 c2VkIGFuZCB0aGVyZWZvcmUgbW9yZSBsaWtlbHkgdG8gYmUgaWdub3JlZC4NCg0KQmFyYmFyYQ0K From nobody Fri Jul 21 03:51:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A86129B3A for ; Fri, 21 Jul 2017 03:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 CeS5xI0mt4Va for ; Fri, 21 Jul 2017 03:51:52 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C50127337 for ; Fri, 21 Jul 2017 03:51:52 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id DBD2260611; Fri, 21 Jul 2017 12:51:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id B646818005A; Fri, 21 Jul 2017 12:51:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0352.000; Fri, 21 Jul 2017 12:51:50 +0200 From: To: "STARK, BARBARA H" , "jordi.palet@consulintel.es" , "v6ops@ietf.org" CC: james woodyatt Thread-Topic: possible path forward with RFC7084 and transition/other stuff Thread-Index: AQHTAfYvm5fd7PB/t0WGdt3Tc+v7nqJd4Q+AgAA4ofA= Date: Fri, 21 Jul 2017 10:51:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A011AC7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DBD5815@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBD5815@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 10:51:55 -0000 SGkgSm9yZGksIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIEJhcmJhcmEsIGhlcmUuIA0KDQpJIGRvIHNl ZSBhIHZhbGUgaW4gbm90IG9ic29sZXRpbmcgNzA4NC4gU28gc2NvcGluZyB5b3VyIGRvY3VtZW50 IGFjY29yZGluZ2x5IGlzIHRoZSByaWdodCBhcHByb2FjaCB0byBhZG9wdCBoZXJlLiAgDQoNCkkg d291bGQgbm90IGFkZCB0aGUgZmxvdyB0byByZXN0YXRlIHdoYXQgaXMgYWxyZWFkeSBpbiA4MDI2 LiBDaXRpbmcgaXQgd291bGQgYmUgc3VmZmljaWVudCwgSU1PLg0KDQpDaGVlcnMsDQpNZWQNCg0K PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogdjZvcHMgW21haWx0bzp2Nm9w cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFNUQVJLLCBCQVJCQVJBIEgNCj4gRW52 b3nDqcKgOiB2ZW5kcmVkaSAyMSBqdWlsbGV0IDIwMTcgMTE6MjUNCj4gw4DCoDogam9yZGkucGFs ZXRAY29uc3VsaW50ZWwuZXM7IHY2b3BzQGlldGYub3JnDQo+IENjwqA6IGphbWVzIHdvb2R5YXR0 DQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIHBvc3NpYmxlIHBhdGggZm9yd2FyZCB3aXRoIFJGQzcw ODQgYW5kDQo+IHRyYW5zaXRpb24vb3RoZXIgc3R1ZmYNCj4gDQo+IA0KPiANCj4gPiAxKSBOb3Qg Y2hhbmdlL3VwZGF0ZSB0aGUgZXhpc3RpbmcgUkZDNzA4NC4NCj4gPiAyKSBVc2UgbXkg4oCcVHJh bnNpdGlvbiBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJz4oCdDQo+ ID4gZG9jdW1lbnQgKGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzcwODQtYmlzLXRyYW5zaXRpb24tMDAp IGFzIGEgc3RhcnRpbmcNCj4gcG9pbnQsDQo+ID4gd2hpY2gg4oCcZXh0ZW5k4oCdIHRoZSByZXF1 aXJlbWVudHMgb2YgUkZDNzA4NCB0b3dhcmRzIHN1cHBvcnRpbmcgYWN0dWFsDQo+ID4gd29ybGQg dHJhbnNpdGlvbiByZXF1aXJlbWVudHMuDQo+ID4gMykgSW4gdGhpcyB1cGRhdGVkIGRvY3VtZW50 LCB0aGUgdHJhbnNpdGlvbiByZXF1aXJlbWVudHMgY2FuIHRoZW4gYmUgYQ0KPiA+IE1VU1QsIHNv IHZlbmRvcnMgdGFrZSBpdCBzZXJpb3VzbHkuDQo+ID4gNCkgSSB3aWxsIGluY2x1ZGUgdGhlIHJl ZmVyZW5jZSB0byBSRkM4MDI2IChzb21lIG1vcmUgdGV4dCwgYXMgdGhpcw0KPiByZWZlcmVuY2UN Cj4gPiBpcyBhbHJlYWR5IGluIGFsbCBteSBkb2NzIHJlZ2FyZGluZyB0aGlzIHRvcGljKSwgc28g dGhlcmUgaXMgYSDigJxmbG934oCdIG9mDQo+IGhvdyB0aGUNCj4gPiBwYWlyIOKAnElTUC1DReKA nSBjYW4gZ2V0IHdvcmtpbmcgSVB2NiBhbmQgdGhlbiBJUHY0IGlmIGl0IGlzIGF2YWlsYWJsZSBm cm9tDQo+IHRoZSBJU1ANCj4gPiDigJxhcyBhIHNlcnZpY2XigJ0uIEkgdGhpbmsgdGhpcyBjYW4g aGF2ZSBhbHNvIHdoYXQgRnJlZCB3YXMgc3VnZ2VzdGluZyBhcw0KPiDigJxJUHY2DQo+ID4gbXVz dCBiZSBvbiBieSBkZWZhdWx04oCdLCByaWdodD8NCj4gDQo+IEkgd291bGQgc3VwcG9ydCB0aGlz LiBJZiB5b3VyIGdvYWwgcmVhbGx5IGlzIGVuY291cmFnaW5nIHRoZSBhdmFpbGFiaWxpdHkNCj4g b2YgQ0Ugcm91dGVycyB3aXRoIHRoZXNlIHY0IG92ZXIgdjYgdGVjaG5vbG9naWVzLCB0aGlzIGlz IHRoZSBhcHByb2FjaCBJDQo+IHdvdWxkIHJlY29tbWVuZC4NCj4gDQo+ID4gQ0hPSUNFIDIgKHRv IG1ha2UgaXQgY2xlYXIsIG15IG93biB0b3VnaHMgYWZ0ZXIgd2FraW5nIHVwIHRoaXMgbW9ybmlu ZywNCj4gbm90DQo+ID4gZGlzY3Vzc2VkIHdpdGggdGhlIG90aGVyIGZvbGtzIHllc3RlcmRheSk6 DQo+ID4gU2FtZSBhcyBjaG9pY2UgMSBhYm92ZSwgYnV0IGluY2x1ZGUgYWxzbyBzdXBwb3J0IGZv ciBITkNQIGFuZCBtYXkgYmUNCj4gPiBzb21ldGhpbmcgZWxzZSBpZiB3ZSBiZWxpZXZlIGl0IGlz IHJlcXVpcmVkIGR1cmluZyB0aGUgZGV2ZWxvcG1lbnQgb2YNCj4gdGhpcw0KPiA+IGRvY3VtZW50 IChmb3IgZXhhbXBsZSBpdCBzZWVtcyBjbGVhciB0aGF0IGlmIHdlIG9mZmVyIElQdjQgYXMgYSBz ZXJ2aWNlLA0KPiA+IGJlY2F1c2UgYWN0dWFsIG11bHRpY2FzdC1iYXNlZCBJUFRWIHNlcnZpY2Vz IHJ1biBvbiBJUHY0LCB3ZSBuZWVkIHRvDQo+IGtlZXANCj4gPiBzdXBwb3J0aW5nIHRoYXQgb24g dG9wIG9mIGFuIElQdjYtb25seSBhY2Nlc3MpLg0KPiA+IFNvIHRoZW4gdGhlIGRvY3VtZW50IHdp bGwgYmUgcmVuYW1lZCB0byBzb21ldGhpbmcgc3VjaCBhcyDigJxUcmFuc2l0aW9uDQo+IGFuZA0K PiA+IGV4dGVuZGVkIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBDRSByb3V0ZXJz4oCdLg0KPiANCj4g SSB3b3VsZCBub3Qgc3VwcG9ydCB0aGlzLiBJIHRoaW5rIGl0IHdvdWxkIG1ha2UgdGhlIGRvY3Vt ZW50IGxlc3MgZm9jdXNlZA0KPiBhbmQgdGhlcmVmb3JlIG1vcmUgbGlrZWx5IHRvIGJlIGlnbm9y ZWQuDQo+IA0KPiBCYXJiYXJhDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Fri Jul 21 04:00:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0112ECF0 for ; Fri, 21 Jul 2017 04:00:40 -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 aY910VW3xvTI for ; Fri, 21 Jul 2017 04:00:38 -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 7BA7212EC51 for ; Fri, 21 Jul 2017 04:00:37 -0700 (PDT) X-Envelope-To: v6ops@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 v6LB0SG8032025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2017 12:00: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: <5971DECC.3030005@foobar.org> Date: Fri, 21 Jul 2017 12:00:28 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: jordi.palet@consulintel.es CC: v6ops@ietf.org References: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> In-Reply-To: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:00:40 -0000 JORDI PALET MARTINEZ wrote: > (I’m sending this email after checking with the WG chairs if they agree on it) > > Yesterday during the bits-N-bytes here in Prague, a few of us (in copy), have a chat about a possible path forward with the RFC7084-bis and related docs. > > If I understood correctly, we somehow agreed that a possible path is (let’s call this CHOICE 1): > 1) Not change/update the existing RFC7084. > 2) Use my “Transition Requirements for IPv6 Customer Edge Routers” document (draft-palet-v6ops-rfc7084-bis-transition-00) as a starting point, which “extend” the requirements of RFC7084 towards supporting actual world transition requirements. > 3) In this updated document, the transition requirements can then be a MUST, so vendors take it seriously. > 4) I will include the reference to RFC8026 (some more text, as this reference is already in all my docs regarding this topic), so there is a “flow” of how the pair “ISP-CE” can get working IPv6 and then IPv4 if it is available from the ISP “as a service”. I think this can have also what Fred was suggesting as “IPv6 must be on by default”, right? > > CHOICE 2 (to make it clear, my own toughs after waking up this morning, not discussed with the other folks yesterday): > Same as choice 1 above, but include also support for HNCP and may be something else if we believe it is required during the development of this document (for example it seems clear that if we offer IPv4 as a service, because actual multicast-based IPTV services run on IPv4, we need to keep supporting that on top of an IPv6-only access). > So then the document will be renamed to something such as “Transition and extended requirements for IPv6 CE routers”. > > Tim, Barbara, James, can you confirm if I got right choice 1, or misunderstood/missed anything? > > WG participants, could you provide your view on those two options? I haven't seen much deployment of HNCP, so at this stage it would probably be premature to state it as a requirement in a CPE router scenario. Otherwise, option 1 looks great, so go for it! Nick From nobody Fri Jul 21 04:24:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7B131483; Fri, 21 Jul 2017 04:24: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, 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 Zo57jjBSgS83; Fri, 21 Jul 2017 04:24:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A824B129B7F; Fri, 21 Jul 2017 04:24:47 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-9cfb.meeting.ietf.org [31.133.156.251]) by relay.sandelman.ca (Postfix) with ESMTPS id 825F31F8F6; Fri, 21 Jul 2017 11:24:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1851C1638; Fri, 21 Jul 2017 13:24:37 +0200 (CEST) From: Michael Richardson To: Fred Baker cc: IPv6 Ops WG , 6man WG In-reply-to: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> Comments: In-reply-to Fred Baker message dated "Thu, 20 Jul 2017 16:22:56 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 13:24:37 +0200 Message-ID: <7172.1500636277@dooku.sandelman.ca> Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:24:49 -0000 --=-=-= Content-Type: text/plain Fred Baker wrote: > Note that this is not as simple as it might sound. There are at least > three configurations that must be allowed for upstream: bridging the > ISP downstream and CPE downstream LANs, Address allocation via DHCP > IA_NA, and address allocation via SLAAC, and on the CPE downstream > LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a > flowchart for this or RFC 7084 defines the algorithms. The > implementation is going to have to enable all three, see which works, > and act accordingly. As an implementer of a PPPoE aggregator/access-router, I found that I had to invert 7084 to determine what I had to implement. It might be worth a document, if only so that ISPs would have something against which to issue RFPs. Maybe. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZceR0AAoJEJVM4Vb9/EKQCqkH/0c9FAxQkHkxtUenPlRkD5mR 77BCopNVhBb4Hvd+rnZaSBqUwldNCQy9gmEbCSirirbyinbpbwI1iOiJAuyb2Iqx PCJO7MfNTsSBJzYCF8x3yzORCs1RrrIlIdVXTwzZQZ8znnTihXha7YFic1XF4Hmb hkRQUxZc9m9MD9PndXnLLqFj4FlC/0V2JpVPwbLxAn1qLEaH0grKTWMXhxnGCF9L 1FikW9Wt82YXZdE/nOJ1wR3EVYuuNVt9Lr9CUctfYaJvcu9fO31+W2WMdXyzTh3N fxCyGKGdWBsLMIGAuzMnBNJErAGZsCNTWgA+NXjbpi9O77DOBIbtIvCf1zNxzik= =lizs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 04:49:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA8131A85; Fri, 21 Jul 2017 04:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 ojYXFcnQlvhR; Fri, 21 Jul 2017 04:49:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2F69F131667; Fri, 21 Jul 2017 04:49:29 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6LBj39V014558; Fri, 21 Jul 2017 07:49:26 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2bu989h4tv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 07:49:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6LBnPX6004930; Fri, 21 Jul 2017 07:49:26 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6LBnLG8004852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jul 2017 07:49:21 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 21 Jul 2017 11:49:09 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 21 Jul 2017 07:49:09 -0400 From: "STARK, BARBARA H" To: Michael Richardson CC: Fred Baker , IPv6 Ops WG , "6man WG" Thread-Topic: [v6ops] Turning on IPv6 Routers Thread-Index: AQHTAWPFkLIZRLGj4keSA/TjIMCW16JeaCWA///Dy6U= Date: Fri, 21 Jul 2017 11:49:08 +0000 Message-ID: <9EBF75B4-CF2F-42C2-B0B4-EC4948F27843@att.com> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>, <7172.1500636277@dooku.sandelman.ca> In-Reply-To: <7172.1500636277@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210185 Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:49:31 -0000 --_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an implementer of a PPPoE aggregator/access-router, I found that I had to invert 7084 to determine what I had to implement. It might be worth a document, if only so that ISPs would have something against which to issue RFPs. Maybe. BBF TR-187 documents the telco IPv6 over pppoe access network archite= cture with some specific requirements for access network elements. https://= www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf --_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As an implementer of a PPPoE a= ggregator/access-router, I found that I
had to invert 7084 to determine what I had to implement.

It might be worth a document, if only so that ISPs would have somethi= ng
against which to issue RFPs.  Maybe.

<bhs> BBF TR-187 documents the telco IPv6 over pppoe access network a= rchitecture with some specific requirements for access network elements.&nb= sp;https://www.broadband-forum.org/technical/download/TR-187_Issue-2= .pdf
--_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_-- From nobody Fri Jul 21 04:53:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39032131667 for ; Fri, 21 Jul 2017 04:53:16 -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 YyavkcrZqjQc for ; Fri, 21 Jul 2017 04:53:14 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA3D12ECB7 for ; Fri, 21 Jul 2017 04:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500637991; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=wiNq3B4k2HIgvZYbNRVaa05LDxtv8lCFRl3EWwWdCkw=; b=FlgFjRAlvHhSOEmg08UonhnmKcbufwAOrunc+F6WWzYuu/PiHpCJiUo8LhBnKmlecGd88kMDjJPbttTdoJ1o8sQMFiMFzRtutvsIPzkwiuyhmpb+64YfuPdlU200HXbjnPcA3hnz1YL5ZMpFdFWM0S1/uSfK03BukmK1LUUUwTI= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-29-douavmQPM7q6RGs5xGr7CQ-1; Fri, 21 Jul 2017 12:53:06 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1156.eurprd07.prod.outlook.com (10.163.188.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Fri, 21 Jul 2017 11:53:03 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1304.010; Fri, 21 Jul 2017 11:53:02 +0000 From: Tim Chown To: Michael Richardson CC: Fred Baker , IPv6 Ops WG , "6man WG" Thread-Topic: [v6ops] Turning on IPv6 Routers Thread-Index: AQHTAWO3srz2b9wieU6bc38h1/dUM6JeJReAgAAH8QA= Date: Fri, 21 Jul 2017 11:53:02 +0000 Message-ID: <7A7963E2-F45B-4ACC-9627-060D8BDBF5E7@jisc.ac.uk> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <7172.1500636277@dooku.sandelman.ca> In-Reply-To: <7172.1500636277@dooku.sandelman.ca> 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:67c:1232:144:ccb6:479:3700:e540] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1156; 20:st0fyP/zcLSa2Mgwb+FvDfBauHOAV8vsIWQK6zM0cV3bZPss3/ji2KKfXDC3ZBxb/jKx5ZsIx+liOZMpcNagUjSPrU14YARANR9bnETjLu1JnScH4OlHIbHElAZV/iVKrfso9le810LXQDTZuLMQ6TkaacGpjJqvBaOE3DDsz7c= x-ms-office365-filtering-correlation-id: f7b15c21-a354-4d63-9e96-08d4d02f0ad4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1156; x-ms-traffictypediagnostic: AM3PR07MB1156: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1156; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1156; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39840400002)(39850400002)(39410400002)(199003)(24454002)(189002)(2906002)(966005)(74482002)(6246003)(305945005)(53546010)(8936002)(101416001)(6116002)(110136004)(72206003)(4326008)(7736002)(97736004)(38730400002)(102836003)(81156014)(76176999)(81166006)(33656002)(50986999)(189998001)(5660300001)(8676002)(50226002)(39060400002)(2900100001)(14454004)(6436002)(82746002)(36756003)(105586002)(106356001)(86362001)(6306002)(54906002)(68736007)(6486002)(3280700002)(5250100002)(229853002)(57306001)(6506006)(25786009)(478600001)(3660700001)(99286003)(53936002)(83716003)(6512007)(2950100002)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1156; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <486C3312BB13924DBB30B14D72109C71@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 11:53:02.9204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1156 X-MC-Unique: douavmQPM7q6RGs5xGr7CQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:53:16 -0000 PiBPbiAyMSBKdWwgMjAxNywgYXQgMTI6MjQsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZA c2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQo+PiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYXMgc2ltcGxlIGFzIGl0 IG1pZ2h0IHNvdW5kLiBUaGVyZSBhcmUgYXQgbGVhc3QNCj4+IHRocmVlIGNvbmZpZ3VyYXRpb25z IHRoYXQgbXVzdCBiZSBhbGxvd2VkIGZvciB1cHN0cmVhbTogYnJpZGdpbmcgdGhlDQo+PiBJU1Ag ZG93bnN0cmVhbSBhbmQgQ1BFIGRvd25zdHJlYW0gTEFOcywgQWRkcmVzcyBhbGxvY2F0aW9uIHZp YSBESENQDQo+PiBJQV9OQSwgYW5kIGFkZHJlc3MgYWxsb2NhdGlvbiB2aWEgU0xBQUMsIGFuZCBv biB0aGUgQ1BFIGRvd25zdHJlYW0NCj4+IExBTihzKSwgYWRkcmVzcyBhbGxvY2F0aW9uIHZpYSBE SENQIElBX05BIGFuZCBTTEFBQy4gQkJGIFRSLTEyNCBnaXZlcyBhDQo+PiBmbG93Y2hhcnQgZm9y IHRoaXMgb3IgUkZDIDcwODQgZGVmaW5lcyB0aGUgYWxnb3JpdGhtcy4gVGhlDQo+PiBpbXBsZW1l bnRhdGlvbiBpcyBnb2luZyB0byBoYXZlIHRvIGVuYWJsZSBhbGwgdGhyZWUsIHNlZSB3aGljaCB3 b3JrcywNCj4+IGFuZCBhY3QgYWNjb3JkaW5nbHkuDQo+IA0KPiBBcyBhbiBpbXBsZW1lbnRlciBv ZiBhIFBQUG9FIGFnZ3JlZ2F0b3IvYWNjZXNzLXJvdXRlciwgSSBmb3VuZCB0aGF0IEkNCj4gaGFk IHRvIGludmVydCA3MDg0IHRvIGRldGVybWluZSB3aGF0IEkgaGFkIHRvIGltcGxlbWVudC4NCj4g DQo+IEl0IG1pZ2h0IGJlIHdvcnRoIGEgZG9jdW1lbnQsIGlmIG9ubHkgc28gdGhhdCBJU1BzIHdv dWxkIGhhdmUgc29tZXRoaW5nDQo+IGFnYWluc3Qgd2hpY2ggdG8gaXNzdWUgUkZQcy4gIE1heWJl Lg0KDQpUaGUgcXVlc3Rpb24gZm9yIDY0MzRiaXMgYW5kIHBlcmhhcHMgNzA4NGJpcyBpZiBpdCBo YXBwZW5zIGlzIHdoYXQgd29yZGluZyB0byBwdXQgaW4uDQoNClR1cm5pbmcgb24gSVB2NiBpbiBh IHRlc3RlZCBJU1DigJlzIHByb3ZpZGVkIENQRSBpcyBhIGRpZmZlcmVudCBtYXR0ZXIgdG8gYSDi gJxyYW5kb23igJ0gZGV2aWNlLCB3aGljaCBtYXkgb3IgbWF5IG5vdCBiZSBjZXJ0aWZpZWQgYWdh aW5zdCB0aGUgSVB2NiBSZWFkeSBwcm9ncmFtIGZvciA3MDg0IGNvbXBsaWFuY2UuDQoNCknigJlt IG5vdCBzdXJlIGlmIHRoZSBmb2xsb3dpbmcgaXMgdGhlIGN1cnJlbnQgdGVzdCBzY2VuYXJpbyBz cGVjIChsYXN0IHVwZGF0ZWQgSmFuIDIwMTYpLCBidXQgaXQgbGlzdHMgdGhlIENFIHRlc3RzIHRo YXQgdGhhdCBJUHY2IFJlYWR5IHByb2dyYW0gaW5jbHVkZXMsIGluY2x1ZGluZyA3MDg0Og0KaHR0 cHM6Ly93d3cuaW9sLnVuaC5lZHUvc2l0ZXMvZGVmYXVsdC9maWxlcy90ZXN0c3VpdGVzL2huYy9p cHY2X3JlYWR5X3Rlc3Rfc3BlY2lmaWNhdGlvbl9jZV9yb3V0ZXJfY29uZm9ybWFuY2UucGRmDQoN ClRpbQ== From nobody Fri Jul 21 06:00:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB0E131C13 for ; Fri, 21 Jul 2017 06:00: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (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 KMjRbSG3I3Mv for ; Fri, 21 Jul 2017 06:00:22 -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 535B912F24E for ; Fri, 21 Jul 2017 06:00:22 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id k43so8155483uaf.3 for ; Fri, 21 Jul 2017 06:00:22 -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:content-transfer-encoding; bh=Zhb0gApqU6bdKuAHST085Xpvu+y4V79FqtofVjVM6FI=; b=GnfWdF3C2cNbGgbOvAmxyLoGG/1nfzh9tZBeJe3zjzw3LQUlfjBF+KXzaUBmGnPy0L oiF6fDqLl/EjLw22Oi7R+camz7mE6tIbjEqqLx72DYQcpVNF0wt8LlPRc42D8i8zhWaQ niOkoWYnarNTMLJlzWKgeKkAQ7azYiqZeUolxv+JReCHyfz39iyFkQ9GRvkyMuOo0jNF 7/kenP5Q7cNkpjpCXYudVgfCxxbL4oEFBgeHOF/81WOSph0tFZeQ6f6429qmmr1EFmWi M7VOzradv3W/q9r9lXeAcVJopepY9Vg7lYE8teeb3OsBuTtZcQI7Z6R8T9XE90P0DuQJ ktxw== 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=Zhb0gApqU6bdKuAHST085Xpvu+y4V79FqtofVjVM6FI=; b=S4FVN10UyMr9lHb6Um9YqrYupl+wHOi0otyieQLG4zJeXyZt+WdqJEIGzhSu6xtcV7 ngURxmj7Z7aE4JyeUjnctuzHJoFileVKIgjDAdkqSPd8iYu6dOMtyPsZ1L0LygccD/Dg 51J/LE+TUFfYLJ/bFrdBybsiGwAOJR2uq0/X8dFAGNAtPC9c1IyXJedixC2KA3sI9jtx Ivnfqb/2VN9sZDhxnS0gdLcAtxklqMH/1gtYr1KkEN+gb3Dxu2Cd9kswNAx+6Oz8W7vj fe17xquWXhRh37zIDQSI0XBDEmuuRybRPZYpF18NenbcH7B0Xz/p25iYtC/7lOTNhk9s 7kIw== X-Gm-Message-State: AIVw110hFXrXfQhy/zhtPsC7vf1ZcU6oA5CCpsaLVkGyyquHMQMh48gN 2Je6VPbkgNfDVaHVurRTN2smsPaqQ8fm X-Received: by 10.176.23.3 with SMTP id j3mr4942968uaf.128.1500642021442; Fri, 21 Jul 2017 06:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Fri, 21 Jul 2017 06:00:20 -0700 (PDT) X-Originating-IP: [212.71.191.138] In-Reply-To: <7A7963E2-F45B-4ACC-9627-060D8BDBF5E7@jisc.ac.uk> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <7172.1500636277@dooku.sandelman.ca> <7A7963E2-F45B-4ACC-9627-060D8BDBF5E7@jisc.ac.uk> From: George Michaelson Date: Fri, 21 Jul 2017 15:00:20 +0200 Message-ID: To: Tim Chown Cc: Michael Richardson , IPv6 Ops WG , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:00:26 -0000 Somebody muttered to me that bridge mode means customer devices 'inside' the demarc present their identity to the BNG demanding some V6 love, which makes accountants very unhappy because they were using that CPE identity as a billing cycle token. So bridge mode, which we all love, can be a bit of a pain, if you decided to use something clever in IID. On Fri, Jul 21, 2017 at 1:53 PM, Tim Chown wrote: >> On 21 Jul 2017, at 12:24, Michael Richardson wro= te: >> >> Fred Baker wrote: >>> Note that this is not as simple as it might sound. There are at least >>> three configurations that must be allowed for upstream: bridging the >>> ISP downstream and CPE downstream LANs, Address allocation via DHCP >>> IA_NA, and address allocation via SLAAC, and on the CPE downstream >>> LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a >>> flowchart for this or RFC 7084 defines the algorithms. The >>> implementation is going to have to enable all three, see which works, >>> and act accordingly. >> >> As an implementer of a PPPoE aggregator/access-router, I found that I >> had to invert 7084 to determine what I had to implement. >> >> It might be worth a document, if only so that ISPs would have something >> against which to issue RFPs. Maybe. > > The question for 6434bis and perhaps 7084bis if it happens is what wordin= g to put in. > > Turning on IPv6 in a tested ISP=E2=80=99s provided CPE is a different mat= ter to a =E2=80=9Crandom=E2=80=9D device, which may or may not be certified= against the IPv6 Ready program for 7084 compliance. > > I=E2=80=99m not sure if the following is the current test scenario spec (= last updated Jan 2016), but it lists the CE tests that that IPv6 Ready prog= ram includes, including 7084: > https://www.iol.unh.edu/sites/default/files/testsuites/hnc/ipv6_ready_tes= t_specification_ce_router_conformance.pdf > > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 21 07:43:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6747131E2F; Fri, 21 Jul 2017 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 DENgDV71DY15; Fri, 21 Jul 2017 07:43:14 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 40A05131E2C; Fri, 21 Jul 2017 07:43:14 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id q4so53552419oif.1; Fri, 21 Jul 2017 07:43:14 -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=cUsJ2EtNsAuC6fRMiFkpWqKobTHYHbKdOaCsYX0FvCA=; b=s2ECSdcOSVyb0nnlZ3XZ5b7in5gAY8uNjpexHYF2RP0r6Al+q+CIRiNfWYNuC8rz79 UDtygLST8WAe8B2ZkQWUd2bU5BfImudWjlJfAUyios14JUUzjNE1CIKHfgs+Iv/SPwzN CMxWIGNVCaFd1CKt/IRWPU1Se/Xuu2kbz/AsNYOcuDzS99U+n64qS/rvUJTGXNh0iJDo b07dJU845oHvptDw0o+jkgbOuRFxYTVmLqDzVzUQdP5mOtzXsdPAc/VorpHMtCepduVk EJOG9xSzfE4AfSC21oME6KDPOS8KrXhHybvRYp2rDts3Hfhl+5AhP94fuRJ5r/jA/JM6 j2sA== 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=cUsJ2EtNsAuC6fRMiFkpWqKobTHYHbKdOaCsYX0FvCA=; b=Z6xsL9YITz6JezBnv6UzAJuFL6RNHo8y4/oEmWxwAyx5bVcTu53yV5zUodfdh0jpu0 7olOAorZz8DPVBJEcO+iPQNc2jLIo9VzVSnu/mkMbrnx0ixPHjq4IuqbI5KjyBqZ4Mmh XI4t/MM3t6rVjazzZzLZg1qYM0h9GNXyHKykIhHvJy+qIXhEcPr21BsxfHcfUiv9MV4A CmwEYwSacMgfFfu0UT35thNsMdEv3RjiJnYq5v2dyH4+l48VupnHQk+AUA0eftygfowX sRlC6i5lR3OKj8Im4Krrmw0cgjZTbrcXDV+OsF6rEHiDEo0ikvZ69fXJKyWdG4smFs/Z kc0w== X-Gm-Message-State: AIVw110VyE8F38+3Bg76PTH2jbxm+mJ9AIecySgBfH+RpyWJr1ahtsuU a9jsFg/9YV2Wr4uImyVmX9rjnbMREw== X-Received: by 10.202.204.208 with SMTP id c199mr2201269oig.253.1500648193510; Fri, 21 Jul 2017 07:43:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.41.198 with HTTP; Fri, 21 Jul 2017 07:43:12 -0700 (PDT) In-Reply-To: References: From: Zied BOUZIRI Date: Fri, 21 Jul 2017 15:43:12 +0100 Message-ID: To: Jen Linkova Cc: Olivier Bonaventure , Olivier Tilmans , V6 Ops List , RTGWG Content-Type: multipart/alternative; boundary="001a1135329c81d41c0554d4e2ed" Archived-At: Subject: Re: [v6ops] Eating our own dog food : students solving IPv6 entreprise multihoming X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 14:43:16 -0000 --001a1135329c81d41c0554d4e2ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot for sharing this Best regards On Fri, Jul 21, 2017 at 7:44 AM, Jen Linkova wrote: > Thanks a lot for sharing those results, Olivier! > > On Thu, Jul 20, 2017 at 4:53 PM, Olivier Bonaventure > wrote: > > Since then, our students only learn IPv6 > > and results are excellent. Once they've learned IPv6, they can quickly > > understand how IPv4 works. Hopefully they'll see sunset4 during their > > career. > > Amen! > > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *cordially*, *=D9=85=D8=B9 =D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A* *Zied BOUZIRI*=D8=8C *=D8=B2=D9=8A=D8=A7=D8=AF =D8=A8=D9=88=D8=B2=D9=8A=D8= =B1=D9=8A* ISET Charguia, Tunisie www.bouziri.tn --001a1135329c81d41c0554d4e2ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for sharing this
Best regards
=

On Fri, Jul 21, 2= 017 at 7:44 AM, Jen Linkova <furry13@gmail.com> wrote:
Thanks a lot for sharing those results, Olivie= r!

On Thu, Jul 20, 2017 at 4:53 PM, Olivier Bonaventure
<olivier.bonaventure= @tessares.net> wrote:
>=C2=A0 Since then, our students only learn IPv6
> and results are excellent. Once they've learned IPv6, they can qui= ckly
> understand how IPv4 works. Hopefully they'll see sunset4 during th= eir
> career.

=C2=A0Amen!

--
SY, Jen Linkova aka Furry

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



--
=
cordially, =D9=85=D8=B9 =D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A
Zied BOUZIRI=D8=8C =D8=B2=D9=8A=D8=A7=D8=AF =D8=A8=D9=88=D8=B2=D9=8A=D8=B1=D9= =8A
ISET Charguia, Tunisie
--001a1135329c81d41c0554d4e2ed-- From nobody Fri Jul 21 10:25:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6EA127601; Fri, 21 Jul 2017 10:25:40 -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, 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 ilxtHpSdjyj2; Fri, 21 Jul 2017 10:25:38 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9239A13167B; Fri, 21 Jul 2017 10:25:38 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 6B6F61F8F6; Fri, 21 Jul 2017 17:25:37 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 15DD61673; Fri, 21 Jul 2017 19:25:28 +0200 (CEST) From: Michael Richardson To: "STARK\, BARBARA H" cc: Fred Baker , IPv6 Ops WG , "6man WG" In-reply-to: <9EBF75B4-CF2F-42C2-B0B4-EC4948F27843@att.com> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>, <7172.1500636277@dooku.sandelman.ca> <9EBF75B4-CF2F-42C2-B0B4-EC4948F27843@att.com> Comments: In-reply-to "STARK, BARBARA H" message dated "Fri, 21 Jul 2017 11:49:08 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 19:25:28 +0200 Message-ID: <25429.1500657928@dooku.sandelman.ca> Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 17:25:40 -0000 --=-=-= Content-Type: text/plain STARK, BARBARA H wrote: > As an implementer of a PPPoE aggregator/access-router, I found that I > had to invert 7084 to determine what I had to implement. > It might be worth a document, if only so that ISPs would have something > against which to issue RFPs. Maybe. bhs> BBF TR-187 documents the telco IPv6 over pppoe access network bhs> architecture with some specific requirements for access network bhs> elements. bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf Yes, I worked from TR-187 as well. It's close to what I want, but it doesn't say what the access network elements *MUST* do, but rather tells you what the CPE boxes MUST try. For instance: *SHOULD* a PPPoE access router provide an address for the CPE router link via RA or via DHCPv6? If it does both, should it offer the same address? It would be rather better if one *knew* the CPE would do PD and then assign itself an address out of one of the /64s. That would eliminate a bunch of routes. Part of the problem is that one can't necessarily depend upon the CPE to do DHCPv6 (-PD) at all! It would just be nice to reduce the number of options. Maybe a BCP is in order. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZcjkHAAoJEJVM4Vb9/EKQjd8H/jUk5cj6MKeNd5FQ1+5p/FC7 EQl55objELygcfadEiuH+NgVCSZmXWaM3zzr7343+S8LPboP72WWvpFVH1JbjlsR GnMPxk2+a3AOoFWVuDYmLYNqZ9102QB31B32WY23xiXKc8OOQ+xrvPqqLq92kcVs As1Mra+A0NjGv80rjOxcLs26flvB8bQfjjh9RDevvFVW44Ijd2MwSLJKZP2GH7Eu be33RP6vOlhJIshXtboX/yxrt4slwgfhj7oaGpHvEYqWgOz/+Mcb78qQt/Wn5a0X DryKKZjQJNMU6TZ82iaZmGzyZHpWLmJmHJakDiQdsnh5erlr0oMZMMZTO+iNAks= =mA1e -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 14:10:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5D7129B35 for ; Fri, 21 Jul 2017 14:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=juniper.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 VKubHr5jnP10 for ; Fri, 21 Jul 2017 14:10:02 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA78128A32 for ; Fri, 21 Jul 2017 14:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Xt6U4INPy4FBJfwx41c0dv6b0A4Eyx4tkehoIwXTZWw=; b=QvCkvtCoziGLtGWG95EkdR6M6D65C0M33AcDltGhkH3jOyOBZFMQzHs6W+aL0L+jUNSsfev1bLCO9ntTvRg0VpG/zm/XX6oKXGABxqxAO6H0ydzoXAuUc75uqfcAWM61zEyeVSKmi9jYE9KajmuPb18GY+dbXDxbnK/5GdWabCs= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB1697.namprd05.prod.outlook.com (10.163.120.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1304.10; Fri, 21 Jul 2017 21:10:00 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1282.016; Fri, 21 Jul 2017 21:10:00 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: IETF 99 Minutes Thread-Index: AdMCZXzE7P0S9ZXoT2iM0BoTOlgNsg== Date: Fri, 21 Jul 2017 21:10:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1697; 7:CwVj23W3HzEVDAHRj+wiY9W8ir2wDLcNArC1xKVmoOYQ9gsRgtGhM4NXPaQj3uSFzylDDQASZa13uSnhq/cay2CEzu2HiLS94xarx/hxaPG3Tcte09h/E80zL0LZs61ZlWo+iANXmR/YIYsX70H8gMcNTmbSo7r1mJ2KA9Iq5oIb7nQGETbUVZo9O6wzcedm3StGPRf+MhNzkpGaHDWNuT40oKi7JhnUpbDKR6DiXFqchBhvEsNHY4fkJH2SfmB2H8mouHAXv/nUUg4TeIOea93ICE1vYanqHlxAb1DuYQM405zNISew79lzOcPc2ywncLLUh7qKVWuq4TFjlHVAZ2ja4WEV1WtealMwHXn6qm7jFDKx1YABVnNzn9BgWlpKRUhDH2UMysZv2aWb6Uu4USwrT76J6Wr94L1IrsFmMM39irHbNnvuABJZ6D1eSZEmcTYOjKCfA7PotHxh7Hv5k0eltKb1+qKAvHpnIKNwHvT02QVxvt0lU9VtpUgnOwO9f87/J0J2p4BvSIyBVlcGXYCu3FMAZhdALZ9S6OAC7SXaKqdN3IfHGJQOeAldRIg9jwd8b7oJEBeW59iLFJNVw6z4OSAFxsZ9Lu9F5AJnziBiHzByXvoiLBmgz8tGCtOX9/sy8+etIjc/MGWo4r1jOpE2hwyN+sZ5Y+0QKle2cGJtlfyRMXZhR8GpIWHRGds6XhO4qLW+yaw/+amBBY1RaLryEJ+zHCJN0ZAtglvPvy8RK/VTOTkBaUtydXPVINX6wHN5EItzdclVCmi9+aYcEvBeDCDcJCKeTxg8OOnuSTA= x-ms-office365-filtering-correlation-id: e4004fc9-8854-40f7-d807-08d4d07cd93d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB1697; x-ms-traffictypediagnostic: BLUPR0501MB1697: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB1697; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB1697; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39450400003)(39860400002)(39410400002)(39850400002)(189002)(199003)(77096006)(105586002)(6436002)(86362001)(7116003)(66066001)(5660300001)(110136004)(6916009)(38730400002)(3660700001)(305945005)(8936002)(478600001)(2906002)(8676002)(81166006)(81156014)(7736002)(25786009)(54356999)(101416001)(50986999)(74316002)(97736004)(9686003)(53936002)(102836003)(3846002)(189998001)(7696004)(3280700002)(6506006)(68736007)(33656002)(106356001)(99286003)(55016002)(14454004)(558084003)(6116002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1697; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 21:10:00.4432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1697 Archived-At: Subject: [v6ops] IETF 99 Minutes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 21:10:04 -0000 Folks, Thanks to Stuart Cheshire for taking minutes at Thursday's meeting. I have = uploaded them. I forget who took minutes at our Tuesday session. Would that person please = send me unicast email. Ron From nobody Sat Jul 22 04:13:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B67127869 for ; Sat, 22 Jul 2017 04:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iqxF9fMdccw for ; Sat, 22 Jul 2017 04:12:50 -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 AD12712EB5D for ; Sat, 22 Jul 2017 04:12:50 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob14.registeredsite.com (8.14.4/8.14.4) with ESMTP id v6MBClTY001279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 22 Jul 2017 07:12:47 -0400 Received: (qmail 22431 invoked by uid 0); 22 Jul 2017 11:12:47 -0000 X-TCPREMOTEIP: 174.221.131.177 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?100.87.27.48?) (lee@asgard.org@174.221.131.177) by 0 with ESMTPA; 22 Jul 2017 11:12:46 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Lee Howard X-Mailer: iPhone Mail (14F89) In-Reply-To: <5970CB51.3090806@foobar.org> Date: Sat, 22 Jul 2017 13:12:44 +0200 Cc: Fred Baker , IPv6 Ops WG , 6man WG , draft-ietf-6man-rfc6434-bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> To: Nick Hilliard Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 11:12:53 -0000 Sent from my iPhone > On Jul 20, 2017, at 5:25 PM, Nick Hilliard wrote: >=20 > Fred Baker wrote: >> "If IPv4 router operation is enabled by default, enable IPv6 router >> operation by default." >=20 > this is undoubtedly well-intentioned, and the idealist bit in me > sympathises with the principal. However with my enable hat on, a > recommendation like this isn't going to fix any problem associated with > ipv6 adoption. >=20 > The problems with ipv6 adoption revolve entirely around cost/benefit. I disagree.=20 IPv6 enablement by the ISP requires work. But once it's enabled, there's oft= en a gap between "100% enabled" and "100% active" that is directly due to CP= E either not supporting or not enabling IPv6.=20 > Pressing problems still include things that should have been resolved > years ago, e.g. vendors charging extra for ipv6 support (today's > bugbear: provisioning system vendors, please note that charging extra > for basic ipv6 functionality is destructive in the long term and > corrosive for your customer relationships) It's great that there are others to choose from. It's unfortunate that the m= arginal cost to buy and integrate is higher than the extra fee for feature s= upport. That recalcitrant vendor better hope you love them enough to stay.=20= >=20 > As a separate issue, from an operational point of view, implicit > enabling of functionality in one area when it's explicitly enabled in > another is something that needs to be handled carefully because > otherwise you can end up violating the principal of least astonishment. Once it's enabled at the edge, it seems more astonishing to me when it doesn= 't work than when it does. The vast majority of IPv6 tickets I've seen have b= een "Why don't I have it yet?" >=20 > Nick >=20 Lee > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sat Jul 22 06:29:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E3E12EC13 for ; Sat, 22 Jul 2017 06:29:15 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-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 04DJcgNZFTNL for ; Sat, 22 Jul 2017 06:29:14 -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 E8FC213157A for ; Sat, 22 Jul 2017 06:29:11 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id v105so60890529wrb.0 for ; Sat, 22 Jul 2017 06:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E74SFDBhRUk4S5HofjPtoX3LQi5SjFX0AMS+BTkLebs=; b=BynVTsRcD+JXpcvkAM0H8DdZ4U6nF/VoinLfU93XtlT9vjp3VxUjeT2grjb1P9hluy +r9231JxlxyViazr3RtksyOCV5mmBBcUGYShRth0cSFxUlssZjIby86JD/TiBX3FQ9Fa 6C2AIJCTISm8t2kKMyyWjMdQ+snQ/E3KSE5VdIOgCOZcIOOAEf7+ISexpRkbCdvQklvT ZMFKGn0BXYwByywXrMleJK8GKrgM9j4H0WZ5x8s3ACGEX6VPKpa8XUOR7GRJ3L8UHjIE 0YlSsQwxbdg+k/JebL3HFrVVqk3GKCUCx8/rKxQ7VQr9t2WtcZrjB1jopRpkmX4HCc+I yr6Q== 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=E74SFDBhRUk4S5HofjPtoX3LQi5SjFX0AMS+BTkLebs=; b=sH68l65t0kZ/7PHWpVGLfy6PyF9mWgIgpfCp6behZIiwi7m6R40wei3qanmiHOH4dx Mf276Bq1nFJFNQ836BoCH01EB2jGXL1KhViik0i+yFqZKm6Zt+lr8/MYG1nYQfYTnp8i /jo2haPIuzOt3DzmqmlVyx+Gt/+BxR2FESqVFn928PCvJcTsfNj93MGx8+TewwvYX4JK MbxpYDsKaRz32DXQEmnimUV1Xnn3h2jGTDdD2Ugkrs2jJFNQjcIDortifTIHHYdshVi5 DsuP/ueuQqwZjP8PQRidmQBbDOzrR3ztjhzjxjK7WEMihYEE/rOWSRB/skYcWHxZ8RkN HjbA== X-Gm-Message-State: AIVw110RtDsKYgHyUFra1ptLO+EVWT2GQoE9dH3XmcXAf4Qw+GADTj8a 7TyI0Kn1+Dt4zWd7729vnMynWRsGFdOAo5A= X-Received: by 10.223.151.135 with SMTP id s7mr9570931wrb.231.1500730150271; Sat, 22 Jul 2017 06:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.27.207 with HTTP; Sat, 22 Jul 2017 06:29:09 -0700 (PDT) In-Reply-To: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> From: Victor Kuarsingh Date: Sat, 22 Jul 2017 09:29:09 -0400 Message-ID: To: IPv6 Ops WG Cc: Nick Hilliard , 6man WG , draft-ietf-6man-rfc6434-bis@ietf.org, Lee Howard Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 13:29:16 -0000 On Sat, Jul 22, 2017 at 7:12 AM, Lee Howard wrote: > > > Sent from my iPhone > >> On Jul 20, 2017, at 5:25 PM, Nick Hilliard wrote: >> >> Fred Baker wrote: >>> "If IPv4 router operation is enabled by default, enable IPv6 router >>> operation by default." >> >> this is undoubtedly well-intentioned, and the idealist bit in me >> sympathises with the principal. However with my enable hat on, a >> recommendation like this isn't going to fix any problem associated with >> ipv6 adoption. >> >> The problems with ipv6 adoption revolve entirely around cost/benefit. > > I disagree. > IPv6 enablement by the ISP requires work. But once it's enabled, there's often a gap between "100% enabled" and "100% active" that is directly due to CPE either not supporting or not enabling IPv6. For operators deploying Native IPv6, I would say this sounds about right. I can't say my area is representative of the entire world, but here, once IPv6 was on for the upstream provider, it only took an IPv6 enabled CPE (which I assisted in for multiple folks) to get full IPv6 service (dual stack in the cases I saw). Operators will likely get their boxes upto IPv6 standard on their own. Depending on how they decided to IPv6 enable a given sets of customer endpoints (or residence) , it may require a call (i.e. provisioning modes can be different for enabled and non-enabled IPv6 customer sites). Operators will likely track their ability to have IPv6 working for a given residence based on their own CPEs capability/support (if they offer that). > > >> Pressing problems still include things that should have been resolved >> years ago, e.g. vendors charging extra for ipv6 support (today's >> bugbear: provisioning system vendors, please note that charging extra >> for basic ipv6 functionality is destructive in the long term and >> corrosive for your customer relationships) > > It's great that there are others to choose from. It's unfortunate that the marginal cost to buy and integrate is higher than the extra fee for feature support. That recalcitrant vendor better hope you love them enough to stay. I have not actually experienced ISPs charing more for IPv6 to date. Early adaptor ISPs seem to have done it as part of the standard offering (incremental network costs likely buried in normal development cycles since it can require significant upgrades - at least historically - to ready the entire network and provisioning systems to support IPv6). > >> >> As a separate issue, from an operational point of view, implicit >> enabling of functionality in one area when it's explicitly enabled in >> another is something that needs to be handled carefully because >> otherwise you can end up violating the principal of least astonishment. > > Once it's enabled at the edge, it seems more astonishing to me when it doesn't work than when it does. The vast majority of IPv6 tickets I've seen have been "Why don't I have it yet?" If you look at the message boards for areas where there are tech savvy customers, you can see many trying to get IPv6 working on their own CPEs or using the operator's provide one , once IPv6 is known to be available. Example here - - http://www.dslreports.com/forum/r30687933-Internet-Rogers-IPv6-appears-to-be-rolling-out - http://www.dslreports.com/forum/r30238214-TELUS-IPv6-on-GPON-CE-network > >> >> Nick >> > > Lee > regards, Victor K From nobody Mon Jul 24 13:01:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066FF131F02; Mon, 24 Jul 2017 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TByNeWabNJKY; Mon, 24 Jul 2017 13:01:04 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E035C131EFE; Mon, 24 Jul 2017 13:01:04 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6OJtLmr046536; Mon, 24 Jul 2017 16:01:03 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2bwma3pv1q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 16:01:03 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6OK0whj024670; Mon, 24 Jul 2017 16:01:00 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6OK0m35024292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jul 2017 16:00:54 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi134.aldc.att.com (RSA Interceptor); Mon, 24 Jul 2017 20:00:35 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 16:00:34 -0400 From: "STARK, BARBARA H" To: Michael Richardson CC: Fred Baker , IPv6 Ops WG , "6man WG" Thread-Topic: PPPoE requirements (was Turning on IPv6 Routers) Thread-Index: AdMEt31v4/lFzKojS3arT0hUd4QLuQ== Date: Mon, 24 Jul 2017 20:00:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.213.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240304 Archived-At: Subject: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 20:01:07 -0000 > > As an implementer of a PPPoE aggregator/access-router, I found that= I > > had to invert 7084 to determine what I had to implement. >=20 > > It might be worth a document, if only so that ISPs would have somet= hing > > against which to issue RFPs. Maybe. >=20 > bhs> BBF TR-187 documents the telco IPv6 over pppoe access > network > bhs> architecture with some specific requirements for access network > bhs> elements. > bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue-= 2.pdf >=20 > Yes, I worked from TR-187 as well. It's close to what I want, but it does= n't say > what the access network elements *MUST* do, but rather tells you what the > CPE boxes MUST try. ?? Section 9 of TR-187 is all about the BNG (BBF term for access network IP ed= ge router that does aggregation) requirements. But the doc as a whole presents a number of ways to do IPv6 over PPPoE -- n= ot just one. This means the ISP has to pick one and configure it appropriat= ely. The BNG requirements include support for all of the described ways. Th= e conditional wording in some of the requirements is a bit strange, though. > For instance: *SHOULD* a PPPoE access router provide an address for the > CPE router link via RA or via DHCPv6? =20 The BNG has to support RA (SLAAC), IA_NA, and IA_PD. The ISP is responsible= for configuring the BNG appropriately/correctly per the ISP's chosen archi= tecture. The ISP can choose to provide the address by RA (SLAAC), IA_NA, or= go with the unnumbered model (CE router picks address from IA_PD prefix). > If it does both, should it offer the same > address? =20 I would recommend against configuring the BNG to use the same prefix for SL= AAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really be ne= eded. And I don't understand why anyone would want to. I would recommend th= e ISP pick a single method to use. The TR-124 RG is expected (by default) t= o support all numbering models. If offered SLAAC, it must take an address f= rom that prefix (at least one). If offered IA_NA, it must accept that. It m= ust do IA_PD. If neither SLAAC nor IA_NA are offered, then it must assign i= tself an address from the IA_PD.=20 > It would be rather better if one *knew* the CPE would do PD > and then assign itself an address out of one of the /64s. That would > eliminate a bunch of routes. =20 TR-124 RG requirements (referenced by TR-187) do require support for IA_PD = and the unnumbered model. RFC 7084 does not require support for the unnumbe= red model; there it's optional. An ISP procuring CE routers can use TR-124 = for an RFP. But such an ISP cannot depend on "retail" CE routers supporting= the unnumbered model. This is because CableLabs eRouters do not support th= e unnumbered model, and eRouters needed to be compliant with RFC 7084. I'm = not sure of the status of the unnumbered model in non-eRouter "retail" CE r= outers. > Part of the problem is that one can't necessarily > depend upon the CPE to do DHCPv6 (-PD) at all! Support for IA_PD is mandatory in RFC 7084, CableLabs eRouters, and TR-124.= The default flow in TR-124 (Appendix A.1 which leads to A.2) is for IA_PD = always to be requested (don't wait for RA). TR-124 was specifically designe= d for use in RFPs. RFC 7084 requires IA_PD be requested if M or O =3D 1. Th= e fact that some CE routers don't support any of these specs doesn't mean w= e need more specs. It means we need more compliant CE routers. > It would just be nice to reduce the number of options. Maybe a BCP is in > order. Unless we know some of the options aren't being used by any ISP, it would b= e hard to get agreement to get rid of any. My sense is there is widespread = support of both IA_NA and unnumbered. I don't know if anyone is using SLAAC= over PPPoE, but I suspect there are. But since the IPv6 over PPPoE flow is= identical to native IPv6 after IPv6CP is done, and for native IPv6 we do k= now of deployments with SLAAC, I would be tempted to keep that same flow ra= ther than get rid of an option for IPv6 over PPPoE. My recommended practices would be more like: - if doing PPPoE, make sure your CE routers / RGs are compliant with TR-= 124 WAN.PPP and WAN.PPP.IPv6 modules - make your CE router vendors get the IPv6 Ready CE router certification - don't configure the same prefix on SLAAC and IA_* or IA_NA and IA_PD I would like to see if we could reduce the number of v4 over v6 tunneling o= ptions that v6ops will be "recommending". I think the current laundry list = is a bad idea. But that's another topic. From nobody Mon Jul 24 19:56:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A5D129AF6 for ; Mon, 24 Jul 2017 19:56:02 -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, 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 VpvcQgkbvNyz for ; Mon, 24 Jul 2017 19:56:00 -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 10456129AD2 for ; Mon, 24 Jul 2017 19:56:00 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i6so27032547ywb.1 for ; Mon, 24 Jul 2017 19:56: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=+SFHELBQsaWIP/kNBIjtYXHGON0geXkhLJ8Tbk2TIo4=; b=MILJ1NPozc827ws/nakrJVdi5TQGA8PPKcCZHPYXw2eRFEbHvX3aWel1zpkbdqxWjX EuN3bcpGkYrgYvktmQVY/5bNC2oHXIYtzPGManEky0zB7VhfBXT1T37WS/acOqYSUVAm oiG/3N3Xu7KnID+lty4TSEcsFSpZE54u8MRVjAOO6EfpxOeVbnMOhGxDMP8oHHosMnnk /d6+9BUIp7hF6QSZCIdTx0EsL6sqHtCTrgC/RJ0v4mueO1FQWVRBSsQsGUANLIWoZ4Ab QjbX1PQx/F0+I5j0E0AAkf4Eanf7zYbefv0sobkInGco6uVdsm1dDBLvp+uEA1JTnH1l JRSw== 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=+SFHELBQsaWIP/kNBIjtYXHGON0geXkhLJ8Tbk2TIo4=; b=rnqkpURhjHud1VRmWn5yv+3rlvXhcwcdeZTJXgqhY/TcxnDrdgehrdqkj3eVxo4JpX h5u9iwsEVsj8tzXA5m21hH8BduoO6d7+Zb4cxhvHuqFcUvLoG1BY99yGyAoDP8brvhPn ARPfA6aTXKRPv1Qf3c7Yy1XHr8QkgjUPQZRT4Teb/Agq0q6vkUPMM/VQKrki0mrYbPHB jnSI3jo+oSGBTfJHjuU+QEK22Ui9SQGw3VVu6QQPHLp5bKtSTWrOcrtW7fqeAHy74Rsb rq7KNkHDWzyTgnLA9H8Vi/lRkaHzSe9rg0vZj9jXoTdeLHdq/5X9hXGJYFq1+IBUZ54+ 7p6w== X-Gm-Message-State: AIVw1121G9JI2QkudvN9BbpbClb8rn4BCyy5tw/LA8GUllurynPQ+XME ZVBBOhMnno481W60pkesWCiRWQpJz8+C X-Received: by 10.37.32.193 with SMTP id g184mr16178717ybg.4.1500951358974; Mon, 24 Jul 2017 19:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.65 with HTTP; Mon, 24 Jul 2017 19:55:38 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Erik Kline Date: Tue, 25 Jul 2017 11:55:38 +0900 Message-ID: To: "STARK, BARBARA H" Cc: Michael Richardson , IPv6 Ops WG , 6man WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1143e0d89bee7505551b78f0" Archived-At: Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 02:56:03 -0000 --001a1143e0d89bee7505551b78f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 25 July 2017 at 05:00, STARK, BARBARA H wrote: >> > As an implementer of a PPPoE aggregator/access-router, I found tha= t I >> > had to invert 7084 to determine what I had to implement. >> >> > It might be worth a document, if only so that ISPs would have some= thing >> > against which to issue RFPs. Maybe. >> >> bhs> BBF TR-187 documents the telco IPv6 over pppoe access >> network >> bhs> architecture with some specific requirements for access network >> bhs> elements. >> bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue= -2.pdf >> >> Yes, I worked from TR-187 as well. It's close to what I want, but it doe= sn't say >> what the access network elements *MUST* do, but rather tells you what th= e >> CPE boxes MUST try. > > ?? > Section 9 of TR-187 is all about the BNG (BBF term for access network IP = edge router that does aggregation) requirements. > But the doc as a whole presents a number of ways to do IPv6 over PPPoE --= not just one. This means the ISP has to pick one and configure it appropri= ately. The BNG requirements include support for all of the described ways. = The conditional wording in some of the requirements is a bit strange, thoug= h. > >> For instance: *SHOULD* a PPPoE access router provide an address for the >> CPE router link via RA or via DHCPv6? > > The BNG has to support RA (SLAAC), IA_NA, and IA_PD. The ISP is responsib= le for configuring the BNG appropriately/correctly per the ISP's chosen arc= hitecture. The ISP can choose to provide the address by RA (SLAAC), IA_NA, = or go with the unnumbered model (CE router picks address from IA_PD prefix)= . > >> If it does both, should it offer the same >> address? > > I would recommend against configuring the BNG to use the same prefix for = SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really be = needed. And I don't understand why anyone would want to. I would recommend = the ISP pick a single method to use. The TR-124 RG is expected (by default)= to support all numbering models. If offered SLAAC, it must take an address= from that prefix (at least one). If offered IA_NA, it must accept that. It= must do IA_PD. If neither SLAAC nor IA_NA are offered, then it must assign= itself an address from the IA_PD. You don't need DAD to deal for link-local addresses? >> It would be rather better if one *knew* the CPE would do PD >> and then assign itself an address out of one of the /64s. That would >> eliminate a bunch of routes. > > TR-124 RG requirements (referenced by TR-187) do require support for IA_P= D and the unnumbered model. RFC 7084 does not require support for the unnum= bered model; there it's optional. An ISP procuring CE routers can use TR-12= 4 for an RFP. But such an ISP cannot depend on "retail" CE routers supporti= ng the unnumbered model. This is because CableLabs eRouters do not support = the unnumbered model, and eRouters needed to be compliant with RFC 7084. I'= m not sure of the status of the unnumbered model in non-eRouter "retail" CE= routers. > >> Part of the problem is that one can't necessarily >> depend upon the CPE to do DHCPv6 (-PD) at all! Is this because it might actually just be a host that's connecting? > Support for IA_PD is mandatory in RFC 7084, CableLabs eRouters, and TR-12= 4. The default flow in TR-124 (Appendix A.1 which leads to A.2) is for IA_P= D always to be requested (don't wait for RA). TR-124 was specifically desig= ned for use in RFPs. RFC 7084 requires IA_PD be requested if M or O =3D 1. = The fact that some CE routers don't support any of these specs doesn't mean= we need more specs. It means we need more compliant CE routers. > >> It would just be nice to reduce the number of options. Maybe a BCP is i= n >> order. > > Unless we know some of the options aren't being used by any ISP, it would= be hard to get agreement to get rid of any. My sense is there is widesprea= d support of both IA_NA and unnumbered. I don't know if anyone is using SLA= AC over PPPoE, but I suspect there are. But since the IPv6 over PPPoE flow = is identical to native IPv6 after IPv6CP is done, and for native IPv6 we do= know of deployments with SLAAC, I would be tempted to keep that same flow = rather than get rid of an option for IPv6 over PPPoE. > My recommended practices would be more like: > - if doing PPPoE, make sure your CE routers / RGs are compliant with T= R-124 WAN.PPP and WAN.PPP.IPv6 modules > - make your CE router vendors get the IPv6 Ready CE router certificati= on > - don't configure the same prefix on SLAAC and IA_* or IA_NA and IA_PD > > I would like to see if we could reduce the number of v4 over v6 tunneling= options that v6ops will be "recommending". I think the current laundry lis= t is a bad idea. But that's another topic. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143e0d89bee7505551b78f0 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgg6wSmL+wACFM2TutI5/ENTWrE39VXKaN A/7mEZRGxzswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzI1 MDI1NTU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAH8d5GZDBy91VOauf3i+9Fh7qzVLiolj51RUwhrLQxzVj88GdSDH I6mAMa+yxSyslA86LDyeCpaCprJ8GuqR+OvNuBgLhRFOX9u+/oo/sclLXCFOPIo0npaw25fHLS8X RxHHT46i/ruobzgfa/MBZj4xQjtdOoz7sENJis/7X9+OlKqpuQaMZJBFNpar/KPswjFj3djAYX6n i1CqzKGLW9dRev//0ke38wVf6C0Qa4aVlGMTqJquA+L4zQ/C6VGDdfMZuJOjfbP+c+exMEB2CdDh tqYnJItB+UqD1TMVRvjnmlt3ZgARBGU0ek1SzSF9y31Bj67xX5jPEBka9yFFODw= --001a1143e0d89bee7505551b78f0-- From nobody Tue Jul 25 05:55:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B431E131CA2; Tue, 25 Jul 2017 05:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 RPPgcBGA0mYp; Tue, 25 Jul 2017 05:55:46 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 03165131C4F; Tue, 25 Jul 2017 05:55:45 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6PCt2ZX006424; Tue, 25 Jul 2017 08:55:41 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2bwttrvpc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2017 08:55:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6PCtdrl006375; Tue, 25 Jul 2017 08:55:40 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6PCtXNs006258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jul 2017 08:55:34 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 25 Jul 2017 12:55:20 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Tue, 25 Jul 2017 08:55:20 -0400 From: "STARK, BARBARA H" To: Erik Kline CC: Michael Richardson , IPv6 Ops WG , 6man WG Thread-Topic: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) Thread-Index: AdMEt31v4/lFzKojS3arT0hUd4QLuQAW4gkAAAtzsBA= Date: Tue, 25 Jul 2017 12:55:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.240.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-25_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250209 Archived-At: Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 12:55:48 -0000 PiA+PiBGb3IgaW5zdGFuY2U6ICpTSE9VTEQqIGEgUFBQb0UgYWNjZXNzIHJvdXRlciBwcm92aWRl IGFuIGFkZHJlc3MgZm9yIHRoZQ0KPiA+PiBDUEUgcm91dGVyIGxpbmsgdmlhIFJBIG9yIHZpYSBE SENQdjY/DQo+ID4+IElmIGl0IGRvZXMgYm90aCwgc2hvdWxkIGl0IG9mZmVyIHRoZSBzYW1lDQo+ ID4+IGFkZHJlc3M/DQo+ID4NCj4gPiBJIHdvdWxkIHJlY29tbWVuZCBhZ2FpbnN0IGNvbmZpZ3Vy aW5nIHRoZSBCTkcgdG8gdXNlIHRoZSBzYW1lIHByZWZpeCBmb3INCj4gU0xBQUMgYW5kIElBX05B IG9yIElBX1BELCBvciBmb3IgSUFfTkEgYW5kIElBX1BELiBUaGVuIERBRCB3b3VsZCByZWFsbHkN Cj4gYmUgbmVlZGVkLiBBbmQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBhbnlvbmUgd291bGQgd2Fu dCB0by4gSSB3b3VsZA0KPiByZWNvbW1lbmQgdGhlIElTUCBwaWNrIGEgc2luZ2xlIG1ldGhvZCB0 byB1c2UuIA0KPiANCj4gWW91IGRvbid0IG5lZWQgREFEIHRvIGRlYWwgZm9yIGxpbmstbG9jYWwg YWRkcmVzc2VzPw0KDQpOby4gT24gUFBQIHlvdSBkb24ndCBuZWVkIERBRCBmb3IgTExBLiBCdXQg aW4gdGhlIGNvbnRleHQgb2YgIm9mZmVyaW5nIiBhZGRyZXNzZXMgdmlhIFJBIGFuZCBESENQdjYg dXNpbmcgdGhlIHNhbWUgcHJlZml4Li4uDQpXZWxsLCBvZiBjb3Vyc2UsIHlvdSBjYW4ndCBhY3R1 YWxseSAib2ZmZXIiIGEgc3BlY2lmaWMgYWRkcmVzcyB2aWEgUkEuIEJ1dCBpZiB5b3UgZW52aXNp b24gYSBDRSBSb3V0ZXIgdGhhdCB1c2VkIHRoZSBFVUktNjQgdG8gZGVyaXZlIGEgU0xBQUMgYWRk cmVzcyBmcm9tIGEgcHJlZml4IGFuZCB0aGVuIG9mZmVyaW5nIHRoYXQgaWRlbnRpY2FsIGFkZHJl c3MgdmlhIERIQ1B2Ni4uLg0KTm8uIEl0J3MganVzdCB0b28gaG9ycmlibGUuIEkgZG9uJ3Qgd2Fu dCB0byB0aGluayBhYm91dCBpdC4gDQogDQo+ID4+IEl0IHdvdWxkIGJlIHJhdGhlciBiZXR0ZXIg aWYgb25lICprbmV3KiB0aGUgQ1BFIHdvdWxkIGRvIFBEDQo+ID4+IGFuZCB0aGVuIGFzc2lnbiBp dHNlbGYgYW4gYWRkcmVzcyBvdXQgb2Ygb25lIG9mIHRoZSAvNjRzLiAgVGhhdCB3b3VsZA0KPiA+ PiBlbGltaW5hdGUgYSBidW5jaCBvZiByb3V0ZXMuDQo+ID4NCj4gPiBUUi0xMjQgUkcgcmVxdWly ZW1lbnRzIChyZWZlcmVuY2VkIGJ5IFRSLTE4NykgZG8gcmVxdWlyZSBzdXBwb3J0IGZvcg0KPiBJ QV9QRCBhbmQgdGhlIHVubnVtYmVyZWQgbW9kZWwuIFJGQyA3MDg0IGRvZXMgbm90IHJlcXVpcmUg c3VwcG9ydCBmb3INCj4gdGhlIHVubnVtYmVyZWQgbW9kZWw7IHRoZXJlIGl0J3Mgb3B0aW9uYWwu IEFuIElTUCBwcm9jdXJpbmcgQ0Ugcm91dGVycyBjYW4NCj4gdXNlIFRSLTEyNCBmb3IgYW4gUkZQ LiBCdXQgc3VjaCBhbiBJU1AgY2Fubm90IGRlcGVuZCBvbiAicmV0YWlsIiBDRSByb3V0ZXJzDQo+ IHN1cHBvcnRpbmcgdGhlIHVubnVtYmVyZWQgbW9kZWwuIFRoaXMgaXMgYmVjYXVzZSBDYWJsZUxh YnMgZVJvdXRlcnMgZG8NCj4gbm90IHN1cHBvcnQgdGhlIHVubnVtYmVyZWQgbW9kZWwsIGFuZCBl Um91dGVycyBuZWVkZWQgdG8gYmUgY29tcGxpYW50DQo+IHdpdGggUkZDIDcwODQuIEknbSBub3Qg c3VyZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSB1bm51bWJlcmVkIG1vZGVsIGluIG5vbi0NCj4gZVJv dXRlciAicmV0YWlsIiBDRSByb3V0ZXJzLg0KPiA+DQo+ID4+IFBhcnQgb2YgdGhlIHByb2JsZW0g aXMgdGhhdCBvbmUgY2FuJ3QgbmVjZXNzYXJpbHkNCj4gPj4gZGVwZW5kIHVwb24gdGhlIENQRSB0 byBkbyBESENQdjYgKC1QRCkgYXQgYWxsIQ0KPiANCj4gSXMgdGhpcyBiZWNhdXNlIGl0IG1pZ2h0 IGFjdHVhbGx5IGp1c3QgYmUgYSBob3N0IHRoYXQncyBjb25uZWN0aW5nPw0KDQpUaGUgcG9wdWxh dGlvbiBvZiBwZW9wbGUgd2FudGluZyB0byBkbyBQUFBvRSBmcm9tIGEgKG5vbiByb3V0ZXIpIGhv c3QgdG8gZ2V0IElQdjYganVzdCB0byB0aGF0IGhvc3QgaXMgZ29pbmcgdG8gYmUgcmVhbGx5LCBy ZWFsbHksIHJlYWxseSBzbWFsbC4gSnVtcGluZyB0aHJvdWdoIGhvb3BzIHRvIGNyZWF0ZSBhbiBh Y2Nlc3MgbmV0d29yayBhcmNoaXRlY3R1cmUgdGhhdCBzdXBwb3J0cyBib3RoIENFIHJvdXRlcnMg YW5kIGhvc3RzIGlzbid0IHdvcnRoIHRoZSB0cm91YmxlLiBJZiBhbiBJU1Agd2FudHMgdG8gc3Vw cGx5IElQdjYgb3ZlciBQUFBvRSBmb3IgYm90aCBob3N0cyBhbmQgQ0Ugcm91dGVycywgbXkgc3Vn Z2VzdGlvbiB3b3VsZCBiZSB0byBzdXBwbHkgc3BlY2lhbCBQUFBvRSBzb2Z0d2FyZSAoZm9yIGRv d25sb2FkIG9udG8gaG9zdHMpIHRoYXQgd2lsbCBsb29rIHRvIHRoZSBhY2Nlc3MgbmV0d29yayBs aWtlIGEgQ0Ugcm91dGVyIChpLmUuLCBhc2sgZm9yIElBX1BELCBldGMuKS4gRG9uJ3QgZXhwZWN0 IHRoZSBQUFBvRSBjbGllbnQgbmF0aXZlIHRvIHlvdXIgT1MgdG8gd29yay4NCkJhcmJhcmENCg== From nobody Tue Jul 25 07:03:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83921131CBD for ; Tue, 25 Jul 2017 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, 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=juniper.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 vXy9BInmNPcu for ; Tue, 25 Jul 2017 07:03:18 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DFF131CB8 for ; Tue, 25 Jul 2017 07:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fiQyRwG7CEH14Wp2/qaZjM+45j3gVXLOoZdaoKRRcdU=; b=Qoit2CfGJfVuZwV/UPm/ENzGcnRdD8Yi2d6YqWcdXWwqazcRnDMJOYbNCPVhBONSPI9qGHjGdLATyuFi8CDkygIWp4wm3Cp7udpwAoceY3DyWEyNnqNnsrWKG/Gi2/rXhub7IQjPDIFG9jJMeV7yL2SUbHI0eiUHIVldekEiDH0= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB1044.namprd05.prod.outlook.com (10.160.35.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 14:03:16 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1304.014; Tue, 25 Jul 2017 14:03:16 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: IETF 99 Minutes Thread-Index: AdMCZXzE7P0S9ZXoT2iM0BoTOlgNsgC6SmUQ Date: Tue, 25 Jul 2017 14:03:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [116.197.188.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1044; 7:9A3gQg1O3t6jyCKznR+iXIkEzGglDOh6GtuPSJHdfwE2NhU0N2xNXJc+TB5qxpfFiGjys1T5RshLpqIXd9ayCZRm0btyn9bV8ywdtjAbMkqXtGD4E3VsXnET9RBLzxUP3uL9keZOl13z5EHh6lo1e1+QxA0ipGmuEu1nOx6u4/EQlrZ2KjlmPcLr8pp7pdUJMt27tKdMM09KfgzA6i5SZXAeJ6lzOhmV45GgMidMe7esoeAZuShhBeuPo3NjR000W6Yt3eTQMMeYOetHHFTgLQ21z3bz//+wobpEJ0+aZxzUE8CxhYtaOu8hlFGfBIdLCH9pFEiMSuiRyPjRSjCmNl3uySz3zPCWY+W+jp8etm5cdKffIrmYWh4Yfs9vqCwK128RuGheRP2le4dP7buD2CVjpK7CbA+rAz1TAheKvPA3hhWJeXkMBq3Y4EG5v8P/Hu3QLOii8gfvdBFkQQ7dMKLd65XK0yqoFb9XgHQRKQwn1WLAr0FFZZ+B4ODblPmW76yP1TKMrVKXXatY5Wgu/Lxq+xETRWbZEwDgHuC0bxcj9fy8H/kP2jpAzW+lI+ZR4GG2+bets9nv+bAi8pLsYZMHKTTTaM0DCS0uDKQcgQdvatZ74gbHlV3giR6SAEteFZ6rgzUnSC11vBXw9C67AYPUobtbl55ONUWcjbkK1Okn/6AJwbDIvswfnX3mfQVdpqVH7KnvWGj8dWZOxkcRuFhyK7phcCFKxy38cyUR2jt8W82NEq8Vm2LwCaW3xkJ/aYTX0ByRMKdHtAtuwfHziNp0O5vQ/13lBFdbG4WlnYs= x-ms-office365-filtering-correlation-id: d2b24b3a-d842-4d5f-6cb0-08d4d365e5a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB1044; x-ms-traffictypediagnostic: BLUPR0501MB1044: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: 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)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB1044; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB1044; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(13464003)(199003)(189002)(377454003)(189998001)(229853002)(53546010)(33656002)(8936002)(2900100001)(81156014)(81166006)(50986999)(8676002)(54356999)(6916009)(101416001)(478600001)(97736004)(9686003)(106356001)(66066001)(53936002)(102836003)(3846002)(6116002)(105586002)(6436002)(3280700002)(99286003)(55016002)(7696004)(14454004)(74316002)(68736007)(305945005)(86362001)(5660300001)(7116003)(25786009)(6246003)(2906002)(7736002)(6506006)(38730400002)(110136004)(77096006)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1044; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 14:03:16.2944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1044 Archived-At: Subject: Re: [v6ops] IETF 99 Minutes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 14:03:20 -0000 Second Call...... Does anybody remember who took minutes for the first V6OPS session? Ron > -----Original Message----- > From: Ron Bonica > Sent: Friday, July 21, 2017 5:10 PM > To: IPv6 Ops WG > Subject: IETF 99 Minutes >=20 > Folks, >=20 > Thanks to Stuart Cheshire for taking minutes at Thursday's meeting. I hav= e > uploaded them. >=20 > I forget who took minutes at our Tuesday session. Would that person pleas= e > send me unicast email. >=20 > Ron From nobody Tue Jul 25 07:06:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C49131CC2 for ; Tue, 25 Jul 2017 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, 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=juniper.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 eIHgNThvdiL7 for ; Tue, 25 Jul 2017 07:06:31 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0119.outbound.protection.outlook.com [104.47.37.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA3F131CB8 for ; Tue, 25 Jul 2017 07:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kOjSxmJoDvYuZM4ZayhNin9TmqojDSAB54DzCFVuxdA=; b=dKoxwF0k4Snsoe1KBirRs7mZbm0yfvhmgad+8bTuh4Z1gRmSoAXTX6419RZ5LqTB07oRizlgOK/q58xZufHDCQr4sSNzr2fnAc7yJ0aOq9Wa4j10MXQHqYHK6PBPiTMJ7lcZwQbz9BcN8c0Xlq0epSRRmbEJUgwz+Ud7Rpan3+I= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB1042.namprd05.prod.outlook.com (10.160.35.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 14:06:29 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1304.014; Tue, 25 Jul 2017 14:06:29 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: IETF 99 Minutes Thread-Index: AdMCZXzE7P0S9ZXoT2iM0BoTOlgNsgC6SmUQAAAeq9A= Date: Tue, 25 Jul 2017 14:06:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [116.197.188.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1042; 7:IR/t97i2sg2JwZFwFA1budwUOyAjXzIUhKUM0XQrBFZMHVdkvVJFZU06xtPUBa8gOYHHM4uN4ARAxkvn+eXP0kCBy5RMEGrCz0gi96UVyygjKp6x6ZJABnkAN8OwUp17JFDnjD0OLv41k2YEEfWjNF6rKwEkPb/pqKNToXldgMdts+hI6oqmnSAhxiaL067I21S1+L8XA93uDkxB60eeJ+pfnPiaDZ3UlzNzk6SVkir/EY2cZcy7r/FdJBlXoumc2HfY0tMmMp3gNvM/KcRBL/cOqJN4oLQjI1Lsn3yUd+/uDdxVcgQdASPAx5ilz6J6e7+DydMFK79UC4bAFnLjR3darlDzudrMBzQ3nGTFypBMPaU+0EMTAxG8mYlXJ8z1PNCKMwWRtRPFOCKG1SUJ81SKOHm1t4yWwMMxhkbiISNdcczWsA1PGmPs10iTKDAfYIE++NJNiHPahA/GW15xBehZCIxfe7K0auZF3/1MDgxEkspClET8gg5e0gGf0qxWjTFz3aPPwsJYmv/mblaT41NulJkpVThUMrFkyFUNJF0xb1gCT6UzMMyzwibSXf8fPQYxOHGsbwMhj6nDR8DmE9LFYm6nb9ooMa/d3zewY+NYi97kKdRHKdrb1z6/OEM5oYn1NjgrRDvstVP7YYliTU2DWL8GXyHIaa8iY0QU2UkAsAQfEf+pevbeEGtk2JdC2uW+fpWXfvsKUNp7/BqBWcjP8nixq15Xoj1S1jIBSNoZhsuEfIt5JLBKUIIcUNdfq6KusE61wFwMRbHsKkDdin3qE1TP1gzgOG7TYMF/6CU= x-ms-office365-filtering-correlation-id: e4e7d0b3-6254-4f28-daef-08d4d36658ed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB1042; x-ms-traffictypediagnostic: BLUPR0501MB1042: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: 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)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB1042; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB1042; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39840400002)(39400400002)(39410400002)(39450400003)(189002)(199003)(377454003)(13464003)(8936002)(6916009)(3846002)(6116002)(102836003)(101416001)(2900100001)(189998001)(478600001)(14454004)(25786009)(229853002)(97736004)(6506006)(50986999)(54356999)(66066001)(53546010)(81166006)(81156014)(7736002)(74316002)(8676002)(105586002)(68736007)(6246003)(305945005)(106356001)(7116003)(5660300001)(53936002)(9686003)(55016002)(99286003)(7696004)(33656002)(77096006)(110136004)(38730400002)(3280700002)(3660700001)(2906002)(86362001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1042; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 14:06:29.7565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1042 Archived-At: Subject: Re: [v6ops] IETF 99 Minutes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 14:06:33 -0000 Please disregard my last message. I just found them. Thanks to Chris Morrow!! Ron > -----Original Message----- > From: Ron Bonica > Sent: Tuesday, July 25, 2017 10:03 AM > To: 'IPv6 Ops WG' > Subject: RE: IETF 99 Minutes >=20 > Second Call...... >=20 > Does anybody remember who took minutes for the first V6OPS session? >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Ron Bonica > > Sent: Friday, July 21, 2017 5:10 PM > > To: IPv6 Ops WG > > Subject: IETF 99 Minutes > > > > Folks, > > > > Thanks to Stuart Cheshire for taking minutes at Thursday's meeting. I > > have uploaded them. > > > > I forget who took minutes at our Tuesday session. Would that person > > please send me unicast email. > > > > Ron From nobody Tue Jul 25 10:50:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045E8131E67; Tue, 25 Jul 2017 10:49: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 YSzQPUltOqG6; Tue, 25 Jul 2017 10:49:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33FB131E6B; Tue, 25 Jul 2017 10:49:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9FA4E2009E; Tue, 25 Jul 2017 13:51:18 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AEB2A80243; Tue, 25 Jul 2017 13:49:53 -0400 (EDT) From: Michael Richardson To: IPv6 Ops WG , 6man WG In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.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: Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 17:49:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >> TR-124 RG requirements (referenced by TR-187) do require support for= IA_PD and the unnumbered model. RFC 7084 does not require support for the = unnumbered model; there it's optional. An ISP procuring CE routers can use = TR-124 for an RFP. But such an ISP cannot depend on "retail" CE routers sup= porting the unnumbered model. This is because CableLabs eRouters do not sup= port the unnumbered model, and eRouters needed to be compliant with RFC 708= 4. I'm not sure of the status of the unnumbered model in non-eRouter "retai= l" CE routers. >>=20 >>> Part of the problem is that one can't necessarily >>> depend upon the CPE to do DHCPv6 (-PD) at all! Erik Kline wrote: > Is this because it might actually just be a host that's connecting? Exactly. It could be the case that it's just one host! The thing is that you can't tell at PPP auth time, nor can you tell at RA time. You can tell at DHCPv6 time if a PD it asked for. But, by that time it's too late for the BMS to change it's mind and not offer an address via SLAAC, or offer a prefix that is within the PD. Running PPPoE from your laptop/desktop is still readily supported under Linux, OSX and Windows. (I think that early PPPoE assumed that there would be multiple PPPoE sessions to get multiple PCs online in the home.) It would be nice if we could have perhaps three (maybe 4) flavours of PPPoE= /IPv6. Vanilla, Chocolate and Strawberry (and Neopolitan). Vanilla =3D=3D unnumbered, device does PD and picks an address. Chocolate =3D=3D number link with SLAAC (prefix is not excludable with 66= 03) Strawberry =3D=3D number link with DHCPv6=20 Neopolitan =3D=3D offer all of the above I wouldn't mind if the router told the BMS of it's intentions during PPP IP6CP time!=20=20=20 While you can pick a flavour via construction and RFP, that doesn't help if the customer provides his own router, or if the ISP is small enough to have supplier of the month problems. (All might be compliant, yet require different configurations. The customers could have more than one brand of device as well, because maybe one device is suspected to be flaky) In my BMS product, what exactly is done/offered is entirely determined by t= he Radius options that are provided. All I've really done is push the problem back up a level :-) Worse case you have to inject a /64 for the numbered link along with a /60 (or whatever) for the PD that was non-overlapping into the routing fabric, when a single /60 would have done. Having the PPP link unnumbered has some small security advantage in that it removes a small surface for attack. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAll3hMEACgkQgItw+93Q 3WUyzAgAiLsZ3+jRCYuYRYyamgUcPzp8WmbOL2GKBQUpFgtfLzW2ZUmjt8FfT5pX hG8oxDAnMpIhsXoM+Jto7c2tHhtXa8Yi1pWsYn8yPBDVRRBs7oPxu3Zc+Rt2VLC/ 08Wl5U5rHmGnV9djJ/6F8rdgDe5K+Pn/iYBgnNojtI+OSolJJ9xQ0kfnZVqudE23 euvnmKO6+Lms3tj5rtpiOyVHIX0SgnH0Ah+zIeE4LAcgkmjZaGD3c7XZ0SOTQf8J 7YF7a+Qc6ad9rUbJKXUEFtI4uQ1xE/JpnFQcOAl/6FurQeQperaDWRfYmp32e7Vv jUK4Q0dMZi+zeEz2DBXIkPyCOEYbBA== =0llg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 25 10:56:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C4A131E6B; Tue, 25 Jul 2017 10:56: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, 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 sf-sA9Weqfmd; Tue, 25 Jul 2017 10:56:22 -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 567C31241FC; Tue, 25 Jul 2017 10:56:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7741BE211; Tue, 25 Jul 2017 13:57:46 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 88A7A8070B; Tue, 25 Jul 2017 13:56:21 -0400 (EDT) From: Michael Richardson To: "STARK\, BARBARA H" cc: Erik Kline , IPv6 Ops WG , 6man WG In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.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: Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 17:56:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable STARK, BARBARA H wrote: >> recommend the ISP pick a single method to use.=20 >>=20 >> You don't need DAD to deal for link-local addresses? > No. On PPP you don't need DAD for LLA. But in the context of "offerin= g" > addresses via RA and DHCPv6 using the same prefix...=20 > Well, of course, you can't actually "offer" a specific address via > RA. But if you envision a CE Router that used the EUI-64 to derive a > SLAAC address from a prefix and then offering that identical address > via DHCPv6...=20 > No. It's just too horrible. I don't want to think about it. The LL address "created" in PPP is well known at both ends. (They can be derived from other addresses, or can be random) It's created during IP6CP. It's not hard to code at all, although I haven= 't done that.=20=20 The router can otherwise wind up with a SLAAC (self-assigned) address, and= =20=20 then also a DHCPv6 address. The BMS chews up two neighbour cache entries. It would be nice to avoid thi= s.=20=20 >> Is this because it might actually just be a host that's connecting? > The population of people wanting to do PPPoE from a (non router) host > to get IPv6 just to that host is going to be really, really, really > small. Jumping through hoops to create an access network architecture > that supports both CE routers and hosts isn't worth the trouble. If an > ISP wants to supply IPv6 over PPPoE for both hosts and CE routers, my > suggestion would be to supply special PPPoE software (for download on= to > hosts) that will look to the access network like a CE router (i.e., a= sk > for IA_PD, etc.). Don't expect the PPPoE client native to your OS to > work.=20 But, it does work. Just like that. While routers are ubiquitous in the first world, they are *not* ubiquitous = in the developing world. Further, there are all sorts of interesting deployments in some places where there are open wifi mesh networks that cross entire communities and offer walled-garden access to local resources for free, but one can use PPPoE over these rather slow (500kbps) links with a provider (sometimes of your choice) for a public IP.=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAll3hkUACgkQgItw+93Q 3WVh5Af/YO8pZ1K8JO4Nee08eh8a17qr0jN52/Jfi1RXvS++eDgW9849NVAIMC4X 7QBeQCZ9IuSncaXuB7wXDn3PHiV3KvJXZ5ziVBEMAAb1G/SYdPP+LxSM3o8Y+HB7 icOkibZfvhisHbYoyGX9BTnjQ3Efr6qYt5xuFNe+Ei1LoUKaSbvlVIfcGr2aJLx5 ML7LwYWNSNavfD831N7Ew32CYOkc3GltBIpY41DOW2fw20WS6EB2VqmK932pSg9Z /kHGWrjrnL1js8HQ6AxbIDVBidzFASZolzaW7y/pOydaIBKppkWCkfwc6coZWenJ 4JSDkAO4XZiLlw4EHiughA/MwJDL6g== =GI0Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 26 14:44:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C21131D1E; Wed, 26 Jul 2017 14:44: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 nbr6W6dpAcvY; Wed, 26 Jul 2017 14:44:06 -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 7A761127601; Wed, 26 Jul 2017 14:44:06 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 80so126899687uas.0; Wed, 26 Jul 2017 14:44: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=zZ3Ov/56Ah65Gzs4uTvD7PzNseoAOYdy+j9tWgQdNfg=; b=VnYPNR199q4V06cJYCQussjZFbUqoo9kNvcWwy/qHs2OwV76of7AMYzS/6PvJMyB35 5I2VoF+ZIDHo3amVc1wzECZdHRmn4aDQJn+2/FC76F/AM+QHBhh2PlAotFSEeMJCyG20 nyftw/hFcZPPcTWUeh/wFwGA/kRi5WqrB2ePopKD7zUKf0kciu8IpCxDfRR2GumsoMd/ swfvavbVl8mI2gUX2+4j6E/SR5nNycVKhXsJ46HQfeOMoZAo5/QO5p79XT5Zey0/r/QU j0P+YVO0BVCFgCCZpUQ500JTYe4V+QMe2i35M0bZQsBrBWRc9zGupHAHx/L1G/ZCAOD+ QuXg== 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=zZ3Ov/56Ah65Gzs4uTvD7PzNseoAOYdy+j9tWgQdNfg=; b=Ml9//as0pLHXIcK/Aqs5e1+I1H8LysLdLmvFFmepeLeVTk5Emwr/wfCE3xSXI4gCVN Z5hEw6eS0n1Y7PSn7k6TNPmzS+qt55eNnMf3CP3A8pDYi4MEh/zaESxHNBWo549pAVq+ Z1D597hVR7y3ikeY6OFmCwQJ5StxrKgRE1a3HGnuOpUXkdnRUyYLfPPnNzW7nu/kFdXj B7V7Na7laLd7Ek8tApNkHkYU0e7MUzdGd9AKBsHD5LxLcYEdSVSQhbKcjGc/hSBJmwfd v8/V/qr/jwE1Us96Z1o7ykg8WSYUdighsXYaIsAzsNs/feHZH/yoO04hsXRmyTtRFPLy qM4Q== X-Gm-Message-State: AIVw113MIMRV/pDlwM+/JNV7KDpGzHUuhiF6vfseOn5kr+Cn4o1flZfu 98SXb7PHBrvlqhnPPea9O0afihxR5w== X-Received: by 10.176.79.201 with SMTP id t9mr1572392uah.176.1501105445583; Wed, 26 Jul 2017 14:44:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Wed, 26 Jul 2017 14:44:04 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Wed, 26 Jul 2017 14:44:04 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Mark Smith Date: Thu, 27 Jul 2017 07:44:04 +1000 Message-ID: To: "STARK, BARBARA H" Cc: Michael Richardson , Erik Kline , 6man WG , IPv6 Ops WG Content-Type: multipart/alternative; boundary="f4030436501edabe1c05553f5815" Archived-At: Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 21:44:09 -0000 --f4030436501edabe1c05553f5815 Content-Type: text/plain; charset="UTF-8" On 25 Jul. 2017 22:56, "STARK, BARBARA H" wrote: > >> For instance: *SHOULD* a PPPoE access router provide an address for the > >> CPE router link via RA or via DHCPv6? > >> If it does both, should it offer the same > >> address? > > > > I would recommend against configuring the BNG to use the same prefix for > SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really > be needed. And I don't understand why anyone would want to. I would > recommend the ISP pick a single method to use. > > You don't need DAD to deal for link-local addresses? No. On PPP you don't need DAD for LLA. I think you now do per RFC8064/RFC7217. I don't really understand the motivation for avoiding DAD. It's a very marginal saving (1 packet) in comparison to the problems and time involved in troubleshooting duplicate addresses. In the scenario described, it can be much worse because there is likely a non-technical end-user and a helpdesk involved in what can be an intermittent and obscure fault (Helpdesks can be motivated to get the customer off the phone by saying "reboot the modem and call us back if you have more problems", which doesn't prevent the fault re-occurring.) I think absolute and consistent failure is much better and easier to troubleshoot than partial and intermittent failure when the cause is simple to determine and discover. But in the context of "offering" addresses via RA and DHCPv6 using the same prefix... Well, of course, you can't actually "offer" a specific address via RA. But if you envision a CE Router that used the EUI-64 to derive a SLAAC address from a prefix and then offering that identical address via DHCPv6... No. It's just too horrible. I don't want to think about it. > >> It would be rather better if one *knew* the CPE would do PD > >> and then assign itself an address out of one of the /64s. That would > >> eliminate a bunch of routes. > > > > TR-124 RG requirements (referenced by TR-187) do require support for > IA_PD and the unnumbered model. RFC 7084 does not require support for > the unnumbered model; there it's optional. An ISP procuring CE routers can > use TR-124 for an RFP. But such an ISP cannot depend on "retail" CE routers > supporting the unnumbered model. This is because CableLabs eRouters do > not support the unnumbered model, and eRouters needed to be compliant > with RFC 7084. I'm not sure of the status of the unnumbered model in non- > eRouter "retail" CE routers. > > > >> Part of the problem is that one can't necessarily > >> depend upon the CPE to do DHCPv6 (-PD) at all! > > Is this because it might actually just be a host that's connecting? The population of people wanting to do PPPoE from a (non router) host to get IPv6 just to that host is going to be really, really, really small. Jumping through hoops to create an access network architecture that supports both CE routers and hosts isn't worth the trouble. If an ISP wants to supply IPv6 over PPPoE for both hosts and CE routers, my suggestion would be to supply special PPPoE software (for download onto hosts) that will look to the access network like a CE router (i.e., ask for IA_PD, etc.). Don't expect the PPPoE client native to your OS to work. Barbara -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f4030436501edabe1c05553f5815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 25 Jul. 2017 22:56, "STARK, BARBARA H" <bs7652@att.com> wrote:
> >> For= instance: *SHOULD* a PPPoE access router provide an address for the
> >> CPE router link via RA or via DHCPv6?
> >> If it does both, should it o= ffer the same
> >> address?
> >
> > I would recommend against configuring the BNG to use the same pre= fix for
> SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would reall= y
> be needed. And I don't understand why anyone would want to. I woul= d
> recommend the ISP pick a single method to use.
>
> You don't need DAD to deal for li= nk-local addresses?

No. On PPP you don't need DAD for LLA.

I think you now do per RF= C8064/RFC7217.

I don'= ;t really understand the motivation for avoiding DAD. It's a very margi= nal saving (1 packet) in comparison to the problems and time involved in tr= oubleshooting duplicate addresses.

In the scenario described, it can be much worse because there is= likely a non-technical end-user and a helpdesk involved in what can be an = intermittent and obscure fault (Helpdesks can be motivated to get the custo= mer off the phone by saying "reboot the modem and call us back if you = have more problems", which doesn't prevent the fault re-occurring.= )

I think absolute and c= onsistent failure is much better and easier to troubleshoot than partial an= d intermittent failure when the cause is simple to determine and discover.<= /div>

But in the context = of "offering" addresses via RA and DHCPv6 using the same prefix..= .
Well, of course, you can't actually "offer" a specific addres= s via RA. But if you envision a CE Router that used the EUI-64 to derive a = SLAAC address from a prefix and then offering that identical address via DH= CPv6...
No. It's just too horrible. I don't want to think about it.

> >> It would be rather better if one *knew* the CPE would do PD > >> and then assign itself an address out of one of the /64s.=C2= =A0 That would
> >> eliminate a bunch of routes.
> >
> > TR-124 RG requirements (referenced by TR-187) do require support = for
> IA_PD and the unnumbered model. RFC 7084 does not require support for<= br> > the unnumbered model; there it's optional. An ISP procuring CE rou= ters can
> use TR-124 for an RFP. But such an ISP cannot depend on "retail&q= uot; CE routers
> supporting the unnumbered model. This is because CableLabs eRouters do=
> not support the unnumbered model, and eRouters needed to be compliant<= br> > with RFC 7084. I'm not sure of the status of the unnumbered model = in non-
> eRouter "retail" CE routers.
> >
> >> Part of the problem is that one can't necessarily
> >> depend upon the CPE to do DHCPv6 (-PD) at all!
>
> Is this because it might actually just be a host that's connecting= ?

The population of people wanting to do PPPoE from a (non router) host= to get IPv6 just to that host is going to be really, really, really small.= Jumping through hoops to create an access network architecture that suppor= ts both CE routers and hosts isn't worth the trouble. If an ISP wants t= o supply IPv6 over PPPoE for both hosts and CE routers, my suggestion would= be to supply special PPPoE software (for download onto hosts) that will lo= ok to the access network like a CE router (i.e., ask for IA_PD, etc.). Don&= #39;t expect the PPPoE client native to your OS to work.
Barbara
-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

--f4030436501edabe1c05553f5815-- From nobody Sun Jul 30 18:36:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD9E128D86 for ; Sun, 30 Jul 2017 18:36:38 -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, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgnywcnL3XXM for ; Sun, 30 Jul 2017 18:36:36 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C53B61200F3 for ; Sun, 30 Jul 2017 18:36:36 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6V1VsTK025015 for ; Mon, 31 Jul 2017 02:36:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=to : from : subject : message-id : date : mime-version : content-type; s=jan2016.eng; bh=acCJR6xhmdp0XdqkcZqxQ21FYryzgqe9KgeVfkLQhHw=; b=Na4ILziCdjR8meZWOSr1BA5/Wpa9iTGTfi2VDbQNifWqhGNW2ClrWwuZ00d3TxYrTexy Oj9hixXraLPyKPuory2mAqpeea8RBoZ9NrkQyB7/NjP7k3TnAIFK6fGsVSR/+OgplmTI Z3Ua4BZ+vE8NVl7WKETXHpGMn/J7RhoNho6gP6v7+7M7izA6iH/FLMm/6RITp3UuZpvT /KwPsGZ8ePYQJht8rELnr6+a5hZwC3tipIhvLU+xO4TV3SiUApRGnsluaoCY746TdX4X yjDQJDnPFrdTFNeJK+YSavmhFNicRzhatVps13TzK2ZGDs5Kp1+znhpC0xmUmz0TuPxw Hg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2c0hwe6rtf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 31 Jul 2017 02:36:34 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6V1a1kZ005354 for ; Sun, 30 Jul 2017 21:36:34 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2c0npvu9td-1 for ; Sun, 30 Jul 2017 21:36:33 -0400 Received: from [172.19.32.87] (sfo-mpvor.kendall.corp.akamai.com [172.19.32.87]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id E693E20064 for ; Sun, 30 Jul 2017 19:36:31 -0600 (MDT) To: IPv6 Ops WG From: "Alvarez, Pablo" Message-ID: <539ae305-841b-8020-e509-62135de04b4b@akamai.com> Date: Sun, 30 Jul 2017 21:36:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FFAC53161E1A16564049026F" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-30_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310026 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-30_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310025 Archived-At: Subject: [v6ops] ICMP rate-limiting in draft-ietf-v6ops-ipv6rtr-reqs-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 01:36:38 -0000 This is a multi-part message in MIME format. --------------FFAC53161E1A16564049026F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I presented data at IETF-99 maprg showing that traceroutes work less well in IPv6 than in IPv4, and that this is likely due to rate limits required by RFC 4443, which are set to very restrictive values on some routers. Moreover, the data suggest that many rate limits may be left at router manufacturer defaults. Slides: https://www.ietf.org/proceedings/99/slides/slides-99-maprg-rate-limiting-of-ipv6-traceroutes-is-widespread-measurements-and-mitigations-02.pdf Video: https://www.youtube.com/watch?v=qYtaKuzXaiM&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h, minute 37:20 Accordingly, I suggest amending the language regarding ICMP filtering in the draft as follows: 1. Paragraph 5.4, third bullet Proposed: o SHOULD rate limit the generation of ICMP error messages with a token bucket method as described in [RFC 4443]. Rate limits SHOULD be narrow enough to (a) protect the device's ability to generate packets and (b) reduce the usefulness of ICMP error packets as part of a distributed denial of service attack. Limits SHOULD be generous enough to allow successful path MTU discovery and traceroute. For example, in a small/mid-size device, the possible defaults could be bucket size=100, refill rate=100/s. Larger devices can afford more generous rate limits. Current draft: oSHOULD rate limit the generation of ICMP messages relative to theability of the device to generate packets and to block the use ofICMP packets being used as part of a distributed denial of serviceattack The example refill rate and bucket size suggested here are 10x higher than the similar example in RFC4443, which was published in 2006. Internet traffic has grown 30x since 2006, single CPU speeds have grown 9x, and devices usually have many more CPUs, so this increase in the suggested rate limits seems reasonably prudent. I would also like to suggest the following revisions to the first bullet, to clarify what types of packets should not be filtered: Proposed: o SHOULD NOT filter Destination Unreachable or Packet Too Big ICMP error messages by default, as this has negative impacts on many aspects of IPv6 operation, particularly path MTU discovery. Current draft: oSHOULD NOT filter ICMP unreachables by default, as this has negative impacts on many aspects of IPv6 operation, particularly path MTU Finally, I have a concern about the second bullet in paragraph 5.4. The current draft states: o SHOULD filter ICMP echo and echo response by default, to prevent the discovery of reachable hosts and topology. This recommendation is quite strong, and is presented without further discussion or justification. I am interested in the justification for this, and its value as compared to the cost to researchers, CDNs, network operators and others who benefit from being able to better understand network topology (and who can provide better service to end users with that understanding). In fact, paragraph 4.2 of the current draft emphasizes the importance of being able to visualize and understand network topology. Pablo Alvarez Akamai Technologies --------------FFAC53161E1A16564049026F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I presented data at IETF-99 maprg showing that traceroutes work less well in IPv6 than in IPv4, and that this is likely due to rate limits required by RFC 4443, which are set to very restrictive values on some routers. Moreover, the data suggest that many rate limits may be left at router manufacturer defaults.

Slides: https://www.ietf.org/proceedings/99/slides/slides-99-maprg-rate-limiting-of-ipv6-traceroutes-is-widespread-measurements-and-mitigations-02.pdf
Video: https://www.youtube.com/watch?v=qYtaKuzXaiM&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h, minute 37:20

Accordingly, I suggest amending the language regarding ICMP filtering in the draft as follows:

 

1. Paragraph 5.4, third bullet

Proposed:
o  SHOULD rate limit the generation of ICMP error messages
   with a token bucket method as described in [RFC 4443].
   Rate limits SHOULD be narrow enough to (a) protect the
   device's ability to generate packets and (b) reduce the
   usefulness of ICMP error packets as part of a distributed
   denial of service attack. Limits SHOULD be generous enough to
   allow successful path MTU discovery and traceroute. For
   example, in a small/mid-size device, the possible defaults
   could be bucket size=100, refill rate=100/s. Larger devices
   can afford more generous rate limits.

 

Current draft:

o  SHOULD rate limit the generation of ICMP messages relative to the 
ability of the device to generate packets and to block the use of       
ICMP packets being used as part of a distributed denial of service       
attack


The example refill rate and bucket size suggested here are 10x higher than the similar example in RFC4443, which was published in 2006. Internet traffic has grown 30x since 2006, single CPU speeds have grown 9x, and devices usually have many more CPUs, so this increase in the suggested rate limits seems reasonably prudent.

 

I would also like to suggest the following revisions to the first bullet, to clarify what types of packets should not be filtered:

Proposed:
o  SHOULD NOT filter Destination Unreachable or Packet Too Big
   ICMP error messages by default, as this has negative impacts
   on many aspects of IPv6 operation, particularly path MTU discovery.

 

Current draft:

o  SHOULD NOT filter ICMP unreachables by default, as this has      
negative impacts on many aspects of IPv6 operation, particularly      
path MTU



Finally, I have a concern about the second bullet in paragraph 5.4. The current draft states:

o  SHOULD filter ICMP echo and echo response by default, to prevent 
   the discovery of reachable hosts and topology.


This recommendation is quite strong, and is presented without further discussion or justification. I am interested in the justification for this, and its value as compared to the cost to researchers, CDNs, network operators and others who benefit from being able to better understand network topology (and who can provide better service to end users with that understanding). In fact, paragraph 4.2 of the current draft emphasizes the importance of being able to visualize and understand network topology.


Pablo Alvarez

Akamai Technologies

--------------FFAC53161E1A16564049026F-- From nobody Mon Jul 31 00:00:58 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45D127444; Mon, 31 Jul 2017 00:00:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150148445751.17707.15424999122129322815@ietfa.amsl.com> Date: Mon, 31 Jul 2017 00:00:57 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 07:00:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Pages : 8 Date : 2017-07-31 Abstract: In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. In most deployments today, IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 31 03:31:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80B41320A2 for ; Mon, 31 Jul 2017 03:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_PBL=3.335, 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 QnU2DRdoOk6h for ; Mon, 31 Jul 2017 03:31:18 -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 53B8B127077 for ; Mon, 31 Jul 2017 03:31:18 -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 629411BC37 for ; Mon, 31 Jul 2017 10:31:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <539ae305-841b-8020-e509-62135de04b4b@akamai.com> Date: Mon, 31 Jul 2017 11:31:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <539ae305-841b-8020-e509-62135de04b4b@akamai.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] ICMP rate-limiting in draft-ietf-v6ops-ipv6rtr-reqs-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 10:31:20 -0000 "Alvarez, Pablo" wrote: > Finally, I have a concern about the second bullet in paragraph 5.4. = The current draft states: >=20 > o SHOULD filter ICMP echo and echo response by default, to prevent=20 > the discovery of reachable hosts and topology.=20 >=20 >=20 > This recommendation is quite strong, and is presented without further = discussion or justification. I am interested in the justification for = this, and its value as compared to the cost to researchers, CDNs, = network operators and others who benefit from being able to better = understand network topology (and who can provide better service to end = users with that understanding). In fact, paragraph 4.2 of the current = draft emphasizes the importance of being able to visualize and = understand network topology. It does seem odd, and it's been a bugbear of mine (with my work hat on) = that basic troubleshooting should be so hampered by people who think = that filtering ICMP Echo endows some sort of security. I liken it to = someone removing the house number from the front of the house as though = not having it visible somehow protects from burglars. From nobody Mon Jul 31 08:13:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDCA1324C1 for ; Mon, 31 Jul 2017 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Qx0Dieu3mzpH for ; Mon, 31 Jul 2017 08:13:25 -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 CB36B1324DA for ; Mon, 31 Jul 2017 08:13:02 -0700 (PDT) X-Envelope-To: v6ops@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 v6VFCwvM016907 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jul 2017 16:12:58 +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: <597F48FA.4000209@foobar.org> Date: Mon, 31 Jul 2017 16:12:58 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: Lorenzo Colitti CC: IPv6 Operations References: <596CF817.8040900@foobar.org> <596D2E63.3070401@foobar.org> <596DFD26.4050206@foobar.org> <596E09CC.3@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 15:13:28 -0000 Lorenzo Colitti wrote: > I think a lot of the disagreement on interpretation is due to the fact > that some in the discussion (including myself) have inappropriately > characterized the RFC as recommending against the *use of DHCPv6 in > general*. this was the source of the confusion which host-addr-update attempted to clarify. As it appears to have been a mistake to start with, the best thing would be to let draft-hilliard-v6ops-host-addr-update expire. > It doesn't - it recommends against *requiring* the use of > IA_NA / IA_TA in order to use IPv6 on a particular network. I think the > confusion is limited to this thread though; then RFC itself is pretty clear. This is a different issue, and it looks like a lot of people on the v6ops-wg have different interpretations on whether it means this in the first place. That said, operators will do what they are going to do and will happily ignore advice from the IETF if they decide it suits their requirements better to do that. Nick From nobody Mon Jul 31 12:02:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB985132620 for ; Mon, 31 Jul 2017 12:02:46 -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 VYqWk3BswzYA for ; Mon, 31 Jul 2017 12:02: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 A4C4112741D for ; Mon, 31 Jul 2017 12:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501527761; x=1502132561; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=SBPkhgnhWduHipk1rLUEOgfPZ+R6BBfeE+lwlrFDdWw=; b=Zf+aHO0CEAz+n kaNdzafYDmmIa42KDhS6XMqGz6+i05G1Bjl/fOz9s5fl/KKPijk5XmGZpcmefYh4 ult4d0kM0dt7P8ABJq0jG+c0NkTCjaED69vC1Br85yIwavsWZkZmEi7qE9wfqjhC anzCqrNhdTMH+U5ts/XfjMrfiRszXA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VzuDYd40AOvcsUiL/Nxsyhwvz7QPLz7/CR8Wt7eceP3J/h42qfes/hE7BTVl 4gX2dwjhpwNWs/WNLFN+juZjFZ50hqohC8Jrsecl6mBdWD0g7qAGKwbj4 rpL+S2ZgrdMs0R6eMgpqCAS0+fZl7fPo9wZvCEbMYK3/q4scyGS+Ac=; X-MDAV-Processed: mail.consulintel.es, Mon, 31 Jul 2017 21:02:41 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 31 Jul 2017 21:02:41 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005491419.msg for ; Mon, 31 Jul 2017 21:02:41 +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:170731:md50005491419::+U9dumIeVzoKdcIU:00002fno X-Return-Path: prvs=13856d59bf=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Mon, 31 Jul 2017 21:02:36 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: IPv6 CPE vendors panel Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] IPv6 CPE vendors panel X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:02:47 -0000 Hi all, I=E2=80=99ve got a slot in the next APNIC meeting (https://conference.apnic= .net/44/) in Taichung, Taiwan (12, 13 or 14 September, the final schedule i= s not yet ready), for a panel with CPE vendors. The target of the panel is to have a short presentation from each vendor an= d then an open discussion about the support for features and updated transi= tion mechanisms. Obviously it is a very high visibility session, so it provides a lot of exp= osure to the community and many ISPs, not only from AP region, as APNIC is = often attended by ISPs from other regions, and presentation materials are p= ublished among all the RIR communities. I will like to invite a few vendors to participate. Please let me know in private if you=E2=80=99re interested and the contact = details of who will attend, so we can arrange all the details with APNIC. Thanks in advance! Regards, Jordi PD: I=E2=80=99ve checked with the chairs before posting this email and my p= lan is to report back about the panel to v6ops, in the list or even with a = presentation in the next IETF 100 meeting. =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.