From nobody Tue Jan 2 10:49:59 2018 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 22EAA12D7EF; Tue, 2 Jan 2018 10:49:54 -0800 (PST) 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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151491899410.22628.14408666128226236605@ietfa.amsl.com> Date: Tue, 02 Jan 2018 10:49:54 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-01.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: Tue, 02 Jan 2018 18:49:54 -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 : Requirements for IPv6 Routers Authors : Zaid Ali Kahn John Brzozowski Russ White Filename : draft-ietf-v6ops-ipv6rtr-reqs-01.txt Pages : 30 Date : 2018-01-02 Abstract: The Internet is not one network, but rather a collection of networks. The interconnected nature of these networks, and the nature of the interconneted systems that make up these networks, is often more fragile than it appears. Perhaps "robust but fragile" is an overstatement, but the actions of each vendor, implementor, and operator in such an interconneted environment can have a major impact on the stability of the overall Internet (as a system). The widespread adoption of IPv6 could, particularly, disrupt network operations, in a way that impacts the entire system. This time of transition is an opportune time to take stock of lessons learned through the operation of large scale networks on IPv4, and consider how to apply these lessons to IPv6. This document provides an overview of the design and architectural decisions that attend IPv6 deployment, and a set of IPv6 requirements for routers, switches, and middleboxes deployed in IPv6 networks. The hope of the editors and contributors is to provide the neccessary background to guide equipment manufacturers, protocol implemenetors, and network operators in effective IPv6 deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 2 10:52:49 2018 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 2F09812D7EF for ; Tue, 2 Jan 2018 10:52:44 -0800 (PST) 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 xda9ntPFmMLX for ; Tue, 2 Jan 2018 10:52:42 -0800 (PST) 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 788E012D811 for ; Tue, 2 Jan 2018 10:52:42 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id x28so39700468ita.0 for ; Tue, 02 Jan 2018 10:52:42 -0800 (PST) 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:thread-index:content-language; bh=5mKCwUAHX+tFJZ6U0PF3JBVq//niXOWdOpqETDKqi88=; b=cDN35WqC/S04A8IVdO4stnDO45cPeLebLLNGaOq+Bbso4ClJLdhpkimONfhQ34h7/v MyCSOAio/UAOzXQvy6aNWw8Rz083VTiM9SIPPZLUZQnW2u+CUjv5TysXiF9YCvS3f+FU xLqAS8au5Fl5e/3qMRX9/34sYANez5L7F7eNQOZF7MNBTGyVw7dz9tJqNbjrlrmera97 BMhFDDJdCYoqAUV3YKsRNWrHjGEw8ud09lovVld8o/rXRrsVsPGVYfnJO9+stjdYY1iD kEdbfJ7nGcy/uj5uUzVWgbJFpedsEt9cIMVDg7Go1b8Fjs7g11Yce9AFGLWrSw5ofvF4 0xMQ== 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:thread-index :content-language; bh=5mKCwUAHX+tFJZ6U0PF3JBVq//niXOWdOpqETDKqi88=; b=TLltH1MWyBi2HsNJ7bZmC9FO8mnmwPrst3f4Qz7xPJEYG1avMFsZ4vyVyb7/d+iHLR 7TlGz4joNFKxxRZCjDzPnYmh6wSyRhnb2yvlA1G8WZRGnb90KecYDLRg4Z9ordP52okY rtNSSkkfu9hpWuVu2RapwQAln+bOgFPo0mww52ibLfbbrrQeCvB/Y/MFM/dweKGRCCq9 H5emicBc0gcVQ9NlL8DApnBOH0p3lCRBU11udUWJVF6Qj2VsVniW1s79jloFFpcA+Avn KmWg/0P7aJFPqThPLhYmRM9jw7gHb+1OFYVcXUxwj/gMI/7H2t7m4mVpC8wEyvP5Ag8Q e07g== X-Gm-Message-State: AKGB3mI1uQ64t/HS21huWT6s+1PKv31nt8smSiHNHZATIwab2TfdPLuW NsyHTvuS/GZt0V3BkHOJWb7T+w== X-Google-Smtp-Source: ACJfBotu3gFLEBqyYvZ/756sVPov01TIy1z1RvXVGuGWq9TlZtGK1L+XrJDkTwRfaeb31c9lm5x6gg== X-Received: by 10.36.162.76 with SMTP id o12mr60693706iti.76.1514919161663; Tue, 02 Jan 2018 10:52:41 -0800 (PST) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id a69sm17331598itc.18.2018.01.02.10.52.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 10:52:41 -0800 (PST) From: <7riw77@gmail.com> To: References: <151491899410.22628.14408666128226236605@ietfa.amsl.com> In-Reply-To: <151491899410.22628.14408666128226236605@ietfa.amsl.com> Date: Tue, 2 Jan 2018 13:52:39 -0500 Message-ID: <09b101d383fa$dd6fca30$984f5e90$@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: AQJjFcGnelufVUlVzumpHXfPVLtZSqJByYxw Content-Language: en-us Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-01.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, 02 Jan 2018 18:52:44 -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. >=20 > Title : Requirements for IPv6 Routers I've addressed all of the comments I had notes for except -- - Should PVD be included? - Add a redirects section -- I don't remember what this was in reference = to. - The suggestion for an appendix containing a plain list of the = requirements. The first needs on list discussion, I think. For the second, I need to = find the context. For the third -- I may add an appendix if we get to a = version with no comments, if folks think it's useful. =F0=9F=98=8A /r=20 From nobody Tue Jan 2 12:34:52 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F112D7EF for ; Tue, 2 Jan 2018 12:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loOU0nz6y_tT for ; Tue, 2 Jan 2018 12:34:50 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 08DC9127076 for ; Tue, 2 Jan 2018 12:34:50 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id x20so33982095oix.12 for ; Tue, 02 Jan 2018 12:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=dfrCVP9q07zu/vCO7p9lZRiNP5uqhc4/FwBQYoPYkGU=; b=ILFdpeiWmN7/Pc+D75/RHV8V12Prdx7Qaunkbt84WR+y0SUca14yn/cAGLR4GXzl4x Qr6lFm6642Eho7ObEgEZPYC2ydT2cPmo9be1MTWwhiAuKPLSJYFZgVfkIdmlSEIDGmY1 TwPibcHkSnSAOeBDGVNtUlsBGdWs/mVdi3058kmQLpUCJRMiOa7e+C0yjnUn0J/ypRmp Z1J3VMUyU4pzoyhdLvVWi6QptFtarlyhuaIt6ibmWGJ+KlRTC6838TxoCv9pMFWCbjZn oSCgZv4AHtqOvwURPtJ7GSpExaCCdCHMUPxs3KfSneg6hcAEBuAQXYhh4rFHLZuN7o3H IGcg== 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:message-id:date:to; bh=dfrCVP9q07zu/vCO7p9lZRiNP5uqhc4/FwBQYoPYkGU=; b=AIDZz/Mgy30evxIK6TtSE0C6SQzreBxpDI2bWFCP/ZK2G4Wfa8NHVSrcUFYdXpPH+g To0C694qrXWH5rxK1X0QPBe+AFVmQ/ZN6VJJYgm5UEjq0U8gjwJuh4QJIltxc0qC0h1u lgvyDqvYYU9RvR1avWiTdccYfoBOECJVGCESREuMS09UEVVMNG7gY2wjBiPThxtXiPx8 MMIv7lyWbcVnjbjLKUOY2nd6bqZXwzLaSY/m8blr4pg0H3ONLMmF+XohUBO4rb+w2oMQ Q/O8ob8M8ANOBh90XKafa2d29hPonJugY4pytfotHFJ5L2/5FtWQAsBSiKxlx3sXqRIy 3uLw== X-Gm-Message-State: AKGB3mK8aLrp8AhSQbzRViFn8FlR3kcMxUEbrsOtCjlwTx5AUdWy4VOD DsULx2DPv8btBnyF3N0qJjvhArQ0 X-Google-Smtp-Source: ACJfBovt3czPC90SfUq+kPX99GjOWvviLQTC2/ncRqHmflx+0y6+rqFrpvSkTCpCUPwlTfmH4W1nmQ== X-Received: by 10.202.6.68 with SMTP id 65mr31277223oig.294.1514925289083; Tue, 02 Jan 2018 12:34:49 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::108b? ([2600:8802:5600:f7a::108b]) by smtp.gmail.com with ESMTPSA id e52sm13676445otc.20.2018.01.02.12.34.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 12:34:46 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_648A0E05-0507-4D7F-B826-ED3BD271DF0C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Tue, 2 Jan 2018 12:34:44 -0800 To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [v6ops] Discussion focus: draft-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, 02 Jan 2018 20:34:52 -0000 --Apple-Mail=_648A0E05-0507-4D7F-B826-ED3BD271DF0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I = wonder what we, as a working group, think of it? The diff may be found at = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6rtr-reqs-01.txt= . The TOC indicates that several sections have been added. Some of the observations the draft makes aren't obvious to me. For = example: < 5.7. IPv6 Operation by Default < < If a device forwards and/or originates IPv4 packets by default < (without explicit configuration by the operator), it SHOULD forward < and/or originate IPv6 packets by default. See the security < considerations section below for reflections on the automatic < configuration of IPv6 forwarding in parallel with IPv4. If I were writing that, I think I might suggest that systems SHOULD = follow the Happy Eyeballs model described in RFC 8305 (which would = normally result in IPv6-only operation if the system and its peer are = IPv6-capable and IPv6-enabled). The advantage of that is that it is a = clear operational specification (this one might lead me to understand = that it should always send both an IPv4 and an IPv6 message if it had = the capability, which seems counter-intuitive), and would trend toward = supporting IPv6-only operation (which I understand to be the point). So, operators... please read the draft and comment. Having a couple of = fairly thorough reviews would help. The target is to be able to have an = update to discuss at IETF 101 in March, and move the draft along. No real deadline, but if you could make your comments in the coming two = weeks we can have a focused discussion on it. --Apple-Mail=_648A0E05-0507-4D7F-B826-ED3BD271DF0C 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpL7OQACgkQEhdRnd2G P+BikA//UN7vYY7eVAejfDqPgG4D/iv9dog2rhrRjY1EATvFa3FdW/uvz6r1w9Rz QfkAJhncChuBloJ8ZZ47zjTL4nMxpZM/L1aSurDHsjh0huUV5yt+cEGHc1cuHIE4 bHV7CaBijS++fuIRhpedcyyPgQiRPC/opkGxXQpjlEfDjKLuLykAArPokGTOdHIy emg8Jhvxckp589ZW2yqNXN2D58d7291ilnjODmC5zBwnSvw7aLR22mFkM8ZEIPa+ 0j78C2drQ27MOzjmqK9/rTkzOrHtm7dOMJZf6wmTbvdhksnXUvkc1ig5OHhlH9fn 2/JnppaA55FDlT9lk0q3Tu4j0YWPCE4friJxMo+cVaIMKUWq5nR/a0PjsFe+7Q2y MkviWDkDSJEJ9ef2WasLkwKpwJERe9XHTzhoTxqMoimz3tafOQQ9aPLuN0UKQNih 7CcWbYmmqXQ/4JAianSALoSwwrWLDtkIOTKTLufKH4tSSLMjUOxuid+H8HFeswv7 pc+UQqq73XziBbpg/3ezurOXZBrTxAnmGyVQyqajbIjlgCSOz38QE0K5wEE0C6Pu QFe5kcdV0qGnti15K7mjMXgknQIPf7f0ZKjt0zMCDsskX2P/BXx51T6KSl5+kKKn S1eyVfXu4HZencHas7Xvord+bzsN26+wpU5kDBvEeZ760zUIjrI= =RiMH -----END PGP SIGNATURE----- --Apple-Mail=_648A0E05-0507-4D7F-B826-ED3BD271DF0C-- From nobody Tue Jan 2 13:29:37 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F2B126D05 for ; Tue, 2 Jan 2018 13:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 cgvFXX6rEN1y for ; Tue, 2 Jan 2018 13:29:34 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 31723126CBF for ; Tue, 2 Jan 2018 13:29:34 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id a42so22332236otj.5 for ; Tue, 02 Jan 2018 13:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/seaf+virTXOOCNX9SGUly7ufvnrVac5foTvhGUMvac=; b=evtbbJKjGJvkfhdoUUv8Q3KWCUGjOODSP56D0V88nzuPhILew8DINCf1tna1q9Qwjr ti9KDYy5ntE0/75fHeOIvaimriUvEgm04WcOg4cNh4hwXjYaIugsTtYW06RU2WGk9JlW o1v3O47yZaUYFmJ8tCkRzJM9nYWjGuGHrYvl9oojsox0Pv+ZTATKBx5IdEIJZij/bX7T 6G4mm0WiCoR/hLuhFdY2bUehVjVAZhPXqaYSwixMtpnj68cSLpiDh/p3fq5HFAS978Xc FOMb1Lk6ZOWJeKSotHdwS6gCRdbj9iIS5wLaprpnSEv246fJ34vDkH2tvGAQdPJfCi9O w4Bg== 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=/seaf+virTXOOCNX9SGUly7ufvnrVac5foTvhGUMvac=; b=qEYQjkuDble4sNBeCfK554F2m5pZTOgJuK6ovIIp5CmcAmaAnrTSjWYgqOqvBbXGzv Ug10+T4fffoHqIltG1k2KIAWSmr68gSxFTRs7MCUxKnIOzT8fATYhcpuQVTWi1vWf1w2 QR8th3LnIz2Q6/1jwXoCSg0E0P6T9Cu+r8BWGNBu70sDh6snUVQfb7PEJ+og62RHeDWy I+WeIOOvmZtHwzZ2ou5zTv/xHyp4voEPdY64AVj6T3NhC4LNiMV9HxkCav3+HRUanVIZ m7Z9tPhm8jBSdnSlLkxPrlTeB7vrqceKQptAVYlXNReb+YGVPx83kv7/FU9zb34vjjVy eNng== X-Gm-Message-State: AKGB3mKGKe47EW0b0uB3nsPMsDrU0rs6f5hnS20sg7ADtLUpUIla7x/0 RVbyrgzbk/I+AXtnzxdT3zc= X-Google-Smtp-Source: ACJfBovzk+zchEj8WMm3fBmxYqTyz0Kh871YhW4l4h/LdJS2kiqbFFv79utlITsb3nwbkgSxX3z1Lw== X-Received: by 10.157.8.74 with SMTP id 68mr38392382oty.250.1514928573463; Tue, 02 Jan 2018 13:29:33 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::108b? ([2600:8802:5600:f7a::108b]) by smtp.gmail.com with ESMTPSA id u47sm14547616otf.30.2018.01.02.13.29.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 13:29:32 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_96B4A95E-7790-45D2-85B2-85A9E622BB9D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 2 Jan 2018 13:29:29 -0800 In-Reply-To: <09b101d383fa$dd6fca30$984f5e90$@gmail.com> Cc: v6ops@ietf.org To: 7riw77@gmail.com References: <151491899410.22628.14408666128226236605@ietfa.amsl.com> <09b101d383fa$dd6fca30$984f5e90$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-01.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, 02 Jan 2018 21:29:36 -0000 --Apple-Mail=_96B4A95E-7790-45D2-85B2-85A9E622BB9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 2, 2018, at 10:52 AM, 7riw77@gmail.com wrote: >> 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. >>=20 >> Title : Requirements for IPv6 Routers >=20 > I've addressed all of the comments I had notes for except -- Thanks for this. You will have seen, by now, my request for online = discussion of the draft. If I have one comment, it would be this: The document is developed in comparison to RFC 1812, which I know a = little about. RFCs 1122, 1123, and 1812 were developed by the community = (I came in late in the game) to update and address a variety of small = issues that had been identified and sorted out. Today, if we were doing = this, we might start with an "erratum", such as "let's clarify: subnet = broadcast address has a host part that is all ones, not all zeroes", and = we would address the issue in some subsequent update to the relevant = RFC. In the late 1980's, there was a perception that "OMG, updating each = RFC would be a huge job". I think Bob Braden might agree with me when I = say "updating them all in a single omnibus document, so big it became = three, was a huge job". The major advantage that RFC 1812 had was that it was edited when CIDR = was being agreed to and worked on in a number of working groups, and we = could address CIDR in one broad document. It was also at a time when the = behavior of several routing protocols (RIPv1, which made non-CIDR = assumptions, OSPF with TOS-Based-Routing, and IS-IS with = TOS-Base-Routing) needed to be described so that networks could deploy = them interoperably. The practical objective was to "finish" work that = had been going on for some time and lost its way; the theoretical = objective (stated with the benefit of 20/20 hindsight) was to describe a = new commercial Internet that was just coming into being. The huge benefit that RFCs 1122, 1123, and 1812 brought to the community = was not WHAT they indicated had been decided. It was WHY, among several = possible solutions, they had been selected. The three documents gave = vendors, open source, and other developers a view into operational = experience regarding what worked, what didn't, and WHY some solutions = were better than others. If there is one thing I want to find in this document, it is WHY, backed = by operational experience. Let me put this in a specific request to the authors. I would like to = hear from multiple networks - LinkedIn, yes and of course, but also = others - what you would like to mention by reference in your RFPs. How = do you intend to build your networks? What requirements does that impose = on each bit of equipment? As a transition mechanism, I can imagine that you have micro-services = that are IPv4-only, at your ingress that it might be load balancers = serving a web-based service, and in the back end it might be "simple" = translation such as proposed in IVI or SIIT-DC. Your network therefore = looks something like: ,-. ,---. ,---. / \ / \ / \ / \ ,' `. ,' `. / \ ; : ; : ; : ; : ; : ; : ; : ; : ; : ; : ; : | | ; : ; : | The Great +----+ IPv6-only +----+ IPv4-only | | Unwashed |XLAT| Data Center |XLAT| Back End | | +----+ +----+ Microservices | | | : ; : ; : ; : ; : ; : ; : ; : ; : ; : ; : ; \ / : ; : ; \ / `. ,' `. ,' \ / \ / \ / `-' `---' `---' Tell me what you require of those equipments, and more specifically, = why? Is HTML the waist of your hourglass? Tell me about that? --Apple-Mail=_96B4A95E-7790-45D2-85B2-85A9E622BB9D 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpL+bkACgkQEhdRnd2G P+BX9xAAwZs3FBeSMi5HJNyKGEx/qWxlfoUjQ3TK0GpJyD0r3e2zc1hZn50BY059 KJ/cbQrZHXZBdmk5Sg9cn3OjQhChCpOVSDC5vJ1z1hpLw5apLfOjweDkJ5ttScUN 6sKdsxM2FlyVs3Et3PNpI+nRwmoY5AYJr7Zygi1hhZVEIpMcDjGJzOcwmaKyPpXr vl/wViHp6CR+b5HV7O/R7dI2nv6RlvsuyREFvmR/31FytJ5AfSaTMAuB77/YSHrd ddfqIOEKPxwTZ94l9aETOicETEiaRolQvIVoydVK558BSF7LvE4CsCpdNw/aaZPV KvvTu1/vfJ8ecOYTsHhyaOIg6e0z7F23L1XY9RxGOV5aGKPUlQSpIrqn6wwYfms7 IZaPy2bMtanIqoeKnohsa77uTTEQ3cZxpfuNe4nGLRU5tc78UeAVgEDjMhWMTnlZ UGrw/TDSkOHXRwRp4A0W6JP1Orva0/pkJd2wMtbHCzr7BHf8/KD5ap8Mo7vR4tAv Nzzxt/oMVq5gPeyPXgem5IN6op6take5FrLFcIg5vbqASOoz9czLO1fz0OnTzi8A h+AhuJ6LVQzXTmneb/mv6ym+HBl+gQMn2sVqrfiWquhnpPVoiMauTBY4HnjEPZcL 1TniQtSVxPXSRFcUGuD/R4T6Fsz1k+i85/jvAEsLFFoMVJGWQ9g= =0sZd -----END PGP SIGNATURE----- --Apple-Mail=_96B4A95E-7790-45D2-85B2-85A9E622BB9D-- From nobody Tue Jan 2 15:07:43 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1D12D850 for ; Tue, 2 Jan 2018 15:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg3zjkjZMecA for ; Tue, 2 Jan 2018 15:07:38 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED0F12D811 for ; Tue, 2 Jan 2018 15:07:38 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id E0CEDB4D for ; Tue, 2 Jan 2018 23:07:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXhM5HLQxQxD for ; Tue, 2 Jan 2018 17:07:37 -0600 (CST) Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 78CCEB39 for ; Tue, 2 Jan 2018 17:07:37 -0600 (CST) Received: by mail-lf0-f70.google.com with SMTP id x129so3697138lff.10 for ; Tue, 02 Jan 2018 15:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VGq23DjQl2mySqyvdGnPFUvjQ2b9lCesM/h91npmWdI=; b=f6drAL5kIKF1qeRwy09qQ56auRZmMYJBDZeepPELBkXNDuPIb2M09aRlhu1+0B/Mmq tuwa6hAZJX/DlIKCcs0wn2wR0Wnwk3UhsSK90wKNfoKlGCouhcVS7m2mtoirBbxjVjtL sZARqHBPTKwBeJt1KacZPHXsKmaK8WOq719UYHaPIiKTY9hczSFs4WnRhMjEkD2D98zw RFU8I1RzbnQHprrXCedNR00T7DhQK662ZvxblUKP/wqnrPEp0RHowF1GrNob8FmGrr+E GnsupfY+UYHzHBeUkmLhumYPJC5otKXX7HzD5491Xl12iBEuaPKfQ8ENE8L5ORaNrLEU STnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=VGq23DjQl2mySqyvdGnPFUvjQ2b9lCesM/h91npmWdI=; b=j1DvehOEjrEVlA8OcJaKHBWqIn7IrW4DijCHrk2H2UEDwvi07X0kXheeOfH2OUG87p RtkkUjzR/ZiZT2iB7rhrTxOscIqDva9Bz2XIyt/OLgr2y/YOAcwFclkNnn4b4Jk9GFvS LYwHRMZVrLdRDE5pwnMzkG4dEZ+xIUtB0OwIzF3CXHySKKH+l9ptV5xvAn3e7Qo9NgYi dxtTggAxClrwnZUsf+yYSHJkoJsiINRyW3TLWn0eRjZJ53TzLCh5AQniT7Rhc0l6nLSG FmjzgNB/le3Ss8OM1MTWpxg3y8FMJwGorusN8p3S5R3ojb2ddZC2YiI0tVMnOal8gADB JCuQ== X-Gm-Message-State: AKGB3mIjqORGCGaa5Nb3p7H2+aeezTIpTdiTYDDMFDORdVn/+bgjUZbr +1W7kAx2a2PnOslGqZZEAsrLGKCA7JBTq8Isg7yD+Q8PVpZ0HzympS/1G6rBMPDVntg+MGc6cCh ZLA8hyJFyLNzxTaWTipWOpBIPOw== X-Received: by 10.46.4.2 with SMTP id 2mr27148084lje.133.1514934455704; Tue, 02 Jan 2018 15:07:35 -0800 (PST) X-Google-Smtp-Source: ACJfBosxrj6OGdmYGL3p2hHmHMf5DakqVWL/d7P4dz+KJXJ1+Ju02o7nVper9idcGQsGselTAX+uaHQ8KW2luL7tWHg= X-Received: by 10.46.4.2 with SMTP id 2mr27148082lje.133.1514934455480; Tue, 02 Jan 2018 15:07:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.74 with HTTP; Tue, 2 Jan 2018 15:07:34 -0800 (PST) In-Reply-To: References: From: David Farmer Date: Tue, 2 Jan 2018 17:07:34 -0600 Message-ID: To: Fred Baker Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c1ce15e13caaf0561d32a21" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 02 Jan 2018 23:07:41 -0000 --94eb2c1ce15e13caaf0561d32a21 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 2, 2018 at 2:34 PM, Fred Baker wrote: > The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I > wonder what we, as a working group, think of it? > > The diff may be found at https://tools.ietf.org/ > rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-01.txt. The TOC indicates that > several sections have been added. > > Some of the observations the draft makes aren't obvious to me. For example: > > < 5.7. IPv6 Operation by Default > < > < If a device forwards and/or originates IPv4 packets by default > < (without explicit configuration by the operator), it SHOULD forward > < and/or originate IPv6 packets by default. See the security > < considerations section below for reflections on the automatic > < configuration of IPv6 forwarding in parallel with IPv4. > I read this as if IPv4 forwarding is enabled by default, the so should IPv6 forwarding be enabled by default. I think the "and/or originates" is confusing you, and maybe it should be eliminated. In my opinion this isn't about what type of packets are originate or Happy Eyeballs. It's more simply the fact that IPv6 isn't turn on by default on may routers, and therefore an additional step is needed to enable IPv6, where as IPv4 is turned on by default on most routers. In 2018, if something claims to be a router it should have IPv6 and IPv6 forwarding turned on by default, and probably IPv4 too, or have both IPv4 and IPv6 disabled by default. Maybe in 2025 or so, IPv4 should not be turned on by default, but that's just speculation on my part to illustrate the point. > If I were writing that, I think I might suggest that systems SHOULD follow > the Happy Eyeballs model described in RFC 8305 (which would normally result > in IPv6-only operation if the system and its peer are IPv6-capable and > IPv6-enabled). The advantage of that is that it is a clear operational > specification (this one might lead me to understand that it should always > send both an IPv4 and an IPv6 message if it had the capability, which seems > counter-intuitive), and would trend toward supporting IPv6-only operation > (which I understand to be the point). > > > So, operators... please read the draft and comment. Having a couple of > fairly thorough reviews would help. The target is to be able to have an > update to discuss at IETF 101 in March, and move the draft along. > Will do! > No real deadline, but if you could make your comments in the coming two > weeks we can have a focused discussion on it. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c1ce15e13caaf0561d32a21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 2, 2018 at 2:34 PM, Fred Baker <fredbaker.ietf@gmai= l.com> wrote:
The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I = wonder what we, as a working group, think of it?

The diff may be found at h= ttps://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6rtr-req= s-01.txt. The TOC indicates that several sections have been added.

Some of the observations the draft makes aren't obvious to me. For exam= ple:

< 5.7.=C2=A0 IPv6 Operation by Default
<
<=C2=A0 =C2=A0 If a device forwards and/or originates IPv4 packets by de= fault
<=C2=A0 =C2=A0 (without explicit configuration by the operator), it SHOU= LD forward
<=C2=A0 =C2=A0 and/or originate IPv6 packets by default.=C2=A0 See the s= ecurity
<=C2=A0 =C2=A0 considerations section below for reflections on the autom= atic
<=C2=A0 =C2=A0 configuration of IPv6 forwarding in parallel with IPv4.

I read this as if IPv4 forwarding is ena= bled by default, the so should IPv6 forwarding be enabled by default.=C2=A0= I think the "and/or originates" is confusing you, and maybe it s= hould be eliminated.=C2=A0 In my opinion this isn't about what type of = packets are originate or Happy Eyeballs.=C2=A0 It's more simply the fac= t that IPv6 isn't turn on by default on may routers, and therefore an a= dditional step is needed to enable IPv6, where as IPv4 is turned on by defa= ult on most routers.=C2=A0 In 2018, if something claims to be a router it s= hould have IPv6 and IPv6 forwarding turned on by default, and probably IPv4= too, or have both IPv4 and IPv6 disabled by default.=C2=A0 Maybe in 2025 o= r so, IPv4 should not be turned on by default, but that's just speculat= ion on my part to illustrate the point.
=C2=A0
If I were writing that, I think I might suggest that systems SHOULD follow = the Happy Eyeballs model described in RFC 8305 (which would normally result= in IPv6-only operation if the system and its peer are IPv6-capable and IPv= 6-enabled). The advantage of that is that it is a clear operational specifi= cation (this one might lead me to understand that it should always send bot= h an IPv4 and an IPv6 message if it had the capability, which seems counter= -intuitive), and would trend toward supporting IPv6-only operation (which I= understand to be the point).


So, operators... please read the draft and comment. Having a couple of fair= ly thorough reviews would help. The target is to be able to have an update = to discuss at IETF 101 in March, and move the draft along.
=

Will do!
=C2=A0
No real deadline, but if you could make your comments in the coming two wee= ks we can have a focused discussion on it.

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




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c1ce15e13caaf0561d32a21-- From nobody Tue Jan 2 22:51:12 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B99120713 for ; Tue, 2 Jan 2018 22:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09wYW2tjjFKg for ; Tue, 2 Jan 2018 22:51:09 -0800 (PST) Received: from fe3.lbl.gov (fe3.lbl.gov [128.3.41.68]) by ietfa.amsl.com (Postfix) with ESMTP id 95D50120227 for ; Tue, 2 Jan 2018 22:51:09 -0800 (PST) X-Ironport-SBRS: 2.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GtAADpfExaf0jWVdFdGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYJsglOONXSOJosJjiKCFQqFOwKEMD8YAQEBAQEBAQEBAQIQAQEJCwsIJjG?= =?us-ascii?q?COCIReAEBAQEBAQEBAUwCPi0DAzoGAQE3AQ8LISUPBQ0TAQUBIhOKFgMVAQSlH?= =?us-ascii?q?UCLIoMVgwoBAQWEMQ2CcAEBAQEBAQEBAQEBAQEBAQEaCAkBCIN6gTZcgz+DLoJ?= =?us-ascii?q?rRYU2gjSTOY9dPQKQNoRxgiSGGINcNYdBjWOIdAIEAgQFAgYUJYEXH4IJegqCZ?= =?us-ascii?q?oJFgjFZiRYBAQE?= X-IronPort-AV: E=Sophos;i="5.45,500,1508828400"; d="scan'208";a="101585509" Received: from mail-it0-f72.google.com ([209.85.214.72]) by fe3.lbl.gov with ESMTP; 02 Jan 2018 22:51:08 -0800 Received: by mail-it0-f72.google.com with SMTP id y200so590629itc.7 for ; Tue, 02 Jan 2018 22:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lW2qy9H2e5CmLVUU6ASopFIymmynS0qkKdoiINRzfBs=; b=Xyrr6ZSG6wc54zapwPBOqPhtGmNEsqnu1uNophdpOg4GuH/eCv/yWa09UPZ2n9XcsG 6SFe/Rdkxm1Ao2sI5+1cut1Actsn+7JNKvDV/uKS0w4PJiyMf0XHW9nbJ+giUSkjmD49 5RJzg22aYvJGLGpPmDqAK/ffmr9eAE8kYhYn8ZZWF+/klWB+uPKXfX3u1k6+czDKvLBh /Ttjw7nDo7zpUWyGMLtEb3t/ywLc4vHkmtslWmDjaYCQrdWOs/xx+EeqffLBviMYmC92 EJoW6cF1M56DgPjGr0vuxrvbBPPNgzv/FggXsc3ss3PcjSHoMCkbATk8sST72FPwzWut HQdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lW2qy9H2e5CmLVUU6ASopFIymmynS0qkKdoiINRzfBs=; b=sRTKGtKM9VgQACrFwHLONBd9izTZ/pEbDNl0fNbWZlUJkFLsxOGa9d7WJjELRxPeEh +LwE9t8qllfIbJngG606BULDtodBkMNPtlpcqLAmBMBPSRf2ycc2G0dmmtM0lT5YikVx dJ6AwMMq3DxsbCauqrHoqtickZ0YabXf7r6rZhEiSdvdM95I+riNicXI1ywt6QhTcDCT Y38Ff/aAAVOI5tR1AlujJnxrLBmibqMWXa5Ruw3BERnsl3CuFhHW7utCfCzW0A7Or+Oo Nhkw8I0z+hj7LriBdmvyAngHZpLIvRHfZoycTlPk2bBH+0wcaw7q8ljf8+vnpQhefwXX +JhA== X-Gm-Message-State: AKGB3mJflVgvLZVoPusBt4X/Y3MvNnsSluoZC0Ns/KalyQJWgsgbHkdY EfxLBboW+LJ1OeAQA/KBjquoaBQNbyRgFJoeSMH/bmFwrCSoDoAW07kA+b3MURGUEMT5DXWqoup E9hMBVPA= X-Received: by 10.107.22.3 with SMTP id 3mr543583iow.196.1514962268506; Tue, 02 Jan 2018 22:51:08 -0800 (PST) X-Google-Smtp-Source: ACJfBovt0iZth275uN8w3MWqITErvPVuiUFSxcv9sONWtGrYmTlExW7STZ+5L4NdYpJ0r531rP0Vxw== X-Received: by 10.107.22.3 with SMTP id 3mr543577iow.196.1514962268206; Tue, 02 Jan 2018 22:51:08 -0800 (PST) Received: from localhost (2600-6c44-5f7f-e601-adbb-581b-7acf-ba70.dhcp6.chtrptr.net. [2600:6c44:5f7f:e601:adbb:581b:7acf:ba70]) by smtp.gmail.com with ESMTPSA id r2sm251119ioe.59.2018.01.02.22.51.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 22:51:07 -0800 (PST) Date: Wed, 3 Jan 2018 00:51:05 -0600 From: "Dale W. Carder" To: Fred Baker Cc: "v6ops@ietf.org WG" Message-ID: <20180103065105.GB93804@cs-it-6805697.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 03 Jan 2018 06:51:11 -0000 Thus spake Fred Baker (fredbaker.ietf@gmail.com) on Tue, Jan 02, 2018 at 12:34:44PM -0800: > > So, operators... please read the draft and comment. 2.1 paragraph 2, reference to RFC1918. Is that correct, or is that supposed to point to 1812? Or RFC1981 as an example? Or, I guess I don't understand what in 1918 is referenced. 2.1 bullet 7: particularly if a brad set of protocol, should be "broad set" 3.1 I've seen a huge enterprise deployment of screen scraping which might be more traditional than snmp set ;-) As to programmatic access, to me, as important as a yang configuration model is the candidate configuration capability. Is this section purposefully ambiguous as to the transport of yang (as in netconf, restconf, etc?) or should section 4.1 be referenced here? 3.2 bullet 1: Telnet, really? How about it MUST be disabled by default? 3.2 bullet 3: From a document future-proofing perspective, is it a good idea to specifically require Ethernet? I'm not sure what the motivation is here, that out-of-band access is a capability and/or that it be of reasonable speed (thus not only 9600 baud) 3.3 bullet 1: Perhaps make the second sentence its own bullet, or combine it with the one below so everything about one protocol is in one place. It seems a bit confusing grouped as is. 3.4 Ideally, the router could provide a mirror copy of all traffic destined to the control-plane to an external device for analysis without impacting forwarding performance. 4. bullet 2: The scaling issues I have seen on a large network were related to lexicographic ordering, not the rate of pdu's. For example, try to dump tens of thousands of adjacencies. I can horizontally scale my management servers as needed, but I can't add MHz to my underwhelming router control plane. 4.1 bullet 2: Syslog. My understanding is that there has been some industry success with replacing syslog with IPFIX where appropriate such as logging from middleboxes. 4.2 bullet 1: RFC5424 should probably be RFC7752 ? 4.2 Has there been enough field experience with I2RS to actually recommend it? 5.2 "Routers SHOULD support any prefix length shorter or greater than /64" What does support mean in this context? Is this encompassing filtering as well as forwarding? Or is this redundant to section 5.9? 5.4 Should there be a reference to RFC4890? It's directed at middleboxes, but may apply here, at least in part. I have a strong objection to filtering echo and echo response by default, and note that 4890 does not recommend it. Offhand, this seems pretty extreme given the lack of justification. 5.5 mentions the forwarding table, but what about access to other tables, such as Adj-RIB-In via RFC7854? 5.8 If this is supposed to be an IPv6 router, why isn't IPv6-only capability a MUST? :-) Dale From nobody Wed Jan 3 07:48:03 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71C61275F4 for ; Wed, 3 Jan 2018 07:48:01 -0800 (PST) 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 m8vCnfDUlhze for ; Wed, 3 Jan 2018 07:47:59 -0800 (PST) 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 1381712708C for ; Wed, 3 Jan 2018 07:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1514994477; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=103mzNejxxgCb/EWesfFPfKjkDslyh0j3kLz2yeizUQ=; b=fGe0Lh/l/o4yV/oNbe7mPMLtTDkPFBXUYDCMTmEMVCCLSLMEWKH7/GvYP/lKXODjUrDg7tbhSyX738p1niPrwBgu+Ym2cp0zQZm29flrp7MpRzzAth9uEtA+36kg8EM7ngAHqVduFipqX8aLzopjzg+hr1ZGprsHNCzl3HAWGpE= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0181.outbound.protection.outlook.com [213.199.154.181]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-138-Wa8ixxnVM3Oyjbz-4m37MQ-1; Wed, 03 Jan 2018 15:47:55 +0000 Received: from VI1PR07MB1151.eurprd07.prod.outlook.com (10.163.168.148) by VI1PR07MB3070.eurprd07.prod.outlook.com (10.175.242.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Wed, 3 Jan 2018 15:47:52 +0000 Received: from VI1PR07MB1151.eurprd07.prod.outlook.com ([fe80::8cc3:226b:a0ce:d429]) by VI1PR07MB1151.eurprd07.prod.outlook.com ([fe80::8cc3:226b:a0ce:d429%13]) with mapi id 15.20.0386.005; Wed, 3 Jan 2018 15:47:52 +0000 From: Tim Chown To: "7riw77@gmail.com" <7riw77@gmail.com> CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-01.txt Thread-Index: AQHTg/qceSBENn6uw0eVKi7hGVIwN6Ng7cOAgAFes4A= Date: Wed, 3 Jan 2018 15:47:52 +0000 Message-ID: References: <151491899410.22628.14408666128226236605@ietfa.amsl.com> <09b101d383fa$dd6fca30$984f5e90$@gmail.com> In-Reply-To: <09b101d383fa$dd6fca30$984f5e90$@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.3445.5.20) x-originating-ip: [2001:a88:d510:1101:981e:3190:392a:72ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3070; 7:DEMFuE+jn6+cl0+ovkbp/BRzRCGfWjAvHAyPfg4H4nWyRenuRS19eh8AER2ixrfhYDmkg56/3MTvkXi5pdFhaunZE4HpUInRZ0fhRX+vT8/k1r9oAaVVjnVQLlnjVrFqPSOyYwEnXpM4ndX5XKIz0N3DarmNFe13tuWDsssVGB/fUSHbGqPklOlu8BJKAKke6ddoJPwDr0tATGbR4Tjsh1sshQ7EKViNddxYdBCYm4vAfWwNyIuzm9LQoj2rFDnO; 20:xZ+c9o9HXLtBkwMCx3Q6X8ASAzgutCj9h/zvpwiCuOw6ZORN84y54wENC3dFHVQCTBHYCNmsh2YF9u/mjiLcGbRUyLHo3WB0l6yBuXxQ5YJt3OQ7NGz+XR1PhirYfX5TyNCHWYPLff2lrH3E+lJpkqVL8ZoLcx4DXC/D82xljR0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dac7d155-6a64-43a6-5584-08d552c1593b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:VI1PR07MB3070; x-ms-traffictypediagnostic: VI1PR07MB3070: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(10201501046)(93006095)(93001095)(6041268)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR07MB3070; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3070; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39850400004)(39380400002)(376002)(396003)(189003)(199004)(24454002)(36756003)(2501003)(6506007)(2900100001)(305945005)(53546011)(7736002)(2351001)(76176011)(86362001)(53936002)(50226002)(6116002)(102836004)(97736004)(1361003)(8676002)(57306001)(82746002)(316002)(786003)(5250100002)(59450400001)(83716003)(81156014)(1411001)(3280700002)(74482002)(2906002)(39060400002)(99286004)(3660700001)(4326008)(81166006)(72206003)(230783001)(6436002)(6246003)(105586002)(106356001)(68736007)(14454004)(478600001)(42882006)(6916009)(33656002)(6486002)(229853002)(6512007)(8936002)(5660300001)(5640700003)(25786009)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3070; H:VI1PR07MB1151.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:3; LANG:en; x-microsoft-antispam-message-info: ikJILXZybXxLI4tAXhhzCVpitz6H3jdPvL3R+wgb9AWHfxbwvIwYB7p3zjO9VViiUHldPKQHg0BAOVQuJ9Aouw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <2EED0CF87027854A9E9122DA5D5F77E5@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: dac7d155-6a64-43a6-5584-08d552c1593b X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 15:47:52.1238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3070 X-MC-Unique: Wa8ixxnVM3Oyjbz-4m37MQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-01.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, 03 Jan 2018 15:48:02 -0000 SGkgUnVzcywNCg0KPiBPbiAyIEphbiAyMDE4LCBhdCAxODo1MiwgN3Jpdzc3QGdtYWlsLmNvbSB3 cm90ZToNCj4gDQo+IA0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0KPj4g DQo+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBJUHY2IFJvdXRl cnMNCj4gDQo+IEkndmUgYWRkcmVzc2VkIGFsbCBvZiB0aGUgY29tbWVudHMgSSBoYWQgbm90ZXMg Zm9yIGV4Y2VwdCAtLQ0KPiANCj4gLSBTaG91bGQgUFZEIGJlIGluY2x1ZGVkPw0KPiAtIEFkZCBh IHJlZGlyZWN0cyBzZWN0aW9uIC0tIEkgZG9uJ3QgcmVtZW1iZXIgd2hhdCB0aGlzIHdhcyBpbiBy ZWZlcmVuY2UgdG8uDQo+IC0gVGhlIHN1Z2dlc3Rpb24gZm9yIGFuIGFwcGVuZGl4IGNvbnRhaW5p bmcgYSBwbGFpbiBsaXN0IG9mIHRoZSByZXF1aXJlbWVudHMuDQo+IA0KPiBUaGUgZmlyc3QgbmVl ZHMgb24gbGlzdCBkaXNjdXNzaW9uLCBJIHRoaW5rLiBGb3IgdGhlIHNlY29uZCwgSSBuZWVkIHRv IGZpbmQgdGhlIGNvbnRleHQuIEZvciB0aGUgdGhpcmQgLS0gSSBtYXkgYWRkIGFuIGFwcGVuZGl4 IGlmIHdlIGdldCB0byBhIHZlcnNpb24gd2l0aCBubyBjb21tZW50cywgaWYgZm9sa3MgdGhpbmsg aXQncyB1c2VmdWwuDQoNCkkgZm9yd2FyZGVkIHlvdSB0aGUgY29udGV4dCBvZiB0aGUgcmVkaXJl Y3RzIHNlcGFyYXRlbHkuDQoNCk9uZSB0aGluZyB3ZSBzaG91bGQgZG8sIGFzIFJGQzY0MzQtYmlz IGlzIG5vdyBiZWluZyB3cmFwcGVkIHVwLCBpcyBhIHNhbml0eSBjaGVjayBvZiB0aGUgdHdvIGRv Y3VtZW50cyB0byBsb29rIGZvciBhbnkgY29uZmxpY3RzLiBXZSBkaWQgdGhpcyBhIGNvdXBsZSBv ZiB2ZXJzaW9ucyBhZ28gYW5kIG5vdGhpbmcgbWFqb3Igc3BydW5nIG91dCAoSSB0aGluayBJIGVt YWlsZWQgeW91IGEgY291cGxlLCB3aGljaCB3ZXJlIHJlc29sdmVkKSwgYnV0IGl0IHdvdWxkIGJl IHVzZWZ1bCB0byByZXBlYXQgdGhlIGV4ZXJjaXNlLiAgVGltIGFuZCBJIGFyZSBpbiB0aGUgcHJv Y2VzcyBvZiBhIC0gaG9wZWZ1bGx5IGZpbmFsIC0gNjQzNGJpcyB1cGRhdGUgaW4gdGhlIG5leHQg d2VlayBvciB0d28sIHNvIGl04oCZcyB0aW1lbHkuDQoNCkJlc3Qgd2lzaGVzLA0KVGlt From nobody Thu Jan 4 01:01:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5802212025C for ; Thu, 4 Jan 2018 01:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9zQFjvy7Fc-c for ; Thu, 4 Jan 2018 01:01:42 -0800 (PST) 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 52C65120227 for ; Thu, 4 Jan 2018 01:01:42 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id p139so1571847itb.1 for ; Thu, 04 Jan 2018 01:01:42 -0800 (PST) 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=RnB3T/2TncQflS4l9JhxDFQl8WB6QSy4bC6nTtdsfoI=; b=QL9qwN3Jtxskg2DVUsT4GmgohYPyUM7JWUdiegFIQmXLCMdGDpLR27H3b3zU4cDpaU SIjuH8cqLDPiTJ6aXPf1OvnEyQwVNiSwYcABJAZv2gDOTZvPYq+l55+Lf1IDdCmUmiFr Fi8BQ+0l7yxq+DI2FdQyvvGvmoTa8nuDeV/sNwMZp1Q6kLTGOUHGoA6NXICYR4SyCsfS iS9K5DLtA1QDawb6uX+H1Rfl2YJ1jYMnXyK5umBsHiT7TR7DN/FWXkNtjHz/opoUQuzx 9ASWJkQx1S0UdaDOl4FxAVZRTz5PoFaA+JvACkVQJnJ88XqZPYTh5jO4R0o61uOcqxNL D53Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=RnB3T/2TncQflS4l9JhxDFQl8WB6QSy4bC6nTtdsfoI=; b=f0hNYPc5rYIQHNAgK2guVzFVAUV4OVfzejXjcDj9hEo/gZJziW4cnXbswaNR1TJ1WJ rWSb3LF4GOSnss37dpKfyKnZMORP5cJsNs8u/PxetQAaLWQGqUyzZjJvKsO7lcxjk8l7 +h4Jc39JG4z+R2MUHhEyLNOFibvFy2RfqsKuhXRBUz2A8d81dDiZP6PeZstj/QRCDCwH XrgfExBW3Jety6G5J9zqntZsu8uebo1ottKP+mRGu1KIeMEvErUBENvoxNumdz8lZeVM f0/vYXLzGzXbRzCD5tO9TsKcB/bK56BJxxXADfplgB2VEy8HuTeha1pOXzZjTZeiNIn1 Wn/w== X-Gm-Message-State: AKGB3mJlncjwBFVrIR40Ga+QZYUeOHf05iL9V5tintL0IZSnmNLGUEwA AB+HOzasGf+kKKcqH7glXf+RK5tuB16bjEt9VoDdZQ== X-Google-Smtp-Source: ACJfBoux/8Mk95lWGLj1n16dBvfCMXhSocvvCNbotoD5btAb2jmqQtdCjg0SWSBsWC2B9sDv66UwQHeVK7UeocDzN7I= X-Received: by 10.36.81.149 with SMTP id s143mr5112332ita.144.1515056501263; Thu, 04 Jan 2018 01:01:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.176.204 with HTTP; Thu, 4 Jan 2018 01:01:20 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 4 Jan 2018 18:01:20 +0900 Message-ID: To: Fred Baker Cc: "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 04 Jan 2018 09:01:45 -0000 On Wed, Jan 3, 2018 at 5:34 AM, Fred Baker wrote: > The authors of draft-ietf-v6ops-ipv6rtr-reqs have just updated it. I wonder what we, as a working group, think of it? As the implementer of devices that are sometimes IPv6 routers, I object to the requirement that such devices MUST implement DHCPv6. The reason is that implementing DHCPv6 will degrade the user experience. See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html for an example of how that can happen. From nobody Thu Jan 4 11:22:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E2312D7E6; Thu, 4 Jan 2018 11:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 aRz2PrVn_-LD; Thu, 4 Jan 2018 11:22:37 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 AFFD8126CD8; Thu, 4 Jan 2018 11:22:34 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id q5so2173029oth.2; Thu, 04 Jan 2018 11:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:references:to:message-id; bh=qS0AKrfWWD41uLZR+RdjamIrYouKwixSJuWXSOZ9Yg4=; b=Gl6LEKiA8N2qzVv6Dsfy6WfTBb6+ehAK/nuQ02KnBZ2fFsII54aX8vnFj6TCoCAyZo 2MqlfduOdsUFLriKVboPuoHGFHfh0L3Y5Ae1kMuEzgCQDAZTTCciTHKAXoaZbZVVRA9v cHkrTSAmyuv732FC2yr4wFg1dE1DYkT+T07IKaV121VgapURX8i0isXHhKNfqxrMNo+t CHpdzy7tuP8hvL1/KgjEOjdPcwLBTQav7iB8JHMMBB+xgMP70Z9BYhMz/92fV6kM521c xruMu+mhfVP/RvtIUX3RQyMf5/iNfjAaBla4lFCjbnOHvV/5ooZ7pr+d54Jr9VSIm/ET v4Qg== 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:date:subject:references:to :message-id; bh=qS0AKrfWWD41uLZR+RdjamIrYouKwixSJuWXSOZ9Yg4=; b=Wb85StQzVmiHkXflOLf2ui95h/w9i2rw7Tfk0b+j/fsgU/aCqWkp33bYEqNzbetCRz YE6P2E4oO1oKxqqFYNMrxnASXdtktS5Swo/rYREONwzNG2Fpk9gY9Oa7DNO99Yu/YjXC 5wmrUijMkDwsJYlhujlblwz0rsUp+nLuBf9+MmymFzuNt9YKSA4pVB0IiZPlyzc/EzAF h/U34VakEwtja3xAN9Sea5NG/1igyqtxRVLzjE2Ivud2dUiepfmepSa6zlkAG6joBG31 vsX2AHmPwjrfYkp1/I0V+Y3JCLfJO8b+UscdA6ERwbFOptINWN8EXfE4tOqAbOMEPJ9P 6r/A== X-Gm-Message-State: AKwxytftv9Me0tlES09Bm4oBwN/TR9Q6FCJa6hlBiGkHcX8Q848OeVTr TWbFr8sYzJERWYndgIvgd25a78In X-Google-Smtp-Source: ACJfBovZzm4RaY1MF6APymRsO+ulxBNGxTmUvEjrLZ2h1FVQM9mcg/zaVYDE38RMq9zYSElI2CNTTg== X-Received: by 10.157.47.33 with SMTP id h30mr427935otb.49.1515093753775; Thu, 04 Jan 2018 11:22:33 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::100a? ([2600:8802:5600:f7a::100a]) by smtp.gmail.com with ESMTPSA id 33sm1822573otg.41.2018.01.04.11.22.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 11:22:32 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_F503210A-A5C1-4DA7-807A-CBB154F88188"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 4 Jan 2018 11:22:30 -0800 References: To: "v6ops@ietf.org WG" Message-Id: <272E5AE4-9879-48D1-BA9D-1046571BE257@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [v6ops] Fwd: [Rift] kicking off the charter discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jan 2018 19:22:40 -0000 --Apple-Mail=_F503210A-A5C1-4DA7-807A-CBB154F88188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Heads up to data center operators: you may find this interesting if you = run a CLOS-like or Fat Tree routing architecture. Discussion should be = on rift@ietf.org. https://tools.ietf.org/html/draft-przygienda-rift "RIFT: Routing in Fat Trees", Tony Przygienda, Alankar Sharma, John = Drake, Alia Atlas, 2017-10-28 > From: Alia Atlas > Subject: [Rift] kicking off the charter discussion > Date: January 4, 2018 at 11:03:18 AM PST > To: rift@ietf.org >=20 > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT = WG charters with Alvaro. Here is what we have so far. Comments and = improvements would be most welcome. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Routing in Fat Trees (RIFT) >=20 > Clos and Fat-Tree topologies have gained prominence in data center = networks as a result of a trend towards centralized data center network = architectures that may deliver computation and storage services. >=20 > The Routing in Fat Trees (RIFT) protocol addresses the demands of = routing in Clos and Fat-Tree networks via a mixture of both link-state = and distance-vector techniques colloquially described as 'link-state = towards the spine and distance vector towards the leafs'. RIFT uses = this hybrid approach to focus on networks with regular topologies with a = high degree of connectivity, a defined directionality, and large scale. >=20 > The RIFT Working Group will work on a standards track specification of = a specialized, dynamic routing protocol for Clos and fat-tree network = topologies. The protocol will: >=20 > - deal with automatic construction of fat-tree topologies based on = detection of links, > - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a sufficient = subset of links, > - support automatic disaggregation of prefixes on link and node = failures to prevent black-holing and suboptimal routing, > - allow traffic steering and re-routing policies, > - and provide mechanisms to synchronize a limited key-value data-store = that can be used after protocol convergence. >=20 > It is important that nodes participating in the protocol should need = only very light configuration and should be able to join a network as = leaf nodes simply by connecting to the network using default = configuration. >=20 > The protocol must support IPv6 and should also support IPv4. >=20 > The Working Group may establish additional requirements to constrain = and inform their work. >=20 > The RIFT Working Group is chartered for the following list of items: >=20 > - A Standards Track specification based on draft-przygienda-rift. The = document will include: >=20 > - an Implementation Status section as described in RFC 7942 > - an Operational Considerations section to explain how the protocol = is configured, deployed, and diagnosed > - Security and Privacy Considerations, although this material may = refer to a separate Threat Analysis document (q.v.). > - A YANG module focused on configuration of protocol instances > - An Applicability Statement that describes how to deploy and = configure the protocol in networks with different topologies > - A Security Threat Analysis document that describes the attack = vectors and mitigations that shall be sent for publication at the same = time as the protocol specification. >=20 > Milestones >=20 > Feb 2018 Adopt a protocol specification document > Feb 2019 Submit protocol specification to IESG for publication > Feb 2019 Submit Threat Analysis to IESG for publication > Apr 2019 Submit YANG module to IESG for publication > Apr 2019 Submit Applicability Statement to IESG for publication > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Thanks, >=20 > Alia >=20 > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift --Apple-Mail=_F503210A-A5C1-4DA7-807A-CBB154F88188 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpOfvYACgkQEhdRnd2G P+Di6w//bFqQIfIrBYIAdd+lSEAIad6MiJuWEbQq1ZJTAjanrK8IgjzYfqA7WW9R Fyn9lq+oO45fo8Q2ola7JzMIqpecm2VQPV79/YAEhHsat6ijE4yASPVT4uECITMm v4P8ObS9KZY8S+dXFvs8f9PGcj3h67U0RZHZblAuQTye7L4Q/WyuzJPK2E5Luw66 /tpjKdybMh7n4EuEA7dhFEDOJRhT28zLGwM+aLgIx1Pd/5gxlAiW2JoE991Dr1jG HHBi9z9oXPKOaSyhJp+Eqt2c+BP1DO3CrhrSe+I/X593lbMXbxOFhUqEZchDxc5b pIId3wWbSGbit1GS3cfyFhJ9YrTRTs/tIiDT7eEffP0qMjBfiCBJulWNdZk6G/R+ Tm0GWkoEV0yfezwstvTJGp6o79fBYrlT5dDXsnFT6uZSVwevgPVuWwtytoK1un+p PCY4Z/LOVTKvfgZ6uO14o4hCsDpe5sZ+tWpDpr1f8ycxUBJbEcHBRevk+KIY4ha5 fniUecTjQDWBUgweAanvHFzScOM+/G9Nn0UuspWU7g1Sa1Eeshk1H6uK2K/xGMto ju8ow+Qgc7rHTkd6t4sB5zbaQTTYibslPlcY/wcys5yrSJLg0i3Z4fns9D1UFExW zrgbsgA/7Qw6k77SOPqNcHTmhe3YA7Vik2SWfzUf9mDvuWdvg5c= =Wzsj -----END PGP SIGNATURE----- --Apple-Mail=_F503210A-A5C1-4DA7-807A-CBB154F88188-- From nobody Thu Jan 4 14:28:55 2018 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 51CF71242F5 for ; Thu, 4 Jan 2018 14:28:54 -0800 (PST) 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 ZqNi9U43SVk7 for ; Thu, 4 Jan 2018 14:28:52 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416751201FA for ; Thu, 4 Jan 2018 14:28:52 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id x199so1142346ywg.5 for ; Thu, 04 Jan 2018 14:28:52 -0800 (PST) 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:content-language :thread-index; bh=i9y0VgPgum0LZRlTsqktbVfH1U/YvVg+gejs/r0QHPQ=; b=loRrHhOpvQKbswDQW9paQ2wBWNzwyh07cKJUTOkUM1i3dbqII/dBrd3Mu/FVRR2g+p CHGPAktIjsdLpz3YXRHoxR7EJaXEcWajZeGW8bW2Yd/i3hf5uWRIn2pBaBY/f0G63z9r cf0BTqqq6RxML3sV9wqcCyK5YaLyJVpSxckdR8JM0ljkq5pmgParjwnuhRowZinqIS5v Nfr+eASkOxyFEHvnsoDtm6RJ30ei9TBhsl4ncINcnj3Fmo0IxfuQVuW+A0ZS+4MIiIXa HddSz7VEL8CIWsDQz+675D3BluozR8niuz1FSkT8IfHy9xSTH0KHb+RdRYOCEqa1unWX 3hVw== 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:content-language :thread-index; bh=i9y0VgPgum0LZRlTsqktbVfH1U/YvVg+gejs/r0QHPQ=; b=YUsOs3uBn8/CCfMmiasq3wLuzMnURa03E4IZ7yzitZCDz2L+GrMyF66eUfDJJtZftR skpZLJGpoLNPEJ7rzqf0nSrBgYNC8jVril9zafmmxTd8co3wUsHsyxV+ZJJFOnnqRZCH QFG+gOWzPWWsE6Nyjjrvbf8qdHKqF6u9kSWUWN/IZ/u+I6oSbfhR/WH3une0YApBWNaa eDEmMLDO1hY2oD9P4xyMQjDtChV8W9JHH2ElpIF6vf8QO7C3fG5d+jhQO8NytLK1y4dE lmoN++a7qX8PPIDSRvUhg4gpWw3+UTpDvwhGfJezfgON5S0vmGFXc5u1oH3/tXdbG/qG HH3Q== X-Gm-Message-State: AKGB3mLG+J6Zh09CZXEgIc90hXTRk8XJ+E0TpPF5fgzRkhIE/OkUHdDZ yX6+totbjGM+v0gypD1DjmM= X-Google-Smtp-Source: ACJfBot7lesALHrJwaRFva0GhDRfXZAFxcQ9KFODXcZE1x9Wm1nwqlLLqMzCusVUM+FaeB0LtnnI6Q== X-Received: by 10.13.246.1 with SMTP id g1mr1023464ywf.476.1515104931545; Thu, 04 Jan 2018 14:28:51 -0800 (PST) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id h67sm1845823ywd.101.2018.01.04.14.28.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 14:28:51 -0800 (PST) From: <7riw77@gmail.com> To: "'Lorenzo Colitti'" , "'Fred Baker'" Cc: References: In-Reply-To: Date: Thu, 4 Jan 2018 17:28:48 -0500 Message-ID: <066901d385ab$64d663b0$2e832b10$@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: AQJhq6FqXfQxKPsi9uY8X1ef5BV5bQJ9OQ9TojQVPZA= Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 04 Jan 2018 22:28:54 -0000 > As the implementer of devices that are sometimes IPv6 routers, I = object to the > requirement that such devices MUST implement DHCPv6. The reason is = that > implementing DHCPv6 will degrade the user experience. > See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html > for an example of how that can happen. Being required to implement DHCPv6 is far different than being required = to _turn it on by default_ -- the draft specifically does not require = DHCPv6 to be turned on by default for this very reason. To argue that = implementing something that may go haywire in a specific environment = should lead to it not being implemented would doom BGP, OSPF, IS-IS, = SLAAC... the list is almost endless. =F0=9F=98=8A /r From nobody Thu Jan 4 17:21:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049FB12785F for ; Thu, 4 Jan 2018 17:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 fVP9wLBm5Nr3 for ; Thu, 4 Jan 2018 17:21:11 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F8E1241F8 for ; Thu, 4 Jan 2018 17:21:11 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id i196so1415856pgd.0 for ; Thu, 04 Jan 2018 17:21:11 -0800 (PST) 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=Gn94InKKFKQOHRpa3Fs9EJCxoW9zUuJX3XwkdpCKPdQ=; b=V3Px8dLwCujOPmq+7dOY+AayVn3GR7g8KCGDSBDwx/c62PvdJu8eVBT1bzP3tuEPr4 k873agH9Znd2kn1BUNItTnfqkAg8unGfhxihpRk/17wZlodtNvFGeOjlwKBd4ZGGWfLI yEDa/xEscR0Cn3gFnuQfAv9hMoH7q24a6WgHxLKv4S3GQ0z4ufiM0mhsFkmBSOy1oDEn AQLkzyH47tefMDT2H+CyvTEgsarsB0joKwaKe4nUVcQhN/rNvgDwaEYokYwfZy3etXZO gb+up4Sx91nxcml6ybFpTALrnKiv6qH5yWQk6vJf33o1OFh0+LQrjo2fgbxtmuDhzWOK xKwg== 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=Gn94InKKFKQOHRpa3Fs9EJCxoW9zUuJX3XwkdpCKPdQ=; b=lwe2pXs9plnBNEOuiKJpTBGipSqOv+GLAnCTbn/FNBfnWURevfiFGufVghDT7LWNBR sBQh7YvkZ1A4wOJLAt3a9MUnvYf822kB/AqegiiGL9n4kmVl2P2K4k6l3ePKcjkQEtjK qt3RjiKtJrL3pZejru2x6SCDCpI3DtrQXkjBzIZHrYVtNIzL2F+Yc2s6iP8Sf9O11aCx VXSrcgrx9YFohufqUpW13A30nZzATPbPWATZAAi1cIryTiJvA/JdOJLpTzOLFwW2g/hh l5uQFgYgGYT5k4ZNW1CqIJxDbDlWHhL1NiBNkR51yXyByMf/FWrU7vP3HTPlQpP3yoz1 Pdkg== X-Gm-Message-State: AKGB3mIA31eF/oo9kHvTFzgwErrgC+gCQTCkMbd1rukwdNlsU/Z4i8YY H27FVwxEtdNfmUzPXr9Cniaq/A== X-Google-Smtp-Source: ACJfBosrpQBbPeV/ui8af+5wTClUUSbFdyLflvYfIkBFtJd8wR5AJKgRn0nuDBL0fITMwXw3Iq4IHA== X-Received: by 10.99.127.29 with SMTP id a29mr1096932pgd.3.1515115270415; Thu, 04 Jan 2018 17:21:10 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e9sm10557781pfl.138.2018.01.04.17.21.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 17:21:09 -0800 (PST) To: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <95b93f9e-f3f5-0ae3-289d-f82f2eacd45c@gmail.com> Date: Fri, 5 Jan 2018 14:21:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <066901d385ab$64d663b0$2e832b10$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Fri, 05 Jan 2018 01:21:13 -0000 On 05/01/2018 11:28, 7riw77@gmail.com wrote: > >> As the implementer of devices that are sometimes IPv6 routers, I object to the >> requirement that such devices MUST implement DHCPv6. The reason is that >> implementing DHCPv6 will degrade the user experience. >> See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html >> for an example of how that can happen. > > Being required to implement DHCPv6 is far different than being required to _turn it on by default_ -- the draft specifically does not require DHCPv6 to be turned on by default for this very reason. To argue that implementing something that may go haywire in a specific environment should lead to it not being implemented would doom BGP, OSPF, IS-IS, SLAAC... the list is almost endless. Given that some customers require DHCPv6, I can't imagine why any router vendor would be happy shipping a product that does not include DHCPv6 and/or DHCPv6 Relay. So in a sense the only thing that makes sense in the draft is to recommend the default status (on or off). "Off" seems reasonable. Brian From nobody Thu Jan 4 17:32:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A21241F8 for ; Thu, 4 Jan 2018 17:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_RP_MATCHES_RCVD=-0.01, 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 REIMl7s0UHIC for ; Thu, 4 Jan 2018 17:32:27 -0800 (PST) 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 36161120713 for ; Thu, 4 Jan 2018 17:32:27 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id d16so4489188itj.1 for ; Thu, 04 Jan 2018 17:32:27 -0800 (PST) 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=a+34V9m0Pu+OIzz0KPcYcVNmeQgv9lEwYhFhoGNP6m8=; b=cnlJCzw2uQRCnEYqfp2WMNfR+paX8kKk4KCLHgA1fxgbdrvsFDPRwqitx/RqXQTMnA fqnKMBxzrVVsbtyEqldbC5P8+n+W+FfZPe8D2ZhdMbRnKuz4MbBFh4ooQuk7mI6X5IvD hgPQ6futFQO0xd63gsRI7b+dzhFwUX28MOC/018a80WzdIUeN1HoAJd0ZkmfYdkoT4wD 9QsOXj41obbLIUFhmOW1g6j6ccGM71W3/wkVy/t4meLDX8Ppd2xeu1OiEE4qaulCY7Hh tQ1v0zBSxvgMNyBwnZ9PoXijl5o7+LUsV3qySfIhXij1KA6lRHukzDCq4LCKx8p0aQlO 6Qvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=a+34V9m0Pu+OIzz0KPcYcVNmeQgv9lEwYhFhoGNP6m8=; b=Mye2IM3r4GoFrkwTktcuH9V4OQQX69AZ5h46GNMY8mRSING4C+JMrnp4+xyPs331ce gE8kdTKLYwabnwOLxHHiTuiEs2f1RM7/2e5in8P7iHBgInd5z5AAnU42joeT0yPsWXr0 3oDmtnx7TT8yDJfdWWzq0CU6KpRHiRgV5HdH8i5hph0vAhndTB96dikpRFpmt4FF6ruV KYQOvc03QfdaUkWh+s2tZ0GQ/OZ8FHldv53ZNO8t/Fi4W+0DOXEw4H6ykbH8dAp3Q1g0 XDQF6Hwpmxgfy4TD7jElrFvXlppmII3ctX/kZlAekkikEZDqKMHlYEHTWgAAbKQXTno+ 7O+g== X-Gm-Message-State: AKGB3mJwD5h9hE5thXi5Cngec3Jo7tUqw9XVBMdhzRRd6zVcvJCzd9/w dWs0h+mdm1vxiDjrtln1xlMN/FwwTJ9ZKXZKBsiAzA== X-Google-Smtp-Source: ACJfBos83hzQMQ+dkMAT9Wh2Sxg5NNa9oHCB5CaLeo9ejdfvlnRUHWSgP8x7Dq9MwauNoPDpe9yemI/RjC1QybpM1Vg= X-Received: by 10.36.65.10 with SMTP id x10mr1635627ita.124.1515115946041; Thu, 04 Jan 2018 17:32:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.149.149 with HTTP; Thu, 4 Jan 2018 17:32:05 -0800 (PST) In-Reply-To: <066901d385ab$64d663b0$2e832b10$@gmail.com> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: Lorenzo Colitti Date: Fri, 5 Jan 2018 10:32:05 +0900 Message-ID: To: Russ White <7riw77@gmail.com> Cc: Fred Baker , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11c14ad2c29a510561fd6b03" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Fri, 05 Jan 2018 01:32:29 -0000 --001a11c14ad2c29a510561fd6b03 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 5, 2018 at 7:28 AM, <7riw77@gmail.com> wrote: > > > As the implementer of devices that are sometimes IPv6 routers, I object > to the > > requirement that such devices MUST implement DHCPv6. The reason is that > > implementing DHCPv6 will degrade the user experience. > > See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html > > for an example of how that can happen. > > Being required to implement DHCPv6 is far different than being required to > _turn it on by default_ -- the draft specifically does not require DHCPv6 > to be turned on by default for this very reason. Help me understand. Are you saying that mobile hotspots should implement DHCPv6 because this draft says so, but then never turn it on because it's bad for their users? --001a11c14ad2c29a510561fd6b03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 5, 2018 at 7:28 AM, <7riw77@gmail.com> wrote: > As the implementer of devices that are sometimes IPv6 routers, I objec= t to the
> requirement that such devices MUST implement DHCPv6. The reason is tha= t
> implementing DHCPv6 will degrade the user experience.
> See https://www.ietf.org/mail-= archive/web/v6ops/current/msg26286.html
> for an example of how that can happen.

Being required to implement DHCPv6 is far different than being requi= red to _turn it on by default_ -- the draft specifically does not require D= HCPv6 to be turned on by default for this very reason.
Help me understand. Are you saying that mobile hotspots should = implement DHCPv6 because this draft says so, but then never turn it on beca= use it's bad for their users?
--001a11c14ad2c29a510561fd6b03-- From nobody Thu Jan 4 18:01:38 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE76128C0A for ; Thu, 4 Jan 2018 18:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rbdVJ1E-pSLL for ; Thu, 4 Jan 2018 18:01:34 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 9F4711201F8 for ; Thu, 4 Jan 2018 18:01:34 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id o2so2180167plk.12 for ; Thu, 04 Jan 2018 18:01:34 -0800 (PST) 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=Q/7LRHJXibg0t8DzgZvqvknTPn5NK53ob+agZGccvpU=; b=CaLrzLKigDgPSwhQUP2HWcHKYFi1KdtV0VcCc6ClgJtf8L3BzjqDDD1pdcpP0aOiO5 8yzWcCIWPRN80C/e4DGVzuQRqjrKb884Lw/mFa3NDr9khGiy7ldswx0Z4DDUpdLJySIG zlOTQjOGHJ8OEWCS+Owp8djFCvXRJEFLAlhEJpzhEG3xqV/GRHLsCypZ1pI5WhO8sfag 3fbAAdqt12sc4D3ETYwMotz+kmr21mwcaApG9ns3OFFVjLhZbrID84WvDJpAoQKp2YgQ EjBorkHTzyR5qE5tVX5xnbSI/nTWMPfoyebQo4vUKswxS4AsP+et8DEtJMZXBZq3SfVa vcSQ== 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=Q/7LRHJXibg0t8DzgZvqvknTPn5NK53ob+agZGccvpU=; b=blBvHln+WwrMJTL2giBJb99mzbGHa/KEp6E9PcoB7RxLG1ADPop6A35rZPA+5w2Z5T y0tR5MkLXiBhs8Upq/cRGxYNkAr8AQ4V7R2qb5ucdMbPbKMkwKlIe/tla4qSAsmjXX+y 8YlPtHvroCFXR1SDxhB+GItbER5dBydF3Ua6DIck3aBW0JckzWlMkmEISDS4IkLghy0d AAMaUNAE4TNyXl5nrq15taPzHnZMLvmAKUI/AlCLuIzD+DysiC5OvWQssZGEI/0G4iiM A9ROPdcVb+SIGGsPuh2oVL1OrxSkEE1IGFgr+ju0xq8wPiLCJfy6j8mRk8VkrouGNYUy 6EPw== X-Gm-Message-State: AKGB3mJGgNhvALxiHdugbUg0CMcd8nSfe4bLpygXyVWnytrefnIpEzPY sVPePnxVbxFRcyGYqVEywvofvg== X-Google-Smtp-Source: ACJfBov9jrq8EczeZUlsQTTU4r0y4rCBohyGxtRSiAMcSK3f1j0kEySS2vF3Jz8Lyitt6aXqC3PA7A== X-Received: by 10.84.132.97 with SMTP id 88mr1428755ple.57.1515117693955; Thu, 04 Jan 2018 18:01:33 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g7sm8483183pfm.76.2018.01.04.18.01.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 18:01:33 -0800 (PST) To: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 5 Jan 2018 15:01:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] Discussion focus: draft-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: Fri, 05 Jan 2018 02:01:37 -0000 On 05/01/2018 14:32, Lorenzo Colitti wrote: > On Fri, Jan 5, 2018 at 7:28 AM, <7riw77@gmail.com> wrote: >> >>> As the implementer of devices that are sometimes IPv6 routers, I object >> to the >>> requirement that such devices MUST implement DHCPv6. The reason is that >>> implementing DHCPv6 will degrade the user experience. >>> See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html >>> for an example of how that can happen. >> >> Being required to implement DHCPv6 is far different than being required to >> _turn it on by default_ -- the draft specifically does not require DHCPv6 >> to be turned on by default for this very reason. > > > Help me understand. Are you saying that mobile hotspots should implement > DHCPv6 because this draft says so, but then never turn it on because it's > bad for their users? Lorenzo, are you saying that the requirements in this draft need to be scoped? That doesn't sound unreasonable, but if so, what would the scoping text look like? Rgds Brian From nobody Thu Jan 4 18:21:34 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D28D12D574 for ; Thu, 4 Jan 2018 18:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 M4DlohFrkEz0 for ; Thu, 4 Jan 2018 18:21:30 -0800 (PST) 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 EF0471271FD for ; Thu, 4 Jan 2018 18:21:29 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g70so4267229ioj.6 for ; Thu, 04 Jan 2018 18:21:29 -0800 (PST) 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=svoyzhEI+bsuQyBZKmCtLndVUV6cflgIURKejnQI/YU=; b=GtKLtBG+b+ZZ2EzRRsl73WTHO3uuQ7KMkkr+CeBoPf3PgUfL8UGFglIo9Yle851JQ1 kH1J1hSLpcSNmhCNECLhp7OReNdRoqV8WGBPVcwf00OEfHzeoAANleBdUh7uiQ5OL69r EDh1xKgiuFZndKaTcYI25HEAV/zze6wwOJds3T+eVWIQ3M1HKxS/vpEUeKy10YnaZ1EV JLPlsJf0FqR2ook5J4QiCJPsVT1QRHWeLQh5Qo1KEVp4GNj1Qe8j5iWUHpmIdPSFkmUV PI3PZnPUyoDyfbNf8tX5jhrJBh1G/6lbVr/R8yiTCgS+aXSgtb2xp7HBZOK2G0qHKc5D 4B0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=svoyzhEI+bsuQyBZKmCtLndVUV6cflgIURKejnQI/YU=; b=EWC3uxvF0IScnGa3kj8dTM6j9ASE+nAFDab7sWbOv0HQUWywO/yDcBG9+iy4odi7gx 3gpF6S3OudZ4xLqCvbmGZn4t/agkAWTd9rGggjwDi+6xuHq9DSA98p+ME1+cjeDLO3Y8 WZVspkrm/67g8jr3wctE5qHTIvYRW0H6wksTD3zHEKEiBFG6zx0pJ7pfsPpW+9kLt68I QNJ0d5Jl1pY4U0sJvGpH4SKs+PHOSqdTaLg5UN9A2BaPULy1r9UfG17wAP98gKQegU8h UzhbVEzFq0d9V7yUR6uJMNWYVLtIkEeArcSnQS/TroKRIWk0FcpzcBXctHOMkR49OFpz YG/g== X-Gm-Message-State: AKGB3mL4VkYxLUm2MJkf+bNVLka/mkvScVcnCOVGyNKpBz5neR4Thy6Q hcnRliNhEolnWifWq25cxPAJO9erEM3z3WxZo3iQVw== X-Google-Smtp-Source: ACJfBotepHhHIH4dauBvithXn9M/k6InWVkweIucn+q9gtv6Ip4wjl/Gw0F0Gf8qOrTrsDGNkU13Mw4YvGD088fdneQ= X-Received: by 10.107.17.32 with SMTP id z32mr1873636ioi.254.1515118888813; Thu, 04 Jan 2018 18:21:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.149.149 with HTTP; Thu, 4 Jan 2018 18:21:08 -0800 (PST) In-Reply-To: References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: Lorenzo Colitti Date: Fri, 5 Jan 2018 11:21:08 +0900 Message-ID: To: Brian E Carpenter Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113f267629c1130561fe1bb2" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Fri, 05 Jan 2018 02:21:32 -0000 --001a113f267629c1130561fe1bb2 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Help me understand. Are you saying that mobile hotspots should implement > > DHCPv6 because this draft says so, but then never turn it on because it's > > bad for their users? > > Lorenzo, are you saying that the requirements in this draft need to be > scoped? That doesn't sound unreasonable, but if so, what would the > scoping text look like? > Yes, I think that's the problem. The document takes a bit of a one-size-fits all approach. You also don't need netconf/yang/syslog on a mobile hotspot. Nor does it make sense to say "the I2RS interface to the RIB be supported" on a home router that has one default route and two directly-connected subnets. You probably also don't need DHCPv6 or RAs on a backbone router that's primarily intended as an LSR or segment router. IETF standards are about interoperability, they are not shopping lists. (For an example of a document that suffered from this problem to a much greater degree, see RFC 7849, which was taken out of the WG and published as individual submission.) Not sure how best to address this. A couple of options that come to mind are: 1. Removing the parts of the draft that are essentially a device profile ("routers must support X, Y and Z"). 2. Changing the aforementioned parts of the draft so that instead of saying "routers must support X" they say "if routers support X, they must support RFCs A, B, and C". An example is section 3.1. Instead of saying "routers must support DHCPv6, SLAAC, first-hop router selection, etc." it could say "if routers are intended to act as first-hop routers for hosts, they must support...", and "if routers are intended to be operator-configurable, then they must allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084 does - it defines a basic profile that everything must support, and then consists of a large number of statements along the lines of "if the CE router supports X, then it must do A, B, and C". 3. Defining a number of device profiles that have mandatory requirements. This risks turning the document into a number of shopping lists, but perhaps those will be easier to get consensus on. Cheers, Lorenzo --001a113f267629c1130561fe1bb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> Help m= e understand. Are you saying that mobile hotspots should implement
> DHCPv6 because this draft says so, but then never turn it on because i= t's
> bad for their users?

Lorenzo, are you saying that the requirements in this draft nee= d to be
scoped? That doesn't sound unreasonable, but if so, what would the
scoping text look like?

Yes, I think th= at's the problem. The document takes a bit of a one-size-fits all appro= ach. You also don't need netconf/yang/syslog on a mobile hotspot. Nor d= oes it make sense to say "the I2RS interface to the RIB be supported&q= uot; on a home router that has one default route and two directly-connected= subnets. You probably also don't need DHCPv6 or RAs on a backbone rout= er that's primarily intended as an LSR or segment router.
IETF standards are about interoperability, they are not shoppin= g lists. (For an example of a document that suffered from this problem to a= much greater degree, see RFC 7849, which was taken out of the WG and publi= shed as individual submission.)

Not sure how b= est to address this. A couple of options that come to mind are:
<= ol>
  • Removing the parts of the draft that are essentially a device profil= e ("routers must support X, Y and Z").
  • Changing the a= forementioned parts of the draft so that instead of saying "routers mu= st support X" they say "if routers support X, they must support R= FCs A, B, and C". An example is section 3.1. Instead of saying "r= outers must support DHCPv6, SLAAC, first-hop router selection, etc." i= t could say "if routers are intended to act as first-hop routers for h= osts, they must support...", and "if routers are intended to be o= perator-configurable, then they must allow disabling SLAAC and enabling DHC= Pv6". This is what RFC 7084 does - it defines a basic profile that eve= rything must support, and then consists of a large number of statements alo= ng the lines of "if the CE router supports X, then it must do A, B, an= d C".
  • Defining a number of device profiles that have mandatory= requirements. This risks turning the document into a number of shopping li= sts, but perhaps those will be easier to get consensus on.
    • Ch= eers,
    Lorenzo
    --001a113f267629c1130561fe1bb2-- From nobody Thu Jan 4 23:42:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A557E126BF3 for ; Thu, 4 Jan 2018 23:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 j51YePQ5CVdn for ; Thu, 4 Jan 2018 23:42:25 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 0BC9D127136 for ; Thu, 4 Jan 2018 23:42:22 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id t81so2616688oih.13 for ; Thu, 04 Jan 2018 23:42:22 -0800 (PST) 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=AR+WVI2DRw2PgEM/5NQKa65zus0y1XldXnkRDcGjKOQ=; b=B+YPh0sHoIOIJX0+f+oqZ96+Pq7sfD4uQRgcXs7FW4b7SKBKj2paeBHiaRYqVWRXeW TOLbP3Rr0XYvGBvNT6Nty2PcdkFqmwaIx6AKxX40XXWkq1FbDgQB89PDtlT8Z8Fe++Es D5lGglx7mLIYHvpH47XQuZQU96tBXth6FQ4u7jDX7gjzXtdQ04IhUX2ObO2ErRZ6ZIff Q1/a+dtTEHQXOR+AMLq9uks7lS2p10qlx5ZKCn4PBUL46q5OcLXb7wVTor1p/wp2UoVZ C5c5ViS2MxZB12EOqjvXZQMywDVm1Qvi3Mbq+SAIep1md1ZLDaNQElrDMtwhx22cZI6P 4R9Q== 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=AR+WVI2DRw2PgEM/5NQKa65zus0y1XldXnkRDcGjKOQ=; b=bWwQw4tmgN0zlYlsF8KjwjnDaLB5oeUWb6iXNNdseNWZOirlD6FCKudLV3ya77e8z3 VriYqWwoCyKKKiDn5W2PMVSR/pyB2ruvzy/kiNI4iu3nGNZT7/ngwNi2DcSW4Mz/yR23 v6bNGSM2w4bDfXRKyHiSgWEfzYLx6U6Vd5oYOcLLHDeh4N7qRG0h619E2O93BkehJc21 xlL7uhMLmcX15sHCXLax24kGSIWmx7Jy1gbhAtmSVtDgtVEDspCQ64eqVaEGZYvabmZl w68LFxsgRebzkGWW+3tLj69VMQcdsldNF23/Nmr8tdl/rRIy5QucgaZtlcGqpP3vmrbK Jzpg== X-Gm-Message-State: AKGB3mKfuuzcI1Y4PmpuxXh7/onBCkGeKMJ23ZGy9goqoK2iUwZWHd8b Lji9hvTfq3brefDRTOAZKIAmh70N X-Google-Smtp-Source: ACJfBotw6x6/bPEarkXSGlYnH6nVkkUIdFtEGeKyh8iG5NEe5TPGZ34wkRb1UcvXYKKMYBBN5L3jqw== X-Received: by 10.202.229.11 with SMTP id c11mr1098475oih.16.1515138142046; Thu, 04 Jan 2018 23:42:22 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::1006? ([2600:8802:5600:f7a::1006]) by smtp.gmail.com with ESMTPSA id 44sm2445290ote.68.2018.01.04.23.42.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 23:42:20 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6291D92D-3B96-4244-AB50-34C9C5D085F0 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPad Mail (15C153) In-Reply-To: Date: Thu, 4 Jan 2018 23:42:18 -0800 Cc: Brian E Carpenter , "v6ops@ietf.org WG" Content-Transfer-Encoding: 7bit Message-Id: <66076429-6BFD-49C1-90E8-1585502857CA@gmail.com> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> To: Lorenzo Colitti Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Fri, 05 Jan 2018 07:42:29 -0000 --Apple-Mail-6291D92D-3B96-4244-AB50-34C9C5D085F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I suspect that there are at least two levels of requirements. If you look ve= ry hard at 1122/1123/1812, they don=E2=80=99t require that something be turn= ed on; they require that the code do something specific when turned on. It m= ust be possible for the network to deploy a certain thing. If the network do= esn=E2=80=99t choose to, that=E2=80=99s on the network, not the implementati= on. But if the network wants to implement, oh I dunno avian carriers perhaps= , and the products don=E2=80=99t support it, that=E2=80=99s a problem. Sent from my iPad > On Jan 4, 2018, at 6:21 PM, Lorenzo Colitti wrote: >=20 >> On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter wrote: >> > Help me understand. Are you saying that mobile hotspots should implemen= t >> > DHCPv6 because this draft says so, but then never turn it on because it= 's >> > bad for their users? >>=20 >> Lorenzo, are you saying that the requirements in this draft need to be >> scoped? That doesn't sound unreasonable, but if so, what would the >> scoping text look like? >=20 > Yes, I think that's the problem. The document takes a bit of a one-size-fi= ts all approach. You also don't need netconf/yang/syslog on a mobile hotspot= . Nor does it make sense to say "the I2RS interface to the RIB be supported"= on a home router that has one default route and two directly-connected subn= ets. You probably also don't need DHCPv6 or RAs on a backbone router that's p= rimarily intended as an LSR or segment router. >=20 > IETF standards are about interoperability, they are not shopping lists. (Fo= r an example of a document that suffered from this problem to a much greater= degree, see RFC 7849, which was taken out of the WG and published as indivi= dual submission.) >=20 > Not sure how best to address this. A couple of options that come to mind a= re: > Removing the parts of the draft that are essentially a device profile ("ro= uters must support X, Y and Z"). > Changing the aforementioned parts of the draft so that instead of saying "= routers must support X" they say "if routers support X, they must support RFC= s A, B, and C". An example is section 3.1. Instead of saying "routers must s= upport DHCPv6, SLAAC, first-hop router selection, etc." it could say "if rou= ters are intended to act as first-hop routers for hosts, they must support..= .", and "if routers are intended to be operator-configurable, then they must= allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084 does - it= defines a basic profile that everything must support, and then consists of a= large number of statements along the lines of "if the CE router supports X,= then it must do A, B, and C". > Defining a number of device profiles that have mandatory requirements. Thi= s risks turning the document into a number of shopping lists, but perhaps th= ose will be easier to get consensus on. > Cheers, > Lorenzo > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-6291D92D-3B96-4244-AB50-34C9C5D085F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I suspect that there are at least two level= s of requirements. If you look very hard at 1122/1123/1812, they don=E2=80=99= t require that something be turned on; they require that the code do somethi= ng specific when turned on. It must be possible for the network to deploy a c= ertain thing. If the network doesn=E2=80=99t choose to, that=E2=80=99s on th= e network, not the implementation. But if the network wants to implement, oh= I dunno avian carriers perhaps, and the products don=E2=80=99t support it, t= hat=E2=80=99s a problem.

    Sent from my i= Pad

    On Jan 4, 2018, at 6:21 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

    <= blockquote type=3D"cite">
    On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter <= span dir=3D"ltr"><brian.e.carpenter@gmail.com> wrote:
    > Help me understand. Are you saying that mobile hotspots shoul= d implement
    > DHCPv6 because this draft says so, but then never turn it on because it= 's
    > bad for their users?

    Lorenzo, are you saying that the requirements in this draft need= to be
    scoped? That doesn't sound unreasonable, but if so, what would the
    scoping text look like?

    Yes, I think tha= t's the problem. The document takes a bit of a one-size-fits all approach. Y= ou also don't need netconf/yang/syslog on a mobile hotspot. Nor does it make= sense to say "the I2RS interface to the RIB be supported" on a home router t= hat has one default route and two directly-connected subnets. You probably a= lso don't need DHCPv6 or RAs on a backbone router that's primarily intended a= s an LSR or segment router.

    IETF standards are abou= t interoperability, they are not shopping lists. (For an example of a docume= nt that suffered from this problem to a much greater degree, see RFC 7849, w= hich was taken out of the WG and published as individual submission.)

    Not sure how best to address this. A couple of option= s that come to mind are:
    1. Removing the parts of the draft t= hat are essentially a device profile ("routers must support X, Y and Z").
    2. Changing the aforementioned parts of the draft so that instead of s= aying "routers must support X" they say "if routers support X, they must sup= port RFCs A, B, and C". An example is section 3.1. Instead of saying "router= s must support DHCPv6, SLAAC, first-hop router selection, etc." it could say= "if routers are intended to act as first-hop routers for hosts, they must s= upport...", and "if routers are intended to be operator-configurable, then t= hey must allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084 d= oes - it defines a basic profile that everything must support, and then cons= ists of a large number of statements along the lines of "if the CE router su= pports X, then it must do A, B, and C".
    3. Defining a number of device p= rofiles that have mandatory requirements. This risks turning the document in= to a number of shopping lists, but perhaps those will be easier to get conse= nsus on.
    Cheers,
    Lorenzo
    ____________________= ___________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mai= lman/listinfo/v6ops
    = --Apple-Mail-6291D92D-3B96-4244-AB50-34C9C5D085F0-- From nobody Fri Jan 5 05:41:18 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59C12D775 for ; Fri, 5 Jan 2018 05:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXUVgMr_fQiF for ; Fri, 5 Jan 2018 05:41:15 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6353C124319 for ; Fri, 5 Jan 2018 05:41:15 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 9AAF360B for ; Fri, 5 Jan 2018 13:41:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-neDhH1BYlV for ; Fri, 5 Jan 2018 07:41:14 -0600 (CST) Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 41D8E57A for ; Fri, 5 Jan 2018 07:41:14 -0600 (CST) Received: by mail-lf0-f71.google.com with SMTP id t200so990530lff.18 for ; Fri, 05 Jan 2018 05:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yWD2JTQjYPhTXHDqNV4C/zzuUdnL1ke3nV8+kpscM4o=; b=WRmIkLssZ8T6QoEV90Zp4kfC9fVT7kSpYcB/kOcN+oJWlroCw9c48mSFHvHGs4QvTp 6GaE4LiGNslanQ6skZB4zO0SV0h48RGgoqkVd0xOO9QRIb+XA2mo+fjgU1IOVfkuyCw6 dF4UPyGsicR3aA5p2GgARAeo2JGuJrHbnafyjpQ60aaklnQ548Q9Ni41omWU5qmPFKkR 1Csggc+V86fVW7vMITO3Zj1cLepOVCa2RqV/07iH/csXAgrAXLiiwQ6yGC8QK63o89Yu T8AZL76lzKjZMcmD2+E5zVWVyNxD0Z9wQLqYGkQ29s8NRWeNu5lUNhl1T43H3ojJ9k99 rTdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=yWD2JTQjYPhTXHDqNV4C/zzuUdnL1ke3nV8+kpscM4o=; b=IucFwsr1hudl88Myr5FJ1KEIQlsHNN7D+0G0vVQuLv/aDetJ0vV1dTXDR1tLeOWOWU YH5GlGjJKbN+P6D5iRz11+HIbEj/ZTLFlh3R7yxz3kVJkByLRgN5lyk73xaVb714e1y6 JLze5KwBf91Idb0f9Ej5WILEfpH/Tq/5NNyCZQeUb5lZCoQNL6aWkevGPK1iinjR2/0R wrYyAd/xDDiVtDBOEFeYO68zXX6Am0DUyz3++pgFQzenQFSbTfM3itC3i1qFWcsZ/j+F DXww2eRJSuZkgIxzpKYURBjzoyvmK5YnlNLzuO/ofp8e22vThKfe/0wGf4ECa+OiQcny HqQw== X-Gm-Message-State: AKGB3mK28p30REjS6Rl3AQxvHjVwTTz4dbjKgwzMCkV87q7kzILgLVqb VuTOFQhJbT/6hyZouCgCtCQ5K/a6Sd+4KMLbGJyAd7i6jJhVHzXiaPMTpTXKo1EV6lYmkqbL/ur bgpRyBtARarCut5b6OXjbG48ibw== X-Received: by 10.46.95.148 with SMTP id x20mr1768089lje.133.1515159672616; Fri, 05 Jan 2018 05:41:12 -0800 (PST) X-Google-Smtp-Source: ACJfBouSRG5UmauwxcNqh97VvE6fTvD3Xwue5sppbD+94p6gkAZMen3Rz0VyEur2xkXowdZG4ZQiZ94+Z/NPu6JbLbE= X-Received: by 10.46.95.148 with SMTP id x20mr1768084lje.133.1515159672412; Fri, 05 Jan 2018 05:41:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.74 with HTTP; Fri, 5 Jan 2018 05:41:11 -0800 (PST) In-Reply-To: References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: David Farmer Date: Fri, 5 Jan 2018 07:41:11 -0600 Message-ID: To: Brian E Carpenter Cc: V6 Ops List Content-Type: multipart/alternative; boundary="001a114a55f60d6db70562079a17" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Fri, 05 Jan 2018 13:41:17 -0000 --001a114a55f60d6db70562079a17 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 4, 2018 at 8:01 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05/01/2018 14:32, Lorenzo Colitti wrote: > > On Fri, Jan 5, 2018 at 7:28 AM, <7riw77@gmail.com> wrote: > >> > >>> As the implementer of devices that are sometimes IPv6 routers, I object > >> to the > >>> requirement that such devices MUST implement DHCPv6. The reason is that > >>> implementing DHCPv6 will degrade the user experience. > >>> See https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html > >>> for an example of how that can happen. > >> > >> Being required to implement DHCPv6 is far different than being required > to > >> _turn it on by default_ -- the draft specifically does not require > DHCPv6 > >> to be turned on by default for this very reason. > > > > > > Help me understand. Are you saying that mobile hotspots should implement > > DHCPv6 because this draft says so, but then never turn it on because it's > > bad for their users? > > Lorenzo, are you saying that the requirements in this draft need to be > scoped? That doesn't sound unreasonable, but if so, what would the > scoping text look like? > While not specifically or plainly stated in the document, I remember from early discussion of this document that this was intended to be focused on enterprise and/or carrier grade routers and not CPE or consumer grade routers, in fact we already have documents for CPE IPv6 routers (RFC7084). I think this is supported by the fact that this document discusses subjects like MPLS, YANG, etc... Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114a55f60d6db70562079a17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Thu, Jan 4, 2018 at 8:01 PM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
    On 05/01/2018 14:32, Lorenzo Colitti wrote:
    > On Fri, Jan 5, 2018 at 7:28 AM, <7riw77@gmail.com> wrote:
    >>
    >>> As the implementer of devices that are sometimes IPv6 routers,= I object
    >> to the
    >>> requirement that such devices MUST implement DHCPv6. The reaso= n is that
    >>> implementing DHCPv6 will degrade the user experience.
    >>> See https://www.ietf.o= rg/mail-archive/web/v6ops/current/msg26286.html
    >>> for an example of how that can happen.
    >>
    >> Being required to implement DHCPv6 is far different than being req= uired to
    >> _turn it on by default_ -- the draft specifically does not require= DHCPv6
    >> to be turned on by default for this very reason.
    >
    >
    > Help me understand. Are you saying that mobile hotspots should impleme= nt
    > DHCPv6 because this draft says so, but then never turn it on because i= t's
    > bad for their users?

    Lorenzo, are you saying that the requirements in this draft need to be
    scoped? That doesn't sound unreasonable, but if so, what would the
    scoping text look like?

    While not speci= fically or plainly stated in the document, I remember from early discussion= of this document that this was intended to be focused on enterprise and/or= carrier grade routers and not CPE or consumer grade routers, in fact we al= ready have documents for CPE IPv6 routers (RFC7084).=C2=A0 I think this is = supported by the fact that this document discusses subjects like MPLS, YANG= , etc...

    Thanks.

    --
    =
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Telecommunication Service= s
    Office of Information Technology
    University of Minnesota=C2=A0=C2= =A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-08= 15
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --001a114a55f60d6db70562079a17-- From nobody Fri Jan 5 08:35:05 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB161274D2 for ; Fri, 5 Jan 2018 08:35:04 -0800 (PST) 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, 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 exIeKJCpMDDr for ; Fri, 5 Jan 2018 08:35:01 -0800 (PST) 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 312DC1205D3 for ; Fri, 5 Jan 2018 08:35:01 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w05GWoDi025445 for ; Fri, 5 Jan 2018 16:35:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : references : from : to : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=ccdlXiK129IuXu/i9wjcAjnhqKckd/JL0R4t70S4528=; b=JMXXv6EpfeiC4dH2OeBaiyTP2llD54xL6aTXCLX6y7/WXanDQBVZNBMtZclao94DE4oh KJufMMrO6MZFKPfg6wlbw8UI9OLwU1kour4zU0WWi/pa4kCKPstspu3LDIsZrPVZX8oV 2dgo2+F5wr3i8Piuru8HG+4N/AIdaDTn0MU0LvpZlsLXV9h5YaafoFknr0BpD4FMc3vd FOWHs98LmJoFCTvkjesn8nEOYqE7+IeWFpQSzA57sihTOKrvHeJq54SRwlrSBgeXyJGT DEDqeo2EOBMHQO4ggFWhHVhaMtQ9C9CEINuQv9gcBxr4GCBOSdeAVDYMmuUIEX7dCRX2 1g== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2f62x9960v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 05 Jan 2018 16:35:00 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w05GXmcp022654 for ; Fri, 5 Jan 2018 11:35:00 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2f95dex3ej-1 for ; Fri, 05 Jan 2018 11:34:59 -0500 Received: from [172.28.11.215] (padesk.kendall.corp.akamai.com [172.28.11.215]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id AF17F20069 for ; Fri, 5 Jan 2018 09:34:59 -0700 (MST) References: <151491899410.22628.14408666128226236605@ietfa.amsl.com> <09b101d383fa$dd6fca30$984f5e90$@gmail.com> From: Pablo Alvarez To: v6ops@ietf.org Message-ID: Date: Fri, 5 Jan 2018 11:34:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <09b101d383fa$dd6fca30$984f5e90$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=12 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801050232 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=12 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801050233 Archived-At: Subject: Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs-01.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: Fri, 05 Jan 2018 16:35:04 -0000 Comments on section 5.4 ICMP Considerations 1. Thanks for adding the new text in the fifth bullet ("SHOULD NOT filter Destination Unreachable or Packet..."). It was intended to clarify and supersede the text in the first bullet ("SHOULD NOT filter ICMP unreachables..."), so I do not think the first bullet is needed any longer. 2. I believe the statement in the second bullet ("SHOULD filter ICMP echo and echo response by default, to prevent the discovery of reachable hosts and topology") is too strong. There are valid business and research reasons to discover reachable hosts and topology. I understand that obscurity is a valid security layer. However, it is not clear to me that the security risks of that discovery or of ICMP based attacks are high enough that we should recommend ICMP filtering by default. Moreover, the text does not specify whether the filtering refers to all echo and echo reply packets traversing the router (which I believe would clearly be excessive) or only those intended for the router (which I still would argue is too strong). I propose the following. By default: - ICMP echo request/reply packets not intended for the router should be forwarded like any other packet - ICMP echo request packets directed at the router should be rate-limited to protect the router CPU (in a similar way to the error packet generation described in the third bullet point). - I have no strong opinion on ICMP echo reply packets directed at the router. Pinging from a router can be a useful tool so we want to be able to see those. Maybe blocking them by default unless the ping tool is in use would work, but that adds complexity. Pablo Alvarez On 01/02/18 13:52, 7riw77@gmail.com wrote: > >> 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 : Requirements for IPv6 Routers > > I've addressed all of the comments I had notes for except -- > > - Should PVD be included? > - Add a redirects section -- I don't remember what this was in reference to. > - The suggestion for an appendix containing a plain list of the requirements. > > The first needs on list discussion, I think. For the second, I need to find the context. For the third -- I may add an appendix if we get to a version with no comments, if folks think it's useful. > > 😊 /r > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jan 9 03:53:26 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05398126DEE for ; Tue, 9 Jan 2018 03:53:25 -0800 (PST) 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 3CSR1P5MX8AJ for ; Tue, 9 Jan 2018 03:53:23 -0800 (PST) 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 C171C1200FC for ; Tue, 9 Jan 2018 03:53:22 -0800 (PST) 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 w09BrK63037542 for ; Tue, 9 Jan 2018 12:53:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C282E2050C4 for ; Tue, 9 Jan 2018 12:53:20 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B85202030B8 for ; Tue, 9 Jan 2018 12:53:20 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09BrKVw003306 for ; Tue, 9 Jan 2018 12:53:20 +0100 To: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 9 Jan 2018 12:53:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] Discussion focus: draft-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, 09 Jan 2018 11:53:25 -0000 Le 05/01/2018 à 03:21, Lorenzo Colitti a écrit : > On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter > > wrote: > > > Help me understand. Are you saying that mobile hotspots should > implement > > DHCPv6 because this draft says so, but then never turn it on > because it's > > bad for their users? > > Lorenzo, are you saying that the requirements in this draft need to be > scoped? That doesn't sound unreasonable, but if so, what would the > scoping text look like? > > > Yes, I think that's the problem. The document takes a bit of a > one-size-fits all approach. I think I agree with identifying such a problem of trying to be a one-size-fits-all document. But in defence of it, I think there _are_ some requirements that all routers must implement regardless of being just a smartphone, a CPE or a big router. E.g. MUST work on arbitrary prefix lengths (RFC7608), MUST respond to RS (why is RFC4861 absent from ipv6rtr-reqs and why RFC4861 does not make this a MUST?), MUST join all-routers group (no RFC?), etc. Again: a router MUST respond to RS, please. Those who dont please tell why. > You also don't need netconf/yang/syslog on a > mobile hotspot. That could be a recommendation, instead of a requirement. Mobile hotspots do need to be configured somehow and these netwconf/yang/syslog are coomonly agreed tools that are good recommendations. > Nor does it make sense to say "the I2RS interface to the > RIB be supported" on a home router that has one default route and two > directly-connected subnets. Agreed. > You probably also don't need DHCPv6 or RAs > on a backbone router that's primarily intended as an LSR or segment router. I can agree about not needing DHCPv6 between backbone routers, but I think RAs are mandatory even there for things like MTU or similar. > IETF standards are about interoperability, they are not shopping lists. > (For an example of a document that suffered from this problem to a much > greater degree, see RFC 7849, which was taken out of the WG and > published as individual submission.) > > Not sure how best to address this. A couple of options that come to mind > are: > > 1. Removing the parts of the draft that are essentially a device > profile ("routers must support X, Y and Z"). > 2. Changing the aforementioned parts of the draft so that instead of > saying "routers must support X" they say "if routers support X, they > must support RFCs A, B, and C". An example is section 3.1. Instead > of saying "routers must support DHCPv6, SLAAC, first-hop router > selection, etc." it could say "if routers are intended to act as > first-hop routers for hosts, they must support...", and "if routers > are intended to be operator-configurable, then they must allow > disabling SLAAC and enabling DHCPv6". This is what RFC 7084 does - > it defines a basic profile that everything must support, and then > consists of a large number of statements along the lines of "if the > CE router supports X, then it must do A, B, and C". > 3. Defining a number of device profiles that have mandatory > requirements. This risks turning the document into a number of > shopping lists, but perhaps those will be easier to get consensus on. 0. Select the requirements that are mandatory in all routers including mobile hotspots and CPEs and state them at the beginning. Alex > > Cheers, > Lorenzo > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jan 9 03:59:11 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DC9127337 for ; Tue, 9 Jan 2018 03:59:10 -0800 (PST) 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 1CU1vG6m061R for ; Tue, 9 Jan 2018 03:59:09 -0800 (PST) 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 539D4126DEE for ; Tue, 9 Jan 2018 03:59:09 -0800 (PST) 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 w09Bx7m5047708 for ; Tue, 9 Jan 2018 12:59:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 045312050E3 for ; Tue, 9 Jan 2018 12:59:07 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E59042050C8 for ; Tue, 9 Jan 2018 12:59:06 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09Bx6dC008337 for ; Tue, 9 Jan 2018 12:59:06 +0100 To: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> From: Alexandre Petrescu Message-ID: <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> Date: Tue, 9 Jan 2018 12:59:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] Discussion focus: draft-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, 09 Jan 2018 11:59:11 -0000 Le 05/01/2018 à 02:32, Lorenzo Colitti a écrit : > On Fri, Jan 5, 2018 at 7:28 AM, <7riw77@gmail.com > > wrote: > >> As the implementer of devices that are sometimes IPv6 routers, I >> object to the requirement that such devices MUST implement DHCPv6. >> The reason is that implementing DHCPv6 will degrade the user >> experience. See >> https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html > >> for an example of how that can happen. > > Being required to implement DHCPv6 is far different than being > required to _turn it on by default_ -- the draft specifically does > not require DHCPv6 to be turned on by default for this very reason. > > > Help me understand. Are you saying that mobile hotspots should > implement DHCPv6 because this draft says so, but then never turn it > on because it's bad for their users? On my side I think this: mobile hotspots MUST implement and turn on DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot. (I am saying "DHCPv6 PD", not DHCPv6 overall; i.e. a mobile hotspot MUST implement and turn on DHCPv6 PD, _and_ MUST NOT necessarily implement DHCPv6 IA_NA nor MUST it turn on DHCPv6 IA_NA). Alex From nobody Tue Jan 9 04:07:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066B0127369 for ; Tue, 9 Jan 2018 04:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkGjmo-QkmSt for ; Tue, 9 Jan 2018 04:07:03 -0800 (PST) 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 0925D126DEE for ; Tue, 9 Jan 2018 04:07:02 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 898CC423DD for ; Tue, 9 Jan 2018 13:07:00 +0100 (CET) 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 7B80041B8A; Tue, 9 Jan 2018 13:07:00 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 6CC1D6D8FD; Tue, 9 Jan 2018 13:07:00 +0100 (CET) Date: Tue, 9 Jan 2018 13:07:00 +0100 From: Gert Doering To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20180109120700.GW45648@Space.Net> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:07:05 -0000 Hi, On Tue, Jan 09, 2018 at 12:59:06PM +0100, Alexandre Petrescu wrote: > On my side I think this: mobile hotspots MUST implement and turn on > DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot. Uh... "no"? 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 Tue Jan 9 04:15:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A4B127342 for ; Tue, 9 Jan 2018 04:15:13 -0800 (PST) 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 JQU1QIdnVebi for ; Tue, 9 Jan 2018 04:15:11 -0800 (PST) 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 4477D126DEE for ; Tue, 9 Jan 2018 04:15:11 -0800 (PST) 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 w09CF9jt052635; Tue, 9 Jan 2018 13:15:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 60934205134; Tue, 9 Jan 2018 13:15:09 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 49FE2204F18; Tue, 9 Jan 2018 13:15:09 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09CF9OZ025424; Tue, 9 Jan 2018 13:15:09 +0100 To: Gert Doering Cc: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> From: Alexandre Petrescu Message-ID: <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> Date: Tue, 9 Jan 2018 13:15:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180109120700.GW45648@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:15:13 -0000 Le 09/01/2018 à 13:07, Gert Doering a écrit : > Hi, > > On Tue, Jan 09, 2018 at 12:59:06PM +0100, Alexandre Petrescu wrote: >> On my side I think this: mobile hotspots MUST implement and turn on >> DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot. > > Uh... "no"? the most scalable, most secure, most path-efficient, most DNS friendly... most recommendable (the others are not that good in some of these respects) Alex > > Gert Doering > -- NetMaster > From nobody Tue Jan 9 04:16:59 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3221275AB for ; Tue, 9 Jan 2018 04:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_bdnCAXcAZv for ; Tue, 9 Jan 2018 04:16:56 -0800 (PST) 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 368E1127342 for ; Tue, 9 Jan 2018 04:16:56 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D020B44134 for ; Tue, 9 Jan 2018 13:16:54 +0100 (CET) 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 C089844130; Tue, 9 Jan 2018 13:16:54 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id B58E16D962; Tue, 9 Jan 2018 13:16:54 +0100 (CET) Date: Tue, 9 Jan 2018 13:16:54 +0100 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20180109121654.GY45648@Space.Net> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mtJy7Gj4yntYVuD/" Content-Disposition: inline In-Reply-To: <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:16:57 -0000 --mtJy7Gj4yntYVuD/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 09, 2018 at 01:15:09PM +0100, Alexandre Petrescu wrote: > Le 09/01/2018 =E0 13:07, Gert Doering a =E9crit=A0: > > On Tue, Jan 09, 2018 at 12:59:06PM +0100, Alexandre Petrescu wrote: > >> On my side I think this: mobile hotspots MUST implement and turn on > >> DHCPv6 Prefix Delegation, because it is the only way to be a mobile ho= tspot. > >=20 > > Uh... "no"? >=20 > the most scalable, most secure, most path-efficient, > most DNS friendly... most recommendable This might all well be, but it is not "the only way to be a mobile hotspot". Which falsifies your whole sentence, thus short answer. 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 --mtJy7Gj4yntYVuD/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlpUsrUACgkQ31bAZeTO f8Udzw//Wka3DhlvRxnfINHeNqvypirFAPLWAMV/Vf7IvkEvCLF695UTLmPemU+1 mLLhUg45AdjjKfJA3ONBKG9+qJAgFVB/jDJ0CNBzf5NQa6hEuPFh5vvMKcP7Wf2T jsWEzBlLhpN7GK87ppFYcT78zDDq3Kd+calG/1euBJwpWf5Wp/1GIi+5W408IlwG sU53sc4+0uDVFh9LR00IXB15YWeKv/Iyp68GSTNNqPWQSMz5SfitXUPlgEnmHcdq /70UIUCZ3Ns2q6IFdHng1Edt6GMxNIf4W2e7FJ9oPrhE0KFqbCn9unAnpTnSgPpc Wtw+P/aR1slFq1mRnTfHX8svCIjiELb39+/Z9/EzUdnT6fhKGkX+Ii/d3PC6bcFC ADNarvAFjcCphRe4QbzcKQJ+qJwTOQfi6G9MNRjS/HZ5n2A8UxYH78lNwBaFv04f X6qODyfolawt47cA89WD4LHHGzblt9yIYNBAF8l9i3/xyl5GKrJaPvkqZvG/e+TS bu/LH4Lhz4pMeZ/0rjxQPuQ6d52LxuxK6ZO2rV4W1Q7pdGuD3f6vgjzDBKLCAUEe bRU6uS4ihh/scoZm908fSyvGvp1+yw14CqjA5TVelmmP1yQ29OXS9o6HafS60g51 Oo41H2HtfGP3VUMmkDe+tFQSv5E4PU9BQnNSy/WvGyxvOcdbjdg= =EMjt -----END PGP SIGNATURE----- --mtJy7Gj4yntYVuD/-- From nobody Tue Jan 9 04:27:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48169127342 for ; Tue, 9 Jan 2018 04:27:34 -0800 (PST) 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 MlXfNDfdXaUT for ; Tue, 9 Jan 2018 04:27:32 -0800 (PST) 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 8B31F126DEE for ; Tue, 9 Jan 2018 04:27:32 -0800 (PST) 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 w09CRUST047682; Tue, 9 Jan 2018 13:27:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9D154205134; Tue, 9 Jan 2018 13:27:30 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 861A12030B8; Tue, 9 Jan 2018 13:27:30 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09CRUkG004620; Tue, 9 Jan 2018 13:27:30 +0100 To: Gert Doering Cc: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> From: Alexandre Petrescu Message-ID: <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> Date: Tue, 9 Jan 2018 13:27:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180109121654.GY45648@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:27:34 -0000 Le 09/01/2018 13:16, Gert Doering a crit: > Hi, > > On Tue, Jan 09, 2018 at 01:15:09PM +0100, Alexandre Petrescu wrote: >> Le 09/01/2018 13:07, Gert Doering a crit: >>> On Tue, Jan 09, 2018 at 12:59:06PM +0100, Alexandre Petrescu wrote: >>>> On my side I think this: mobile hotspots MUST implement and turn on >>>> DHCPv6 Prefix Delegation, because it is the only way to be a mobile hotspot. >>> >>> Uh... "no"? >> >> the most scalable, most secure, most path-efficient, >> most DNS friendly... most recommendable > > This might all well be, but it is not "the only way to be a mobile hotspot". > > Which falsifies your whole sentence, thus short answer. Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make a mobile hotspot. Alex > > Gert Doering > -- NetMaster > From nobody Tue Jan 9 04:28:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605B9127599 for ; Tue, 9 Jan 2018 04:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKhPLC0zTRMO for ; Tue, 9 Jan 2018 04:28:46 -0800 (PST) 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 185A2126DEE for ; Tue, 9 Jan 2018 04:28:46 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B89F744130 for ; Tue, 9 Jan 2018 13:28:44 +0100 (CET) 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 A951341C00; Tue, 9 Jan 2018 13:28:44 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 9A9C86DA5A; Tue, 9 Jan 2018 13:28:44 +0100 (CET) Date: Tue, 9 Jan 2018 13:28:44 +0100 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20180109122844.GZ45648@Space.Net> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JPtwXV6RYI1g9nHD" Content-Disposition: inline In-Reply-To: <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:28:47 -0000 --JPtwXV6RYI1g9nHD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 09, 2018 at 01:27:30PM +0100, Alexandre Petrescu wrote: > Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make= =20 > a mobile hotspot. No. 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 --JPtwXV6RYI1g9nHD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlpUtXoACgkQ31bAZeTO f8WvuhAAhUYTLdgX/vcPV4/MgSIWddzRma1DEmRXQH7qKdjQtNhTvpISY1PSGteV vQrMyuXayI2Om6eiFXhNpvs4mmJ1PrZfhOFnhYXg2tdhfoZWcr15mRhulB6931Mm VmjaYFkUL/Hae4OlHw7UY+LR9infiBHQKAEqJr1pwZ69HkuY0FRnHp71VnFW/v+1 uP9AJJ+2IMT+gz/p6/jAHufguxqmaRT50Oa3rlBnOeuToWYj//pMVWDH8fdl/3yM VzrFVtQfCCc8jTuEt9fZ8WdP1l09mcNFYL3O35TYKovZ8y4vZ/R3mqDVQPz6t/Km w4H5mMasBuae8/u/o3fCqUNkVdKqePxKy3Ug0Yq+f6K6X5k3RGevlMvWOaFdRee+ JqyHXAq5QtlzeGXKxqn2urmdiSPw+fNlmJ8K5U/A31ecaQgUv7uqvNRpg8lXoPbX XFnzI/33YyHw3CN/MgUgMbCnd6rUIqRV9XmM5TCTg816Y7DYX5IkLr2D7wJiRku8 /IxCByHm0Lk67XCXG2AcC4E8+yKyzxtAx3IfdzkrvfyfqfLMVjR3tuQRgb5jE6d4 WBHehH+Goqen9TqvpgVn6SAeFjixeIQS0JfycYYGtl7SS3DazjABGgvNB9K52iUh l/7oaVvEf5pTr0uKzvsXGBoW/lUnAQgkxCW9uOFLS3amlg8Z5pM= =2mB5 -----END PGP SIGNATURE----- --JPtwXV6RYI1g9nHD-- From nobody Tue Jan 9 04:30:00 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7718212773A for ; Tue, 9 Jan 2018 04:29:58 -0800 (PST) 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 xUTlP2IIAtlt for ; Tue, 9 Jan 2018 04:29:57 -0800 (PST) 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 1B781126DEE for ; Tue, 9 Jan 2018 04:29:56 -0800 (PST) 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 w09CTt0H056697; Tue, 9 Jan 2018 13:29:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 25FB8205143; Tue, 9 Jan 2018 13:29:55 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0FC8D20503D; Tue, 9 Jan 2018 13:29:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09CTsef006741; Tue, 9 Jan 2018 13:29:54 +0100 To: Gert Doering Cc: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> From: Alexandre Petrescu Message-ID: <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> Date: Tue, 9 Jan 2018 13:29:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180109122844.GZ45648@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:29:58 -0000 Le 09/01/2018 13:28, Gert Doering a crit: > Hi, > > On Tue, Jan 09, 2018 at 01:27:30PM +0100, Alexandre Petrescu wrote: >> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make >> a mobile hotspot. > > No. Err, I do not know what you have in mind when you say 'no', but I do know what I have in mind when I say it is. Alex > > Gert Doering > -- NetMaster > From nobody Tue Jan 9 04:40:05 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF881275FD for ; Tue, 9 Jan 2018 04:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 roa3eRQc39ci for ; Tue, 9 Jan 2018 04:40:02 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4035126DEE for ; Tue, 9 Jan 2018 04:40:01 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41A61B1; Tue, 9 Jan 2018 13:39:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1515501599; bh=l6KnlZsQX6Zc184piMaf3oKutuoM8RdRfZKj9RVqHnc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Zp11BRfugdz3fo0eAoHq9H115kWN8p6ValZpNRrf27nXloxzDtzTm3A9MiBV7k54W XskxFrmn4spZx5Np0IUP76FtmkRWrkOocQSi3RJ0m1UaxHyLEYoBA94ZKT+4i8LOHS x6H/2q6kxOw9UlDtF5c5pgnQHorSSMTv1+/kX7Uw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2DC92B0; Tue, 9 Jan 2018 13:39:59 +0100 (CET) Date: Tue, 9 Jan 2018 13:39:59 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Gert Doering , v6ops@ietf.org In-Reply-To: <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> Message-ID: References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-2030810793-1515501599=:8884" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:40:04 -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-2030810793-1515501599=:8884 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 9 Jan 2018, Alexandre Petrescu wrote: > > > Le 09/01/2018 13:28, Gert Doering a crit: >> Hi, >> >> On Tue, Jan 09, 2018 at 01:27:30PM +0100, Alexandre Petrescu wrote: >>> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make >>> a mobile hotspot. >> >> No. > > Err, I do not know what you have in mind when you say 'no', but I do know > what I have in mind when I say it is. Today we have hundreds of millions of mobile hotspots that do not require DHCPv6-PD to work. Judging from your earlier email, we seem to have some experimental ones that do implement DHCPv6-PD to make them mobile hotspots, meaning the ratio of deployed ones using DHCPv6-PD and those without, differ in orders of at least 6-7 magnitudes, probably more. So you don't have enough operational experience to substantiate your claim that this is the "best way". -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-2030810793-1515501599=:8884-- From nobody Tue Jan 9 04:43:13 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67612D832 for ; Tue, 9 Jan 2018 04:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhNYVIrtgKaQ for ; Tue, 9 Jan 2018 04:43:10 -0800 (PST) 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 7196F12D7E8 for ; Tue, 9 Jan 2018 04:43:10 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6D2F444141 for ; Tue, 9 Jan 2018 13:43:08 +0100 (CET) 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 5C2E944130; Tue, 9 Jan 2018 13:43:08 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 58BB46DBF5; Tue, 9 Jan 2018 13:43:08 +0100 (CET) Date: Tue, 9 Jan 2018 13:43:08 +0100 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20180109124308.GA45648@Space.Net> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4Vp8LQD7rcmNQ+jz" Content-Disposition: inline In-Reply-To: <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:43:12 -0000 --4Vp8LQD7rcmNQ+jz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 09, 2018 at 01:29:54PM +0100, Alexandre Petrescu wrote: > Le 09/01/2018 =E0 13:28, Gert Doering a =E9crit=A0: > > On Tue, Jan 09, 2018 at 01:27:30PM +0100, Alexandre Petrescu wrote: > >> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to ma= ke > >> a mobile hotspot. > >=20 > > No. >=20 > Err, I do not know what you have in mind when you say 'no', but I do=20 > know what I have in mind when I say it is. "No" means "it is not the best way". 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 --4Vp8LQD7rcmNQ+jz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlpUuNkACgkQ31bAZeTO f8X9qA//QU7VcVOba5WhPYO6cTswn5VuUcKURx9GpSrM+p4Xv8BuHNIZgr0CAhQd mAyEwD7lB4jSOSdXcXz2RQPh0d6MFPyz1Glb2frKRtvVp8StBTHNgg9VQl3iIVwI tu79ZOi0ejpWRrfa9reKlUw6grQUsM9/Hvja5BKSdj0N9JBwYj7aACX4C8SvMHpD WKEzwO5HleHhqg1+3dOc7dKHaP0L4NVyffLr9WlHUZD6R0fz6BgnFn8j5LU3Hy7U RLsmvIFxmXsMETdc/dvxcQcdwVxoTGy3rPjBQHHfhVtXICrAvHgjmKsXPHosMbmR 3HFHLMPY+W2Toq7xQMVMwgLPhe8/ljYi4XWHmDCYKIM60FNV1bC9XNrY6qjPutvy JQgvwb6j4VS2z+VgfI9+pj7L7qM4TM6zOO4p3Z6xL2rOmUTO6Wf6IaZDPb1Yld1d GiIuFjE9H9qghb0J7AyvbWMJphaKtASeHiOFD4pqGWvyCprLfEB/oV2ZcEHjdsT8 8Lco1y9KEDlI7gQC3NqqHq7APJbTewcfsChEDHv328H/RLakhCdPcETK6g+/T4Dh 9ZeFdLpcX+LMJ54hpVWI8BItYEEdrP2Xxv27rlFC9fTLLMmkF2EC86bYnh2MQiEh 1GsqIFTdWRpR82g5rTEJMP00dzN4WWqYni1IElq4UMyNxd0LGCI= =tx04 -----END PGP SIGNATURE----- --4Vp8LQD7rcmNQ+jz-- From nobody Tue Jan 9 04:51:04 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003B112D832 for ; Tue, 9 Jan 2018 04:51:02 -0800 (PST) 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 UFERHfS6fJBs for ; Tue, 9 Jan 2018 04:51:01 -0800 (PST) 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 3F1B412420B for ; Tue, 9 Jan 2018 04:51:01 -0800 (PST) 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 w09Cox7F002442; Tue, 9 Jan 2018 13:50:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3DF1E205165; Tue, 9 Jan 2018 13:50:59 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 258B92050DE; Tue, 9 Jan 2018 13:50:59 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09CowPw028614; Tue, 9 Jan 2018 13:50:59 +0100 To: Mikael Abrahamsson Cc: Gert Doering , v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> From: Alexandre Petrescu Message-ID: <13202ae7-fc2c-7114-cebb-25dc93bd3f3a@gmail.com> Date: Tue, 9 Jan 2018 13:50:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] Discussion focus: draft-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, 09 Jan 2018 12:51:03 -0000 Le 09/01/2018 13:39, Mikael Abrahamsson a crit: [...] [numbers] > So you don't have enough operational experience to substantiate your > claim that this is the "best way". There should be more to a "best way" than just numbers. Alex From nobody Tue Jan 9 04:52:31 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB56412D847 for ; Tue, 9 Jan 2018 04:52:29 -0800 (PST) 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 QqGQB2mdRWyf for ; Tue, 9 Jan 2018 04:52:28 -0800 (PST) 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 DCB6B12D834 for ; Tue, 9 Jan 2018 04:52:27 -0800 (PST) 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 w09CqQqk003272; Tue, 9 Jan 2018 13:52:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3C9132051CB; Tue, 9 Jan 2018 13:52:26 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 243E62051C9; Tue, 9 Jan 2018 13:52:26 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09CqPWZ030467; Tue, 9 Jan 2018 13:52:25 +0100 To: Gert Doering Cc: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> <20180109124308.GA45648@Space.Net> From: Alexandre Petrescu Message-ID: Date: Tue, 9 Jan 2018 13:52:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180109124308.GA45648@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:52:29 -0000 Le 09/01/2018 13:43, Gert Doering a crit: > Hi, > > On Tue, Jan 09, 2018 at 01:29:54PM +0100, Alexandre Petrescu wrote: >> Le 09/01/2018 13:28, Gert Doering a crit: >>> On Tue, Jan 09, 2018 at 01:27:30PM +0100, Alexandre Petrescu wrote: >>>> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to make >>>> a mobile hotspot. >>> >>> No. >> >> Err, I do not know what you have in mind when you say 'no', but I do >> know what I have in mind when I say it is. > > "No" means "it is not the best way". It seems there is some good idea about what "best way" is. Alex > > Gert Doering > -- NetMaster > From nobody Tue Jan 9 04:53:42 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08AF12D848 for ; Tue, 9 Jan 2018 04:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etrcoK4XWWc0 for ; Tue, 9 Jan 2018 04:53:39 -0800 (PST) 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 8B0B712D838 for ; Tue, 9 Jan 2018 04:53:39 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 36FF744134 for ; Tue, 9 Jan 2018 13:53:38 +0100 (CET) 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 29310423DD; Tue, 9 Jan 2018 13:53:38 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1A75C6DD17; Tue, 9 Jan 2018 13:53:38 +0100 (CET) Date: Tue, 9 Jan 2018 13:53:38 +0100 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20180109125337.GB45648@Space.Net> References: <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> <20180109124308.GA45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ckGNliy1hXaptuZg" 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] Discussion focus: draft-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, 09 Jan 2018 12:53:41 -0000 --ckGNliy1hXaptuZg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 09, 2018 at 01:52:25PM +0100, Alexandre Petrescu wrote: > It seems there is some good idea about what "best way" is. "Something that works in more than 5% of all networks world wide" would be a reasonable start for "best" 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 --ckGNliy1hXaptuZg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlpUu08ACgkQ31bAZeTO f8Vk1xAAh8lszI1r0kgSKI64emjzQi3aE+kXiDmbe/U9kdouMrtjb7n4xG7d24tR VEvn2j3MvKidXpcOPPf789yxZ6dK2iC14C/tuDUXKMvtkjQ2Xui07WLDPzVTxU3K BVhBOnKCDASfGtiaPDQWsU71M4K1x0pL+rrx7/WcmB2T0hDZNZnwO11wtTiKyCVF b0GzZCc6xbjdkJ3DbpFo3gOzczAFwNafTWQASJqHIBV+lRHiSeigw82ipzw6v6WO gPFNqKI68N2Q2q1g/I5f/Qt1gywVokJ8ioG5Ivy6M+5xFMtsjVZLLVruYkcAp/wd zcQrSJRDlL2IMT8/FwhN9J2ui1zm6I4WrZbdn/j5u2VbVnbttetC9AZOCFl4O+ba ZojiW82dsPQwfFFBF1HxGmmN26g2xpI9VfsFqdNvLX4bAXaLq8PPxtYqoSdz8b+O va1R7At9L8XqAqPrjT4QWrkjddYKvP/sXYN4MMpB+00GNaEy4Kg0Epc7m+7jlfUl EsWwTQvHGyY1R7mKoeFwXGoiBhc0A4e0kz2b5P72Yd/2PcyRu3WpUZ73EQ2U4RHf t3hNi2kTFE5RJdumOMbiqpQ38nK8LSyjEHGiOiQZrwS72Kumroq33ijmd6meBD0Z mQifkvJPY31fOuEtEdd1brvA9UPboXPV0zzLeYg3mbKomvTkfdw= =a2gy -----END PGP SIGNATURE----- --ckGNliy1hXaptuZg-- From nobody Tue Jan 9 04:56:59 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA0112D838 for ; Tue, 9 Jan 2018 04:56:56 -0800 (PST) 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 aO4mo1RB3iqy for ; Tue, 9 Jan 2018 04:56:55 -0800 (PST) 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 0FF2212D834 for ; Tue, 9 Jan 2018 04:56:54 -0800 (PST) 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 w09Curh5008693; Tue, 9 Jan 2018 13:56:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 45A12204FAC; Tue, 9 Jan 2018 13:56:53 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2EE04202244; Tue, 9 Jan 2018 13:56:53 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w09CuqBf002291; Tue, 9 Jan 2018 13:56:53 +0100 To: Gert Doering Cc: v6ops@ietf.org References: <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> <20180109124308.GA45648@Space.Net> <20180109125337.GB45648@Space.Net> From: Alexandre Petrescu Message-ID: <8853d89b-0c18-d8ed-511e-5417491030b0@gmail.com> Date: Tue, 9 Jan 2018 13:56:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180109125337.GB45648@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 12:56:56 -0000 Le 09/01/2018 13:53, Gert Doering a crit: > Hi, > > On Tue, Jan 09, 2018 at 01:52:25PM +0100, Alexandre Petrescu wrote: >> It seems there is some good idea about what "best way" is. > > "Something that works in more than 5% of all networks world wide" would > be a reasonable start for "best". DHCPv6 Prefix Delegation applies well there. Nonetheless, I suggst to think of a more engineering approach to designing a "best way" rather than an economics approach. Something like: it MUST work in accordance with fundamental principles of Internet. Alex > > Gert Doering > -- NetMaster > From nobody Tue Jan 9 05:26:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36212D85F for ; Tue, 9 Jan 2018 05:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_RP_MATCHES_RCVD=-0.01, 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 HIHAJDHoo0_q for ; Tue, 9 Jan 2018 05:26:27 -0800 (PST) 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 0130712D859 for ; Tue, 9 Jan 2018 05:26:23 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id x42so8017639ita.4 for ; Tue, 09 Jan 2018 05:26:23 -0800 (PST) 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=wlnaa5s0Nrhlwbva8654YmTOjNQ1dVyGMgbF+06AE2o=; b=lK5YNfwIbKptqg2iARrCQmP5VD51zcboDsx3YjOiRPGEmeiboAk2gXkI3vyVZeZ/TA RJt+HuwUG4mdAzGJj31wJwIC51AwhmS/qAUfQEJo4k+tYs8kZbp84a87PtA1DJTeNICG 7oj2OPVatWwX9PC/mBxzyrzwCfBUdHyJrJRPDzlL4r+oBoLjAbaKkMWbC7BGFu7fNeW6 iC7cLIz6Xs4X044e04Njxu/SKrr2vHEvAh87gjCw7TNyetXCcreugiktxyJC+binioiF s7O/YWsgxC3WfwM1w5TTa54PIv564nMtYNWadoaJBGxdHygMPjRJ6ss/IDPeA0x8ensY rVmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=wlnaa5s0Nrhlwbva8654YmTOjNQ1dVyGMgbF+06AE2o=; b=g4TzNtU7n/tF02M1UolhEoBV8law88/U4XZt3BXXY82QUZW9DF5M+MUOz8ERzLyXjK 0oBbJ1r4pVk418Qw+Nbt8UsVU8bb6n/Ewh66CXKKoJH7CXD0p9zMCc37rJaxG2jVWgqq w0jQV7COq4L788ytuvD4xfOmn8h6QFxr9a9SVnOXnDVLMYt95Q3mfvqhJcwELIruP6wN 4H3u59KyrkfqODKjq4E4hfGmP24yUB8ZF/ro+hqaT78/lPnP/18+27MT2ormoOp5HaSc M75rKmRCXRRyyBlCGRTFoM0P/xw+eu8DBve0IQfsbi1h5sVtVs3f50V1J+AKTOGVKYJD bR3g== X-Gm-Message-State: AKwxytcaxkSCEvfC9zaNIKTPE4kQ7KRkZZkoGZDHAJXt0Kay+HB4WXJe 1Y2nWL+Btr18qObx5iQ2KKMi8m0UKtr/92tOlvLecA== X-Google-Smtp-Source: ACJfBotkswZR3hHK8ge6XXr9E4pCjALkXABd7o5SwVgWLpmED3Zgq/U7k93PgN2hTZbUYeYu3P0eSLSx2duJyCqDkAg= X-Received: by 10.36.182.73 with SMTP id d9mr1900774itj.124.1515504382950; Tue, 09 Jan 2018 05:26:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.102.19 with HTTP; Tue, 9 Jan 2018 05:26:02 -0800 (PST) In-Reply-To: <20180109124308.GA45648@Space.Net> References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <11d764f6-e0d7-c24e-7b51-c8b5bb026082@gmail.com> <20180109120700.GW45648@Space.Net> <592ac6fa-9d1f-e802-3c29-8d70dedf60b3@gmail.com> <20180109121654.GY45648@Space.Net> <7d0aa9fb-ac74-52dc-0437-01c173f2b38e@gmail.com> <20180109122844.GZ45648@Space.Net> <4cca5ac8-e80a-6297-205e-464f490facb0@gmail.com> <20180109124308.GA45648@Space.Net> From: Lorenzo Colitti Date: Tue, 9 Jan 2018 22:26:02 +0900 Message-ID: To: Gert Doering Cc: Alexandre Petrescu , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="089e082038f8678c1c056257dc33" Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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, 09 Jan 2018 13:26:29 -0000 --089e082038f8678c1c056257dc33 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 9, 2018 at 9:43 PM, Gert Doering wrote: > > >> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the best way to > make > > >> a mobile hotspot. > > > > > > No. > > > > Err, I do not know what you have in mind when you say 'no', but I do > > know what I have in mind when I say it is. > > "No" means "it is not the best way". Well... FWIW, RFC 7278 does say that DHCPv6 PD is the best way :-) --089e082038f8678c1c056257dc33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On T= ue, Jan 9, 2018 at 9:43 PM, Gert Doering <gert@space.net> wrote= :
    > >> Ok, let me rewrite: The Prefix Delegation DHCPv6 is the be= st way to make
    > >> a mobile hotspot.
    > >
    > > No.
    >
    > Err, I do not know what you have in mind when you say 'no', bu= t I do
    > know what I have in mind when I say it is.

    "No" means "it is not the best way".

    Well... FWIW, RFC 7278 does say that DHCPv6 PD is the = best way :-)
    <ducks>
    --089e082038f8678c1c056257dc33-- From nobody Wed Jan 10 09:51:25 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ECC12DA50; Wed, 10 Jan 2018 09:51:17 -0800 (PST) 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 idGJFQa8RBjo; Wed, 10 Jan 2018 09:51:15 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D87812DA6B; Wed, 10 Jan 2018 09:51:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w0AHpEKP002428; Wed, 10 Jan 2018 10:51:15 -0700 Received: from XCH15-03-12.nw.nos.boeing.com (xch15-03-12.nw.nos.boeing.com [137.136.239.150]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w0AHp8Th002276 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 10 Jan 2018 10:51:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-03-12.nw.nos.boeing.com (137.136.239.150) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 10 Jan 2018 09:51:07 -0800 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.1347.000; Wed, 10 Jan 2018 09:51:07 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" , IPv6 List CC: "Benson, Michael W" , "Yeh, Eric D" , "Bae, Kyle" Thread-Topic: DHCPv6 PD and IPv6 ND for OpenVPN (source code) Thread-Index: AdOKOa41r6kL84prQ46bwpgX69mhNw== Date: Wed, 10 Jan 2018 17:51:07 +0000 Message-ID: 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: [v6ops] DHCPv6 PD and IPv6 ND for OpenVPN (source code) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jan 2018 17:51:17 -0000 Recently, I announced that Boeing has DHCPv6 PD and IPv6 ND working over OpenVPN. I offered to make the source code available to the public domain, and at least one person expressed interest. Our code has now been approved for public release and is available for free download here: http://linkupnetworks.net/aero/AERO-OpenVPN-1.0.tgz We run the code on both linux and Android, and we can demonstrate its opera= tion in the CORE network emulation environment, on physical linux machines and o= n any Android platform (phones, tablets, etc.). Feel free to review the code and experiment with it, and let us know if you= have any questions or comments. If there is interest, we can show a live demo ov= er the Internet; let us know if that would be of interest. Thanks - Fred fred.l.templin@boeing.com =20 From nobody Wed Jan 10 23:46:18 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066BF127863 for ; Wed, 10 Jan 2018 23:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apBSdJbfnJhP for ; Wed, 10 Jan 2018 23:46:15 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4081F12025C for ; Wed, 10 Jan 2018 23:46:15 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id a12so1646477lfe.13 for ; Wed, 10 Jan 2018 23:46:15 -0800 (PST) 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=Aaf10Z2uHZ38GsjdiyX6Wl6aJ9LNLxBQod4Ed6ThGWw=; b=enc8FxfYLDfbzDmYiY7mI6DUlu2p05nTMWBw0uegQeBvg03fx3hV2JX0BiTnwvq0rk xa5SJ1t03cDfsa3ZOPaLw+VWB6Wur5d1D5NOtH82xdOd+0qPrm02+QhAxmScv2TZ/OnN Kd4PXTCNbgcccFQ7lKh9vBtAS8q732IDMWv7Xz7gudLIfzfM4XRT9lqFBbf2uxym61xC xOauwAYp7aJ3I8UQBJOhS3F30GOyxYaa+v4r+x/ERnzcNEqN59DdbDS88igzW5T2D2jJ mZyFhsaug6M4ViNb8NV4TTSMi5pLvvxtMYprC5dq7xiCvfIEH5vod2EGWCFe3NTYZMtG YTQQ== 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=Aaf10Z2uHZ38GsjdiyX6Wl6aJ9LNLxBQod4Ed6ThGWw=; b=SXOXm8aQ4bk3dDMNxh6702ZJa1ZwJNA02nxsRZ4vp8SHIqQguo7/WOxSZLj7yJt+PL APeItiKRw+53hx21i2GkrK48NnXUNnClpkx8Ryhd6ZCwE32/MYlkW9k3VoWaiovy0aaV NbtP1iJRPxI44icq5r09pkPyNk7Q0RfqKogeePHsUGuDOVvQ9EpZ/Nv0wqyTgYly+qby 24oMIFG8judcxseZ17HSlCP+CnBf5zy+MlmMYLHCdRNVSkABBlV0+63zKH0GBZVq1ZqO yj4GWiVi7+7I69+Nb9lz4K/mcLYj2HkmATFU6UyV6dGqU05qpKkFdarUG+VTrDrtje+P hMqg== X-Gm-Message-State: AKwxyteTRDT9SLMx7TIKrZi2RDqQD8uyErBoxdXlm214qC7Np/0USf8a PQBvgLbRcpZCh5kV7yM4sof4rw8O4V3nVk9pHUQ9Yvs/ X-Google-Smtp-Source: ACJfBotEl6HuBhCTk3YJjhfXwYDa3b2HiLvA/8bPP536Yxsp3n8zuZESATgF3SgJ8vW0RPdGuLSeZJ0PPXnPj4Z6J2o= X-Received: by 10.25.76.214 with SMTP id z205mr10835509lfa.134.1515656773212; Wed, 10 Jan 2018 23:46:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.67.188 with HTTP; Wed, 10 Jan 2018 23:46:12 -0800 (PST) From: Thor-Henrik Kvandahl Date: Thu, 11 Jan 2018 08:46:12 +0100 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary="001a114b0c62919e9a05627b5704" Archived-At: Subject: [v6ops] Mobile: Happy DNSclientBalls X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 07:46:17 -0000 --001a114b0c62919e9a05627b5704 Content-Type: text/plain; charset="UTF-8" Hi, Does anyone know if there are defined requirements on behaviour for the DNS client on a Mobile Node (MN/UE) connected to a dual stack APN where the 3gpp IE container provisioned both IPv4 and IPv6 name servers? As far as I know it is up to the UE to prefer between the provisioned name servers, and I think they should prefer IPv6 name servers. My Android Oreo and Nougat DNS clients uses only IPv4 for DNS requests and I think it would be better for the NAT44(4) devices between the PGW and the resolver if the UE preferred to use the IPv6 name server(s). If there are no requirements for this, does anyone know the Google policy for Android on this? Iphone's seems to prefer the IPv6 name servers. -- *Thor-Henrik Kvandahl* --001a114b0c62919e9a05627b5704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    =

    Hi,

    =C2=A0

    Does anyone = know if there are defined requirements on behaviour for the DNS client on a= Mobile Node (MN/UE) connected to a dual stack APN where the 3gpp IE contai= ner provisioned=C2=A0both IPv4 and IPv6 name servers?

    As far as I kno= w it is up to the UE to prefer between the provisioned name servers, and I = think they should prefer IPv6 name servers.
    My Android Oreo and Nougat D= NS clients uses only IPv4 for DNS requests and I think it would be better f= or the NAT44(4) devices between the PGW and the resolver if the UE preferre= d to use the IPv6 name server(s).

    If there are no requirements for th= is, does anyone know the Google policy for Android on this?

    Iphone's seems to prefer t= he IPv6 name servers.

    =

    =C2=A0

    --

    Thor-Henrik Kvandahl
    <= /div>
    --001a114b0c62919e9a05627b5704-- From nobody Wed Jan 10 23:57:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E29712EA97 for ; Wed, 10 Jan 2018 23:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sX1HiXPPXhV2 for ; Wed, 10 Jan 2018 23:57:53 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D91E124D37 for ; Wed, 10 Jan 2018 23:57:53 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id f140so3517519wmd.2 for ; Wed, 10 Jan 2018 23:57:53 -0800 (PST) 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=ULWge1DmXrSGbE3VOkDv68d9O9zZwxj3j7O4O/NENi8=; b=GeR1BM5WGHutMaQP9nlRAGm30c7LYEZU9YvxeUN1bIzdGuN9vdQLGUlXo6TBdVP3HK 14+Qz2mj6BfFatPaoES7WiHft/pcGDAXUj0fQsFV5WdtJ/p7Iwjhcu4Xt91LqkCKy5GK FZoL90pRXVXY7WOwb9J/2eNORNCMdit8rgy8DIUju/085Ea0ooZJMxCzLEkAAfkmVuk9 +MXIVB9T98gP1jqZ3Kc/DuD+aNItvFaQuZRSEYALeYJq9FIpG5N5E91njF0wmMsj84ZG LT6d2wd5Bok1kteIcBBQmL3GnpIPxOb8TVZNxSbKQ80T0BIQUSR0b/33ZnjU0M5CseWf WrJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=ULWge1DmXrSGbE3VOkDv68d9O9zZwxj3j7O4O/NENi8=; b=C6yJz7B/J+c4cLsVIRzNUEWzoKJmlzwlcG0/s1OHNnOv78qjs69chu3S5p6MjvxIen PK1ZV5963L2W+ZexmeEROSz67TSs8P6ynfK1ugS6/EFX9xZlh0Xd1JmsBd/jfvDbuHV+ ZU6OZt19xn9Lf7WQEMzN8Ix6dM1sSNwFPqzjoum6UhneEPfnLatVUvMfo3B4lp2qk0vc 07Tudmp6mJywRQY5OmcRmNKAY4u8SjdaP1kMiGlTEgpA5GEbToBD7eOvfWHaMxqnsWvs ZdXgYVGAy/OBJY9sUmF73yp6Dex2xek9RfpGRi7qWCG9gBSwk3tU/ApLOfSmkxsJRyNM jSag== X-Gm-Message-State: AKwxytd04daXGC/X6irwst0xGDMg02JFstGdWJQCZKfTuyiZcM5gdyTs x0yTFTTX9DQ3fhIuMqN5ppw1ZQhHA96ZbKg6tIIF6w== X-Google-Smtp-Source: ACJfBotJmQB2joOlV2okaUN+drJyez9bWE5KrrIA591WFywnsiDMzGXlKt8ZFiTqyKSS5fuFkQUgGURUavlGbnfbKUU= X-Received: by 10.28.23.139 with SMTP id 133mr392104wmx.0.1515657471183; Wed, 10 Jan 2018 23:57:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.210.132 with HTTP; Wed, 10 Jan 2018 23:57:30 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Thu, 11 Jan 2018 16:57:30 +0900 Message-ID: To: Thor-Henrik Kvandahl Cc: "v6ops@ietf.org WG" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114702b433574705627b81ec" Archived-At: Subject: Re: [v6ops] Mobile: Happy DNSclientBalls X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 07:57:55 -0000 --001a114702b433574705627b81ec Content-Type: text/plain; charset="UTF-8" We have an open bug to do RFC6724 sorting of nameservers. Haven't gotten around to it just yet. As far as requirements go, I'm not aware of anything off the top of my head. Carriers can (and do) try to require whatever they can dream up, but that's separate. On 11 January 2018 at 16:46, Thor-Henrik Kvandahl wrote: > Hi, > > > > Does anyone know if there are defined requirements on behaviour for the DNS > client on a Mobile Node (MN/UE) connected to a dual stack APN where the 3gpp > IE container provisioned both IPv4 and IPv6 name servers? > > As far as I know it is up to the UE to prefer between the provisioned name > servers, and I think they should prefer IPv6 name servers. > My Android Oreo and Nougat DNS clients uses only IPv4 for DNS requests and I > think it would be better for the NAT44(4) devices between the PGW and the > resolver if the UE preferred to use the IPv6 name server(s). > > If there are no requirements for this, does anyone know the Google policy > for Android on this? > > Iphone's seems to prefer the IPv6 name servers. > > > > > -- > > Thor-Henrik Kvandahl > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114702b433574705627b81ec 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgO/6oAdB1hPqkJ9pTPNhX4vV3vnCq+2Jt WMuIuTCusFowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMTEx MDc1NzUxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADVIM4w+zPRfysRrKpxRD2CNyoYBDKM+3TyBfyLKR49mY4qpQkf5 BlQJ8Xaw8OeFsI9VddB6Kii8GsIYDUAb5HSOwweVo4K05XoXgxj70W2Dp231TxtCK6ykKizHxbj/ wUJj3NzuRoHkaRgronbIB3Cd1+7/i1jOftsREtFoQnJO3Cc4kCvux6xxgBPyu62vgwouG0KWOev7 DNrwZYfZqL7AILqvr45n7cxuSUWccisOEO7hoHh0VjtTcU19DTOS02hX/CEjhxlMDdWELHO37ZRR WWNHnGZ8beZOtcGL8mWz6X/yOMV08jFFuQzzkKF2zuMgBfRiyBCp9j68WmwFAUk= --001a114702b433574705627b81ec-- From nobody Thu Jan 11 02:55:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B3012EAD4; Thu, 11 Jan 2018 02:55:44 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 6NQ6qScEWyTu; Thu, 11 Jan 2018 02:55:42 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BD212EADC; Thu, 11 Jan 2018 02:55:41 -0800 (PST) Received: from 10.236.51.101 (EHLO ZE16MR06.tp.gk.corp.tepenet) ([10.236.51.101]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id HWS16585; Thu, 11 Jan 2018 11:55:35 +0100 (CET) From: Kossut Tomasz - Hurt To: "v6ops@ietf.org" CC: "v6ops-owner@ietf.org" Thread-Topic: IPv6-only mobile ISP alliance Thread-Index: AdOKyTmwgK4OaRlRQjS2PFoi0LREGQ== Date: Thu, 11 Jan 2018 10:55:13 +0000 Message-ID: <542c87df1c214bdd9457fab0f8874fc7@orange.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.38] x-tm-as-product-ver: SMEX-12.0.0.1727-8.200.1013-23588.006 x-tm-as-result: No--8.317400-0.000000-31 x-tm-as-matchedid: 701625-704425-700685-701153-710207-121101-700401-139006-7 07163-701960-106660-187160-705861-701249-700881-700108-703254-139703-708196 -700047-700618-703141-700074-710304-703041-704287-703788-106230-702020-7055 08-188019-148004-148133-42000-42003-63 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2018.1.11.101817:17:7.944, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NO_NAME, __TO_NAME, __HAS_CC_HDR, __CC_NAME, __SUBJ_ALPHA_END, __HAS_MSGID, __SANE_MSGID, __MSGID_32HEX, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __HTTPS_URI, __URI_WITH_PATH, __CP_URI_IN_BODY, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_800_899, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, WEBMAIL_SOURCE, MSG_THREAD, LEGITIMATE_SIGNS, __SINGLE_URI_TEXT, SINGLE_URI_IN_BODY, BODY_SIZE_1000_LESS, BODY_SIZE_2000_LESS, __MIME_TEXT_P, BODY_SIZE_7000_LESS, URI_WITH_PATH_ONLY X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0207.5A5742A7.0244, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0207.5A5742A7.0244, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dd47aaac419821309683881a73ff1c69 Archived-At: Subject: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 10:55:45 -0000 Dear All, Any IPv6-only mobile ISP's alliance exists? How many ISP's already deployed IPv6-only? How many IPv6-only mobile customers we have? Cheers, TK -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of v6ops-request@ietf= .org Sent: Wednesday, January 10, 2018 9:00 PM To: v6ops@ietf.org Subject: v6ops Digest, Vol 89, Issue 10 Send v6ops mailing list submissions to v6ops@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/v6ops or, via email, send a message with subject or body 'help' to v6ops-request@ietf.org You can reach the person managing the list at v6ops-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of v6ops digest..." From nobody Thu Jan 11 03:15:55 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56DE126DFE for ; Thu, 11 Jan 2018 03:15:53 -0800 (PST) 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 KvKNhejfULQM for ; Thu, 11 Jan 2018 03:15:51 -0800 (PST) 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 63993126DFB for ; Thu, 11 Jan 2018 03:15:51 -0800 (PST) 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 w0BBFnGm017177 for ; Thu, 11 Jan 2018 12:15:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8B3F32073BE for ; Thu, 11 Jan 2018 12:15:49 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 822B620737D for ; Thu, 11 Jan 2018 12:15:49 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0BBFnlv019129 for ; Thu, 11 Jan 2018 12:15:49 +0100 To: v6ops@ietf.org References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> From: Alexandre Petrescu Message-ID: <038bb6d0-4dec-b249-e9bc-f4cbf09f59d3@gmail.com> Date: Thu, 11 Jan 2018 12:15:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <542c87df1c214bdd9457fab0f8874fc7@orange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 11:15:54 -0000 Le 11/01/2018 à 11:55, Kossut Tomasz - Hurt a écrit : > Dear All, > > Any IPv6-only mobile ISP's alliance exists? I wonder the same. I know about the "IPv6 Forum" and there they can tell. > How many ISP's already deployed IPv6-only? It depends what do you mean by "IPv6-only". If by "IPv6-only" you mean the T-Mobile or Orange Poland style of IPv6-only smartphones, then I can say that there at least 4 mobile ISPs that deployed it. But do not forget that there is no operator that transports GTP in IPv6, even when that is for "IPv6-only" smartphones. They all transport in on IPv4. That's why, for me, it is hard to talk about "IPv6-only" mobile operators. > How many IPv6-only mobile customers we have? I think it is a good question that can be answered easily. But one needs to do some work to ask each of the operators, and then sum it up and post it back here. There will be no person on this list that can authoritatively say, e.g., there are 10 million IPv6-only mobile customers. Alex > > Cheers, > TK > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of v6ops-request@ietf.org > Sent: Wednesday, January 10, 2018 9:00 PM > To: v6ops@ietf.org > Subject: v6ops Digest, Vol 89, Issue 10 > > Send v6ops mailing list submissions to > v6ops@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/v6ops > or, via email, send a message with subject or body 'help' to > v6ops-request@ietf.org > > You can reach the person managing the list at > v6ops-owner@ietf.org > > When replying, please edit your Subject line so it is more specific than "Re: Contents of v6ops digest..." > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 11 03:45:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422FF12EB0B for ; Thu, 11 Jan 2018 03:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 6Q8kQLlt2eSV for ; Thu, 11 Jan 2018 03:45:32 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C7612EB0A for ; Thu, 11 Jan 2018 03:45:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 20BD5B1; Thu, 11 Jan 2018 12:45:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1515671129; bh=imaYKgmMjKPMQDJ/uobxQFbd5AX1wwGAK4op7+1aDJY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0P6x3oFbNSsKge/9U7MTBbwp+W0CfpJphvasGQmcXsMvgzvBq4cRAVhfjDy5Uz0ss FyiqGB+ZQ2nTX7xyO+/Yed/tLdy25m2ThfiqIauWejMBh3snr/3M8M1hd90cCCSkQ8 6cEHYp8Ficg175bVB6WG/xEXmdok5qqipFMmDPMc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E89EB0; Thu, 11 Jan 2018 12:45:29 +0100 (CET) Date: Thu, 11 Jan 2018 12:45:29 +0100 (CET) From: Mikael Abrahamsson To: Kossut Tomasz - Hurt cc: "v6ops@ietf.org" In-Reply-To: <542c87df1c214bdd9457fab0f8874fc7@orange.com> Message-ID: References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 11:45:34 -0000 On Thu, 11 Jan 2018, Kossut Tomasz - Hurt wrote: > How many IPv6-only mobile customers we have? If you're by this referring to single IPv6 PDP context customers, then at least tens of millions, perhaps a few hundreds of millions. https://getipv6.info/display/IPv6/3GPP+Mobile+Networks "... IPv6-only (e.g. T-Mobile USA, Orange Poland, Telenor Norway) PDP/PDN bearers. " I know at least T-Mobile USA uses this approach, and I'd imagine they have tens of millions of customers just there. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 11 03:47:11 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2EE12EB10 for ; Thu, 11 Jan 2018 03:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 JEFFBnidW1N9 for ; Thu, 11 Jan 2018 03:47:08 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B848512EB0B for ; Thu, 11 Jan 2018 03:47:08 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5762FB1; Thu, 11 Jan 2018 12:47:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1515671227; bh=7+JZeNncnpms53FVKyDrdUbVFnHxE0RI/jfTzgoc56w=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=z4rs2jjyymIDwmUvkJuNdq9FMO+SIPqHjQVs6vt/Szi2/QfnY/dqtoRTHrE7OHxYr BdZpm/WVHht6YgyEgGI7dwFZ4afhIT5zxEZOKgsN2h1m6YQV9qv8I+/Yeb9v3pIfw3 RkHbMvdF85ROowrUWOxQPWGII19KbAmTmBTsXboQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 550B3B0; Thu, 11 Jan 2018 12:47:07 +0100 (CET) Date: Thu, 11 Jan 2018 12:47:07 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <038bb6d0-4dec-b249-e9bc-f4cbf09f59d3@gmail.com> Message-ID: References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> <038bb6d0-4dec-b249-e9bc-f4cbf09f59d3@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 11:47:10 -0000 On Thu, 11 Jan 2018, Alexandre Petrescu wrote: > But do not forget that there is no operator that transports GTP in IPv6, > even when that is for "IPv6-only" smartphones. They all transport in on > IPv4. That's why, for me, it is hard to talk about "IPv6-only" mobile > operators. No, it's not. It's only you who focus on this. Everybody else (which has been said repeatedly) defines what the customer device sees, which means an IPv6 only PDP context carried over IPv4 GTP packets is defined by everybody (but you) as "IPv6 only". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 11 03:48:08 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DAB12EB0B for ; Thu, 11 Jan 2018 03:48:06 -0800 (PST) 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 uRRP1YvGTmgp for ; Thu, 11 Jan 2018 03:48:04 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB0612EB20 for ; Thu, 11 Jan 2018 03:47:59 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id h5so2457831lfj.2 for ; Thu, 11 Jan 2018 03:47:59 -0800 (PST) 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=swedUqsjSOzK1GE+1tO+qvAid1B7MQ1nuGtWi8CaFuk=; b=L4xdn2h8hU4qvlRTPVpMfBs7R6D29wWuh3urqYcn6WWhR7F1L7Y3ADYJhE004PXgy9 eEWrIytzOsHOsgPbtd0HGq4PEBv8DVfYu9pQazTP889z3J+uq1aumeEnsXGAcahaHZVJ hX1o+ONBwLtycRU4s5/qU3VewZqpYOab4c8m3bsxRYvcAF1f5nGc1FA9bDADRgiEehmc Rdzv3hO49Uc0LXiB8PTnZznWx2HB+oBnMn5CKIZ6MXQ2JfhZRvfBa5SZcIDrM3sQOio4 LgzptRnFe4fd/kS8lxcBoO0bCn4v5IG9q+drDIKx2jZKCYkrC/yS1KO60O08uxRhL7aE s6kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=swedUqsjSOzK1GE+1tO+qvAid1B7MQ1nuGtWi8CaFuk=; b=n7doTN4XYQe18WeuNYrYDQxb66ESxswANE3BOsfe4VmmxdvFmBWoa+3JZCXcDVdTbS BYP3Wt9K7Zjdjj+Y71qiU2tUsOPutwvXmukRpA5dkW5rfsPpIV6dpw/LF5pfvOmXSvA2 hQ2FOJhgB1lRFV5VveF6o7YfELxIkTULDvbq8uXczWy5BsIYHzlRrLv7LopYIsJnFhwl JEmjYqcri+fmmUrKnn3YXcvNW6UQszefjhrm9Gz14GYBndpB3l+bOlwxtFilaDSgkQ4k 3Dd9QY2XOQZqIbvS/iV6C5HiA3kvoqOqIFU7QrnKTlntpUTY0ER1+XBeUUBLAuKAOZtn OvQg== X-Gm-Message-State: AKGB3mKlqvhmzwrMq2oUHSGlSopGrEHmudjROXjSshkDw0LWky50wc1F VhmJn1pQ1xblqwwt1Ktm8ekIvpt1OA4RkURYny2SfUzQ X-Google-Smtp-Source: ACJfBot+CGZUd6hzHjtajESLs5be5YbswPoSm0B20vWN/v6ZTPSB6EaWjFLxYLkYG4Qt8ftnU6EDOWdM47r0TxKyOJ8= X-Received: by 10.46.99.151 with SMTP id s23mr12585434lje.50.1515671277858; Thu, 11 Jan 2018 03:47:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.67.188 with HTTP; Thu, 11 Jan 2018 03:47:57 -0800 (PST) In-Reply-To: References: From: Thor-Henrik Kvandahl Date: Thu, 11 Jan 2018 12:47:57 +0100 Message-ID: To: Erik Kline Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c1aa6941cf30b05627eb89f" Archived-At: Subject: Re: [v6ops] Mobile: Happy DNSclientBalls X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 11:48:07 -0000 --94eb2c1aa6941cf30b05627eb89f Content-Type: text/plain; charset="UTF-8" Actually, in the updated "Happy Eyeballs" RFC8305, handling of multiple DNS server addresses are addressed and "queries SHOULD be sent over IPv6 first". Also you say Google has an open bug on RFC6724, sorting of nameservers. If I understand the RFCs correct, Android Oreo and Nougat (and also older?) terminals should change behavior and prefer IPv6 nameservers. Is this correct and can we expect a change ? 3.1 . Handling Multiple DNS Server Addresses "If multiple DNS server addresses are configured for the current network, the client may have the option of sending its DNS queries over IPv4 or IPv6. In keeping with the Happy Eyeballs approach, queries SHOULD be sent over IPv6 first (note that this is not referring to the sending of AAAA or A queries, but rather the address of the DNS server itself and IP version used to transport DNS messages). If DNS queries sent to the IPv6 address do not receive responses, that address may be marked as penalized and queries can be sent to other DNS server addresses. As native IPv6 deployments become more prevalent and IPv4 addresses are exhausted, it is expected that IPv6 connectivity will have preferential treatment within networks. If a DNS server is configured to be accessible over IPv6, IPv6 should be assumed to be the preferred address family. Client systems SHOULD NOT have an explicit limit to the number of DNS servers that can be configured, either manually or by the network. If such a limit is required by hardware limitations, the client SHOULD use at least one address from each address family from the available list." *--* *Thor-Henrik Kvandahl* 2018-01-11 8:57 GMT+01:00 Erik Kline : > We have an open bug to do RFC6724 sorting of nameservers. Haven't > gotten around to it just yet. > > As far as requirements go, I'm not aware of anything off the top of my > head. Carriers can (and do) try to require whatever they can dream > up, but that's separate. > > On 11 January 2018 at 16:46, Thor-Henrik Kvandahl > wrote: > > Hi, > > > > > > > > Does anyone know if there are defined requirements on behaviour for the > DNS > > client on a Mobile Node (MN/UE) connected to a dual stack APN where the > 3gpp > > IE container provisioned both IPv4 and IPv6 name servers? > > > > As far as I know it is up to the UE to prefer between the provisioned > name > > servers, and I think they should prefer IPv6 name servers. > > My Android Oreo and Nougat DNS clients uses only IPv4 for DNS requests > and I > > think it would be better for the NAT44(4) devices between the PGW and the > > resolver if the UE preferred to use the IPv6 name server(s). > > > > If there are no requirements for this, does anyone know the Google policy > > for Android on this? > > > > Iphone's seems to prefer the IPv6 name servers. > > > > > > > > > > -- > > > > Thor-Henrik Kvandahl > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --94eb2c1aa6941cf30b05627eb89f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Actually, in the updated=C2=A0"Happy Eyeballs" RFC8305, handl= ing of multiple DNS server addresses are=C2=A0addressed and "queries SHOULD= be sent over IPv6 first".
    Also you say Google has an open bug on=C2=A0RFC6724,=C2=A0sorting of nameservers.
    If I understand the RFCs correct, Android Oreo and No= ugat (and also older?) terminals should change behavior and=C2=A0prefer IPv6 nameservers.
    Is = this correct and can we expect a change ?

    3.1.  Handling Multiple =
DNS Server Addresses
    

   "If multiple DNS server addresses are configured for the current
   network, the client may have the option of sending its DNS queries
   over IPv4 or IPv6.  In keeping with the Happy Eyeballs approach,
   queries SHOULD be sent over IPv6 first (note that this is not
   referring to the sending of AAAA or A queries, but rather the address
   of the DNS server itself and IP version used to transport DNS
   messages).  If DNS queries sent to the IPv6 address do not receive
   responses, that address may be marked as penalized and queries can be
   sent to other DNS server addresses.

   As native IPv6 deployments become more prevalent and IPv4 addresses
   are exhausted, it is expected that IPv6 connectivity will have
   preferential treatment within networks.  If a DNS server is
   configured to be accessible over IPv6, IPv6 should be assumed to be
   the preferred address family.

   Client systems SHOULD NOT have an explicit limit to the number of DNS
   servers that can be configured, either manually or by the network.
   If such a limit is required by hardware limitations, the client
   SHOULD use at least one address from each address family from the
   available list."

    <= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0)">
    =
    =
    --
    Thor-Henrik Kva= ndahl

    2018-01-11 8:57 GMT+01:00 Erik Kline <ek@google= .com>:
    W= e have an open bug to do RFC6724 sorting of nameservers.=C2=A0 Haven't<= br> gotten around to it just yet.

    As far as requirements go, I'm not aware of anything off the top of my<= br> head.=C2=A0 Carriers can (and do) try to require whatever they can dream up, but that's separate.

    On 11 January 2018 at 16:46, Thor-Henrik Kvandahl <kvandahl@gmail.com> wrote:
    > Hi,
    >
    >
    >
    > Does anyone know if there are defined requirements on behaviour for th= e DNS
    > client on a Mobile Node (MN/UE) connected to a dual stack APN where th= e 3gpp
    > IE container provisioned both IPv4 and IPv6 name servers?
    >
    > As far as I know it is up to the UE to prefer between the provisioned = name
    > servers, and I think they should prefer IPv6 name servers.
    > My Android Oreo and Nougat DNS clients uses only IPv4 for DNS requests= and I
    > think it would be better for the NAT44(4) devices between the PGW and = the
    > resolver if the UE preferred to use the IPv6 name server(s).
    >
    > If there are no requirements for this, does anyone know the Google pol= icy
    > for Android on this?
    >
    > Iphone's seems to prefer the IPv6 name servers.
    >
    >
    >
    >
    > --
    >
    > Thor-Henrik Kvandahl
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops=
    >

    --94eb2c1aa6941cf30b05627eb89f-- From nobody Thu Jan 11 03:54:38 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FD612EB11 for ; Thu, 11 Jan 2018 03:54:37 -0800 (PST) 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 F7E6N9FMwu_m for ; Thu, 11 Jan 2018 03:54:36 -0800 (PST) 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 E56B112D779 for ; Thu, 11 Jan 2018 03:54:35 -0800 (PST) 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 w0BBsYpT028434; Thu, 11 Jan 2018 12:54:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 068D7207468; Thu, 11 Jan 2018 12:54:34 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E3566207444; Thu, 11 Jan 2018 12:54:33 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0BBsXXS025810; Thu, 11 Jan 2018 12:54:33 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> <038bb6d0-4dec-b249-e9bc-f4cbf09f59d3@gmail.com> From: Alexandre Petrescu Message-ID: <3707b808-f796-3ffe-a985-3b930e2a24d1@gmail.com> Date: Thu, 11 Jan 2018 12:54:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 11:54:38 -0000 Le 11/01/2018 à 12:47, Mikael Abrahamsson a écrit : > On Thu, 11 Jan 2018, Alexandre Petrescu wrote: > >> But do not forget that there is no operator that transports GTP in >> IPv6, even when that is for "IPv6-only" smartphones.  They all >> transport in on IPv4.  That's why, for me, it is hard to talk about >> "IPv6-only" mobile operators. > > No, it's not. It's only you who focus on this. Everybody else (which has > been said repeatedly) defines what the customer device sees, which means > an IPv6 only PDP context carried over IPv4 GTP packets is defined by > everybody (but you) as "IPv6 only". I agree that most people consider "IPv6 only" in mobile networks to mean IPv6 PDP Type, as opposed to the IPv4IPv6 PDP Type. When times comes, maybe we will want to to write down a common definition of "IPv6 only", and then we'll see. Alex > From nobody Thu Jan 11 04:06:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6B12EB12 for ; Thu, 11 Jan 2018 04:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9839Y8H8jYMb for ; Thu, 11 Jan 2018 04:06:52 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E30D12EB10 for ; Thu, 11 Jan 2018 04:06:52 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id c78so893375ywb.13 for ; Thu, 11 Jan 2018 04:06:52 -0800 (PST) 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=3ZWiZnRPNRYrprCTLD0hwWDKIeij9Q5YBvfoq970goM=; b=ZTLuNqwE+kBb2FEQPU/qJAvBp1UTdgUGyyJ9iNWRi3U8pUYjz2DzqiphN46zAyf/e8 /5sL4IN2aNZu0tynAadSZbw7dhVtXW5rVURyxY1XAHoRrU7O2oW5c7Au35PpgdF8vWf8 vpfLjBYbK/S19JUqzVZAXEk/eWFChiUIADO+B9lMndPV/6ZDYtjlR6U7XhEMdoRF+JUv Q7aOAaVyPM1p//sRZAJgKJ5YgR/gQ3Cm8Ko5aAfLsGfOh/J8sQO1yo9CMpfWnGnJqzHI oLb9Q79RsYSl9g8gQIaGggDZo75KOdA+pJA83iCmSYYzxO6FUuQ1ptVS1JgTGflnjQ9Q rcTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=3ZWiZnRPNRYrprCTLD0hwWDKIeij9Q5YBvfoq970goM=; b=bWGjDkfJHY+o+0MB8NJ+1n2lwHeVkLvLV1ykznC9dQtMqNt/cHR/E5IPL9qT7OMkzs IDYEuclfK2Y4toGvCIId/gtwK2NRe87fOLR4LfnnQJ14lqlWvCwbj4tG3MOdSdJWTmk6 /CwM22gJLVt5YfzSw1GMLmteIK0AUKYPf6YLV6VDqwtz2JnIwTZGhHNAHCwCKoUEFRRu GQokbTMIK/jEUaDIgHg3gS+3RMriW6nfzdqE/2JLCiysRZoVAbpen5BBxZJEs2yB3uJt BPJgSOdvtxs3UdarXZ8ePCb406Ejk5LQpA864pFRJm1c+qAhgWNUhwHj/1gnJ2PG2ZBA zPoA== X-Gm-Message-State: AKGB3mLGFuicUAIxDBZbraW5BywtkcOnyKc2qGCZT33KSYp5nanEjiuC S0jZt8zcprdx45jQhaY66j8B9XsJqyOElzkeq78sY62A X-Google-Smtp-Source: ACJfBosEX/ClwgWVhc8JKnZzrXGgbMdm1K4nQlO0OEouKwd7UwH96gU127M7mzw53vU0YJQKH5nevXM/qcBFixIGMvA= X-Received: by 10.13.217.80 with SMTP id b77mr12636047ywe.123.1515672411305; Thu, 11 Jan 2018 04:06:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.167 with HTTP; Thu, 11 Jan 2018 04:06:30 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Thu, 11 Jan 2018 21:06:30 +0900 Message-ID: To: Thor-Henrik Kvandahl Cc: "v6ops@ietf.org WG" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c087654b5161705627efbe7" Archived-At: Subject: Re: [v6ops] Mobile: Happy DNSclientBalls X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 12:06:54 -0000 --94eb2c087654b5161705627efbe7 Content-Type: text/plain; charset="UTF-8" You can "expect a change" in the sense that it is something we want to fix. When it is ultimately fixed it will effectively only apply to releases going forward from the date of the fix (i.e. it will not be backported to contemporaneous nor prior releases). On 11 January 2018 at 20:47, Thor-Henrik Kvandahl wrote: > Actually, in the updated "Happy Eyeballs" RFC8305, handling of multiple DNS > server addresses are addressed and "queries SHOULD be sent over IPv6 first". > Also you say Google has an open bug on RFC6724, sorting of nameservers. > If I understand the RFCs correct, Android Oreo and Nougat (and also older?) > terminals should change behavior and prefer IPv6 nameservers. > Is this correct and can we expect a change ? > > 3.1. Handling Multiple DNS Server Addresses > > "If multiple DNS server addresses are configured for the current > network, the client may have the option of sending its DNS queries > over IPv4 or IPv6. In keeping with the Happy Eyeballs approach, > queries SHOULD be sent over IPv6 first (note that this is not > referring to the sending of AAAA or A queries, but rather the address > of the DNS server itself and IP version used to transport DNS > messages). If DNS queries sent to the IPv6 address do not receive > responses, that address may be marked as penalized and queries can be > sent to other DNS server addresses. > > As native IPv6 deployments become more prevalent and IPv4 addresses > are exhausted, it is expected that IPv6 connectivity will have > preferential treatment within networks. If a DNS server is > configured to be accessible over IPv6, IPv6 should be assumed to be > the preferred address family. > > Client systems SHOULD NOT have an explicit limit to the number of DNS > servers that can be configured, either manually or by the network. > If such a limit is required by hardware limitations, the client > SHOULD use at least one address from each address family from the > available list." > > > > -- > Thor-Henrik Kvandahl > > 2018-01-11 8:57 GMT+01:00 Erik Kline : >> >> We have an open bug to do RFC6724 sorting of nameservers. Haven't >> gotten around to it just yet. >> >> As far as requirements go, I'm not aware of anything off the top of my >> head. Carriers can (and do) try to require whatever they can dream >> up, but that's separate. >> >> On 11 January 2018 at 16:46, Thor-Henrik Kvandahl >> wrote: >> > Hi, >> > >> > >> > >> > Does anyone know if there are defined requirements on behaviour for the >> > DNS >> > client on a Mobile Node (MN/UE) connected to a dual stack APN where the >> > 3gpp >> > IE container provisioned both IPv4 and IPv6 name servers? >> > >> > As far as I know it is up to the UE to prefer between the provisioned >> > name >> > servers, and I think they should prefer IPv6 name servers. >> > My Android Oreo and Nougat DNS clients uses only IPv4 for DNS requests >> > and I >> > think it would be better for the NAT44(4) devices between the PGW and >> > the >> > resolver if the UE preferred to use the IPv6 name server(s). >> > >> > If there are no requirements for this, does anyone know the Google >> > policy >> > for Android on this? >> > >> > Iphone's seems to prefer the IPv6 name servers. >> > >> > >> > >> > >> > -- >> > >> > Thor-Henrik Kvandahl >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > > > --94eb2c087654b5161705627efbe7 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgsKeDvgtroAV7uTwYF9ndaN2wAg8p91qU /343VYuHXe4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMTEx MTIwNjUxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGgpLOJLJS6SmSOITZamV9cps6UYb55RcnLPy/QM8RoBHbQTLDFG AmlmfkH1B7z6yxMqO42aETLJJYlSaBNGkjnxk1vDHlPnSSnZXNZdhhqQ+k4WXoI6hTCog/m1tESf gr4agNFVHr3txGUh8R6HWyZH/jaHYoUY4LhP6hxXVWbwFElfqehqWISwO3y6gs7zlG3lSPRdUc8r W31c74OUo/WISKaodurVZldkrKOn4sZ4aVr4Q25kpqmmWOGS0pmlZsyBRf2nizVqBpyf5Cy9Rt4k BD/jdrsyrOaqzws8hXWkacmiCYVshyuy1O/R1ZHPXE1Pib8mnL61pbuPDQJ6M0I= --94eb2c087654b5161705627efbe7-- From nobody Thu Jan 11 08:10:27 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A712D863 for ; Thu, 11 Jan 2018 08:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 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_FONT_FACE_BAD=0.981, 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 Fl1EkQP3bq8D for ; Thu, 11 Jan 2018 08:10:23 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5127812D860 for ; Thu, 11 Jan 2018 08:10:23 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id g1so6550486wmg.2 for ; Thu, 11 Jan 2018 08:10:23 -0800 (PST) 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=FWRkNKiaAOcLHCepjuJ4Zt/Hf7bJnFvpeiy9G0xG3X8=; b=EzVpGKLLVazWqJjXaF092uFK8U3WhxaNcuDGgT9/QOTBocJj031UUor/r082kmVcFz xIZylvqzQfo3ADYS5gka86mFcdn8qjx7oG5Q7dpr4WqPohhFWd/7NutOXy9xoPQU6CLi uOjGcmmiSc+6t5ERA73lhrzKjmlbY+bovysJlT1byMv6IVNAdTgAp9+xvvlQ1UofPodW xV1nptuZ/TyOUoqxuq1B0vTQvYqmfTxz8S6YI99FLw2sEKFP6mPo6p8u7iHq+ZPSCKqY +4IySI1fL2AKJ8Sw+P8SiiVfiR5fHxkbxWY3e/4VKiw9ZGWbVVBClD3JLvahMHiOPdqc zu/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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FWRkNKiaAOcLHCepjuJ4Zt/Hf7bJnFvpeiy9G0xG3X8=; b=YiPQzcIUgsVvgYjxN/ppN7gVCoKlvYODohj1ZLTJs2bwvfrdtua7D3r25rWBlML/nL z20XXJF/bzN+f0jgziy5fJzDN2hP/X+Hye4lMTAuqGTrjp1gPM85HJxVjiWrCkp19Wva qp/OhvuHHgft6xboxU6N0vZveRqcZaMuFfZwM8vR10zHcFPAlFd3bL51hQVsJhtCwPVs o4pQx3RkZ+RGJ20Wu4RnNni90aHp2s7Kx2FTq+jMeSLavpCL5G+cYNg457P3V/A8ows+ AcardTY4ymXUXPTKr4eod6sJTyEFEieN6CQT3fWnWJdqQs6CfBcDgDBzC7FcCXf1dQf3 AWnQ== X-Gm-Message-State: AKwxytcxXIEvkE0kfzJzKoc3wLRS7quQr3e7zfTBsnzCc35AOFYR3vkl 7VIdeK7rv6vD1v2gyK0Fo2eRUiBL6BueavYKNCo= X-Google-Smtp-Source: ACJfBosVva45OKrsYen7ARH+/iC3w9cebGlnQzj9bz5XTdwUmz5BKq0U+P4/7GVI5IInMRMG8bjndXTJJLkOuA4IFDg= X-Received: by 10.28.91.142 with SMTP id p136mr1568834wmb.55.1515687021581; Thu, 11 Jan 2018 08:10:21 -0800 (PST) MIME-Version: 1.0 References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> In-Reply-To: From: Ca By Date: Thu, 11 Jan 2018 16:10:10 +0000 Message-ID: To: Mikael Abrahamsson Cc: Kossut Tomasz - Hurt , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a11444a7e831fb205628262c9" Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 16:10:26 -0000 --001a11444a7e831fb205628262c9 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 11, 2018 at 3:45 AM Mikael Abrahamsson wrote: > On Thu, 11 Jan 2018, Kossut Tomasz - Hurt wrote: > > > How many IPv6-only mobile customers we have? > > If you're by this referring to single IPv6 PDP context customers, then at > least tens of millions, perhaps a few hundreds of millions. > > https://getipv6.info/display/IPv6/3GPP+Mobile+Networks > > "... IPv6-only (e.g. T-Mobile USA, Orange Poland, Telenor Norway) PDP/PDN > bearers. " > 464XLAT: SK Telecom, BT/EE, Bouygues France, Telsta Australia, Sprint US, Rogers CA, T-Mobile US, Orange Poland ... Afaik, T-Mobile US is the only one with deployed HEv2 for iPhones. Come on in, the water is fine. > I know at least T-Mobile USA uses this approach, and I'd imagine they have > tens of millions of customers just there. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11444a7e831fb205628262c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    On Thu, Jan 11, 2018 = at 3:45 AM Mikael Abrahamsson <swmik= e@swm.pp.se> wrote:
    On Thu, = 11 Jan 2018, Kossut Tomasz - Hurt wrote:

    > How many IPv6-only mobile customers we have?

    If you're by this referring to single IPv6 PDP context customers, then = at
    least tens of millions, perhaps a few hundreds of millions.

    https://getipv6.info/display/IPv6/3GPP+Mobile+= Networks

    "... IPv6-only (e.g. T-Mobile USA, Orange Poland, Telenor Norway) PDP/= PDN
    bearers. "

    464XLAT: SK Telecom, BT/EE, Bouygues France, Telsta Australia, S= print US, Rogers CA, T-Mobile US, Orange Poland ...

    Afaik, T-Mobile US is the only one with deploy= ed HEv2 for iPhones.=C2=A0 Come on in, the water is fine.=C2=A0

    =

    I know at least T-Mobile USA uses this approach, and I'd imagine they h= ave
    tens of millions of customers just there.

    --
    Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    --001a11444a7e831fb205628262c9-- From nobody Thu Jan 11 09:18:23 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302901200C5 for ; Thu, 11 Jan 2018 09:18:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-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=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo2jJCSRXouw for ; Thu, 11 Jan 2018 09:18:16 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAABA12DA03 for ; Thu, 11 Jan 2018 09:18:15 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 17:18:07 +0000 Received: from smtpe1.intersmtp.com (10.187.98.10) by EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 11 Jan 2018 17:18:12 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.211) by smtpe1.intersmtp.com (62.239.224.234) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 17:18:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SlcSMHETf765UzlTRcC4JkFkdUd2i3CV4CLa8Kxcf3k=; b=DNXU/GrJie0drS88brJcy/95CShLTU+puSfTe1TkbGCdJLBJxfdj4IPI2thAtwD2/AD7MC4Svaz0++PbxqM4IheXSDX0NP+2BoCSMMd1vVGMuceqdfOcB8pFfJ5q/QbHgvErkLFKsbz1Fnm6HR+Vipk0Kpghxp5z5NYMF6f4Khg= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB0113.GBRP123.PROD.OUTLOOK.COM (10.167.24.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Thu, 11 Jan 2018 17:18:10 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0386.009; Thu, 11 Jan 2018 17:18:10 +0000 From: To: , CC: , Thread-Topic: [v6ops] IPv6-only mobile ISP alliance Thread-Index: AdOKyTmwgK4OaRlRQjS2PFoi0LREGQACHP2AAAk+dAAAAkQ1gA== Date: Thu, 11 Jan 2018 17:18:10 +0000 Message-ID: References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [77.97.239.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P123MB0113; 7:82nVVvk0MX7old4kLj8BaKXupf/2bfn5L2Ujc8nRjrp6bBqGqqi20dNWuRVuR3EGfC6FqIcUNmDN2d9Eo+3Hqw+hv+nckZXamtZgPljNssoNQQGf/5EDC3cCl6dscGKUN+D2qkoTCWobwJXzXZOiKCwk8f0vA/gHEHWgXPScqdfE1JMsw/41Xbup08JH04gDR6uD7oSEeMIToC/+IRWgUSxifFq18Hu8tIQs5X3uxUlDYGmOgMstpZ9EulfR8+Lv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7fae3e68-9354-475a-e587-08d559174a2b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020069)(4652020)(4534099)(4602075)(4627195)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:LO1P123MB0113; x-ms-traffictypediagnostic: LO1P123MB0113: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231023)(944501134)(6041268)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:LO1P123MB0113; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:LO1P123MB0113; x-forefront-prvs: 0549E6FD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(39860400002)(376002)(366004)(396003)(189003)(199004)(6506007)(110136005)(6306002)(54906003)(9686003)(33656002)(54896002)(77096006)(53936002)(55016002)(316002)(6436002)(86362001)(3846002)(105586002)(790700001)(7696005)(74316002)(6246003)(478600001)(8936002)(25786009)(5880100001)(8676002)(81156014)(66066001)(2906002)(76176011)(81166006)(7736002)(99286004)(3280700002)(558084003)(102836004)(68736007)(6116002)(3660700001)(97736004)(2900100001)(39060400002)(106356001)(14454004)(59450400001)(229853002)(2950100002)(5660300001)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0113; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cUjeWa828pr+lK366BCcgNsIuLYoNbbv896mADfkQXr/rJqWmndRe9nhnWFrwjd0znw070c6QWi/B6U4e0scHA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB0116102CDA3EECEBBFB9DE05EA160LO1P123MB0116GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7fae3e68-9354-475a-e587-08d559174a2b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2018 17:18:10.4897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0113 Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 17:18:19 -0000 --_000_LO1P123MB0116102CDA3EECEBBFB9DE05EA160LO1P123MB0116GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo0NjRYTEFUOiBTSyBUZWxlY29tLCBCVC9FRSwgQm91eWd1ZXMgRnJhbmNlLCBUZWxzdGEgQXVz dHJhbGlhLCBTcHJpbnQgVVMsIFJvZ2VycyBDQSwgVC1Nb2JpbGUgVVMsIE9yYW5nZSBQb2xhbmQg Li4uDQoNCkFmYWlrLCBULU1vYmlsZSBVUyBpcyB0aGUgb25seSBvbmUgd2l0aCBkZXBsb3llZCBI RXYyIGZvciBpUGhvbmVzLiAgQ29tZSBvbiBpbiwgdGhlIHdhdGVyIGlzIGZpbmUuDQoNCkNvbmdy YXR1bGF0aW9ucywgZ29vZCB3b3JrIENhbWVyb24NCg== --_000_LO1P123MB0116102CDA3EECEBBFB9DE05EA160LO1P123MB0116GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6I0U5RUJFRSI+NDY0WExBVDogU0sgVGVsZWNvbSwg QlQvRUUsIEJvdXlndWVzIEZyYW5jZSwgVGVsc3RhIEF1c3RyYWxpYSwgU3ByaW50IFVTLCBSb2dl cnMgQ0EsIFQtTW9iaWxlIFVTLCBPcmFuZ2UgUG9sYW5kIC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjti YWNrZ3JvdW5kOiNFOUVCRUUiPkFmYWlrLCBULU1vYmlsZSBVUyBpcyB0aGUgb25seSBvbmUgd2l0 aCBkZXBsb3llZCBIRXYyIGZvciBpUGhvbmVzLiZuYnNwOyBDb21lIG9uIGluLCB0aGUgd2F0ZXIg aXMgZmluZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPkNvbmdyYXR1bGF0aW9ucywgZ29vZCB3b3JrIENhbWVyb248L2k+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_LO1P123MB0116102CDA3EECEBBFB9DE05EA160LO1P123MB0116GBRP_-- From nobody Thu Jan 11 09:18:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D00A1200C5 for ; Thu, 11 Jan 2018 09:18:47 -0800 (PST) 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 vxzg5Jmu8ifx for ; Thu, 11 Jan 2018 09:18:44 -0800 (PST) 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 AA00812EBEF for ; Thu, 11 Jan 2018 09:18:44 -0800 (PST) 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 w0BHIhib004487 for ; Thu, 11 Jan 2018 18:18:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0EDC92079DE for ; Thu, 11 Jan 2018 18:18:43 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0566B207991 for ; Thu, 11 Jan 2018 18:18:43 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0BHIg0R014766 for ; Thu, 11 Jan 2018 18:18:42 +0100 To: v6ops@ietf.org References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> From: Alexandre Petrescu Message-ID: Date: Thu, 11 Jan 2018 18:18:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 17:18:47 -0000 Le 11/01/2018 à 17:10, Ca By a écrit : > > On Thu, Jan 11, 2018 at 3:45 AM Mikael Abrahamsson > wrote: > > On Thu, 11 Jan 2018, Kossut Tomasz - Hurt wrote: > > > How many IPv6-only mobile customers we have? > > If you're by this referring to single IPv6 PDP context customers, > then at > least tens of millions, perhaps a few hundreds of millions. > > https://getipv6.info/display/IPv6/3GPP+Mobile+Networks > > "... IPv6-only (e.g. T-Mobile USA, Orange Poland, Telenor Norway) > PDP/PDN > bearers. " > > > 464XLAT: SK Telecom, BT/EE, Bouygues France, Telsta Australia, Sprint > US, Rogers CA, T-Mobile US, Orange Poland ... ... also operator named "Reliance JIO" situated in India. There must be something in Norway as well, something like 'Telenor' if I remember correctly, it was the first one to do true IPv6 to smartphone (not 464XLAT). Some operators also still propose true IPv6 to smartphones (not 464XLAT). > Afaik, T-Mobile US is the only one with deployed HEv2 for iPhones.  Come > on in, the water is fine. And Bouygues France is probably the only one who does 464XLAT only for Android and not for iPhones. Alex > > > I know at least T-Mobile USA uses this approach, and I'd imagine > they have > tens of millions of customers just there. > > -- > 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 > From nobody Thu Jan 11 09:51:19 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8EF12EC01 for ; Thu, 11 Jan 2018 09:51:15 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-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=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqjY19AMGME7 for ; Thu, 11 Jan 2018 09:51:13 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F3D12EC12 for ; Thu, 11 Jan 2018 09:51:07 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 17:51:17 +0000 Received: from smtpe1.intersmtp.com (10.187.98.11) by EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 11 Jan 2018 17:51:04 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (213.199.154.245) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 17:50:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IMD+1ujl0a85GkasPu5vAJyhL8jwTJVpMIO+ZP2NbYo=; b=LnN9EIeBDK+vnr8+6qRLFkI2FMOCTJ6mPu5qxjUjIV5HMHD/WbNHvCW4yGx1qo+g93f5Y2QCGTN284v0F+dBxmxihoIN0IJumJiuk+KVKKp5QMuQXqg8349lbVSDsXSpC6SQm7HEZFOqbceKSMNSQbJVQehkpOU/JDr20spYPmY= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1SPR8PMB27.GBRP123.PROD.OUTLOOK.COM (10.167.25.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Thu, 11 Jan 2018 17:51:02 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0386.009; Thu, 11 Jan 2018 17:51:02 +0000 From: To: CC: Thread-Topic: [v6ops] IPv6-only mobile ISP alliance Thread-Index: AdOKyTmwgK4OaRlRQjS2PFoi0LREGQABE7+AAAEX2IAAAEJ2gAAMQWBg Date: Thu, 11 Jan 2018 17:51:02 +0000 Message-ID: References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> <038bb6d0-4dec-b249-e9bc-f4cbf09f59d3@gmail.com> <3707b808-f796-3ffe-a985-3b930e2a24d1@gmail.com> In-Reply-To: <3707b808-f796-3ffe-a985-3b930e2a24d1@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [77.97.239.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1SPR8PMB27; 7:d4OSmWD60v7i7lr5baay4lcer3zF33oTOIAxB9rdL2HXBwClOYQxQTzkJIL7EyAARsJlYuDCCsEo8Xo1q7l8IJsGVDN/WetTyLi8VLQtxd1TmHOeXKayJJf+m5YHyG63ETeE8+bzpH/i9kIMiW/JxKl6LEZJNukP23HLkysz9psCO4jFZIP2hOQGft5AQ/nJLawdDs+FJpdPq1B7WfH1NyfLVYqgUt+vHCbLGWYem/dVme6TgNmqf2yMkEUAz7ZD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 54b0f8a8-3720-424f-0517-08d5591be1a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:LO1SPR8PMB27; x-ms-traffictypediagnostic: LO1SPR8PMB27: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:LO1SPR8PMB27; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:LO1SPR8PMB27; x-forefront-prvs: 0549E6FD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(39860400002)(376002)(366004)(189003)(199004)(76176011)(8936002)(74316002)(55016002)(316002)(93886005)(99286004)(4326008)(14454004)(9686003)(7736002)(6246003)(2906002)(6436002)(229853002)(3280700002)(3660700001)(6916009)(106356001)(7696005)(39060400002)(77096006)(305945005)(8676002)(6116002)(81166006)(68736007)(81156014)(53936002)(97736004)(25786009)(86362001)(6506007)(478600001)(105586002)(66066001)(2900100001)(102836004)(33656002)(5660300001)(2950100002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1SPR8PMB27; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Qe+QBVaj3HVvBgFrT1jn90ZInhEjX9uzUXzKjHTT/aPsxHJdQMnS6/1aseFXmqp1sVilCsiBuy/GUOrKm9mvnA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 54b0f8a8-3720-424f-0517-08d5591be1a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2018 17:51:02.6286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1SPR8PMB27 Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jan 2018 17:51:15 -0000 SSBhZ3JlZSB0aGF0IG1vc3QgcGVvcGxlIGNvbnNpZGVyICJJUHY2IG9ubHkiIGluIG1vYmlsZSBu ZXR3b3JrcyB0byBtZWFuDQpJUHY2IFBEUCBUeXBlLCBhcyBvcHBvc2VkIHRvIHRoZSBJUHY0SVB2 NiBQRFAgVHlwZS4NCg0KV2hlbiB0aW1lcyBjb21lcywgbWF5YmUgd2Ugd2lsbCB3YW50IHRvIHRv IHdyaXRlIGRvd24gYSBjb21tb24gZGVmaW5pdGlvbiBvZiAiSVB2NiBvbmx5IiwgYW5kIHRoZW4g d2UnbGwgc2VlLg0KDQpBbGV4LCBXaGVuIHNlZWtpbmcgYSBjb21tb24gZGVmaW5pdGlvbiBpdCBp cyBiZXN0IHRvIGdvIHdpdGggdGhlIG9uZSBtb3N0IHBlb3BsZSBjb25zaWRlciDwn5iKDQo= From nobody Thu Jan 11 22:53:27 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DCD1289B0 for ; Thu, 11 Jan 2018 22:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 zAoKGKhgTTjv for ; Thu, 11 Jan 2018 22:53:24 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F291277BB for ; Thu, 11 Jan 2018 22:53:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 72410B0; Fri, 12 Jan 2018 07:53:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1515740000; bh=ympkdd0zGJ4eoTQT4ZCtnLCbWvdAJLyicgreq7eDsQM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tiNRIaGIuHHL0SSvtJdlwms1PN+4lBlDVfy6DKhD610+jPHNxi4EK6ThdnvvZLCEp 0cF81gWlsF7ZZkj/3rlvRT/LSLsnRUTYj2R+kRj7J6Kquja56UcSVUB2ZkhobdaoKf kXB/4mTsOUg9ZIU1Zlx43a6WRh3ic0I1AjNJvRXs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 688FD9F; Fri, 12 Jan 2018 07:53:20 +0100 (CET) Date: Fri, 12 Jan 2018 07:53:20 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2018 06:53:26 -0000 On Thu, 11 Jan 2018, Alexandre Petrescu wrote: > Some operators also still propose true IPv6 to smartphones (not > 464XLAT). Yes, there are many tens of millions of active users on IPv4v6 PDP contexts as well. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jan 12 01:45:18 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0B1126C23 for ; Fri, 12 Jan 2018 01:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EAwHhbrSs6q for ; Fri, 12 Jan 2018 01:45:12 -0800 (PST) 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 8B8DE12E055 for ; Fri, 12 Jan 2018 01:45:12 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=34766 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 1eZvte-0003er-9t; Fri, 12 Jan 2018 10:45:10 +0100 Date: Fri, 12 Jan 2018 10:45:09 +0100 From: Tore Anderson To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20180112104509.3eb1f5f6@echo.ms.redpill-linpro.com> In-Reply-To: References: <542c87df1c214bdd9457fab0f8874fc7@orange.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] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2018 09:45:14 -0000 * Alexandre Petrescu > There must be something in Norway as well, something like 'Telenor' if I= =20 > remember correctly, it was the first one to do true IPv6 to smartphone=20 > (not 464XLAT). =C2=ABTrue IPv6=C2=BB is a prerequisite for 464XLAT, so this statement does= not really make any sense. That said, Telenor was not the first. I think that award might go to Verizon Wireless in the United States. I am not certain, but they definitively arrived earlier to the IPv6 party than Telenor did at least. Telenor did initially launch 464XLAT for a small number of UEs, but this approach was abandoned in favour of dual stack. Their deployment is currently just shy of 75% IPv6 according to my own measurements: https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html There's also another small Norwegian PLMN called Ice that has rolled out IPv6. As far as I've been told they are also using dual stack, not 464XLAT. Tore From nobody Fri Jan 12 01:55:55 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6F1267BB for ; Fri, 12 Jan 2018 01:55:54 -0800 (PST) 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 7ALddfJZ_S8C for ; Fri, 12 Jan 2018 01:55:52 -0800 (PST) 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 7CD39124239 for ; Fri, 12 Jan 2018 01:55:52 -0800 (PST) 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 w0C9tkAr124406; Fri, 12 Jan 2018 10:55:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0E109208112; Fri, 12 Jan 2018 10:55:46 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01FE62080E6; Fri, 12 Jan 2018 10:55:46 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0C9tjDR017457; Fri, 12 Jan 2018 10:55:45 +0100 To: Tore Anderson Cc: v6ops@ietf.org References: <542c87df1c214bdd9457fab0f8874fc7@orange.com> <20180112104509.3eb1f5f6@echo.ms.redpill-linpro.com> From: Alexandre Petrescu Message-ID: <72640ffd-5fb2-94eb-b0ad-56f791f97aec@gmail.com> Date: Fri, 12 Jan 2018 10:55:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180112104509.3eb1f5f6@echo.ms.redpill-linpro.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6-only mobile ISP alliance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2018 09:55:54 -0000 Le 12/01/2018 à 10:45, Tore Anderson a écrit : > * Alexandre Petrescu > >> There must be something in Norway as well, something like 'Telenor' if I >> remember correctly, it was the first one to do true IPv6 to smartphone >> (not 464XLAT). > > «True IPv6» is a prerequisite for 464XLAT, so this statement does not > really make any sense. Ah. I definitely have to work my vocabulary. > That said, Telenor was not the first. I think that award might go to > Verizon Wireless in the United States. In terms of years, IIRC, I received an invitation in year approximate 2007 to go to Norway and try native IPv6 on mobile phone there (it was straight IPv6 on phone, not IPv6-in-IPv4, which was done even earlier, like 2001). > I am not certain, but they > definitively arrived earlier to the IPv6 party than Telenor did at > least. Could be. > Telenor did initially launch 464XLAT for a small number of UEs, but > this approach was abandoned in favour of dual stack. Their deployment > is currently just shy of 75% IPv6 according to my own measurements: > > https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html These figures are impressive, showing a majority of traffic is IPv6. It is very encouraging. > There's also another small Norwegian PLMN called Ice that has rolled > out IPv6. As far as I've been told they are also using dual stack, not > 464XLAT. Ah, good to know, this dual stack. ALex From nobody Fri Jan 12 06:58:59 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32510127775 for ; Fri, 12 Jan 2018 06:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_8q-cU2KCHR for ; Fri, 12 Jan 2018 06:58:53 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 078A612E889 for ; Fri, 12 Jan 2018 06:58:53 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id d10so5243549oti.7 for ; Fri, 12 Jan 2018 06:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=aZxZGpG4s7WkFV70GdmAX58I/gFwtjSY0JiHNXZXnYs=; b=AVNgbGxMaYcmv6dssX5MN5l/e0KuDMP+soAh1SD5SMgEj/mYxyH2zVgGtYFfpHAq9Z t/pWk+Qa5QyXwEhc4qyf1aHpVYyYKzHzhGBo7pgN/DNrTat8+hYgvo/ovSaBgEM2YZ8k Be8ntB4U2W0+r4g8MaGw9+tpHdIEnLGAs48bMbsXa6CNYFiqH2nV28sw8v9HreodN0MP 3g/q5NUh3+i5w8VBPPHZCxrIdzyLEZ4HVX5V7meXIT9Vx7eo08bdisi23rBPQ+4iwktq EdqTkrhGWRlmnWOJnaa5nDf4ZLS9VAVfw7Q1xQvj/zUxu0ScRiZCx98w6Z0HM9LsVo74 QAGQ== 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:message-id:references :to:date; bh=aZxZGpG4s7WkFV70GdmAX58I/gFwtjSY0JiHNXZXnYs=; b=m4vzKW3sVpzT5z7SgMAyrqZn0yYS7+OkE0ZsQkBR+cb9xScAyyb1nT0MXM5cTr/D3t khRhwRXUyrClPtHY1kikPaYvx/E14Oh3T3YYF0H+C+Z5Yebo0B7qmNf/Z/HRl2WLDnY1 3qBIynhNW8slbdvHFuVFRsu138ME3RUg4/Yq+H7c/7gYxHBXgjLiaq3vbj5K/AKkbj33 D70spSXf89d6H+C5ILuS1YFw5HmlzHmz4+TQlDk+MmDoT3/wxBeZMep0zqk0Vs/k46Vo WRFADEefvo5hsX+zLnQLTyYkDYIPuLt0SDXyEgW+T1xcMrp2XUpF7+E4cIxZdDtBFzdy urwg== X-Gm-Message-State: AKwxytdtPSPLRmpa7iuNDbSaNtT45otEm+r/GU6T/IEIlivM/ni+s7ze PW/JG23tVhEHuu2C6rHd8ZRcCicK X-Google-Smtp-Source: ACJfBouRzEQw0qzAVkv8S0ai1f74ZU0//3s5vQFBv+CIXAAYXS1UzZ8YOEuod+QdSR9EknY+jWitEA== X-Received: by 10.157.13.2 with SMTP id 2mr14927112oti.162.1515769132128; Fri, 12 Jan 2018 06:58:52 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::103f? ([2600:8802:5600:f7a::103f]) by smtp.gmail.com with ESMTPSA id h66sm3132451oig.12.2018.01.12.06.58.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 06:58:50 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_03716D39-E4AC-4D30-AD26-9B4B40DD4CFC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: References: <151320065528.29995.16506651199948659318.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" Date: Fri, 12 Jan 2018 06:58:49 -0800 X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [v6ops] Fwd: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vector Routing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2018 14:58:58 -0000 --Apple-Mail=_03716D39-E4AC-4D30-AD26-9B4B40DD4CFC Content-Type: multipart/alternative; boundary="Apple-Mail=_50023CF8-69E9-45B1-AB83-6E407D60E4DA" --Apple-Mail=_50023CF8-69E9-45B1-AB83-6E407D60E4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few weeks ago, I mentioned the chartering of the rift working group on = this list. A parallel group has started the chartering exercise, working = n BGP SPF. You may be interested to join it. > Begin forwarded message: >=20 > From: IETF Secretariat > Subject: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vector = Routing > Date: December 13, 2017 at 1:30:55 PM PST > To: "IETF Announcement List" > Cc: aretana.ietf@gmail.com, lsvr@ietf.org, gunter@vandevelde.cc, = victor@jvknet.com > Reply-To: ietf@ietf.org >=20 > A new IETF non-working group email list has been created. >=20 > List address: lsvr@ietf.org > Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dlsvr > To subscribe: https://www.ietf.org/mailman/listinfo/lsvr >=20 > Purpose: > This list is for discussion related to architectural, standardization = and manageability aspects for Link State Vector Routing. >=20 >=20 > For additional information, please contact the list administrators. >=20 > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr --Apple-Mail=_50023CF8-69E9-45B1-AB83-6E407D60E4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii A = few weeks ago, I mentioned the chartering of the rift working group on = this list. A parallel group has started the chartering exercise, working = n BGP SPF. You may be interested to join it.

    Begin = forwarded message:

    From: = IETF Secretariat <ietf-secretariat@ietf.org>
    Subject: = [Lsvr] New Non-WG = Mailing List: LSVR- Link State Vector Routing
    Date: = December 13, 2017 at 1:30:55 PM = PST
    To: = "IETF Announcement List" <ietf-announce@ietf.org>
    Cc: aretana.ietf@gmail.com, lsvr@ietf.org, gunter@vandevelde.cc, victor@jvknet.com
    Reply-To: = ietf@ietf.org

    A new IETF non-working group = email list has been created.

    List address: = lsvr@ietf.org
    Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dlsvr=
    To subscribe: https://www.ietf.org/mailman/listinfo/lsvr

    Purpose:
    This list is for = discussion related to architectural, standardization and manageability = aspects for Link State Vector Routing.


    For additional information, please contact the list = administrators.

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

    = --Apple-Mail=_50023CF8-69E9-45B1-AB83-6E407D60E4DA-- --Apple-Mail=_03716D39-E4AC-4D30-AD26-9B4B40DD4CFC 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpYzSkACgkQEhdRnd2G P+AgThAAjrUKUMAO7W7qCVnD1FzV7pY5BBcm2fq9x+Jg/x5Tkp8oE+Y8nO69GbvI 8H8+/Z8al+21kR0Gj24nahZvvCscPg/sQRht4OfpcSTIZBgxD+r5Cn889WQ9rj2C fCkLfhl4sdP1+nBakxHx/oCdVG3NXeryrcwM9AExMDBfnzoN1OTzD58SSAylgNjE sgCAT7a+AhUjAmDnbzy3ch2Cyf9gItcEFVLQNBKVofSqF8GQebhS+x6VPTzwhtdX ejP7Rbend+3ZpqOXDI6B/je+3QVpZb2h8Fm3Ye7HUJhjcEy770R7M/tn/ltejBTe Epl7tGtEXZxOuja4JOsXLjObLB3EhpzViY1bb2oTxg3PuQHpKxHsKLRQtCn5k24h hjhFvB5SoC9p5uap79wUQFS28KEA/NFpkIpC9tjJ2aSzq7lV2nQbp+gDDjSGJdCg TudW4FpzKXg3qQ/bBfN1Ekh+loYHzrZYin32Xy3OqM+nN21obJbpF6wCbGRCc6fo SddgWnaY9RWd56EMegqqc5P1GbOIaz45jkkmMU2bjA47Mrjv4htcNH+2xwFInbLE 7ZDLM+hdG34+rOlcoIiwI4a0g/SmIknhj2B32sbyOasZlB4r4cnnXCxyqemjUGJG +iqs1TgahMaw7xcpbyJ2esGMx9lhlXTQBZ+aCOa+slRYPQ9V3wI= =bbyF -----END PGP SIGNATURE----- --Apple-Mail=_03716D39-E4AC-4D30-AD26-9B4B40DD4CFC-- From nobody Fri Jan 12 07:04:37 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDF8127275 for ; Fri, 12 Jan 2018 07:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, 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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fkl-1ER4H2W for ; Fri, 12 Jan 2018 07:04:32 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0102.outbound.protection.outlook.com [104.47.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0AC1270A3 for ; Fri, 12 Jan 2018 07:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lEpRLpdoRbKMYIAsKngt/rPdl8KxwnXHcSdMwAJVfow=; b=E1Y9Z69LRSu5q97MFnMDYGOUQIeO44FxPmxepBAiTcQuABgJdmOEcwNwUUQ9dDOVCF37C6lzX2ynkYQhDUpPh49FBpwdvs4HbztMGH56A9GYWG+6rQYwFDUA7IKoAJTrNgtblcQKTtWk72kMaxgIgxAHtjvZighVHJm1IYyxQbg= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB1746.eurprd07.prod.outlook.com (10.167.215.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Fri, 12 Jan 2018 15:04:28 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::645d:a0f3:c36b:9aa3]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::645d:a0f3:c36b:9aa3%14]) with mapi id 15.20.0407.009; Fri, 12 Jan 2018 15:04:28 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Fred Baker , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Fwd: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vector Routing Thread-Index: AQHTi7XkbZDeCOpi+EinFsc485SpjKNwVW7g Date: Fri, 12 Jan 2018 15:04:28 +0000 Message-ID: References: <151320065528.29995.16506651199948659318.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [2a02:1810:4d67:a00:7c0a:3264:9d6d:66ee] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1746; 7:RKfRXas0ll7NFPePl7BZegfevQqbVZUGHjLIVki5St/NN09ZY7t4BUkEFs1gBnQ/BupXeV43CsW2WJoykhYC/2x7yDIBr+v5E8oeYHMJb1N9kHuWKMbcRM1L4+P25blvDV+fukaVdJjrJb7UNcw1wbUK4uvemaH0LxRSwuR5mAyZuAMXh7lZ53JJP7JruKJ7u9SNjdyGt464H4lsUUMivL8/F7dMbDWePbkvCcr7r2M5azN5EdxMiQ4IrRvY/2+8 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f0466ab1-104a-473e-17df-08d559cdc72f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM5PR0701MB1746; x-ms-traffictypediagnostic: AM5PR0701MB1746: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231023)(11241501184)(806099)(944501075)(3002001)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:AM5PR0701MB1746; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB1746; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(39380400002)(396003)(189003)(199004)(33656002)(2900100001)(606006)(105586002)(106356001)(81156014)(25786009)(110136005)(2950100002)(2906002)(790700001)(6116002)(53936002)(5250100002)(81166006)(14454004)(8676002)(53546011)(6506007)(68736007)(316002)(8936002)(3660700001)(966005)(478600001)(3280700002)(97736004)(39060400002)(236005)(9686003)(102836004)(54896002)(6306002)(55016002)(86362001)(5660300001)(74316002)(7736002)(6436002)(99286004)(19609705001)(59450400001)(6246003)(76176011)(7696005)(229853002)(437434002)(223123001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1746; H:AM5PR0701MB2836.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3pLMc+oTSvhbwQIHi6LHSevqEXAHztCC3ljbpw+PG+huHFisCqH1gmUowGo/tlk0dZ4QmKxTRnfZKkdURglPQ92itMhsTuNCOmW8TdK9yb08NM+6D5j+0yYcMnbdw2Qz spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB28366002452B3336E90911B5E0170AM5PR0701MB2836_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0466ab1-104a-473e-17df-08d559cdc72f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 15:04:28.6775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1746 Archived-At: Subject: Re: [v6ops] Fwd: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vector Routing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jan 2018 15:04:35 -0000 --_000_AM5PR0701MB28366002452B3336E90911B5E0170AM5PR0701MB2836_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Fred. Currently the charter is under discussion on LSVR email list. The proposed = draft charter: > [Note: Target audience, and discussions should happen on > lsvr@ietf.org, however "rtgwg", "idr" and "dcroutin= g" email lists have > been added as the concepts originated in those working groups] > > Since dcrouting@ietf100, a few people have been discussing a possible WG = charter for LSVR (Link State Vector Routing). > Here is what we have so far. Comments and improvements would be most wel= come. > > WG page is to be setup soon. > Subscription to LSVR mailing list: > https://www.ietf.org/mailman/listinfo/lsvr > > Feedback (comments, edits, corrections, etc) on the draft LSVR > charter is appreciated > > > ***** DRAFT CHARTER UPDATE - JAN 10 2018 ***** > > Charter: LSVR - Link State Vector Routing > > The Link-State Vector Routing (LSVR) Working Group is chartered to develo= p and document a hybrid routing protocol utilizing a combination of link-st= ate and path-vector routing mechanisms. The LSVR WG will utilize existing = the IPv4/IPv6 transport, packet formats, and error handling from BGP-4 (RFC= 4271). Additionally, the BGP-LS NLRI encoding mechanisms defined in RFC7752= are utilized to facilitate Link-State Vector (LSV) routing information dis= tribution. An LSV is intended to be specified as a data structure comprised= of a link identification, link attributes, neighbor information, cost towa= rd neighbors, and other attributes that are defined for control plane funct= ion and policy-based routing decisions. > > The LSVR specification is initially focused on operation within a single = datacenter (DC) with preliminary focus on specifying functionality within a= single distribution domain. Routing protocol functionality defined by LSV= R would be typically routing within a datacenter's underlay routing plane. > > In order to achieve the noted objective, the working group will focus on = standardization of protocol functionality, defining Link-State Vectors (LSV= s), and defining standard path-vector route selection utilizing existing Di= jkstra SPF based algorithm, BGP-4 protocol mechanics, and BGP-LS NRLI encod= ing. > > For the purposes of the initial work within the LSVR WG, and until furthe= r specified by the WG, the following definitions apply to this charter. > > - Link-State Vector - An LSV is intended to represent a data structure (d= ata set) comprised of link identification, link attributes, neighbor inform= ation, cost towards neighbors, and other potential attributes that can be u= tilized to make routing decisions. > - LSVR Distribution Domain - Initially scoped as a set of participating L= SVR nodes in a single administrative domain. > > > The LSVR WG is chartered to deliver the following documents: > > - Publish Applicability Statement for the use of LSVR in the > Datacenter - Target Status: Informational > - Publish specification document describing LSV with standard Dijkstra > SPF route/path selection (calculation) utilizing existing BGP protocol > baseline functionality and BGP-LS packet encoding formats - Target: > Standards Track (Based on draft draft-keyupate-idr-bgp-spf) > - Publish specification documenting protocol extensions required to > efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with > scope to include privacy and security considerations - - Target: > Standards Track > - Publish YANG model specification for LSVR - - Target: Standards > Track > > LSVR Milestones: > > - Applicability statement for LSVR in DCs: March 2019 > - LSVR with standard Dijkstra path selection: March 2019 > - LSV distribution using BGP transport: March 2019 > - YANG specification for LSRV: July 2019 From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Friday, January 12, 2018 15:59 To: v6ops@ietf.org WG Subject: [v6ops] Fwd: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vect= or Routing A few weeks ago, I mentioned the chartering of the rift working group on th= is list. A parallel group has started the chartering exercise, working n BG= P SPF. You may be interested to join it. Begin forwarded message: From: IETF Secretariat > Subject: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vector Routing Date: December 13, 2017 at 1:30:55 PM PST To: "IETF Announcement List" > Cc: aretana.ietf@gmail.com, lsvr@ietf.org, gunter@vandevelde.cc, vic= tor@jvknet.com Reply-To: ietf@ietf.org A new IETF non-working group email list has been created. List address: lsvr@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dlsvr To subscribe: https://www.ietf.org/mailman/listinfo/lsvr Purpose: This list is for discussion related to architectural, standardization and m= anageability aspects for Link State Vector Routing. For additional information, please contact the list administrators. _______________________________________________ Lsvr mailing list Lsvr@ietf.org https://www.ietf.org/mailman/listinfo/lsvr --_000_AM5PR0701MB28366002452B3336E90911B5E0170AM5PR0701MB2836_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thanks Fred.

     

    Currently the charter is under discussion on LSVR em= ail list. The proposed draft charter:

     

    > [Note: Target audience, and discussions shou= ld happen on

    > lsvr@ietf.o= rg, however "rtgwg", "idr" and "dcrouting"= ; email lists have

    > been added as the concepts originated in tho= se working groups]

    >

    > Since dcrouting@ietf100, a few people have b= een discussing a possible WG charter for LSVR (Link State Vector Routing).<= o:p>

    > Here is what we have so far.  Comments = and improvements would be most welcome.

    >

    > WG page is to be setup soon.

    > Subscription to LSVR mailing list:

    > https://www.ietf.org/mailman/listinfo/lsvr

    >

    > Feedback (comments, edits, corrections, etc)=   on the draft LSVR

    > charter is appreciated

    >

    >

    > ***** DRAFT CHARTER UPDATE - JAN 10 2018 ***= **

    >  

    > Charter: LSVR - Link State Vector Routing

    >  

    > The Link-State Vector Routing (LSVR) Working= Group is chartered to develop and document a hybrid routing protocol utili= zing a combination of link-state and path-vector routing mechanisms.  = The LSVR WG will utilize existing the IPv4/IPv6 transport, packet formats, and error handling from BGP-4 (RFC4271). Additi= onally, the BGP-LS NLRI encoding mechanisms defined in RFC7752 are uti= lized to facilitate Link-State Vector (LSV) routing information distri= bution. An LSV is intended to be specified as a data structure comprised of a link identification, link attributes, n= eighbor information, cost toward neighbors, and other attributes that are d= efined for control plane function and policy-based routing decisions.<= /o:p>

    >  

    > The LSVR specification is initially focused = on operation within a single datacenter (DC) with preliminary focus on spec= ifying functionality within a single distribution domain.  Routing pro= tocol functionality defined by LSVR would be typically routing within a datacenter's underlay routing plane.

    >  

    > In order to achieve the noted objective, the= working group will focus on standardization of protocol functionality, def= ining Link-State Vectors (LSVs), and defining standard path-vector route se= lection utilizing existing Dijkstra SPF based algorithm, BGP-4 protocol mechanics, and BGP-LS NRLI encoding.<= /o:p>

    >  

    > For the purposes of the initial work within = the LSVR WG, and until further specified by the WG, the following definitio= ns apply to this charter.

    >  

    > - Link-State Vector - An LSV is intended to = represent a data structure (data set) comprised of link identification, lin= k attributes, neighbor information, cost towards neighbors, and other poten= tial attributes that can be utilized to make routing decisions.

    > - LSVR Distribution Domain - Initially scope= d as a set of participating LSVR nodes in a single administrative domain.

    >  

    >  

    > The LSVR WG is chartered to deliver the foll= owing documents:

    >  

    > - Publish Applicability Statement for the us= e of LSVR in the

    > Datacenter - Target Status: Informational

    > - Publish specification document describing = LSV with standard Dijkstra

    > SPF route/path selection (calculation) utili= zing existing BGP protocol

    > baseline functionality and BGP-LS packet enc= oding formats - Target:

    > Standards Track (Based on draft draft-keyupa= te-idr-bgp-spf)

    > - Publish specification documenting protocol= extensions required to

    > efficiently reuse BGP to distribute LSVs wit= hin an IPv4/IPv6 DC with

    > scope to include privacy and security consid= erations - - Target:

    > Standards Track

    > - Publish YANG model specification for LSVR = - - Target: Standards

    > Track

    >  

    > LSVR Milestones:

    >  

    > - Applicability statement for LSVR in DCs: M= arch 2019

    > - LSVR with standard Dijkstra path selection= : March 2019

    > - LSV distribution using BGP transport: Marc= h 2019

    > - YANG specification for LSRV: July 2019

     

     

    From: v6ops [mailto:v6ops-bounces@ietf.org] <= b>On Behalf Of Fred Baker
    Sent: Friday, January 12, 2018 15:59
    To: v6ops@ietf.org WG <v6ops@ietf.org>
    Subject: [v6ops] Fwd: [Lsvr] New Non-WG Mailing List: LSVR- Link Sta= te Vector Routing

     

    A few weeks ago, I mentioned the chartering of the r= ift working group on this list. A parallel group has started the chartering= exercise, working n BGP SPF. You may be interested to join it.<= /p>



    Begin forwarded message:

     

    From: IETF Secre= tariat <ietf-secretariat@ie= tf.org>

    Subject: [Lsvr] New Non-WG Mailing List: LSVR- Link State Vecto= r Routing

    Date: December 1= 3, 2017 at 1:30:55 PM PST

    To: "IETF= Announcement List" <ietf= -announce@ietf.org>

    Reply-To: ietf@ietf.org

     

    A new IETF non-working group email list has been cre= ated.

    List address: lsvr@ietf.org
    Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dlsvr
    To subscribe: https:= //www.ietf.org/mailman/listinfo/lsvr

    Purpose:
    This list is for discussion related to architectural, standardization and m= anageability aspects for Link State Vector Routing.


    For additional information, please contact the list administrators.

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

     

    --_000_AM5PR0701MB28366002452B3336E90911B5E0170AM5PR0701MB2836_-- From nobody Sat Jan 13 19:54:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED73126579 for ; Sat, 13 Jan 2018 19:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.326 X-Spam-Level: X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, 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 IkDLtvbnZCse for ; Sat, 13 Jan 2018 19:54:44 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D14120713 for ; Sat, 13 Jan 2018 19:54:44 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id k132so5751500vke.10 for ; Sat, 13 Jan 2018 19:54:44 -0800 (PST) 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=e5Lfl2ylPRhG+pxtQn3ivEXjtsqcWC0MTkwqc9zA92I=; b=G/jQuliKBA1opRtdl+K5O3oNV1ZgCfWwhoICNQ2wEKkVwSlfDz61LhmdaGvsYU9HjW Fog7J+1UJx3aei6Ttf6sAy5miprPZORdWlwAS0DDNk82JcUbLCR5ORreiMVKTTdCtT3l 4frVixX6rrmsJudiAT3NlCc29xfMBg7BYxPG0JTisZgbNOYZmyIzLc36rtSQHOGCLD4g 8fN2Zb9eRIXH4NGK3bugPCFZB3XhAoaYDdo7wbUDJ33SAB8mGFVV3pLcPgi8NNpaKBYS ZKIEIlla6gRoJhlQuM5yn7+04uAr2fyA/9/2weVXbdh02GK4WdWzhi6c17O7Mlf3RhLN 4ilg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=e5Lfl2ylPRhG+pxtQn3ivEXjtsqcWC0MTkwqc9zA92I=; b=nEI7IEQmXrx9HkxDveVPlr3hZoZbKY00BjEGUe4KTg5XKlsOl3qjfkO7TQlPF8me2B hpaBjX8Z0hL3K5nvWu2tfPmTl3KycPSYsTOnwqkZQtXUFx5XN9C41TnkFjB+XU9RD59k GSwzJ2vYDU/35MgNJm7N1u/WJqbULbaxjm9WpNQawWykmkwIJgiSUyhDVAoGpHK1TJvc fS01cME/4biEDEuebaeQwl6ORTij0TbLuryS5vX39hcAvBY/MEOy5iwMG6HD7aNrkM/t GDzY+klt61deq797q5sO5YXpeW04qfuEpgJzYGxQk1dM1z/jRB10bdF34WrwjTrlerMd bw3w== X-Gm-Message-State: AKwxytfalT5Xz3KcvNzm6LIhNFh3o24l/XTYKsAK24DXmcScyWE0eP1e Fh3/yWaYU90dvRKX9qfM5GG4GP8NbOJXAaWAKiI= X-Google-Smtp-Source: ACJfBosd0BNnH6YIVVVOWARJ2He7JSWK8RSrwKmyh9Jkbkp9M1kSN9PJrDrMi6GF5O1pShSKAQE/UbrjmM2jy4S0h6w= X-Received: by 10.31.92.200 with SMTP id q191mr6744399vkb.151.1515902083560; Sat, 13 Jan 2018 19:54:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.53.99 with HTTP; Sat, 13 Jan 2018 19:54:13 -0800 (PST) In-Reply-To: References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> From: Mark Smith Date: Sun, 14 Jan 2018 14:54:13 +1100 Message-ID: To: james woodyatt Cc: Brian E Carpenter , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Jan 2018 03:54:47 -0000 Forgot to send this, still useful I think. On 28 December 2017 at 10:07, james woodyatt wrote: > On Dec 22, 2017, at 19:35, Brian E Carpenter > wrote: > > > I don't see that argument for homenets. ISPs don't seem reluctant to hand > out /64, /56 or /48 to paying subscribers. I can see that if you want to = do > something fancy while roaming, you might have to deal with a single /128. > > > They are very reluctant to deploy CPE gateways that use any current or > forthcoming protocol to delegate automatically any portion of their prefi= x > to routers on home network links. In shorter terms, they are happy to han= d > out /56 (less so /48) to CPE edge routers owned by paying customers, but > there is no appetite for supporting customers with interior routers > downstream of the CPE edge router. Certainly not in their provider > provisioned CPE gateway devices that are more often than not bundled in t= he > service agreement and quietly included in the total charge for access. Oh= , > they might have plans to use that number space with some non-standard pre= fix > distribution protocol, but it appears there is very little appetite for > adopting any standard made available for third parties to use freely. > > That=E2=80=99s why anybody planning to offer consumers technology solutio= ns that > include IPv6 router functions running on nodes located behind CPE routers > are forced to resort to address amplifying NAT to operate as a router on = the > downstream links and a host on the upstream home network link behind the = CPE > router. Just as happened with IPv4 for pretty much the same reasons. I=E2= =80=99ve > spent the better part of three years trying to avoid that conclusion, and= my > experience in V6OPS and HOMENET has led me to conclude that it was a badl= y > wasted effort. NAT66 is the wave of the future. Is NAT66 the only option? It seems to me that one of the fundamental problems with NAT, including 1:1 NAT, is that it is somewhere in between simple IP forwarding based on the IP header, and full host/application processing. The context and state held in the true end-host and application is not available in the NAT66 device, and that is why it can't do a fully transparent translation. The NAT device neither a router or a host. I wonder if it would be better to have the "NAT66" device be the true application end-point for all communications, and then have it communicate with the down stream devices "internally" via a ULA address space, as internal application inter-process communication. The external host/application then has all of the context and application state necessary to function, so none of the NAT issues occur. Internally, IPv6 with ULA address just happens be being used as an application message bus between the downstream devices and the globally reachable application endpoint. If the downsteam devices need to have globally unique identifiers and indirectly globally reachable and visible, they could be generic UUIDs. They don't need to be IPv6 addresses, because all access to them is via messages sent to the application with the global IPv6 address. Regards, Mark. > > --james woodyatt > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Jan 14 03:12:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE698127058 for ; Sun, 14 Jan 2018 03:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RaVOghkp-Jde for ; Sun, 14 Jan 2018 03:12:38 -0800 (PST) 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 D9E711270AB for ; Sun, 14 Jan 2018 03:12:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BEAAF4B; Sun, 14 Jan 2018 12:12:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1515928352; bh=6owUvthKIAgMY2emSed51INM2Moza2OLpNnSKUA+ByM=; b=c CgpP1HGR6UrbWkW47ZEWnQR2caNGbq5Dvwx2Ky9E58St5n2caa+Brpi+gkISVEnH bwkzVEI0sFw22Zd2NBxU1eHRBvrmVppGcA0qgPjQNBmC+OO0NJMQgp3LdP7dBHBQ V5XTTxFweXF3Ykd6VFAXiLPO5wI7F96B+ANeEWBpM4= 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 nWhDzLZBANQD; Sun, 14 Jan 2018 12:12:32 +0100 (CET) Received: from [IPv6:2a02:a213:a301:1000:547:2140:ed09:a6c0] (unknown [IPv6:2a02:a213:a301:1000:547:2140:ed09:a6c0]) (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 A150F4A; Sun, 14 Jan 2018 12:12:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Sun, 14 Jan 2018 12:12:30 +0100 Cc: james woodyatt , v6ops list Content-Transfer-Encoding: 7bit Message-Id: References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> To: Mark Smith X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Jan 2018 11:12:40 -0000 Hi, > I wonder if it would be better to have the "NAT66" device be the true > application end-point for all communications, and then have it > communicate with the down stream devices "internally" via a ULA > address space, as internal application inter-process communication. So, back to using proxy servers then. Sander From nobody Sun Jan 14 10:46:34 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C48612D85F for ; Sun, 14 Jan 2018 10:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7jYpHnF_lMya for ; Sun, 14 Jan 2018 10:46:32 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 02731129C6F for ; Sun, 14 Jan 2018 10:46:32 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id q2so2163905pll.3 for ; Sun, 14 Jan 2018 10:46:31 -0800 (PST) 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=32OiAYbsqDystNhI/0GWxamAKQFYB/COzjciDyZiZHE=; b=ZgacvUaNVqEnlD19lj3nTkv5qQkEaRMyWU6mipD5hVqokLD80R1xMppO7FBFkwxmwd QStTTfSohpEL6RWKJuO27c7LDZwMQ/GIX2AIPXmjNLQQ6qIWwO2zw5T1KwpwMzdl4cnY sjVvBYLJrk1mq/QF8ZpqI66G2/AVf5brdH6DfdvBntsOvVfPrm6M+ULayJb7IqdH9auD NocqscoBK72HxQIe+iei5mUcLlfTBpETocJn3y7aziyNgRX+8uarFp0/Ac8JTt1iPYaK ERvJVq93Ysi9sUgBK4dqf7ZSi74BT9wm+5XYgcxBfh8GBgZ5FgOCKifzMf2uI5hCMvwi vQtQ== 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=32OiAYbsqDystNhI/0GWxamAKQFYB/COzjciDyZiZHE=; b=hzHhKE1ms+iLMUNwlJnXerDiUHg3onQSSG32V1YDVpJED+n1xOe3+bAgri1zaueXpX c0psIYvgs9JLNLYmuDvw2OS7ekTvZNs97oTl7m5qEmeue6CMex6iXZJO5E9urgQpKkcl lMCaimar5IEieyAXcb5tzfjSoRCgOw9TS+QdxU+Aa8+WtAlgDqOjjk2lL0EZG+KNDUzl 6Td50C1h0HR+HvoB4S4LmecpTD1EuWQuMyYs1E5fWeo4mRfAEX4nzo90VDFrnX0HUGOV cGyADcW/2TVfbWeuCtBCiWGL35r7s+R3NoOB6PVP8eqWgiC7jv6ndSLKW8VVml0zKVqh p9fA== X-Gm-Message-State: AKwxytePeksv0cfsxXRveaoYi8zOPkBzA/1bwRubSEBywZtm3UVgtJ/J gmx8WT4tA6elP30sTEQCDmeFAw== X-Google-Smtp-Source: ACJfBov7yQOGt5LCg2kiO69PlZL6mAUzVeR+BJtwJPURGb332imAZfTAXCCagI4kcNXD5ScxeJXhww== X-Received: by 10.84.132.76 with SMTP id 70mr1011593ple.221.1515955591231; Sun, 14 Jan 2018 10:46:31 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q6sm48623606pgv.72.2018.01.14.10.46.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jan 2018 10:46:30 -0800 (PST) To: v6ops@ietf.org References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> Date: Mon, 15 Jan 2018 07:46:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Jan 2018 18:46:33 -0000 On 15/01/2018 00:12, Sander Steffann wrote: > Hi, > >> I wonder if it would be better to have the "NAT66" device be the true >> application end-point for all communications, and then have it >> communicate with the down stream devices "internally" via a ULA >> address space, as internal application inter-process communication. > > So, back to using proxy servers then. > Sander a) The faulty email quoting in Mark's message made it look as if I might have been advocating NAT66 - not so, that was James in respnse to me. b) I don't see using proxies as a step backwards. On the contrary, with home networks in particular likely to contain increasing numbers of IoT devices with poor security, proxying a network behind a reasonably secure device seems like an excellent idea. c) If James is correct about the attitude of ISPs we (for some sense of "we") need to do something about it. ISPs are motivated by revenue and OPEX. How can we make support of prefix delegation more attractive to ISPs? Brian From nobody Mon Jan 15 00:38:29 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C19124207 for ; Mon, 15 Jan 2018 00:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FMmAam74Sns for ; Mon, 15 Jan 2018 00:38:27 -0800 (PST) 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 739A71200FC for ; Mon, 15 Jan 2018 00:38:27 -0800 (PST) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D55EA2D50B4; Mon, 15 Jan 2018 08:38:25 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AE4912016C2BB0; Mon, 15 Jan 2018 09:38:23 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B835313D-576A-45EB-8E50-1DCD4533F080"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 15 Jan 2018 09:38:22 +0100 In-Reply-To: <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> Cc: v6ops@ietf.org To: Brian E Carpenter References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Jan 2018 08:38:29 -0000 --Apple-Mail=_B835313D-576A-45EB-8E50-1DCD4533F080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > c) If James is correct about the attitude of ISPs we (for some sense = of > "we") need to do something about it. ISPs are motivated by revenue and > OPEX. How can we make support of prefix delegation more attractive to > ISPs? Let's clarify this a bit to avoid misunderstandings. ISPs _do_ prefix delegation today. What is missing is any further use of that address block inside of the = home network. 1) Subnet the delegated prefix and assign /64s to local interfaces. 2) Static routes 3) Sub-delegation with DHCP PD 4) HNCP As far as I know only 1 is commonly supported. You can argue to what extent this is an ISP problem or something else, = depending on where the demarcation point is. Likely a chicken and egg problem too, since internal routers a) haven't = been that common b) don't support HNCP, c) there hasn't been that much = of a use case. Perhaps if we James can describe his use case, that might give us a bit = more leverage. Cheers, Ole --Apple-Mail=_B835313D-576A-45EB-8E50-1DCD4533F080 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 iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlpcaH4ACgkQvtpYqJhC 33b6MBAAolAAP3dcsl/VfjEQVyQP81YUVexg8sVqB4LkC5pRtaPfhzrF6NaEe7WU uDSIE555IWt7IMd3/vDXFbFa7HVvoDjW/011e6H72GKCOUdV5rzkVujUODdrGv8N 9qP1slKUZovMJuCtGSGkWx9zXzJsxM5XrspfcgQYXPEm5V7Pu6qnPnH/FGTzJlYG /AwkT0zqbUInaAB7bM7wnlyN0fr7q/9O0ZlUFk6yKFS+ZOCDtntm09u0E/2xAWVn FtmDzwcjSrm+dTHxu/EUKS48UO9qsWrtODifNSpvWmQALUtYV46XPjKZ8g9RzVKE OxF6gTWjclA9/rwJ7qwGsPNArQIgTQezptjQ+IOUr6BULDC4zWj7juvfLH1RnHGF yVZAe2sdoH89V3DNapg47oAWowfu3Gvi3jzThCnbTpdmzjECr0PpxlxP7XnvwNg9 FCG2WBCNlsmXq1Ec/JI9Cq+P0q73UwX91rq7sT/u4NPxGzXqwFjuW1OstGmQivcc LiMTMeQK6eBzNbFRA1w/DkyzsrD/AGJErnYGFmegCcaZwCBZeEHS31H14R1A+O0h sUAq4Rn0EJnV+gXXxK6kjlj2QS1odakhKRt86OZToblNL+c4H3G0DzoWe/8+UIEj BEG10oqzvYnMhgwPhWaTVvk66uvOZkylwEzs7b3mX01y8OULHOI= =t14Y -----END PGP SIGNATURE----- --Apple-Mail=_B835313D-576A-45EB-8E50-1DCD4533F080-- From nobody Mon Jan 15 02:24:48 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9838A12DA29 for ; Mon, 15 Jan 2018 02:24:47 -0800 (PST) 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 exlV7rBVibr3 for ; Mon, 15 Jan 2018 02:24:46 -0800 (PST) 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 E241212DA0A for ; Mon, 15 Jan 2018 02:24:44 -0800 (PST) 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 w0FAOgqe037973 for ; Mon, 15 Jan 2018 11:24:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9EA7B208200 for ; Mon, 15 Jan 2018 11:24:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 956EF200801 for ; Mon, 15 Jan 2018 11:24:42 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0FAOgBf009729 for ; Mon, 15 Jan 2018 11:24:42 +0100 To: v6ops@ietf.org References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> From: Alexandre Petrescu Message-ID: <8945bf1f-4127-50ac-00e4-3df1b57228d4@gmail.com> Date: Mon, 15 Jan 2018 11:24:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Jan 2018 10:24:47 -0000 Le 15/01/2018 09:38, Ole Troan a crit: >> c) If James is correct about the attitude of ISPs we (for some sense of >> "we") need to do something about it. ISPs are motivated by revenue and >> OPEX. How can we make support of prefix delegation more attractive to >> ISPs? > > Let's clarify this a bit to avoid misunderstandings. > > ISPs _do_ prefix delegation today. > > What is missing is any further use of that address block inside of the home network. > > 1) Subnet the delegated prefix and assign /64s to local interfaces. > 2) Static routes > 3) Sub-delegation with DHCP PD > 4) HNCP > > As far as I know only 1 is commonly supported. 2 is also supported in ISP for home network. The ISP I use has a web GUI on the CPE on which the end user at home ('grandma') can fill in IPv6 static routes. Alex > > You can argue to what extent this is an ISP problem or something else, depending on where the demarcation point is. > Likely a chicken and egg problem too, since internal routers a) haven't been that common b) don't support HNCP, c) there hasn't been that much of a use case. > > Perhaps if we James can describe his use case, that might give us a bit more leverage. > > Cheers, > Ole > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 15 02:51:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B81126CBF for ; Mon, 15 Jan 2018 02:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 EEexTu66Qf-Y for ; Mon, 15 Jan 2018 02:51:54 -0800 (PST) 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 81EF51243FE for ; Mon, 15 Jan 2018 02:51:54 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id u62so425364ita.2 for ; Mon, 15 Jan 2018 02:51:54 -0800 (PST) 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=i3RIy8CO81YL9pdrBv1ZZRckMYOtFYDw+0XZLxlZojM=; b=Y8WvHf5J+/LgpSPrDItqDUopM4b7AdlwUNMCkrrE+fWFJvx67meAaD/Zta6w4QGAhT qm+h88O5kjgCzX8V+4AZ2PLb2kGEmpcU4d+0Q6jwsozCeDG+ay8q4Bx1CjaBcE9ljNBS 2yp6+fo9wB1lK4TluJ/I0x1rfMPQWFLUK/FqYrYftBI+mCPcronuHVBA1p8TmRsSdsUf mUl9Szm+dN98S2UpVUX0063GO9jE/jWervCDCCQgFs7SYB0KbXEC2+K1X1mNArl+hPqX VtyzE032OObQuaBbfQGfBTZmctnujV16807S23vtOyG22oIz7g/XcPiofl7GD1h6NNvA vq5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=i3RIy8CO81YL9pdrBv1ZZRckMYOtFYDw+0XZLxlZojM=; b=O5hvk8N4ohskX55z7ULCuVajY5/shNaLpfepkVeiCzhEdFLspkxX7fpEb3LzZL4MFo m5crL61tmpGzqSgDRi2xOP7zq00bzKytHdJnPP+DK0doNGw4djMfm7ywhSdCHGrmLK+f 4MBslZMmL/OvTlAICVuAN3uZCBl8vJ8bnutSqNQY/IOLVmAa6NzPaXLBgmBbEhEuz1cz qMAzvMfS975kJCA7uH0crPsl/NyqFxnioBnYSfORwabPHqfP5oV4OJFB/N/T+ZMFsEg6 N6SjxL/KuM31JP9JOhcTIsL3adXNJ0xb5dZakkKyuRd1+LK8JPDWV9kUVkuJ1ewOwwvi mPuw== X-Gm-Message-State: AKwxytdummJlfssufaoM3N3Sp/Kj4i5pQ1LiNrZ1thsQEcWJn6k86OOW BXEIO3VYHr4u93eSlGzJlHc/GQQ4N0GSDpEDJqxcpA== X-Google-Smtp-Source: ACJfBovz99gfbe3aBgzFu67t+odL/E+iVCM9JJJhU1pI9CMuCRzoDKRWWF4cVxuXnqefuNI5T+nxBYnnl6IPDw9Ij8A= X-Received: by 10.36.85.206 with SMTP id e197mr6921715itb.124.1516013513363; Mon, 15 Jan 2018 02:51:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.102.19 with HTTP; Mon, 15 Jan 2018 02:51:32 -0800 (PST) In-Reply-To: <8945bf1f-4127-50ac-00e4-3df1b57228d4@gmail.com> References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> <8945bf1f-4127-50ac-00e4-3df1b57228d4@gmail.com> From: Lorenzo Colitti Date: Mon, 15 Jan 2018 19:51:32 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11399242f0f6df0562ce66a7" Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Jan 2018 10:51:55 -0000 --001a11399242f0f6df0562ce66a7 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 15, 2018 at 7:24 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > 1) Subnet the delegated prefix and assign /64s to local interfaces. >> 2) Static routes >> 3) Sub-delegation with DHCP PD >> 4) HNCP >> >> As far as I know only 1 is commonly supported. >> > > 2 is also supported in ISP for home network. The ISP I use has a web GUI > on the CPE on which the end user at home ('grandma') can fill in IPv6 > static routes. > My ISP also happens to support #2. But support is definitely not universal. --001a11399242f0f6df0562ce66a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On M= on, Jan 15, 2018 at 7:24 PM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
    1) Subnet the delegated prefix = and assign /64s=C2=A0 to local interfaces.
    2) Static routes
    3) Sub-delegation with DHCP PD
    4) HNCP

    As far as I know only 1 is commonly supported.

    2 is also supported in ISP for home network.=C2=A0 The ISP I use has a web = GUI on the CPE on which the end user at home ('grandma') can fill i= n IPv6 static routes.

    My ISP also happe= ns to support #2. But support is definitely not universal.=C2=A0
    --001a11399242f0f6df0562ce66a7-- From nobody Mon Jan 15 12:54:26 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DA412EC27 for ; Mon, 15 Jan 2018 12:54:24 -0800 (PST) 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 3I7Tc96H5DeA for ; Mon, 15 Jan 2018 12:54:22 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D507C12EC08 for ; Mon, 15 Jan 2018 12:54:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w0FKsLDx055477; Mon, 15 Jan 2018 13:54:21 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w0FKsKVT055463 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 15 Jan 2018 13:54:20 -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.1347.2; Mon, 15 Jan 2018 12:54:19 -0800 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.1347.000; Mon, 15 Jan 2018 12:54:19 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" , Gert Doering Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdOOQvRDLl8emuHnQGO0WDphKQAHfA== Date: Mon, 15 Jan 2018 20:54:19 +0000 Message-ID: <1275a519d5aa450abf382c7a41ef6d02@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group 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: Mon, 15 Jan 2018 20:54:25 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, November 20, 2017 10:38 AM > To: Templin, Fred L > Cc: Gert Doering ; Ole Troan ; v6op= s@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > Hi, >=20 > On Mon, Nov 20, 2017 at 06:32:53PM +0000, Templin, Fred L wrote: > > > > The DHCPv6 client piece in OpenVPN is a few hundred lines of code > > > > and was not hard to implement. And, if the client needs to do > > > > something to request, manage and maintain a delegated prefix it > > > > might as well be DHCPv6. > > > > > > So what does your patch *do* with the received prefix (since it's > > > an out of tree patch I haven't seen yet)? "Just configure it on the > > > tun interface" (you do not need DHCPv6-PD for that)? > > > > It configures addresses derived from the prefix and assigns them > > to the tun interface. It does not join the solicited-node multicast > > address nor perform DAD over the tun interface. >=20 > So where's the benefit of doing DHCPv6-PD here? *This* is a function > OpenVPN can do out of the box just fine... *scratch head* >=20 > Single address, or "many"? >=20 > > Right now, it is only assigning a single address but it can in fact ass= ign > > as many addresses as it wants as shown in Figure 3 of 'pdhost' > > without having to invoke MLD or DAD. > > > > Do you want to see our code? >=20 > It would be nice to have a look, but the "do DHCPv6-PD handshake" is not > the really challenging bit Per your interest, and for the benefit of the community, we published our code on 01/10/2018:=20 https://www.ietf.org/mail-archive/web/v6ops/current/msg28860.html > - "do something interesting with the prefix" > is... That subject is covered in detail in 'draft-templin-v6ops-pdhost', and the code provides an example. Thanks - Fred > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jan 16 12:03:36 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7612EB0A for ; Tue, 16 Jan 2018 12:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0RuxZUUyQwut for ; Tue, 16 Jan 2018 12:03:21 -0800 (PST) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::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 9EFF512EACB for ; Tue, 16 Jan 2018 12:02:50 -0800 (PST) Received: by mail-pl0-x22d.google.com with SMTP id b96so6989395pli.2 for ; Tue, 16 Jan 2018 12:02:50 -0800 (PST) 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=5L6bqzeswZiVyJt0jV4+N2Lws8YJfZN/YH+EtiMnuk8=; b=SBZeSGyzExh6WK7ezFU5Ew3a2ms1Q66AsyoeHCTeFleZMJTzYIY5wyIreQ7gSO3OJj HwQIAgMYN6c6CZaHNQWFnkKMRIJl2eSpUN5PhosoCQvYIzxMxru3w+mDOVp1iFAwy+qL ygUL0xTuD4OFeYQ4dR3uol91XRfWZcAvYB4RaI8ihrQ4o9ZSfjhxRQ+N2GvyqXLcULJo j8PDMgm5j8HiXZYBrBtc4EuA1Lj24vhXZjhfdhXFueGTPQHtHK9wUZfAk0opCXAFIqoo nU22VWxHRpNyjVBxFL/yrnpVls5udT8HFsobGfaebLv0HlnQ1egZqdizvPpZC/lA2/Fe OOQA== 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=5L6bqzeswZiVyJt0jV4+N2Lws8YJfZN/YH+EtiMnuk8=; b=d/hkbozGpZNgDHP5019rTEepAw4ineRpUxsuEjNjXRJfVRbMr9mpX841Oz6fUiMMUx Wc6arLggzRxax5UidUKDpTzwG2fzug/YcSDm4daWyplPuM1IfeG0XP2zkUeec0J63XX9 R0j/Fmy3GwhMG3jgX7ph9CoEKi3gFWtreotQXLIeOy+xCY0+5osdKCSQvlBaVMWZL4P/ o2g1fmP9TRNVDiZRgNr8JJX4RY5J2ExIlVxFeyOPAVFbAas4JI4wBijyESjlpdYtoISU 6w9cBq6SDpBZ4NHldIKkySa+nP6E9AWSCAoAAIfdmOBIa4N/8nX1MhUVI3g9y1lV0dQv AFJw== X-Gm-Message-State: AKwxytcq37eSxFTGm+WEiROSKuJBYu/xGA8fyUpDLsfxamLoXrNtTQzd SeW9IkC+eio8r1I4vMmnK1B2Vw== X-Google-Smtp-Source: ACJfBourG2NH2GGAUmay52pva83gZgIN+RprqMea/GMSBNxT/2hBuBFHY2DCjP2c4HqbJMq5PkzCKA== X-Received: by 10.84.236.14 with SMTP id q14mr7652583plk.445.1516132969795; Tue, 16 Jan 2018 12:02:49 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id q27sm5288507pfd.14.2018.01.16.12.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 12:02:48 -0800 (PST) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_10D7BC95-EF58-408C-857D-B38AB4123AAB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 16 Jan 2018 12:02:47 -0800 In-Reply-To: Cc: Brian E Carpenter , v6ops@ietf.org To: Ole Troan References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Jan 2018 20:03:34 -0000 --Apple-Mail=_10D7BC95-EF58-408C-857D-B38AB4123AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2018, at 00:38, Ole Troan wrote: >=20 > Perhaps if we James can describe his use case, that might give us a = bit more leverage. Again? Okay. Consider the Nest Secure system of products, which includes Nest Guard, = Nest Detect, Nest Tag, et cetera. One product in particular is called = Nest Connect. It=E2=80=99s a simple wall wart that provides Thread/WiFi = border routing functionality. This functionality is also included in = Nest Guard and other products with better marketing, but if you have a = big house and you need to connect a Nest Guard to a Nest Detect too far = away to reach over Thread, then you would use a Nest Connect for that. All these devices have a Wi-Fi interface and a Thread interface. > Here=E2=80=99s more about Thread border routers from the nice people at = OpenThread: > The basic use case is that each Thread mesh that depends from the home = Wi-Fi network requires its own /64 prefix. But the Nest Connect cannot = reliably get one on practically any currently deployed home networks, = even those like Comcast which provide IPv6 service to hosts. Neither can = the Nest Guard or any of the other products in system that operate as = Thread border routers. Thread=E2=84=A2 is a network layer, and not an = application layer, but without a reliable method of acquiring a prefix, = a border router can only be made to function passably with a NAT66 = function. There is no reason to be optimistic this will change. And IETF is making = it worse by signaling that it won=E2=80=99t include HNCP and Babel or = anything else that can solve this problem in its revision of the RFC = 7084 recommendations for CPE routers. I=E2=80=99ve raised this topic = before and the response has never been more than shoulder shrugs. Sure, the Nest Guard and the Nest Connect currently work by providing a = sort of application proxy: they establish a private virtual IPv6 network = over an IPv4 tunnel between the home and the Nest Service. Because the = Nest Service does not (currently) assign globally routed addresses to = Thread border routers in the home, e.g. Nest Connect and Nest Guard, = it=E2=80=99s not possible for any 3rd party product that joins the = Thread network to reach anything other than the Nest Service, i.e., not = even other devices on the home Wi-Fi network. Resolving that problem in = the absence of a reliable system of assigning globally routed prefixes = to interior routers on home networks is not easy. For a variety of = reasons related to the weedy technical aspects of how Thread works, = which are too tedious to explain here, using NAT66 instead of ND6 Proxy = is really the only sensible way to work around the prefix delegation = cluster-fail. --james woodyatt > p.s. Clever readers will naturally want to try to fix the problems in = Thread that made ND6 proxy unsuitable for solving this problem. Good = luck storming that castle. I tried and gave up.= --Apple-Mail=_10D7BC95-EF58-408C-857D-B38AB4123AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 15, 2018, at 00:38, Ole Troan <otroan@employees.org> wrote:

    Perhaps if we James = can describe his use case, that might give us a bit more = leverage.

    Again? Okay.

    Consider the Nest Secure = system of products, which includes Nest Guard, Nest Detect, Nest Tag, et = cetera. One product in particular is called Nest Connect. It=E2=80=99s a = simple wall wart that provides Thread/WiFi border routing functionality. = This functionality is also included in Nest Guard and other products = with better marketing, but if you have a big house and you need to = connect a Nest Guard to a Nest Detect too far away to reach over Thread, = then you would use a Nest Connect for that.

    All these devices have a Wi-Fi = interface and a Thread interface.

      <https://store.nest.com/product/nest-connect/>

    Here=E2=80=99s more = about Thread border routers from the nice people at = OpenThread:

      <https://openthread.io/guides/border_router/>

    The basic use case is = that each Thread mesh that depends from the home Wi-Fi network requires = its own /64 prefix. But the Nest Connect cannot reliably get one on = practically any currently deployed home networks, even those like = Comcast which provide IPv6 service to hosts. Neither can the Nest Guard = or any of the other products in system that operate as Thread border = routers. Thread=E2=84=A2 is a network layer, and not an application = layer, but without a reliable method of acquiring a prefix, a border = router can only be made to function passably with a NAT66 = function.

    There = is no reason to be optimistic this will change. And IETF is making it = worse by signaling that it won=E2=80=99t include HNCP and Babel or = anything else that can solve this problem in its revision of the RFC = 7084 recommendations for CPE routers. I=E2=80=99ve raised this topic = before and the response has never been more than shoulder = shrugs.

    Sure, = the Nest Guard and the Nest Connect currently work by providing a sort = of application proxy: they establish a private virtual IPv6 network over = an IPv4 tunnel between the home and the Nest Service. Because the Nest = Service does not (currently) assign globally routed addresses to Thread = border routers in the home, e.g. Nest Connect and Nest Guard, it=E2=80=99s= not possible for any 3rd party product that joins the Thread network to = reach anything other than the Nest Service, i.e., not even other devices = on the home Wi-Fi network. Resolving that problem in the absence of a = reliable system of assigning globally routed prefixes to interior = routers on home networks is not easy. For a variety of reasons related = to the weedy technical aspects of how Thread works, which are too = tedious to explain here, using NAT66 instead of ND6 Proxy is really the = only sensible way to work around the prefix delegation = cluster-fail.


    --james woodyatt <jhw@google.com>

    p.s. Clever readers will naturally want to try to = fix the problems in Thread that made ND6 proxy unsuitable for solving = this problem. Good luck storming that castle. I tried and gave = up.= --Apple-Mail=_10D7BC95-EF58-408C-857D-B38AB4123AAB-- From nobody Wed Jan 17 01:41:40 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7512FAD3 for ; Wed, 17 Jan 2018 01:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GFpum4tmw8br for ; Wed, 17 Jan 2018 01:41:31 -0800 (PST) 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 A8C3A12FAEB for ; Wed, 17 Jan 2018 01:41:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 880EA4B for ; Wed, 17 Jan 2018 10:41:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:message-id:in-reply-to:references:date:date:subject :subject:mime-version:content-transfer-encoding:content-type :content-type:from:from:received:received; s=mail; t=1516182083; bh=3qs5XCC6B5bGX2xr2Fl/rl7JoEbw0Mngo1s2JrfEUiA=; b=doza2RlNE9FT NyQr5R6M8crvZcLzy5ayjG6GEwfbTlo7zt1InlwWNKpJIvdbX11jvjnc0unWr4LW e6Rsa6TJl0+DTxNMlPM7Sh1nveeGYLSgrYHYACPYY9vetH6P+2NgaWQpUOerpH6j l56KuP5+8vMaQSdxiUEzZtXYg/TaTX8= 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 o8JxukBss1eI for ; Wed, 17 Jan 2018 10:41:23 +0100 (CET) Received: from [IPv6:2a02:a213:a301:1000:1820:14b0:2bb6:30d1] (unknown [IPv6:2a02:a213:a301:1000:1820:14b0:2bb6:30d1]) (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 D21AE49 for ; Wed, 17 Jan 2018 10:41:23 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Wed, 17 Jan 2018 10:41:25 +0100 References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com> To: v6ops list In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Jan 2018 09:41:38 -0000 Hi, > There is no reason to be optimistic this will change. And IETF is = making it worse by signaling that it won=E2=80=99t include HNCP and = Babel or anything else that can solve this problem in its revision of = the RFC 7084 recommendations for CPE routers. I=E2=80=99ve raised this = topic before and the response has never been more than shoulder shrugs. More like silently crying :'( Sander From nobody Wed Jan 17 16:21:08 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42312D881 for ; Wed, 17 Jan 2018 16:21:02 -0800 (PST) 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=quantonium-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 YdS9LfrVZ78k for ; Wed, 17 Jan 2018 16:21:00 -0800 (PST) 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 B1893124BAC for ; Wed, 17 Jan 2018 16:20:59 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id g38so17602453wrd.2 for ; Wed, 17 Jan 2018 16:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5GcdZU/d7P/2y1OzJesSUCKA5bkZUf4R0cSV+EGeHQY=; b=w7bfuYMGoDgHuXhrz4Ro7MIZyvlJxCBJ3jzRA9sIPOdJ22gRQ3pM2eM6mu2bmCDVbZ Mdzzae6p3xzS9xDhhE/gm2Og/pcZo+TIrX1LN+P5Npy0a/ceG/UVvqcmFmOX9Csj3Jvu stntWZBkGxCMIeBosjltkLWrl8YMm9LMMJZOUr+6x/0U1vqYscRua60Kq8asBM6dc0CJ kbJD7Vd33KQPpA4rtsIbgAJYUDRTIGlcIUcXnzMQSL55bUBOsipAp+vuggb5AeykuBdT oE7BI/sPVpGEp7WKj8+nBtOxE8JwOrOvxk5XoZr83CTaU+OBFCCgWK3rbzeZmooiao+Q npKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=5GcdZU/d7P/2y1OzJesSUCKA5bkZUf4R0cSV+EGeHQY=; b=t/y32g7S6fFKTK3g5WZ5y/JQHpQDwQ0D4zqANV4yodQdIuaCGvrbuZ3qfi0YZeOo8Q WSAuhzJ8hLcn94Mj/zb8w1KVAeQuNE/G7NYhYQuZ5cvbEJqrwaw2jOd0w6He+Lfa8D7U kmPMUKZSCeB8siRywbkRuqSSAonXSTk4QPWtWSdvWPParVKV4Ox9o2l4uc4Y7RVen+rM WUAfCqyZND04K1C5xzK7vKIjxb2MY0slqRYuYLIGwvOp9dYVQ8uwRulWjR04CIRVLj15 7xd7WUiwxAW5mZUDJ3GHxIiOnMsM3I6cW3Q0F0Izskly09y6gHDhA0kUHe5WeURwnYDQ Azfg== X-Gm-Message-State: AKwxytfx0AK4ALMGUWlStvX125ojKALrIUbZin9zFBIqtsVBN2kSgZ6a Gn+wBwt5YNmgY6qaSBIm5TudHL58bqS7dCLDnBoKoQ== X-Google-Smtp-Source: ACJfBouGq4RBooFILDWUKQZ7a/TNEJtRWN0KyrvPxCvGYfmkZCp0FGyLOQ7Lj8YsEyRgIEToOpoX76eJ6U94heRh49Y= X-Received: by 10.223.184.197 with SMTP id c5mr4316050wrg.105.1516234858241; Wed, 17 Jan 2018 16:20:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.208.204 with HTTP; Wed, 17 Jan 2018 16:20:57 -0800 (PST) In-Reply-To: <151622987793.10801.18023834922828246722.idtracker@ietfa.amsl.com> References: <151622987793.10801.18023834922828246722.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 17 Jan 2018 16:20:57 -0800 Message-ID: To: int-area@ietf.org, v6ops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Fwd: New Non-WG Mailing List: ILA- Identifier Locator Addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jan 2018 00:21:02 -0000 Hello, Per Suresh's recommendation, a mailing list for ILA had be set up to discuss architecture, problems to solve, and potential for a WG on the topic. If you're interested please join the list! Tom ---------- Forwarded message ---------- From: IETF Secretariat Date: Wed, Jan 17, 2018 at 2:57 PM Subject: New Non-WG Mailing List: ILA- Identifier Locator Addressing To: IETF Announcement List Cc: Kalyani.Bogineni@verizonwireless.com, tom@quantonium.net, suresh@kaloom.com, ila@ietf.org A new IETF non-working group email list has been created. List address: ila@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=ila To subscribe: https://www.ietf.org/mailman/listinfo/ila Purpose: This mailing list is for discussion about Identifier Locator Addressing (ILA) and the possibility of forming a working group around this topic. For additional information, please contact the list administrators. From nobody Fri Jan 19 12:15:57 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7612D72F for ; Fri, 19 Jan 2018 12:15:55 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 2fFX1_lBEvgu for ; Fri, 19 Jan 2018 12:15:53 -0800 (PST) Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4B61270FC for ; Fri, 19 Jan 2018 12:15:53 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0JKFpdZ003600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 19 Jan 2018 15:15:51 -0500 Received: (qmail 3347 invoked by uid 0); 19 Jan 2018 20:15:51 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 19 Jan 2018 20:15:50 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 19 Jan 2018 15:15:48 -0500 From: Lee Howard To: Message-ID: Thread-Topic: discussion of transition technologies Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3599219750_74824803" Archived-At: Subject: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jan 2018 20:15:55 -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_3599219750_74824803 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The WG Chairs were discussing the various transition technologies at some length today. I mentioned a previous conversation in another forum that led to this list of networks and their mechanisms: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7N= K 9vcVApc/edit#gid=3D0 (Corrections and additions encouraged, especially with links) Our impression was that of the 26+ transition mechanisms defined, only a fe= w have any modern relevance (editorial comments are mine, not consensus positions): 6rd. It may be that its light is waning, with early deployments moving to native IPv6, and no new deployments. DS-Lite. Widely deployed, existing support among home gateway manufacturers. NAT64/464xlat. Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No home gateway CLAT yet. MAP-T. Announced trials and lots of buzz, but no large-scale deployments, no home gateway support yet. MAP-E. Some buzz, no announced trials or deployments, no home gateway support yet. Native dual-stack. Still the gold standard, but doesn=E2=80=99t solve IPv4 addr= ess shortage. (Note that =E2=80=9Cyet=E2=80=9D may change at any time). As a matter of discussion, do you agree? To guide our work, is there work we should do to document or deprecate any of these? Thanks, Lee --B_3599219750_74824803 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    The WG Chairs = were discussing the various transition technologies at some length today.
    I mentioned a previous conversation in another forum that led to thi= s list of networks and their mechanisms:
    (Corrections and additions encouraged, = especially with links)

    Our impression was that of t= he 26+ transition mechanisms defined, only a few have any modern relevance (= editorial comments are mine, not consensus positions):
    6rd.  = It may be that its light is waning, with early deployments moving to native= IPv6, and no new deployments.
    DS-Lite.   Widely deployed, ex= isting support among home gateway manufacturers.
    NAT64/464xlat. &n= bsp; Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No hom= e gateway CLAT yet.
    MAP-T.   Announced trials and lots of buz= z, but no large-scale deployments, no home gateway support yet.
    MA= P-E.   Some buzz, no announced trials or deployments, no home gateway s= upport yet.
    Native dual-stack.   Still the gold standard, but= doesn’t solve IPv4 address shortage.

    (Note t= hat “yet” may change at any time).
    As a matter of disc= ussion, do you agree?
    To guide our work, is there work we should d= o to document or deprecate any of these?

    Thanks,

    Lee

    --B_3599219750_74824803-- From nobody Fri Jan 19 16:22:24 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD1129C6E for ; Fri, 19 Jan 2018 16:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4JwZRlSKMVfZ for ; Fri, 19 Jan 2018 16:22:19 -0800 (PST) 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 36BDD120713 for ; Fri, 19 Jan 2018 16:22:19 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id z48so3037182wrz.6 for ; Fri, 19 Jan 2018 16:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0UoAOGncSxHkQO796ayJwi7dFk+0nTmEA9y73gFsNis=; b=VGzRnb1UwYUrnB9kC2FkUjqe2uZ4+DDhde3I5jfE01IouBqww+h9DW4p35oDg8pQdz zTJviuzwhJ1Z2OM2HJl2By8CTbwfq4ULkOlG7kKNPgQ2g1KRYWPhFh6JPWIWeyzCZq/D 6KSahuJk+n+eaQgvaQx8K5m7kIdipfD/3F75EXKVIwn5hAMdLTGgz5rgRXUwrL61iVLf 7w9iYK+HWFeFOgtlvVXrONaEPWCMdlJfFIPY9riI5wuaQfPIQa38IMau+N6JUGSg7zC8 qqsOJcHNiN4g3RTgktUnUr1Yhrkh1GWpSxMV7YrLbMaUk8Mtw50OkPvTzgpKAstpyBaA S3/w== 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=0UoAOGncSxHkQO796ayJwi7dFk+0nTmEA9y73gFsNis=; b=iR6+mi90A/OoZXUvDOwL2zyqauBzGS4b0q1AwDrY2HahtKYfzyT3iV6z+l3L29mHho nTo+JE9gNkPu9Lq84YZE9bbOt7jxPlstYn/L2Rmtzr18WwLMa6CNOVqBxBb0FBc3zw3L 7OMQlFDv64ayI+DauFtCUXKTCsbq1t7Zz+L/D+TtL40CIiQXHhrlbKxfV649e8nzSWwM foUVNvrLtUX1HxuRx6qTgSA0RoSD/seWnm7ruRwV1/K0/qROgOngQBoM1fgucMhSRUkS ks3EW56p1Ou6YhleHaZeG0Wspi1B6TA6uIZ+oWexioHZNk0djc+FhkSw9dWtpfj7vbV+ LLUQ== X-Gm-Message-State: AKwxytcWz3qTWaoM9eaokNHNUQv5H0hMupwbQZBOKZsxBAi/eOj4F/q/ 53ovukgHjDt1N/kGnllc8Ws= X-Google-Smtp-Source: AH8x226QNK/MhbDCRhZGFxBUtrCidINJf90b6JU3SDQAGgC9PQkGhpFA7F55Wm6lL3iIOfTSX/wvdw== X-Received: by 10.223.166.16 with SMTP id k16mr183227wrc.100.1516407737322; Fri, 19 Jan 2018 16:22:17 -0800 (PST) Received: from 246.66.20.149.in-addr.arpa (246.66.20.149.in-addr.arpa. [149.20.66.246]) by smtp.gmail.com with ESMTPSA id w14sm8778399wrc.63.2018.01.19.16.22.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 16:22:16 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_739D0947-5A4D-4737-A9AF-E80A65A97584"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 19 Jan 2018 16:22:12 -0800 In-Reply-To: Cc: v6ops@ietf.org To: Lee Howard References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jan 2018 00:22:23 -0000 --Apple-Mail=_739D0947-5A4D-4737-A9AF-E80A65A97584 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 At least part of this commentary wound up in = https://tools.ietf.org/html/rfc6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=3D49679 = bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) I think Jari's view in that was that we needed to rein in the plethora = of transition technologies, and "if one has to translate, can we please = do so above the IP layer?" I added SIIT/NAT64, because I think there is = market relevance including several deployments of various kinds; any = mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation = of RFC 6180 was: - first choice, deploy native IPv6 - for scenarios in which IPv6 islands are connected across IPv4 space, = use dslite (a tunneling design). - for scenarios in which IPv6 systems have to talk with IPv4 systems, = translate. Please consider doing so above the IP layer. I would argue that 464XLAT, MAP-E, and MAP-T are "ways that an ISP might = use SIIT/NAT64 in its network", and are therefore not fundamental = transition technologies as much as ISP services built using them. I think I might also argue that the market has more or less followed = that advice. Your spreadsheet seems to suggest that. > On Jan 19, 2018, at 12:15 PM, Lee Howard wrote: >=20 >=20 > The WG Chairs were discussing the various transition technologies at = some length today. > I mentioned a previous conversation in another forum that led to this = list of networks and their mechanisms: > = https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7= NK9vcVApc/edit#gid=3D0 > (Corrections and additions encouraged, especially with links) >=20 > Our impression was that of the 26+ transition mechanisms defined, only = a few have any modern relevance (editorial comments are mine, not = consensus positions): > 6rd. It may be that its light is waning, with early deployments = moving to native IPv6, and no new deployments. > DS-Lite. Widely deployed, existing support among home gateway = manufacturers. > NAT64/464xlat. Implies NAT64, SIIT, which may be used elsewhere. = Handset CLATs. No home gateway CLAT yet. > MAP-T. Announced trials and lots of buzz, but no large-scale = deployments, no home gateway support yet. > MAP-E. Some buzz, no announced trials or deployments, no home = gateway support yet. > Native dual-stack. Still the gold standard, but doesn=E2=80=99t = solve IPv4 address shortage. >=20 > (Note that =E2=80=9Cyet=E2=80=9D may change at any time). > As a matter of discussion, do you agree? > To guide our work, is there work we should do to document or deprecate = any of these? >=20 > Thanks, >=20 > Lee --Apple-Mail=_739D0947-5A4D-4737-A9AF-E80A65A97584 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpii7QACgkQEhdRnd2G P+D4PA//Y1EX8y3o3AGVAX075mNKfa0my1hKQWaa3K11RuH6ua8wMsrXHZ/5isip MIjQI8/zqOOGw4TDOP69bLWEFD3n2bQGVg8E8eXUGh1pewErqQNBd7v+d7FDTSWf FquErXVYuGlB8tBGgCAdHjw0p/GhyRrqpajAQx6+m4mknttlUdstTbWoMFa95oEr A1Z7wWk+PLYmoKCrEgDsmXdk8CCdtA4416fRSbwF/lRxywJ3n8Icp9L2nZRbOYC5 zpOZrvpCnjpR7UlbqnH5bN7EgV2jZNoRU7PzXMHdZ2Wq6/lBE52D17FpV/zl0efC dfH92cgTAAZxb6Ev/cjmjsLTojWUQ3q23aJSU4QmEXCFQkUCVQjK+CCLhK6KIx4G Pna0X8YFqiwsAPCROMZjfp5Tl3zqM3x+jZaHsIBJzOH4iJzA69W69yi2JicnAcSa akFPVkvT8ghaowx23r3oBYgNgP4epk1He6nYy61OH99AVM0VjtDZe7Xp4nM996ZS QSDOfx4FXeGvYf7V86tKemzOKuHcsFpU90SN02t1Oj3xGEyG3Pv084ioCacI3ICz BGeSB5zQViAnz2ciIDmJO0oB/nPEi5vpAs9QzozSSXogMBgn9aAjbYLe2xutIq84 +3lmWGTsQuPBQS++AcycgHEKU8E16ZxkdsQkfaCCnPVDxIBg4G4= =WOaR -----END PGP SIGNATURE----- --Apple-Mail=_739D0947-5A4D-4737-A9AF-E80A65A97584-- From nobody Fri Jan 19 16:51:33 2018 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 BE168126FB3 for ; Fri, 19 Jan 2018 16:51:30 -0800 (PST) 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 0oAchmy92gOE for ; Fri, 19 Jan 2018 16:51:29 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F8D120713 for ; Fri, 19 Jan 2018 16:51:24 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id y77so1257371ybe.13 for ; Fri, 19 Jan 2018 16:51:24 -0800 (PST) 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=tcmqmlvDtiJwkcQrvMS6/QdP+SX/8Fe6Z1d7hP8is2g=; b=TOy8/13YDphhDxm7MPgcZXe4MnDzvVPkJpH0yVbt7UpgNq/6iOjhhraUy6bJ2pV2ku +8iXspt364fsZVV0uDUiOZiLIY50LhT0gi7aPJNfO/cnuYshelb0SqoxABLnpXShnbxE /XXoyZ3LA+t9yRDn8SyF5fwIlCFb5VMT0n5NJn+1N/9p/1kWTylMMH3FP5ZLwyp6ZY/4 hZAQ3Lm+0WV5cIj1sxKsWtitFBZ0KhXbmIKvDc4JjGqpseQLv/NFa0PFsoHUF00l0EgK h2vZVqFek5G0kf4f7B9EtpaMJKqm/9ToUpx76F4rzRKEjDlFQNZr0Sa7O2VCyxSw3LPV 1BUw== 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=tcmqmlvDtiJwkcQrvMS6/QdP+SX/8Fe6Z1d7hP8is2g=; b=j+gW7W1sgU743rFFz9jsUxZdaWol02bgWJ/lRlqXwu75AHdrdikwdfaWut/nfvMnoC 6VTZ6Fu1yNia3QR/P1TPuNpd13s5mZDU0Qm6+lBvByx79aNzmE0agdqgE2ojhRSr1j5P VbvWBpn71ggD5nplxVzPUcF6ik49mIIpPM543peIoV5OrBNIE5VJntu4GSM5lI/Hf4wH OuogzYT6Kdii21LIvAjLBxNHDehLTBPWA1or2OehSuN7Ro4ohfVH+Xz2Tl8Brze5F9ha U6BntAx3399M3qpjI4SZx4xdXu485T0PwaeK5ffg/10OB6Jko6CHi0rF95DgNkTcr25L IZHw== X-Gm-Message-State: AKwxytfGYkoOcQGF664faoja8zb2glkb9Fz+MXGudb0nUre1RBw3T6Uv GAFWVYmBaHb1k8FmZl6eNiY= X-Google-Smtp-Source: AH8x2254AkQuDO8kDncy1b2IwuYdV+l+yasHmleuOMDUhAAXJWPgeR5jKHOs19dTTIoGWvJaOsRZIw== X-Received: by 10.37.178.10 with SMTP id i10mr239881ybj.122.1516409483511; Fri, 19 Jan 2018 16:51:23 -0800 (PST) Received: from Russ ([2600:1700:720:1050:bccc:f1d:f0f3:d534]) by smtp.gmail.com with ESMTPSA id m34sm3263886ywh.106.2018.01.19.16.51.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 16:51:23 -0800 (PST) From: <7riw77@gmail.com> To: "'Lorenzo Colitti'" , "'Brian E Carpenter'" Cc: References: <066901d385ab$64d663b0$2e832b10$@gmail.com> In-Reply-To: Date: Fri, 19 Jan 2018 19:51:22 -0500 Message-ID: <058c01d39188$cb3f7630$61be6290$@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: AQJhq6FqXfQxKPsi9uY8X1ef5BV5bQJ9OQ9TASu4nfEBwpaRTQKGdYJTAomRt9CiC9Z1cA== Content-Language: en-us Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Sat, 20 Jan 2018 00:51:32 -0000 > Yes, I think that's the problem. The document takes a bit of a = one-size-fits all > approach. You also don't need netconf/yang/syslog on a mobile hotspot. = Nor > does it make sense to say "the I2RS interface to the RIB be supported" = on a > home router that has one default route and two directly-connected = subnets. Sometimes you are building a small wireless community network with "wifi = hotspot" style routers -- in which case YANG should definitely be there = ("oh, that's a lower end device, we only support a GUI config on it" = would not be an acceptable answer). Or maybe you're building a "router = in a smart television," in which case maybe you don't want it to do DHCP = or RA or anything else, because it's only intended to "route" for = devices internal to the television itself (or a car, or some other = thing). > You probably also don't need DHCPv6 or RAs on a backbone router that's > primarily intended as an LSR or segment router. I can think of many situations when you do (see below for a specific = example). The point of this sort of document is to say: "Some people might not = need this, but it SHOULD be included in implementations, so operators = don't have to constantly guess at what might be included where, but = rather can count on a set of common features across all = implementations." This process will never be perfect (of course!), but = the closer we can get to this, the closer we can get to interoperability = and lack of large surprises among all devices that run IPv6. > 1. Removing the parts of the draft that are essentially a device > profile ("routers must support X, Y and Z"). Which essentially leaves the document as a description of architecture = and lessons learned -- okay, but this doesn't help interoperability, nor = do I see the value of what remains as an RFC. > 2. Changing the aforementioned parts of the draft so that instead > of saying "routers must support X" they say "if routers support X, = they must > support RFCs A, B, and C". An example is section 3.1. Instead of = saying > "routers must support DHCPv6, SLAAC, first-hop router selection, etc." = it could > say "if routers are intended to act as first-hop routers for hosts, = they must > support...", and "if routers are intended to be operator-configurable, = then they > must allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084 > does - it defines a basic profile that everything must support, and = then > consists of a large number of statements along the lines of "if the CE = router > supports X, then it must do A, B, and C". IMHO, this document should be a mixture of both kinds of things.=20 To give a specific counter example: I would disagree that routers should = only support SLAAC and DHCPv6 if they are slated to be a "first hop = router for hosts." There are far too many situations where having SLAAC = needs to be supported on a router that does not connect to a "host." For = instance, FR Routing uses SLAAC to build IPv6 addresses on which to = connect BGP sessions without manual configuration. Now imagine you go to = a vendor and say, "this device isn't intended to connect to a host, so = you don't need to support SLAAC," then you try to run configurationless = BGP on top of it -- now it doesn't work, because some basic = functionality -- something that it seems like, to me, should be included = in every IPv6 stack -- is simply not there. I don't see how this = promotes interoperability, or functioning networks.=20 > 3. Defining a number of device profiles that have mandatory > requirements. This risks turning the document into a number of = shopping lists, > but perhaps those will be easier to get consensus on. I don't think this will help -- we'd just argue about what the device = profiles should be, creating a new one for each new set of requirements = we can think of. Ultimately, I think we'd have a draft that just says = "support whatever you like by choosing which profile you think your = device fits under." =F0=9F=98=8A The basic question comes down to this: Does the WG think building a = basic set of requirements "pretty much" _all_ IPv6 routers should run a = worthwhile concept, or -- is it that there are always going to be too = many corner cases we can think of, too many exceptions to try to account = for, to make this useful work? In other words, can we hope for an actual = set of base IPv6 features with which to create an interoperable network, = or is everything, always, going to be a "one off?" =F0=9F=98=8A Russ From nobody Fri Jan 19 16:53:26 2018 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 EB84B12D779 for ; Fri, 19 Jan 2018 16:53:23 -0800 (PST) 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 AXeG7b89nuKU for ; Fri, 19 Jan 2018 16:53:22 -0800 (PST) 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 A1B83120713 for ; Fri, 19 Jan 2018 16:53:22 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id p124so4071090ite.1 for ; Fri, 19 Jan 2018 16:53:22 -0800 (PST) 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:thread-index:content-language; bh=nR2W9qkSbGbLb3V6p6kq040C8lKIiP6W8oSqPzt5qTc=; b=qPA7Wj42+Zb8l/RqUTJXbRYQYyXHv9X4DbGtM4whVwcdl+pYypr+Uuraq+teABKwnd KfCIG6m0MaVqxhy4A1iZ3FOXmlEnjpmS3nDHZzSBoIcKRi2NF8SPr5rJ58uBhUeIqtt6 DhAQh6LKnvbl836Bl2dVIS/farkmSeFLDlUY36gty3HcQJ7Sie3oYp5YIYRcytKxdtlw WjxF6+ZX9OB0GopMfWRY0Mftxh9M97N8JXm2cAb55PlCSsiMNprLTu7CvdkovMf7sUIz f++J2nsUkj0XL0ZRu2NuitQJORZY6lVAvddFk8SQDtPJ57pYHpAS1qQubklpA9UofsG1 spZw== 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:thread-index :content-language; bh=nR2W9qkSbGbLb3V6p6kq040C8lKIiP6W8oSqPzt5qTc=; b=kop5/to28AxdsKM0/L+kjiO/sawlfmGW3/AMFQOWA1Zgmg7lv8CFQiCPAyM/TbcI37 /lXWxMgLtR0Wd1cX6nSC8kfphHhkkoaiU9CDzIKoP5GAka5d85IopPJ5nT6Qk5u7Gvgk fGmMuVRjkLndKzW7BRLmOOzRz7a3ZR4AsQVOJFmA6dDsyrc6Qwj0bE6gkPSa7KXRbpyh ZIT2HDZ4Fql93/5cq0s9tHivKfMAl6xrTYi2R/KAlPOUFA6qiwV4cii+kQl1+ceAT41f BmmW8i9eXQBKWLtcI7NOrNhkywPVFsNGsRmNXTKGp13RnLhIm/MKIVJL+8sIGrCCIm/J zjyg== X-Gm-Message-State: AKwxytdbLFwIyTuFnXO3fkxi9RdMTso0UiL5bp6EgSgZbJGKMujxC3T+ IWSM7pQnh8fsXLY1SVnYxOo= X-Google-Smtp-Source: AH8x2252eyZ4NW5NecT0wkBcGpTyIJs5XvDBtFw4xGp4azF3rhSx1HXbas9n+8CmN0NVMSaWL0aXfQ== X-Received: by 10.36.122.17 with SMTP id a17mr36990itc.91.1516409601934; Fri, 19 Jan 2018 16:53:21 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id 137sm5738163ioo.22.2018.01.19.16.53.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 16:53:21 -0800 (PST) From: <7riw77@gmail.com> To: "'Pablo Alvarez'" , References: <151491899410.22628.14408666128226236605@ietfa.amsl.com> <09b101d383fa$dd6fca30$984f5e90$@gmail.com> In-Reply-To: Date: Fri, 19 Jan 2018 19:52:59 -0500 Message-ID: <058d01d39189$11cb4e80$3561eb80$@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: AQJjFcGnelufVUlVzumpHXfPVLtZSgKUQ9kqAP0OiwOiQFvP0A== Content-Language: en-us Archived-At: Subject: Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs-01.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: Sat, 20 Jan 2018 00:53:24 -0000 > Comments on section 5.4 ICMP Considerations Thanks! I'll modify the text as suggested. =F0=9F=98=8A Russ From nobody Fri Jan 19 20:17:33 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26627126B72 for ; Fri, 19 Jan 2018 20:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 gjuyf_XP1N3F for ; Fri, 19 Jan 2018 20:17:29 -0800 (PST) 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 D412012D7EE for ; Fri, 19 Jan 2018 20:17:28 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id y26so2855016pfi.10 for ; Fri, 19 Jan 2018 20:17:28 -0800 (PST) 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=j7sFCp9LjCAW/Yfka03K3RLKHLE7MCcXimhpVDCNXcg=; b=K3sQA/bNQYqvQoA88uRVQ/O9mRetqZFClZDcpfmaIXceSakFpo3NbINSDxSCXcWM7T s87uSN8KtiTDFJuvlyi1pyla7r/XlPX0/b8eWPXYfEABPFts0RJCpXtTLpU1I8zKgRB+ 1bjAZHXSKneDbAqcOg0juB584D+EZu4m1wVAt7YM/lSFFplPyqP6U/puNQChqj4CCaqR ivm9pX+CwLpmCBWHMlhOoFxbi5dHX9YfsR+VBwlbvrqWkoKxDwDfkf8swLSHkmyTtMv5 YSWMxj/sR1UvHI1yl1qfx+b2WlKihAVT8nRpFCRukN2MRlAH7cyy7btzUnxE495MHUN2 LzSg== 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=j7sFCp9LjCAW/Yfka03K3RLKHLE7MCcXimhpVDCNXcg=; b=t6cCbeGpHEhB9Zjl1bsksym6UIXUPrqoV6eyr7T4+RFRiXs4EGJcPKE2woBkv17qiB 3fUlhaZAb+QDsxq56VX4BWLJxamVNvUS/WQnJxCZW3qhQa1E6XsBwd021qgCP4F6ovuj XjC1jS0RmChNEUs7ywyoxykuM+dXBZnay2VqsZG8J8xcIVrjGiojaan52K6NCBo1KtLR bWwGY8tq2pTamuhZpuaRfJF8fp+D6I8uZZez6IFhQQcPaZtsWYpgpFrevqI93a8SFHYw +D0GFKKpTN8zkWhL85gQoKDxZnqL10VhyoN+DqfWYvcGfci387ElLR306wL4MGBVJSu6 Ao1Q== X-Gm-Message-State: AKwxytdMBFWLJHhpbGAFZ99NsVVCwnp5OOQpUOdVeQQdRn9YRm2yRwV2 kr52Fjh2zkPC8R69DKVJJgYmBA== X-Google-Smtp-Source: AH8x224+5Fdz9T+75uuZ4gLCcABFXY420nWkbMfG8MAy3rfciZPkb8jPrF2n+P/8npAsOBXt8Cy5LA== X-Received: by 10.98.131.200 with SMTP id h191mr879668pfe.149.1516421848151; Fri, 19 Jan 2018 20:17:28 -0800 (PST) Received: from [192.168.178.30] ([118.149.106.69]) by smtp.gmail.com with ESMTPSA id v7sm15480658pgs.83.2018.01.19.20.17.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 20:17:27 -0800 (PST) To: 7riw77@gmail.com Cc: v6ops@ietf.org References: <066901d385ab$64d663b0$2e832b10$@gmail.com> <058c01d39188$cb3f7630$61be6290$@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 20 Jan 2018 17:17:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <058c01d39188$cb3f7630$61be6290$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Discussion focus: draft-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: Sat, 20 Jan 2018 04:17:31 -0000 Russ, On 20/01/2018 13:51, 7riw77@gmail.com wrote: > >> Yes, I think that's the problem. Just to restore a little context, Lorenzo wrote that in response to something I said: >>> Lorenzo, are you saying that the requirements in this draft need to be >>> scoped? That doesn't sound unreasonable, but if so, what would the >>> scoping text look like? > The basic question comes down to this: Does the WG think building a basic set of requirements "pretty much" _all_ IPv6 routers should run a worthwhile concept, a) I think you mean "should be able to run if needed, must be configurable on/off". b) If you can provide scoping text that defines which routers are covered, rather than a generalisation like "pretty much all", we could stop arguing. > or -- is it that there are always going to be too many corner cases we can think of, too many exceptions to try to account for, to make this useful work? In other words, can we hope for an actual set of base IPv6 features with which to create an interoperable network, or is everything, always, going to be a "one off?" All IETF standards are voluntary, so we can never get away from the corner cases and exceptions. IMHO the best we can do is as above: define scope, define recommendations, require configurability. Brian Brian From nobody Sun Jan 21 04:48:48 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D7129C56 for ; Sun, 21 Jan 2018 04:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss-OqsuV4Lcs for ; Sun, 21 Jan 2018 04:48:44 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2498E127869 for ; Sun, 21 Jan 2018 04:48:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 120DD4A; Sun, 21 Jan 2018 13:48:40 +0100 (CET) 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=1516538916; bh=b26dUonTAkYobWKnEwR CHN6n01K5Ac8hQDOHC+Xa1VE=; b=aKfs8cMTB+yRzIdDRW+8N0yX4uuWTp9HpXO 7lQ5kMulpyGd+BVy8QC1Iyfhn6rc12t7jAPLwCC8qQutmu99ewMUyzApFgDYMaLJ VceExjDrt+JBWeD5lX0a/Q/qHeLH+2HOgZiWfu1lw+RtiWGJbtikNmCPOXsQdV0A f3NBBLKk= 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 AES8ElXePtFi; Sun, 21 Jan 2018 13:48:36 +0100 (CET) Received: from [IPv6:2a02:a213:a301:1000:59e6:6a08:263f:e494] (unknown [IPv6:2a02:a213:a301:1000:59e6:6a08:263f:e494]) (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 1D71B49; Sun, 21 Jan 2018 13:48:36 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <0D7FF435-BA8B-40CF-AAC9-4B96F76D058E@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_4A757A1F-4E67-4AFC-AD1E-858B207AC324"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Sun, 21 Jan 2018 13:48:35 +0100 In-Reply-To: Cc: Lee Howard , v6ops@ietf.org To: Fred Baker References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jan 2018 12:48:46 -0000 --Apple-Mail=_4A757A1F-4E67-4AFC-AD1E-858B207AC324 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, I think this one is the wrong way around: > - for scenarios in which IPv6 islands are connected across IPv4 = space, use dslite (a tunneling design). DS-Lite connects IPv4 islands over IPv6 infra, and 6rd connects IPv6 = islands over IPv4 infra. Cheers! Sander --Apple-Mail=_4A757A1F-4E67-4AFC-AD1E-858B207AC324 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAlpkjCMACgkQoC0DsP4k E7meuwf9F6kzwsBspTKZ+EGYhCnrP4NEX36zkU1/oX7tBZQBd5kqrtG6xd3rBken Izx0valyBvcfX+hzJeCppyzy/VOlh6nNnxN3uV5zZ1Z6dr4fdh5tQXj8cZxbwAcG bANFFy9DpLSuvSReyrX7/3rB4mcV4bZ6Os5tc9YMluOJGC4AxxRUYXDkFqRnHeag vmsFpVgK6Qz7AVdNqiTHEUnrx32OTqlbBqJkD9eeVV+Nkt5FEbZvB9L4bZKW65Hz jKEBdQI8X/NFn+8UlzHrqODNYxKef8dPMRrgovIekFsWiJ3j8K7GxwzcI3PsDMsq WlOMe474dujuQ7eGIOJCFfe99A9XBA== =l6QA -----END PGP SIGNATURE----- --Apple-Mail=_4A757A1F-4E67-4AFC-AD1E-858B207AC324-- From nobody Sun Jan 21 11:19:54 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66481270A0 for ; Sun, 21 Jan 2018 11:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 pIyBGb0hVjhN for ; Sun, 21 Jan 2018 11:19:51 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1C2127023 for ; Sun, 21 Jan 2018 11:19:51 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id y27so5391394pgc.5 for ; Sun, 21 Jan 2018 11:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jf79r2D+JWsfaSisLoJcOABKNvHbMRV13am2WJWmQfI=; b=Wm6oXHi1H9IT8BYBhbbl/zfkXAuUJ7MYasKzFBW9i9Me2QaXW+J1KEgm1pTCPvC4Gi CLclGF3OiXG9zTSzr4uTKohcfD0QBfWtlRzBRoZMLMp++unr3SH/hZZdHtRweVbRGfPY GSw+lx40QtpjY7ss0cT1Cj6cWKAc5idgceac06js5YmITh8fX3WgqzDa3h7g91y3s2nN K5omfNbEMcFkr2CnAxXZMgvwEsH/X2Wy0SMeQn6CfDx/1GwOQAIVactDJL+Te8Z5XldF PpjdItHdv0bBJFgDRp1LDX7n/4bjyUawtvbM0tIVPWFQzF5lwDFtTUfqGZY/ooClW1ar EDpA== 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=jf79r2D+JWsfaSisLoJcOABKNvHbMRV13am2WJWmQfI=; b=c4z9GsojD4DelDjAkT2Z9RIX/O459okEPe0yPH5HifzkUxALvkzWtdk+2QjxW8Tmoe 4mvn8Wnv5zcUOPYH/lD+tYtlMMrJ/lrXZUzvxI57Y5Z8WB075QBAgGgWlCO7JVaW4ytO lPOFaXTnutxXYlRC1okwdKmsgcL8KSTZDkAelGSdz2ZQq6rwap4Pe7LM4OjVTGRCvi35 S2h5POo94I/ZrN5TrPm2LFskYKIw2smAFFU0fbLBzeZtAC52EtRoruL3mDzI+izg7JA1 p0kKZhcPLaJDF9v0+5hLf2XMQKrSe7QumQDy+7H9wzV1DdnsRWJvSGfcqDxDdvEa0RmE x8bQ== X-Gm-Message-State: AKwxytcQOM7G6PQX7ute47UbiqHGDDRyqiUzXu6+jBCtE4OS/MfFxRtU W6tb5mhrQfPy8Ddlb7Y5N1NUZLIy X-Google-Smtp-Source: AH8x2270+aVN+IpK/kxLUVLjwyBI9LTHdGRDmCP5iYtRWd9cznzrYnw8Rgeg4FkmUizhAP3lJTnEoA== X-Received: by 10.98.152.149 with SMTP id d21mr6028659pfk.108.1516562390788; Sun, 21 Jan 2018 11:19:50 -0800 (PST) Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id u79sm26843218pfg.141.2018.01.21.11.19.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jan 2018 11:19:49 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_91C7DFA8-D25E-4D08-A7F1-51F7A4309A16"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 21 Jan 2018 11:19:48 -0800 In-Reply-To: <0D7FF435-BA8B-40CF-AAC9-4B96F76D058E@steffann.nl> Cc: Lee Howard , v6ops@ietf.org To: Sander Steffann References: <0D7FF435-BA8B-40CF-AAC9-4B96F76D058E@steffann.nl> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jan 2018 19:19:53 -0000 --Apple-Mail=_91C7DFA8-D25E-4D08-A7F1-51F7A4309A16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 21, 2018, at 4:48 AM, Sander Steffann = wrote: >=20 > Hi Fred, >=20 > I think this one is the wrong way around: >=20 >> - for scenarios in which IPv6 islands are connected across IPv4 = space, use dslite (a tunneling design). >=20 > DS-Lite connects IPv4 islands over IPv6 infra, and 6rd connects IPv6 = islands over IPv4 infra. Shows how much I know. So 6rd had to be mentioned as well. --Apple-Mail=_91C7DFA8-D25E-4D08-A7F1-51F7A4309A16 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpk59QACgkQEhdRnd2G P+D1Mw//RuHVyz4SPUKQ7CkSEVWKBTlCldip7Q4LFFzjdSRnj+O59mqZGaQXNIPc U5QOxi/XiBuYOCuvhGI+1XL9OB8Rkzczdgsa4NygDjocu3oS/i9cjvPCxwa3BU7e uUgy3gPzM9z+TLJEUzffrqJU7++0v5G3F6+5kLc27xQlOpdl8zpF0Che/lur8wap uuDonvu2EofC0y2a6U3ERZvXGZ5znsr1U9+cdjSsQDXPFqTitHBSqI8D7gaOqGcY smkIgIghbCIPYiNcfYB7BKx5kNqcChFF+fnDMX91yycZKAwBxzMazL5pvIjILNYe VqtN6iXQIgdXX0Mw2vfPw31wM9hoobCPfx7cGVEBe5n8/q2paq89wxb9iT4D9zjb yp7fRhkpmDLv7RJquONzXWReYBiKZsvJDURsBCdgr6Kji9sfYygQABho78eBW5V5 rr4cZQ6Xyuj7dDNJAqML2/BZhPdMjH2ti4KDHdh97w3XyRCCV2NCdfh0YTCKcoVD m4PvJpv6kbfvUr2pVRXvA+UiCWG+H91DVNFuRPGeyrRMIo8IK+/k9weaoy4P0xSF FZJNn8MHR/6BuaLxkStASTeqhi3jSMdJTBZRM+6T3bxUErcVjOo/fQwadpk9Ke79 /Ef8g+m0EIp+o/osYThZbhEJPHH/qxf4CjYH/dBaIl9K4N7PBaM= =ywx9 -----END PGP SIGNATURE----- --Apple-Mail=_91C7DFA8-D25E-4D08-A7F1-51F7A4309A16-- From nobody Sun Jan 21 11:28:24 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4BE12D77C for ; Sun, 21 Jan 2018 11:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BZdN_-LPio5v for ; Sun, 21 Jan 2018 11:28:20 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F659127023 for ; Sun, 21 Jan 2018 11:28:14 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id u1so5407800pgr.0 for ; Sun, 21 Jan 2018 11:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1f4Iq24jqVA2YFfdrwbLVV5wCvMeOmgUHJwQK4Y0Bts=; b=ax5mVhUlpQ3ChEXbawM3eACWaLLtgGSmRgqJA5blE5GHSqXmQsxdX1Hsy7UlEqqs0o GvVng1wCrYbEyhObbBR+JCoLtzWD1sW71dNPDRXU3tLUV77miCL0bnMIOlhl4h0ejeQH 1rIgYq88mkBiQtKfK5UozHE3m3bdx4KfzSZAsze87kfAdssOwBlGbdMfKfhbOkyTV1DK jXjtsvqPdbcyf6LHjk2QpFPypU3Wu5+wBObJTC9Og1HgnUVbWSIJdZjzE0uLtVlmQjF9 fgM6y6klykw8RDFOZjknsW7NehNIxSjCJH0IgOCuodzqBf4lVuhyevW8W3vCzs1HmsGI CtEQ== 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=1f4Iq24jqVA2YFfdrwbLVV5wCvMeOmgUHJwQK4Y0Bts=; b=rkM5AXlpXa5CtEChOxM8i4dyuDvtBfAci5jH4GkvDUe49ElSXpSoDN/DjfMSL/K3bl KF0BtALkf77089xhnNFp8LMsdR42AuysWWp9IaNIDAqABiaMrsnQJZO+6vGQeT2Jia85 TuVv7CVsiMsQOPmHkDFu7obvUecbbcpOj8kQFBgZ8A6ail8Wn4VofLYk2mUrXvWCRdOn isZz3jHKkebMwJuB9+7Rt1mZ2oXGY3JJ4tDsIIDFrPXRc/Vr4jMavi9Q6HhA08xhxssi numqlfpDjQxZ0FuQnkO76hi/O5yML41R5+iMMqcBP0yAMj+oSJQsztfncY60Jajq2rTR ASyg== X-Gm-Message-State: AKwxyteUoUlVotQT/00/dhnb5d7ZRmqbl/9neUz57M0a2ujngmrrwBKB 3RdfB8bjhlAdw2dc+KbCNwzAkd6c X-Google-Smtp-Source: AH8x227D/2jxcF8K0iCzC61iKL97q7e5vSG3hGU3zZs6tEeGjkO4srLV3DI5iqdZSBxap9lIE6HftQ== X-Received: by 10.99.65.199 with SMTP id o190mr1742584pga.238.1516562893465; Sun, 21 Jan 2018 11:28:13 -0800 (PST) Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id o1sm28309124pfa.101.2018.01.21.11.28.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jan 2018 11:28:12 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_10F2EE59-37D8-4C9F-B183-C2B8AD193189"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 21 Jan 2018 11:28:09 -0800 In-Reply-To: Cc: "v6ops@ietf.org WG" , Lee Howard To: Sander Steffann References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jan 2018 19:28:23 -0000 --Apple-Mail=_10F2EE59-37D8-4C9F-B183-C2B8AD193189 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Restated. Close? > On Jan 19, 2018, at 4:22 PM, Fred Baker = wrote: >=20 > At least part of this commentary wound up in = https://tools.ietf.org/html/rfc6180 > Guidelines for Using IPv6 Transition Mechanisms during IPv6 > Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=3D49679 = bytes) > (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) >=20 > I think Jari's view in that was that we needed to rein in the plethora = of transition technologies, and "if one has to translate, can we please = do so above the IP layer?" I added SIIT/NAT64, because I think there is = market relevance including several deployments of various kinds; any = mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation = of RFC 6180 was: > - first choice, deploy native IPv6 - for scenarios in which IPv6 = islands are connected across IPv4 space, use dslite (a tunneling = design). > - for scenarios in which IPv4 islands are connected across IPv6 = space, use dslite (a tunneling design). - for scenarios in which IPv6 islands are connected across IPv4 space, = use 6rd (a tunneling design). > - for scenarios in which IPv6 systems have to talk with IPv4 systems, = translate. Please consider doing so above the IP layer. >=20 > I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an = ISP might use SIIT/NAT64 in its network", and are therefore not = fundamental transition technologies as much as ISP services built using = them. >=20 > I think I might also argue that the market has more or less followed = that advice. Your spreadsheet seems to suggest that. The interesting thing is that 6rd, which is a way of appearing to have = an IPv6 network without actually having one, is not what one might call = "prevalent". It has in fact been used for *transition*, in places like = Free - which used to connect IPv6 customers using 6rd and (I understand) = has recently announced native IPv6 deployment. The places I know that = have used it used it for a while and then have gone native. Would you agree with that? Side comment: I wrote the above and then read it back. The common = meaning of the phrase "go native" is not what I meant (it's derogatory), = but humorous in context. = https://www.urbandictionary.com/define.php?term=3Dgo%20native >> On Jan 19, 2018, at 12:15 PM, Lee Howard wrote: >>=20 >>=20 >> The WG Chairs were discussing the various transition technologies at = some length today. >> I mentioned a previous conversation in another forum that led to this = list of networks and their mechanisms: >> = https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7= NK9vcVApc/edit#gid=3D0 >> (Corrections and additions encouraged, especially with links) >>=20 >> Our impression was that of the 26+ transition mechanisms defined, = only a few have any modern relevance (editorial comments are mine, not = consensus positions): >> 6rd. It may be that its light is waning, with early deployments = moving to native IPv6, and no new deployments. >> DS-Lite. Widely deployed, existing support among home gateway = manufacturers. >> NAT64/464xlat. Implies NAT64, SIIT, which may be used elsewhere. = Handset CLATs. No home gateway CLAT yet. >> MAP-T. Announced trials and lots of buzz, but no large-scale = deployments, no home gateway support yet. >> MAP-E. Some buzz, no announced trials or deployments, no home = gateway support yet. >> Native dual-stack. Still the gold standard, but doesn=E2=80=99t = solve IPv4 address shortage. >>=20 >> (Note that =E2=80=9Cyet=E2=80=9D may change at any time). >> As a matter of discussion, do you agree? >> To guide our work, is there work we should do to document or = deprecate any of these? >>=20 >> Thanks, >>=20 >> Lee --Apple-Mail=_10F2EE59-37D8-4C9F-B183-C2B8AD193189 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpk6ckACgkQEhdRnd2G P+AFzRAAkPG6uCXLKoouoL5pe2CXVuLkiGh96g5/pDRD0bCN1jLqHTDOA2H0ZY6E vknrxJOH0txOZ1TBDwIkKVsrvADrXGul/e8+2c/J4so+0gakmvY3q7nKAFMj0++o 9AseVUom1UuiCksI1jW9kW/88qZNPx4sfeqDK8OapM1bwMVajN6sXMLI2bktZFcR HYmk2pdGFd4FWlY0A/qOUj3Gwg/Xupf5qEp4FHyA7rAXu60oO+0w2RrtLvm+fiQa V0PNAK0M5Dlvs5JPIn1hcX2pVBpNT0qpum5jJlV/XIwTCR8oVr38a8KaDLG6reD1 94ohC9FLqnSSlaRor84UbVTK3q3H9sbbCzf2PS7jrrkoXn29zB0s1LYhyublTIRb gaRcETCyCOhfqoRi9Ym11Muv5yn1TF9gQIH1BQUV0+oq9mm39xj8sOX907VjE/3m 6yXS3+5VmIuTrBBE+u0USpLA+YM5N8MvVBXsu0xaSET5CgnmB/5G3CV7UiAIjerP jmacYtl7q28XELrJOJywyKZ67oi0SiPO5OFwNNWDZU/2C3Ym7AmaFz6rUL3uHINd WLlTZTSymyUkXFZYJIraqABWJeU0q8kSBrDScQIM3NCnL1levq7hv/Pr21oDfAPF ENGutS1k0O6ABU0hzCg/W92w/Y3xYojukUkuaFGWVk9JBTdyT/c= =cW5R -----END PGP SIGNATURE----- --Apple-Mail=_10F2EE59-37D8-4C9F-B183-C2B8AD193189-- From nobody Sun Jan 21 11:44:45 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CC512D77E for ; Sun, 21 Jan 2018 11:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7kAPf_nkU0LN for ; Sun, 21 Jan 2018 11:44:42 -0800 (PST) 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 459C4127337 for ; Sun, 21 Jan 2018 11:44:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 691EE4A; Sun, 21 Jan 2018 20:44:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1516563875; bh=TYWOViiHjg94wHUKb5NmOa0p+2ft0iquzWowwe0sJLA=; b=c XKJ75ni4Y6I44Na7JNk1ZL233HX9cb7g8rLLAbjcrmyju16pqYxU/Ovaeicv2kHA doFT8lrDhieRF+KTLkhlsrT7WjBD2hDtQga3+Vnc6MjKOk/DZl2qH2UebXGNDVlp 3zjgXfVz091qC0/6E27qsVOiZkagZhzQrDrvgWLgo0= 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 12u5-76GKxlb; Sun, 21 Jan 2018 20:44:35 +0100 (CET) Received: from [IPv6:2a02:a213:a301:1000:d539:ee60:ce:1c37] (unknown [IPv6:2a02:a213:a301:1000:d539:ee60:ce:1c37]) (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 9C6AB49; Sun, 21 Jan 2018 20:44:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Sun, 21 Jan 2018 20:44:31 +0100 Cc: "v6ops@ietf.org WG" , Lee Howard Content-Transfer-Encoding: quoted-printable Message-Id: <2C4759D8-9B79-4380-B7F1-0E0388E63C10@steffann.nl> References: To: Fred Baker Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jan 2018 19:44:44 -0000 Hi Fred, >> - first choice, deploy native IPv6 - for scenarios in which IPv6 islands a= re connected across IPv4 space, use dslite (a tunneling design). >> - for scenarios in which IPv4 islands are connected across IPv6 space, us= e dslite (a tunneling design). > - for scenarios in which IPv6 islands are connected across IPv4 space, us= e 6rd (a tunneling design). >> - for scenarios in which IPv6 systems have to talk with IPv4 systems, tra= nslate. Please consider doing so above the IP layer. >>=20 >> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an IS= P might use SIIT/NAT64 in its network", and are therefore not fundamental tr= ansition technologies as much as ISP services built using them. >>=20 >> I think I might also argue that the market has more or less followed that= advice. Your spreadsheet seems to suggest that. >=20 > The interesting thing is that 6rd, which is a way of appearing to have an I= Pv6 network without actually having one, is not what one might call "prevale= nt". It has in fact been used for *transition*, in places like Free - which u= sed to connect IPv6 customers using 6rd and (I understand) has recently anno= unced native IPv6 deployment. The places I know that have used it used it fo= r a while and then have gone native. >=20 > Would you agree with that? Looks good! Thanks, Sander= From nobody Mon Jan 22 02:46:59 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247EF124239 for ; Mon, 22 Jan 2018 02:46:57 -0800 (PST) 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 nSJNdbTl8o-r for ; Mon, 22 Jan 2018 02:46:54 -0800 (PST) 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 CE6641201F8 for ; Mon, 22 Jan 2018 02:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1516618012; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=ztSb6zPAdAbsi4hm6E3rrHry+E5JhhzC2Ck6AEICwjM=; b=WJ8M4nPPmXKskckFNKoCw/jEqYZD67J16mirIoe/C7y6m+/cUQKIinRvNnM1RTH+aAPji/IXZFCMGAqDHVnki/YqqfQosOt4NIse30usFlUvqbUaC5uhrav+mbnTxjYKUZRYZKaAPCrPoLCfqXEc8SX3KrlTb41tw1a11+ARvPI= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0213.outbound.protection.outlook.com [213.199.154.213]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-90-7XAMzT7GPwG0fncfjCGf7Q-1; Mon, 22 Jan 2018 10:46:47 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0632.eurprd07.prod.outlook.com (10.160.4.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Mon, 22 Jan 2018 10:46:45 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::c1bb:a18c:e0dc:ca80]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::c1bb:a18c:e0dc:ca80%13]) with mapi id 15.20.0444.008; Mon, 22 Jan 2018 10:46:45 +0000 From: Tim Chown To: Sander Steffann CC: Fred Baker , "v6ops@ietf.org WG" Thread-Topic: [v6ops] discussion of transition technologies Thread-Index: AQHTkWJgKa3/JNne/0WMnUAV2Gh+XKN75qkAgALSgoCAAASSgIAA/BWA Date: Mon, 22 Jan 2018 10:46:45 +0000 Message-ID: References: <2C4759D8-9B79-4380-B7F1-0E0388E63C10@steffann.nl> In-Reply-To: <2C4759D8-9B79-4380-B7F1-0E0388E63C10@steffann.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-originating-ip: [2001:a88:d510:1101:7873:90f2:e3c4:2f64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0632; 20:5z4Fct9jLUaY9CgdfAlv67DbjMUuQ2Il6Ohc3QiFPZzAv4BVW4MXJciFEmj4/Clq6rQ2W5pAEBuIE/AEKx89Gh8pGCZwbRiFMnMdWKvyU/eqUZ03qJW823ncVQcmrYKnilylkiivt3mZ51R2DooTrXuj1yl/PLMVnie3Nku70lA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bcaf376b-0bf5-45f9-8890-08d561856eab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:AM3PR07MB0632; x-ms-traffictypediagnostic: AM3PR07MB0632: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231046)(2400081)(944501161)(3002001)(10201501046)(6041288)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:AM3PR07MB0632; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM3PR07MB0632; x-forefront-prvs: 0560A2214D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(39380400002)(366004)(396003)(376002)(189003)(199004)(786003)(106356001)(33656002)(316002)(82746002)(97736004)(53936002)(305945005)(7736002)(8936002)(8676002)(81156014)(81166006)(2906002)(50226002)(39060400002)(68736007)(3280700002)(3660700001)(6246003)(229853002)(5660300001)(76176011)(478600001)(72206003)(4326008)(6346003)(6506007)(53546011)(6916009)(2950100002)(25786009)(42882006)(102836004)(14454004)(6116002)(57306001)(6512007)(6436002)(36756003)(74482002)(6486002)(105586002)(93886005)(54906003)(2900100001)(83716003)(86362001)(99286004)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0632; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-microsoft-antispam-message-info: VBxnuyDC1fgsLae4kFc4sp7oNhyiDKup8MuGtdIwDuAqaNts5EJuZ61nwF0iRzLmbc1S+3d1LcwCSPqR3EvPAw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <48B31263F5C3C74D9F28290837E57861@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: bcaf376b-0bf5-45f9-8890-08d561856eab X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 10:46:45.7760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0632 X-MC-Unique: 7XAMzT7GPwG0fncfjCGf7Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 10:46:57 -0000 > On 21 Jan 2018, at 19:44, Sander Steffann wrote: >=20 > Hi Fred, >=20 >>> - first choice, deploy native IPv6 - for scenarios in which IPv6 island= s are connected across IPv4 space, use dslite (a tunneling design). >>> - for scenarios in which IPv4 islands are connected across IPv6 space, = use dslite (a tunneling design). >> - for scenarios in which IPv6 islands are connected across IPv4 space, u= se 6rd (a tunneling design). >>> - for scenarios in which IPv6 systems have to talk with IPv4 systems, t= ranslate. Please consider doing so above the IP layer. >>>=20 >>> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an = ISP might use SIIT/NAT64 in its network", and are therefore not fundamental= transition technologies as much as ISP services built using them. >>>=20 >>> I think I might also argue that the market has more or less followed th= at advice. Your spreadsheet seems to suggest that. >>=20 >> The interesting thing is that 6rd, which is a way of appearing to have a= n IPv6 network without actually having one, is not what one might call "pre= valent". It has in fact been used for *transition*, in places like Free - w= hich used to connect IPv6 customers using 6rd and (I understand) has recent= ly announced native IPv6 deployment. The places I know that have used it us= ed it for a while and then have gone native. >>=20 >> Would you agree with that? >=20 > Looks good! So what translation mechanisms are you recommending "above the IP layer" ? Tim From nobody Mon Jan 22 03:05:54 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A23124234 for ; Mon, 22 Jan 2018 03:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 mgIUEPfDyGJ3 for ; Mon, 22 Jan 2018 03:05:51 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C571201F8 for ; Mon, 22 Jan 2018 03:05:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 95AD7B0; Mon, 22 Jan 2018 12:05:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1516619146; bh=NeVPSycMhjGlEvpI0SPbdfaQ2z1elEfEjVsgAV0uaDc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bNd9Cd9Hhe4p6aYUBCVmOXnBkOeDt0yHgd2RWuiQERXQYLG+gUYZTznhc2Nv27AaW kHbROOLGXzNY70wqUt52roXRaL2FHDv5Qv7jQuBDpxnk2rR+FZTIJUf8WPCljOxvQ4 GYlhM2KFY+IiJ/ucrDW582Z08yA4K7RRg7sldPEM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9382E9F; Mon, 22 Jan 2018 12:05:46 +0100 (CET) Date: Mon, 22 Jan 2018 12:05:46 +0100 (CET) From: Mikael Abrahamsson To: Lee Howard cc: v6ops@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-570315284-1516619146=:8884" Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 11:05:54 -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-570315284-1516619146=:8884 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 19 Jan 2018, Lee Howard wrote: > Native dual-stack. Still the gold standard, but doesn’t solve IPv4 address > shortage. Well, this, but with IPv4 behind CGN. I know people who do this for mobile. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-570315284-1516619146=:8884-- From nobody Mon Jan 22 05:11:16 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB91270FC for ; Mon, 22 Jan 2018 05:11:12 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 8NT7BU1toDzQ for ; Mon, 22 Jan 2018 05:11:10 -0800 (PST) Received: from tsinghua.edu.cn (smtp26.tsinghua.edu.cn [101.6.4.50]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF6126C2F for ; Mon, 22 Jan 2018 05:11:09 -0800 (PST) Received: from [101.5.137.88] (unknown [101.5.137.88]) by app-5 (Coremail) with SMTP id EwQGZQCHjRHn4mVaLqncAw--.40485S2; Mon, 22 Jan 2018 21:11:04 +0800 (CST) Message-ID: <5A65E2E8.9010102@cernet.edu.cn> Date: Mon, 22 Jan 2018 21:11:04 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lee Howard CC: v6ops@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040504080504000807020505" X-CM-TRANSID: EwQGZQCHjRHn4mVaLqncAw--.40485S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF18ur1kWryfXw1UAF4UCFg_yoW8CrWDpF WrKw47KF1rJrn5Gw1kXw48Xa1FyFnxtw4xAFnxtwn8AFZ8tF1vqryvka98C3s8Gwn3Wr1U XrWa9ryDZFs5AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6I8v x48I62xC7I0kMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVW8JVWxJwAm72 CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxE wVAFwVW5GwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1l IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v2 6r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07 bwSdkUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 13:11:13 -0000 This is a multi-part message in MIME format. --------------040504080504000807020505 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Lee Howard 写道: Thanks for the summary. > > The WG Chairs were discussing the various transition technologies at > some length today. > I mentioned a previous conversation in another forum that led to this > list of networks and their mechanisms: > https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 > (Corrections and additions encouraged, especially with links) > > Our impression was that of the 26+ transition mechanisms defined, only > a few have any modern relevance (editorial comments are mine, not > consensus positions): > 6rd. It may be that its light is waning, with early deployments > moving to native IPv6, and no new deployments. > DS-Lite. Widely deployed, existing support among home gateway > manufacturers. > NAT64/464xlat. Implies NAT64, SIIT, which may be used elsewhere. > Handset CLATs. No home gateway CLAT yet. > MAP-T. Announced trials and lots of buzz, but no large-scale > deployments, no home gateway support yet. > MAP-E. Some buzz, no announced trials or deployments, no home > gateway support yet. > Native dual-stack. Still the gold standard, but doesn’t solve IPv4 > address shortage. > > (Note that “yet” may change at any time). > As a matter of discussion, do you agree? > To guide our work, is there work we should do to document or deprecate > any of these? FYI, we deployed Stateless translators (IVI) between IPv4 and IPv6 backbones with about 30Gbps traffic, which are used for (1) a couple of IPv6-only servers (2) 30+ campus networks with double translation (a variation of MAP-T) see https://tools.ietf.org/html/draft-xli-v6ops-cernet-deployment-03 for more information. Regards, xing > > Thanks, > > Lee > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------040504080504000807020505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Lee Howard 写道:

    Thanks for the summary.

    The WG Chairs were discussing the various transition technologies at some length today.
    I mentioned a previous conversation in another forum that led to this list of networks and their mechanisms:
    (Corrections and additions encouraged, especially with links)

    Our impression was that of the 26+ transition mechanisms defined, only a few have any modern relevance (editorial comments are mine, not consensus positions):
    6rd.   It may be that its light is waning, with early deployments moving to native IPv6, and no new deployments.
    DS-Lite.   Widely deployed, existing support among home gateway manufacturers.
    NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No home gateway CLAT yet.
    MAP-T.   Announced trials and lots of buzz, but no large-scale deployments, no home gateway support yet.
    MAP-E.   Some buzz, no announced trials or deployments, no home gateway support yet.
    Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 address shortage.

    (Note that “yet” may change at any time).
    As a matter of discussion, do you agree?
    To guide our work, is there work we should do to document or deprecate any of these?

    FYI, we deployed Stateless translators (IVI) between IPv4 and IPv6 backbones with about 30Gbps traffic, which are used for
    (1) a couple of IPv6-only servers
    (2) 30+ campus networks with double translation (a variation of MAP-T)

    see https://tools.ietf.org/html/draft-xli-v6ops-cernet-deployment-03 for more information.

    Regards,

    xing


    Thanks,

    Lee

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

    --------------040504080504000807020505-- From nobody Mon Jan 22 09:29:53 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92E126E64 for ; Mon, 22 Jan 2018 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 VZ_kAxEBEQ3t for ; Mon, 22 Jan 2018 09:29:50 -0800 (PST) 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 31895126CE8 for ; Mon, 22 Jan 2018 09:29:50 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id m20so7595528pgc.11 for ; Mon, 22 Jan 2018 09:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UYBnzPbLYxhoW8SKYPkNf1gQzd4kmTz2vwd9wMH2ACI=; b=qJZJtA1bDgwJZepKyT9X73lGo3TzwbAQZ7pMZwb7/qkoMpxruUut+DiqY8obru2bEK 2NXW3jwbnUms9JoJdnPlWAjYqEWjUYR22ebHPcbS6DkZxqI3WDlrPX3d2pc4Mv0qgAQ1 6qo5zcTMP7YexhVmRoqZGlFdH5fAEMur2LHKVgPgxaHyTdxP04ckGYuUC0vyueksgIW0 z7naHLe+rbZ8f3dG0EveMlx/SNWpCsxAPX+bOuq0+DvLKAhLkhnpsC/5Ij2wr1Kj4Gel O2bpKLw4HToaZx+Oadw15yzfqqWSaY/EfB2V4Xai7fhPiD1aVD/3AhkXekqie8Q+fAXP SiaA== 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=UYBnzPbLYxhoW8SKYPkNf1gQzd4kmTz2vwd9wMH2ACI=; b=s+/+4Tfb+00zoe52+8im+LW5t3Cg1Dg50rdKUx5GN9nSE1nvCM73a9CatdYOjeEveW jliodsfbeDX/s78wUGlByF9DuGMkEjCMwt5jr+Cd0gR20+wHeFRRReU8FAbiZ2yuj2C0 f1dMQB6I9160MBp+GWWo6mvPzo1+cuRamPikaUvPqOQk6CrvUGaDordd57dQcah0QAZc lmkbkFuGf/2YxOAFKZbastri8EXd7zP69J7YDminEJoFPOmcEC2Nl59+r/HY8gZu+Ijj MTYkZRPSs4NgsrPTs7N0/za6MvmolnwWXnktOfPbAWgRghOaJE2+c4b6BWD+ZhEBKkh0 RGAw== X-Gm-Message-State: AKwxytcrMlesNvSnb55uNyOTYmgjhPem7FArVyuFZmw2HKkgVxcP9rn7 Qx0fc2uZasdy4yKZpLq41Mi1Tjvw X-Google-Smtp-Source: AH8x227+UoOunyCUH3f9enJMwPekRGAkzq2es/Wgm1Zl0ZdYuSdEQW06VMSv9CwIzmoQwXb/OsM42w== X-Received: by 2002:a17:902:1682:: with SMTP id h2-v6mr3876265plh.116.1516642189839; Mon, 22 Jan 2018 09:29:49 -0800 (PST) Received: from [192.168.1.20] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id c83sm1434748pfk.8.2018.01.22.09.29.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 09:29:48 -0800 (PST) From: Fred Baker Message-Id: <4288F83D-F4B6-4701-9D38-2C736668489F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_10979FD8-95F9-44EB-9287-A6CDCC4E486B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 22 Jan 2018 09:29:46 -0800 In-Reply-To: Cc: Sander Steffann , "v6ops@ietf.org WG" To: Tim Chown References: <2C4759D8-9B79-4380-B7F1-0E0388E63C10@steffann.nl> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 17:29:52 -0000 --Apple-Mail=_10979FD8-95F9-44EB-9287-A6CDCC4E486B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 22, 2018, at 2:46 AM, Tim Chown wrote: > So what translation mechanisms are you recommending "above the IP = layer" ? The one that comes quickly to mind is a load balancer that terminates = one transport connection and relays data to another. It's a transport = layer gateway, and so not translation in the SIIT sense of the word. It = also has interesting ramifications for ICMP and so on - they don't = follow the transport connection and so are invisible to it through such = a gateway. The one place that seems to be a headache is with = location-based or customer-based services - load balancers will often = insert an http header letting the ultimate recipient know the address of = its ultimate peer in the session. That, of course, has ramifications for = https etc, which might be just as happy to carry the data as some form = of login cookie or REST data element. --Apple-Mail=_10979FD8-95F9-44EB-9287-A6CDCC4E486B 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----- iQIyBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpmH4oACgkQEhdRnd2G P+C99Q/yAr1GSGXtHzhOE12Q3xWxOZ5ALoG9APmJN/IHViGcQCETzgkXnXdjV5PN 3BoyxaIKxEgoRzwIj72cs1AVcKCKSjmjWppW4aWNW6E+hMRg/Y8HyOkLA+pjUZmJ 5ZQ6DyyIswa762stkzpJATtiRW2WeI7VtxCNBtgME0cotJZ7JpqUGEsCT3eIpOoa pXDkNmvLtN8/vK9bqk3dG1kcwjStA3MapdL9KGGelP0u9ysDudUg1oean/uuUV1j SrWrZIcIugKfEJ3TG5h5MQ2iZ6HenAIe04/r4nCeV0zknLL0p2sKaA5aM0o2ElOZ z/yDmbY8NLt/8gP7cl34mT9ya2EMg3fZhZBKEsMDL7ilktqM2qDZVWxrhr6YHAkV JpFdnkvLwOKzY93jjZz/xbU25fA1QNe2qYK519m6terJNBg3Jv6WExi/+3afBH9K mFAkxGiORCUAKbBUQ6QGCnWwE952J3tOiOqtsJGOPhyq+/Nomts+jwuaPnKghmTQ tsyTk/HEawXrGD8Idge6uVHO1nXbtnDyu8ekPWJW67V44MhRL2VzhDFoTfsohOD6 NIGRq/WJf4/n/sdhkxQ5haSoBXzHfIj61S3jxPYzn+Hl+6GDUD+elwrWNqNqq/eL tzZ76CkCkWhSU2yo/jBoWNxLRucMD6TNWmoZnqSMBBONs//yDQ== =jIrj -----END PGP SIGNATURE----- --Apple-Mail=_10979FD8-95F9-44EB-9287-A6CDCC4E486B-- From nobody Mon Jan 22 10:38:05 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4018B127873 for ; Mon, 22 Jan 2018 10:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7Bnlf3OxV3WK for ; Mon, 22 Jan 2018 10:38:01 -0800 (PST) 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 8318B124D37 for ; Mon, 22 Jan 2018 10:38:01 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id r19so7750852pgn.1 for ; Mon, 22 Jan 2018 10:38:01 -0800 (PST) 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=kU5mUUGA0GqtLkz2+YXiEE9wv88V9WDqDI9vR2O8jdY=; b=UZYCSSwGsrWEXvOmm0edpGEm9+R8HKct++tzq31IzzqMnA45SG4pLSzRcoPcTgSRvC 8r39+CwMHGD0P4yB9pc8QQgKo1O8kx72g+gzehIo6O8OglhUP4hMaDx5vYFgDq1sLVlC VkzhfQ9jNLDW7aWQn8Ww4NBCc3cz73SC99iM6L+FhwtVUXGFa0AUZh+NMqAtiE9JtcE8 mZWvKQK27VyEp0B84ScBLBwBTyPj5ewR5j/cgdZgSYytwF35HRShphBBoZ4Qa+RzlR1/ 26Smm38ng4rCwm/HLLOK4lS81pHQPpElT8g+JgSVmOjEWeB65133CaY2o9/HLLSCQXCf pV7Q== 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=kU5mUUGA0GqtLkz2+YXiEE9wv88V9WDqDI9vR2O8jdY=; b=hb7zHdcchdL4lk3TXa4P/6mmrRbBR6T47A4uMBXESPiWxKggd19QRQPB2aaHYIvKI0 vY+MwsvYI/ZKpfz9ItE5zKPmSqkbZjtp0z8wLMDkJt0Z3tkzIq0yRbcQusMAvBAlu6as VH/ZbadAH5hx+/G9+tqIEKWqwmnmSF8WadlOzucixTMPxRMvnqqQbAlyFBcVIY9xMrCl 1gtjyWzlNtt7/ecJudwlL8HiAgd3pnUewiwssdf9UmoS82V3Ud7EOc0pR9CtbGRfoStt FupmGpyXR293QOoLNXgpouRM53m/95lG2WGivF6ZnFO1tzp9h65qIZOJsWPQ6j3HSZ+y fHbQ== X-Gm-Message-State: AKwxytfnPTHp4+DeELpPdmuaE5s21kt28YX0U7uHVekADyjAyjkRWmyG 2AqgFTxifpDJ13pgZYV6tRZoEg== X-Google-Smtp-Source: AH8x225vhNne7FT31BXThi0sXhG4WKwOcVcta9n8nLScHqQxBBIQqHlLWzgqgOwttmwlX0XhyOsYUw== X-Received: by 10.98.10.217 with SMTP id 86mr8915897pfk.240.1516646280467; Mon, 22 Jan 2018 10:38:00 -0800 (PST) Received: from [192.168.178.30] ([118.149.102.251]) by smtp.gmail.com with ESMTPSA id o1sm26969100pgn.6.2018.01.22.10.37.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 10:37:59 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <641cb42f-7d2e-8169-ad5f-a707b57a3390@gmail.com> Date: Tue, 23 Jan 2018 07:37:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 18:38:03 -0000 On 23/01/2018 00:05, Mikael Abrahamsson wrote: > On Fri, 19 Jan 2018, Lee Howard wrote: >=20 >> Native dual-stack. Still the gold standard, but doesn=E2=80=99t solv= e IPv4 address >> shortage. >=20 > Well, this, but with IPv4 behind CGN. I know people who do this for=20 > mobile. That's certainly what we described in https://tools.ietf.org/html/rfc6264= (and it isn't restricted to mobile). Brian From nobody Mon Jan 22 10:47:38 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECE712700F for ; Mon, 22 Jan 2018 10:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 YAFQhLFaVHbH for ; Mon, 22 Jan 2018 10:47:36 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 0DE75124D37 for ; Mon, 22 Jan 2018 10:47:35 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0MIlYNh020346; Mon, 22 Jan 2018 18:47:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=civqloKf1dz9AVdRGaPiW9IzbTuH0fPwl3quligrOas=; b=THC+FhcZqWSObPzBc0rjvHpxNNX0ZElGJZZydFk2P7lDayek3icdQkiXgY3aJrZjw3KK MPhJQXkYD0i8PAY7aSfdUY/0urxyhTA8rSbAiOXh3m80pogTtIFXodBtAeB0Be6XFqSp fv20TUp1mBFu4xn1j6thgkuvQjR2vvSMsm+022xlNuQAqs9+FSqzo4FK/mFllrOMcU82 2OlQkIJYfPZ4L8RwzHnX7bfpeqmWnMrzDnMfsuubDWDVsdlQhwaOeDg/Xg8zfDGsXk9U zatpZFfkuiesNYvNLUxlop2RDKj5mKiMKeV/H/4tVN6IcVr9XznKyZRJGLy9LSheWhDn Iw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2fkxa1kyp7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 18:47:34 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0MIk4Rh017041; Mon, 22 Jan 2018 13:47:34 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fm200djqt-1; Mon, 22 Jan 2018 13:47:34 -0500 Received: from [172.28.11.215] (padesk.kendall.corp.akamai.com [172.28.11.215]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id CFE898274F; Mon, 22 Jan 2018 11:47:33 -0700 (MST) To: 7riw77@gmail.com, v6ops@ietf.org References: <151491899410.22628.14408666128226236605@ietfa.amsl.com> <09b101d383fa$dd6fca30$984f5e90$@gmail.com> <058d01d39189$11cb4e80$3561eb80$@gmail.com> From: Pablo Alvarez Message-ID: <1dcac784-9da2-004c-be24-61404e0a366e@akamai.com> Date: Mon, 22 Jan 2018 13:47:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <058d01d39189$11cb4e80$3561eb80$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=881 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220260 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_07:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220260 Archived-At: Subject: Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs-01.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, 22 Jan 2018 18:47:37 -0000 Thanks! Pablo On 01/19/18 19:52, 7riw77@gmail.com wrote: > >> Comments on section 5.4 ICMP Considerations > > Thanks! I'll modify the text as suggested. > > 😊 > > Russ > From nobody Mon Jan 22 11:00:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595B3126D45 for ; Mon, 22 Jan 2018 11:00:54 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX5dhReT86JS for ; Mon, 22 Jan 2018 11:00:52 -0800 (PST) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05064126D73 for ; Mon, 22 Jan 2018 11:00:51 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0MJ0n9O045137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jan 2018 14:00:49 -0500 Received: (qmail 25591 invoked by uid 0); 22 Jan 2018 19:00:49 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Jan 2018 19:00:48 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 22 Jan 2018 14:00:42 -0500 From: Lee Howard To: Fred Baker , Sander Steffann CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] discussion of transition technologies References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 19:00:54 -0000 On 1/21/18, 2:28 PM, "Fred Baker" wrote: >Restated. Close? > >> On Jan 19, 2018, at 4:22 PM, Fred Baker >>wrote: >>=20 >> At least part of this commentary wound up in >>https://tools.ietf.org/html/rfc6180 >> Guidelines for Using IPv6 Transition Mechanisms during IPv6 >> Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=3D49679 bytes) >> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) >>=20 >> I think Jari's view in that was that we needed to rein in the plethora >>of transition technologies, and "if one has to translate, can we please >>do so above the IP layer?" I added SIIT/NAT64, because I think there is >>market relevance including several deployments of various kinds; any >>mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation >>of RFC 6180 was: >> - first choice, deploy native IPv6 - for scenarios in which IPv6 >>islands are connected across IPv4 space, use dslite (a tunneling design). >> - for scenarios in which IPv4 islands are connected across IPv6 space, >>use dslite (a tunneling design). You would argue that 464xlat, MAP-E, and MAP-T are simply implementations of SIIT/NAT64 (which you do, below), but it seems to me that they are also used in these scenarios. In some cases the =E2=80=9Cisland=E2=80=9D is but a single application on a mobile phone. For large networks, like access ISPs, mobile networks, and maybe campus networks, the advice might be finer-grained: - for scenarios in which IPv4 islands (e.g., households, a mobile phone, or other stub network), consider: =E2=80=94 If you need home gateway support right now, use DS-Lite =E2=80=94 If you are using CGN anyway (such as mobile networks), consider 464xlat, which allows native IPv6 end to end when possible, native IPv6 end-to-translation-edge when IPv4 is needed to reach the other end, and CLAT on the device or IPv4 edge when the local application or device requires it. =E2=80=94 If you can pressure or wait for home gateway vendors for MAP support and would prefer stateless BRs (probably more scalable/cheaper than stateful DS-Lite AFTR), use MAP. (One more decision branch between MAP-T and MAP-E, but they=E2=80=99re pretty close). =20 > - for scenarios in which IPv6 islands are connected across IPv4 space, >use 6rd (a tunneling design). >> - for scenarios in which IPv6 systems have to talk with IPv4 systems, >>translate. Please consider doing so above the IP layer. >>=20 >> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an >>ISP might use SIIT/NAT64 in its network", and are therefore not >>fundamental transition technologies as much as ISP services built using >>them. >>=20 >> I think I might also argue that the market has more or less followed >>that advice. Your spreadsheet seems to suggest that. > >The interesting thing is that 6rd, which is a way of appearing to have an >IPv6 network without actually having one, is not what one might call >"prevalent". It has in fact been used for *transition*, in places like >Free - which used to connect IPv6 customers using 6rd and (I understand) >has recently announced native IPv6 deployment. The places I know that >have used it used it for a while and then have gone native. > >Would you agree with that? I would; that is my perception. MHO is that 6rd has had its day, and while I don=E2=80=99t think it needs to be deprecated, I haven=E2=80=99t heard any scenarios = in the past several years where it solves an actual problem. Lee From nobody Mon Jan 22 11:17:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2D512700F for ; Mon, 22 Jan 2018 11:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm102Qz6zuHj for ; Mon, 22 Jan 2018 11:17:52 -0800 (PST) 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 4CE53126D45 for ; Mon, 22 Jan 2018 11:17:52 -0800 (PST) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A70292D51C4; Mon, 22 Jan 2018 19:17:50 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A038F2017E6C8A; Mon, 22 Jan 2018 20:17:48 +0100 (CET) From: Ole Troan Message-Id: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_C950A053-44E0-4CE9-94BD-B653CEF85839"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 22 Jan 2018 20:17:47 +0100 In-Reply-To: Cc: Sander Steffann , "v6ops@ietf.org WG" To: Fred Baker References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 19:17:54 -0000 --Apple-Mail=_C950A053-44E0-4CE9-94BD-B653CEF85839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jan 2018, at 20:28, Fred Baker wrote: >=20 > Restated. Close? >=20 >> On Jan 19, 2018, at 4:22 PM, Fred Baker = wrote: >>=20 >> At least part of this commentary wound up in = https://tools.ietf.org/html/rfc6180 >> Guidelines for Using IPv6 Transition Mechanisms during IPv6 >> Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=3D49679 = bytes) >> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) >>=20 >> I think Jari's view in that was that we needed to rein in the = plethora of transition technologies, and "if one has to translate, can = we please do so above the IP layer?" I added SIIT/NAT64, because I think = there is market relevance including several deployments of various = kinds; any mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic = recommendation of RFC 6180 was: >> - first choice, deploy native IPv6 - for scenarios in which IPv6 = islands are connected across IPv4 space, use dslite (a tunneling = design). >> - for scenarios in which IPv4 islands are connected across IPv6 = space, use dslite (a tunneling design). > - for scenarios in which IPv6 islands are connected across IPv4 = space, use 6rd (a tunneling design). >> - for scenarios in which IPv6 systems have to talk with IPv4 systems, = translate. Please consider doing so above the IP layer. >>=20 >> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which = an ISP might use SIIT/NAT64 in its network", and are therefore not = fundamental transition technologies as much as ISP services built using = them. >>=20 >> I think I might also argue that the market has more or less followed = that advice. Your spreadsheet seems to suggest that. >=20 > The interesting thing is that 6rd, which is a way of appearing to have = an IPv6 network without actually having one, is not what one might call = "prevalent". It has in fact been used for *transition*, in places like = Free - which used to connect IPv6 customers using 6rd and (I understand) = has recently announced native IPv6 deployment. The places I know that = have used it used it for a while and then have gone native. >=20 > Would you agree with that? No. There are active 6rd deployments with millions of users. This email goes over 6rd. What's the purpose of what you are trying to do? Do you want to describe the world as you want it to be? Or as it is? And for either case, see question 1. Ole >=20 > Side comment: I wrote the above and then read it back. The common = meaning of the phrase "go native" is not what I meant (it's derogatory), = but humorous in context. = https://www.urbandictionary.com/define.php?term=3Dgo%20native >=20 >>> On Jan 19, 2018, at 12:15 PM, Lee Howard wrote: >>>=20 >>>=20 >>> The WG Chairs were discussing the various transition technologies at = some length today. >>> I mentioned a previous conversation in another forum that led to = this list of networks and their mechanisms: >>> = https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7= NK9vcVApc/edit#gid=3D0 >>> (Corrections and additions encouraged, especially with links) >>>=20 >>> Our impression was that of the 26+ transition mechanisms defined, = only a few have any modern relevance (editorial comments are mine, not = consensus positions): >>> 6rd. It may be that its light is waning, with early deployments = moving to native IPv6, and no new deployments. >>> DS-Lite. Widely deployed, existing support among home gateway = manufacturers. >>> NAT64/464xlat. Implies NAT64, SIIT, which may be used elsewhere. = Handset CLATs. No home gateway CLAT yet. >>> MAP-T. Announced trials and lots of buzz, but no large-scale = deployments, no home gateway support yet. >>> MAP-E. Some buzz, no announced trials or deployments, no home = gateway support yet. >>> Native dual-stack. Still the gold standard, but doesn=E2=80=99t = solve IPv4 address shortage. >>>=20 >>> (Note that =E2=80=9Cyet=E2=80=9D may change at any time). >>> As a matter of discussion, do you agree? >>> To guide our work, is there work we should do to document or = deprecate any of these? >>>=20 >>> Thanks, >>>=20 >>> Lee >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_C950A053-44E0-4CE9-94BD-B653CEF85839 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 iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlpmONsACgkQvtpYqJhC 33Z5mhAArRlTOKPn24wTGVYQUI2nWP09AQFxzdNQ97p/xuXSV7eJrlY3Qd2bFrk9 eY6gjSfKXaN0ON2Wv+irpCvQuchDFVfFCf3B/cpo3OIbHjMBH4uvOMTzttV7fRDP BMNXPpFNFweqXWLq5PIaBnGaffRLOYuaIJf14LzTCDRoBtFkYnGzMZ/KMzKpHlJV kdJ0BE7IlHLcvfOHdrq+PSZS932+wf+xIXsHERqJKdHz8Gm+uhKC6xA5y+3wEi6s 3c07kWvLYN6rKzl9s08koewUwr6fnFwHuwkULDPwYrGpNbbD+bhLrYH6evXwv2kR ZMB44gB1uhGfozJIGAysqaBEMf17jBpC7DTYe/PiHSxD8YN5t28kLDfdL8A0l1Qc G0stzwR91wb1oJvL9UmL67CE0XQeJnvJe9TMrh0iDaJ+CAlfdsWY6Ky2BTPPoHoY Bms52Qm1sd+PSPt6sJdL0TD4H5eZyZ8nKpE2Vc4C0CNWEGBjq8rmqWpZaYkq0unT UyFAmP2TwqlxEhJ8P77ge2ICTCjMmaUivF1GLSVCuBDDSqpT3tAn9XSC5plUGZ6g RDXH70eTn1gzbvMrDRuZ/WV2ZM5pgT1UQfq/4y939oNv5vaj3rZCxrEQOwRr2k5P oiO/ggCYnL95+t9l1col9eMYhf2eDwCVxV7dqF0kV4efj6jmAq4= =1IT8 -----END PGP SIGNATURE----- --Apple-Mail=_C950A053-44E0-4CE9-94BD-B653CEF85839-- From nobody Mon Jan 22 11:20:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D45126D45 for ; Mon, 22 Jan 2018 11:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjZhjM4zGkGM for ; Mon, 22 Jan 2018 11:20:11 -0800 (PST) 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 227AA126CF6 for ; Mon, 22 Jan 2018 11:20:11 -0800 (PST) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 9C4C22D50B2; Mon, 22 Jan 2018 19:20:10 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D6BE22017E6ECC; Mon, 22 Jan 2018 20:20:08 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8071AD3F-1EDF-40A7-B04A-F5022933ADA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 22 Jan 2018 20:20:07 +0100 In-Reply-To: Cc: Fred Baker , Sander Steffann , "v6ops@ietf.org WG" To: Lee Howard References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 19:20:13 -0000 --Apple-Mail=_8071AD3F-1EDF-40A7-B04A-F5022933ADA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> Restated. Close? >>=20 >>> On Jan 19, 2018, at 4:22 PM, Fred Baker >>> wrote: >>>=20 >>> At least part of this commentary wound up in >>> https://tools.ietf.org/html/rfc6180 >>> Guidelines for Using IPv6 Transition Mechanisms during IPv6 >>> Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=3D49679 = bytes) >>> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) >>>=20 >>> I think Jari's view in that was that we needed to rein in the = plethora >>> of transition technologies, and "if one has to translate, can we = please >>> do so above the IP layer?" I added SIIT/NAT64, because I think there = is >>> market relevance including several deployments of various kinds; any >>> mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic = recommendation >>> of RFC 6180 was: >>> - first choice, deploy native IPv6 - for scenarios in which IPv6 >>> islands are connected across IPv4 space, use dslite (a tunneling = design). >>> - for scenarios in which IPv4 islands are connected across IPv6 = space, >>> use dslite (a tunneling design). >=20 > You would argue that 464xlat, MAP-E, and MAP-T are simply = implementations > of SIIT/NAT64 (which you do, below), but it seems to me that they are = also > used in these scenarios. In some cases the =E2=80=9Cisland=E2=80=9D is = but a single > application on a mobile phone. >=20 MAP-E is not an implementation of SIIT/NAT64. > For large networks, like access ISPs, mobile networks, and maybe = campus > networks, the advice might be finer-grained: > - for scenarios in which IPv4 islands (e.g., households, a mobile = phone, > or other stub network), consider: > =E2=80=94 If you need home gateway support right now, use DS-Lite > =E2=80=94 If you are using CGN anyway (such as mobile networks), = consider > 464xlat, which allows native IPv6 end to end when possible, native = IPv6 > end-to-translation-edge when IPv4 is needed to reach the other end, = and > CLAT on the device or IPv4 edge when the local application or device > requires it. > =E2=80=94 If you can pressure or wait for home gateway vendors for MAP = support > and would prefer stateless BRs (probably more scalable/cheaper than > stateful DS-Lite AFTR), use MAP. (One more decision branch between = MAP-T > and MAP-E, but they=E2=80=99re pretty close). >=20 >=20 >> - for scenarios in which IPv6 islands are connected across IPv4 = space, >> use 6rd (a tunneling design). >>> - for scenarios in which IPv6 systems have to talk with IPv4 = systems, >>> translate. Please consider doing so above the IP layer. >>>=20 >>> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which = an >>> ISP might use SIIT/NAT64 in its network", and are therefore not >>> fundamental transition technologies as much as ISP services built = using >>> them. >>>=20 >>> I think I might also argue that the market has more or less followed >>> that advice. Your spreadsheet seems to suggest that. >>=20 >> The interesting thing is that 6rd, which is a way of appearing to = have an >> IPv6 network without actually having one, is not what one might call >> "prevalent". It has in fact been used for *transition*, in places = like >> Free - which used to connect IPv6 customers using 6rd and (I = understand) >> has recently announced native IPv6 deployment. The places I know that >> have used it used it for a while and then have gone native. >>=20 >> Would you agree with that? >=20 > I would; that is my perception. MHO is that 6rd has had its day, and = while > I don=E2=80=99t think it needs to be deprecated, I haven=E2=80=99t = heard any scenarios in > the past several years where it solves an actual problem. Apart from giving millions of users IPv6 access? Ole --Apple-Mail=_8071AD3F-1EDF-40A7-B04A-F5022933ADA8 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 iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlpmOWcACgkQvtpYqJhC 33b0VRAAoE6z3gHVl3yh0G5fZaNAi+YRAEjVWfRF09jUkYUXOwBtJuu74xxnFvXD OKvt9nMLIbTkmQD9lnLoq3/J8hwIDpLESjpx6/yi3gGGcuBuw8ojGivXedOAs95T 4dRv4Y34WadFEXZOX0yG84UT+WXfco1YLuUtvSxHg3D8j/C850z+AwjowCi4b7rN QqYXhfWt2jNavU9jyEMxJrQZGhzXnyfACUo8gsTSUUbk9REoPZlYR2vJSEdrSQkK eCAhkmWlYqh6Q7c2ooguYqeD2Oddj+7D0NclaBjIYBGabIbkT7c9ohe+FzkaxBr/ jfIZ+dVi6mh/5lEB5ZdrExUrO5bBM6O3R4JkxNpMV4FrAzomALqcW2gna4u3uK3z AO/jL8hclAWgB3XUkHvhse4/fY7ViKGcZEce5yOc57YwI6mqarbf0EdxuGtnq0hT irJSkPwnyeFEKIKJe+/GKeXsPMzU14Q4xHOkoHZYkWepGGzKXF4rGtzgxWHFL6qH 12HXu3iWbicuEJ4fHjQatIzGom2Xtqd1srvQFD2Fs/taA4g8QhWmrwXRzAigrUUe srRXxb9C+urqM/eRdpJrMUdpAg6dDPIegpb7p2R8+QHJ+2c25yDWYeKTZVUVL6Eu SXEur7bSQeb6OdbhFz526Cm3r1Odxy4AAZ/bWfAYmYujOLvwX+Q= =m+Gj -----END PGP SIGNATURE----- --Apple-Mail=_8071AD3F-1EDF-40A7-B04A-F5022933ADA8-- From nobody Mon Jan 22 11:41:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48E0129C6B for ; Mon, 22 Jan 2018 11:41:49 -0800 (PST) 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 tP6O61DLTsmt for ; Mon, 22 Jan 2018 11:41:47 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582A512706D for ; Mon, 22 Jan 2018 11:41:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w0MJfkZI028544; Mon, 22 Jan 2018 12:41:46 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w0MJfZMV027999 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 22 Jan 2018 12:41:35 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-06-09.nw.nos.boeing.com (137.136.239.172) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Jan 2018 11:41:34 -0800 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.1347.000; Mon, 22 Jan 2018 11:41:34 -0800 From: "Templin, Fred L" To: Ole Troan , Fred Baker CC: "v6ops@ietf.org WG" Thread-Topic: [v6ops] discussion of transition technologies Thread-Index: AQHTk7W/yQI7Mx3jdUimCQMWEAZtjKOAShWw Date: Mon, 22 Jan 2018 19:41:34 +0000 Message-ID: <4086fffe9e46422d8c7e1c4b52288a94@XCH15-06-08.nw.nos.boeing.com> References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> In-Reply-To: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [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] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 19:41:50 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xlIFRyb2FuDQo+IFNlbnQ6IE1v bmRheSwgSmFudWFyeSAyMiwgMjAxOCAxMToxOCBBTQ0KPiBUbzogRnJlZCBCYWtlciA8ZnJlZGJh a2VyLmlldGZAZ21haWwuY29tPg0KPiBDYzogdjZvcHNAaWV0Zi5vcmcgV0cgPHY2b3BzQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkaXNjdXNzaW9uIG9mIHRyYW5zaXRpb24gdGVj aG5vbG9naWVzDQo+IA0KPiANCj4gDQo+ID4gT24gMjEgSmFuIDIwMTgsIGF0IDIwOjI4LCBGcmVk IEJha2VyIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gUmVzdGF0 ZWQuIENsb3NlPw0KPiA+DQo+ID4+IE9uIEphbiAxOSwgMjAxOCwgYXQgNDoyMiBQTSwgRnJlZCBC YWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gQXQgbGVh c3QgcGFydCBvZiB0aGlzIGNvbW1lbnRhcnkgd291bmQgdXAgaW4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzYxODANCj4gPj4gICAgR3VpZGVsaW5lcyBmb3IgVXNpbmcgSVB2NiBUcmFu c2l0aW9uIE1lY2hhbmlzbXMgZHVyaW5nIElQdjYNCj4gPj4gICAgRGVwbG95bWVudC4gSi4gQXJr a28sIEYuIEJha2VyLiBNYXkgMjAxMS4gKEZvcm1hdDogVFhUPTQ5Njc5IGJ5dGVzKQ0KPiA+PiAg ICAoU3RhdHVzOiBJTkZPUk1BVElPTkFMKSAoRE9JOiAxMC4xNzQ4Ny9SRkM2MTgwKQ0KPiA+Pg0K PiA+PiBJIHRoaW5rIEphcmkncyB2aWV3IGluIHRoYXQgd2FzIHRoYXQgd2UgbmVlZGVkIHRvIHJl aW4gaW4gdGhlIHBsZXRob3JhIG9mIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzLCBhbmQgImlmIG9u ZSBoYXMgdG8gdHJhbnNsYXRlLCBjYW4gd2UNCj4gcGxlYXNlIGRvIHNvIGFib3ZlIHRoZSBJUCBs YXllcj8iIEkgYWRkZWQgU0lJVC9OQVQ2NCwgYmVjYXVzZSBJIHRoaW5rIHRoZXJlIGlzIG1hcmtl dCByZWxldmFuY2UgaW5jbHVkaW5nIHNldmVyYWwgZGVwbG95bWVudHMgb2YNCj4gdmFyaW91cyBr aW5kczsgYW55IG1lbnRpb24gb2YgTUFQLVQgb3IgNDY0WExBVCBpcyBTSUlUL05BVDY0LiBCdXQg dGhlIGJhc2ljIHJlY29tbWVuZGF0aW9uIG9mIFJGQyA2MTgwIHdhczoNCj4gPj4gLSBmaXJzdCBj aG9pY2UsIGRlcGxveSBuYXRpdmUgSVB2NiAtIGZvciBzY2VuYXJpb3MgaW4gd2hpY2ggSVB2NiBp c2xhbmRzIGFyZSBjb25uZWN0ZWQgYWNyb3NzIElQdjQgc3BhY2UsIHVzZSBkc2xpdGUgKGEgdHVu bmVsaW5nDQo+IGRlc2lnbikuDQo+ID4+IC0gZm9yIHNjZW5hcmlvcyBpbiB3aGljaCBJUHY0IGlz bGFuZHMgYXJlIGNvbm5lY3RlZCBhY3Jvc3MgSVB2NiBzcGFjZSwgdXNlIGRzbGl0ZSAoYSB0dW5u ZWxpbmcgZGVzaWduKS4NCj4gPiAgLSBmb3Igc2NlbmFyaW9zIGluIHdoaWNoIElQdjYgaXNsYW5k cyBhcmUgY29ubmVjdGVkIGFjcm9zcyBJUHY0IHNwYWNlLCB1c2UgNnJkIChhIHR1bm5lbGluZyBk ZXNpZ24pLg0KPiA+PiAtIGZvciBzY2VuYXJpb3MgaW4gd2hpY2ggSVB2NiBzeXN0ZW1zIGhhdmUg dG8gdGFsayB3aXRoIElQdjQgc3lzdGVtcywgdHJhbnNsYXRlLiBQbGVhc2UgY29uc2lkZXIgZG9p bmcgc28gYWJvdmUgdGhlIElQIGxheWVyLg0KPiA+Pg0KPiA+PiBJIHdvdWxkIGFyZ3VlIHRoYXQg NDY0WExBVCwgTUFQLUUsIGFuZCBNQVAtVCBhcmUgInNlcnZpY2VzIGluIHdoaWNoIGFuIElTUCBt aWdodCB1c2UgU0lJVC9OQVQ2NCBpbiBpdHMgbmV0d29yayIsIGFuZCBhcmUNCj4gdGhlcmVmb3Jl IG5vdCBmdW5kYW1lbnRhbCB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcyBhcyBtdWNoIGFzIElTUCBz ZXJ2aWNlcyBidWlsdCB1c2luZyB0aGVtLg0KPiA+Pg0KPiA+PiBJIHRoaW5rIEkgbWlnaHQgYWxz byBhcmd1ZSB0aGF0IHRoZSBtYXJrZXQgaGFzIG1vcmUgb3IgbGVzcyBmb2xsb3dlZCB0aGF0IGFk dmljZS4gWW91ciBzcHJlYWRzaGVldCBzZWVtcyB0byBzdWdnZXN0IHRoYXQuDQo+ID4NCj4gPiBU aGUgaW50ZXJlc3RpbmcgdGhpbmcgaXMgdGhhdCA2cmQsIHdoaWNoIGlzIGEgd2F5IG9mIGFwcGVh cmluZyB0byBoYXZlIGFuIElQdjYgbmV0d29yayB3aXRob3V0IGFjdHVhbGx5IGhhdmluZyBvbmUs IGlzIG5vdCB3aGF0IG9uZQ0KPiBtaWdodCBjYWxsICJwcmV2YWxlbnQiLiBJdCBoYXMgaW4gZmFj dCBiZWVuIHVzZWQgZm9yICp0cmFuc2l0aW9uKiwgaW4gcGxhY2VzIGxpa2UgRnJlZSAtIHdoaWNo IHVzZWQgdG8gY29ubmVjdCBJUHY2IGN1c3RvbWVycyB1c2luZyA2cmQNCj4gYW5kIChJIHVuZGVy c3RhbmQpIGhhcyByZWNlbnRseSBhbm5vdW5jZWQgbmF0aXZlIElQdjYgZGVwbG95bWVudC4gVGhl IHBsYWNlcyBJIGtub3cgdGhhdCBoYXZlIHVzZWQgaXQgdXNlZCBpdCBmb3IgYSB3aGlsZSBhbmQg dGhlbg0KPiBoYXZlIGdvbmUgbmF0aXZlLg0KPiA+DQo+ID4gV291bGQgeW91IGFncmVlIHdpdGgg dGhhdD8NCj4gDQo+IE5vLiBUaGVyZSBhcmUgYWN0aXZlIDZyZCBkZXBsb3ltZW50cyB3aXRoIG1p bGxpb25zIG9mIHVzZXJzLg0KPiBUaGlzIGVtYWlsIGdvZXMgb3ZlciA2cmQuDQo+IA0KPiBXaGF0 J3MgdGhlIHB1cnBvc2Ugb2Ygd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkbz8NCj4gRG8geW91IHdh bnQgdG8gZGVzY3JpYmUgdGhlIHdvcmxkIGFzIHlvdSB3YW50IGl0IHRvIGJlPyBPciBhcyBpdCBp cz8NCg0KSWYgd2Ugd2FudGVkIHRvIGRlc2NyaWJlIHRoZSB3b3JsZCBhcyBpdCBpcywgd2Ugd291 bGQgYWxzbyBoYXZlIHRvIHVzZSB0aGUgIkkqIiB3b3JkLg0KDQpGcmVkDQoNCj4gQW5kIGZvciBl aXRoZXIgY2FzZSwgc2VlIHF1ZXN0aW9uIDEuDQo+IA0KPiBPbGUNCj4gDQo+IA0KPiA+DQo+ID4g U2lkZSBjb21tZW50OiBJIHdyb3RlIHRoZSBhYm92ZSBhbmQgdGhlbiByZWFkIGl0IGJhY2suIFRo ZSBjb21tb24gbWVhbmluZyBvZiB0aGUgcGhyYXNlICJnbyBuYXRpdmUiIGlzIG5vdCB3aGF0IEkg bWVhbnQgKGl0J3MNCj4gZGVyb2dhdG9yeSksIGJ1dCBodW1vcm91cyBpbiBjb250ZXh0LiBodHRw czovL3d3dy51cmJhbmRpY3Rpb25hcnkuY29tL2RlZmluZS5waHA/dGVybT1nbyUyMG5hdGl2ZQ0K PiA+DQo+ID4+PiBPbiBKYW4gMTksIDIwMTgsIGF0IDEyOjE1IFBNLCBMZWUgSG93YXJkIDxMZWVA YXNnYXJkLm9yZz4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZSBXRyBDaGFpcnMgd2Vy ZSBkaXNjdXNzaW5nIHRoZSB2YXJpb3VzIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIGF0IHNvbWUg bGVuZ3RoIHRvZGF5Lg0KPiA+Pj4gSSBtZW50aW9uZWQgYSBwcmV2aW91cyBjb252ZXJzYXRpb24g aW4gYW5vdGhlciBmb3J1bSB0aGF0IGxlZCB0byB0aGlzIGxpc3Qgb2YgbmV0d29ya3MgYW5kIHRo ZWlyIG1lY2hhbmlzbXM6DQo+ID4+PiBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9zcHJlYWRzaGVl dHMvZC8xa3NPb1dPYVJkUnlqWm5qTFNpa0hmNE81TDFPVVROT09fN05LOXZjVkFwYy9lZGl0I2dp ZD0wDQo+ID4+PiAoQ29ycmVjdGlvbnMgYW5kIGFkZGl0aW9ucyBlbmNvdXJhZ2VkLCBlc3BlY2lh bGx5IHdpdGggbGlua3MpDQo+ID4+Pg0KPiA+Pj4gT3VyIGltcHJlc3Npb24gd2FzIHRoYXQgb2Yg dGhlIDI2KyB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgZGVmaW5lZCwgb25seSBhIGZldyBoYXZlIGFu eSBtb2Rlcm4gcmVsZXZhbmNlIChlZGl0b3JpYWwgY29tbWVudHMNCj4gYXJlIG1pbmUsIG5vdCBj b25zZW5zdXMgcG9zaXRpb25zKToNCj4gPj4+IDZyZC4gICBJdCBtYXkgYmUgdGhhdCBpdHMgbGln aHQgaXMgd2FuaW5nLCB3aXRoIGVhcmx5IGRlcGxveW1lbnRzIG1vdmluZyB0byBuYXRpdmUgSVB2 NiwgYW5kIG5vIG5ldyBkZXBsb3ltZW50cy4NCj4gPj4+IERTLUxpdGUuICAgV2lkZWx5IGRlcGxv eWVkLCBleGlzdGluZyBzdXBwb3J0IGFtb25nIGhvbWUgZ2F0ZXdheSBtYW51ZmFjdHVyZXJzLg0K PiA+Pj4gTkFUNjQvNDY0eGxhdC4gICBJbXBsaWVzIE5BVDY0LCBTSUlULCB3aGljaCBtYXkgYmUg dXNlZCBlbHNld2hlcmUuIEhhbmRzZXQgQ0xBVHMuIE5vIGhvbWUgZ2F0ZXdheSBDTEFUIHlldC4N Cj4gPj4+IE1BUC1ULiAgIEFubm91bmNlZCB0cmlhbHMgYW5kIGxvdHMgb2YgYnV6eiwgYnV0IG5v IGxhcmdlLXNjYWxlIGRlcGxveW1lbnRzLCBubyBob21lIGdhdGV3YXkgc3VwcG9ydCB5ZXQuDQo+ ID4+PiBNQVAtRS4gICBTb21lIGJ1enosIG5vIGFubm91bmNlZCB0cmlhbHMgb3IgZGVwbG95bWVu dHMsIG5vIGhvbWUgZ2F0ZXdheSBzdXBwb3J0IHlldC4NCj4gPj4+IE5hdGl2ZSBkdWFsLXN0YWNr LiAgIFN0aWxsIHRoZSBnb2xkIHN0YW5kYXJkLCBidXQgZG9lc27igJl0IHNvbHZlIElQdjQgYWRk cmVzcyBzaG9ydGFnZS4NCj4gPj4+DQo+ID4+PiAoTm90ZSB0aGF0IOKAnHlldOKAnSBtYXkgY2hh bmdlIGF0IGFueSB0aW1lKS4NCj4gPj4+IEFzIGEgbWF0dGVyIG9mIGRpc2N1c3Npb24sIGRvIHlv dSBhZ3JlZT8NCj4gPj4+IFRvIGd1aWRlIG91ciB3b3JrLCBpcyB0aGVyZSB3b3JrIHdlIHNob3Vs ZCBkbyB0byBkb2N1bWVudCBvciBkZXByZWNhdGUgYW55IG9mIHRoZXNlPw0KPiA+Pj4NCj4gPj4+ IFRoYW5rcywNCj4gPj4+DQo+ID4+PiBMZWUNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4g djZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQoNCg== From nobody Mon Jan 22 11:54:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648D0129C59 for ; Mon, 22 Jan 2018 11:54:12 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 F7hDfWbl3bDW for ; Mon, 22 Jan 2018 11:54:10 -0800 (PST) Received: from atl4mhob20.registeredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2731129BBF for ; Mon, 22 Jan 2018 11:54:10 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob20.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0MJs8iH030639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jan 2018 14:54:08 -0500 Received: (qmail 28045 invoked by uid 0); 22 Jan 2018 19:54:08 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Jan 2018 19:54:07 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 22 Jan 2018 14:54:03 -0500 From: Lee Howard To: Ole Troan CC: Fred Baker , Sander Steffann , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] discussion of transition technologies References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 19:54:12 -0000 On 1/22/18, 2:20 PM, "Ole Troan" wrote: >>>>=20 >>>> I think I might also argue that the market has more or less followed >>>> that advice. Your spreadsheet seems to suggest that. >>>=20 >>> The interesting thing is that 6rd, which is a way of appearing to have >>>an >>> IPv6 network without actually having one, is not what one might call >>> "prevalent". It has in fact been used for *transition*, in places like >>> Free - which used to connect IPv6 customers using 6rd and (I >>>understand) >>> has recently announced native IPv6 deployment. The places I know that >>> have used it used it for a while and then have gone native. >>>=20 >>> Would you agree with that? >>=20 >> I would; that is my perception. MHO is that 6rd has had its day, and >>while >> I don=E2=80=99t think it needs to be deprecated, I haven=E2=80=99t heard any scenari= os >>in >> the past several years where it solves an actual problem. > >Apart from giving millions of users IPv6 access? Why would anyone want to do that? That=E2=80=99s a bit of a snarky question, but it=E2=80=99s a real one. Is there any real-world problem for which 6rd is the best answer? =E2=80=9CI can=E2=80=99t update my network to support IPv6, but there are IPv6-only hos= ts that my users need to be able to reach=E2=80=9D is the scenario 6rd addresses. Is that an actual case? The case =E2=80=9CMy ISP hasn=E2=80=99t updated to support IPv6, b= ut there are IPv6-only hosts I need to reach=E2=80=9D is solved with a tunnel broker= . I don=E2=80=99t deny that it is deployed at scale. I=E2=80=99m asking whether there are any new deployments, recent or contemplated, and what path on a decision tree would lead one to decide =E2=80=9C6rd.=E2=80=9D Lee From nobody Mon Jan 22 12:06:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3059712706D for ; Mon, 22 Jan 2018 12:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Rm9dqwjCuTgh for ; Mon, 22 Jan 2018 12:06:03 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD91F12AF6E for ; Mon, 22 Jan 2018 12:05:57 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id m26so7914709pfj.11 for ; Mon, 22 Jan 2018 12:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y8RvQ3kIow2dNXnYHlJ5zRcDrdWsVUYcb5G6DFx97oo=; b=tN3NfTP+/hN9VlqIbdUmNnyno6uKaUWQB3+sKocUWeJG9gN8xTm4qKpLVPjrQbtuEg oFf9Xn0L44hihZbNMOiFPCOBRtMohoPV8m+YolHDD6Vp3PsmRq07vyU0GYeKIqMVih0v VEgQYfsoAj+t6M0sYoidzNcvBCTvPxVEkk1eRSGPkecIhb58VLPdzjm2a23Y9kQTOs/K +4WV6Jl4azXQNv+KEn7Xu0C+wiCXrLZOQUEbtDz2vzXI+7zflz6J5OGQDXu5ljpyds0Y /C51Z1kRgQL/UBHqVkwzE4X+RpQJ4fx203YdXQddfc/SXEeVYv1fTJnuEvKf32yUc9IS zdKg== 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=Y8RvQ3kIow2dNXnYHlJ5zRcDrdWsVUYcb5G6DFx97oo=; b=fnOeA/Z151Hx7aP+9OlwwSF8h5lIVbLk3fW9YWNfngjTxZuoe+0k2EO10z/csRdlbj /2usiCkW2u4VUNKKpBRy+hXPIDh0K7j0FcP+Vweqn4FxiXQgBG1nAyavELirskZdol00 mk03NckWemtJswMu1kTSf+yk4/JDfdZSpz5bnJthWjTq8DLwH/x3e8CKWKqASJXorBnR WOMp7psbG0qkSj28Cr0Uhw9Hws7VX8VFNv+I7JSr0Jm+6+Na9MLO7ArPgjBxg21LCnOt puyNyjWSmekMLEG0kwk9hhsSP8fKpcTRsNI5fH5VeHd5S7VYwTHjaAT7zLYHSECQxUeI oogQ== X-Gm-Message-State: AKwxytdd5x0eyVUAuAfpgdEN91yX7IWTcgIx8ERtlnGrCmzZ4zMjBG7m YmK4XMdOmi10eG6g38ij7kpycsn7 X-Google-Smtp-Source: AH8x2252KY/6yAOkZNJjCGJWsFUDz9Zd0QTfWfBV3qaLR+w4+pkzCWQ92UgcCre54tjYKvITheLYTQ== X-Received: by 10.98.218.24 with SMTP id c24mr8970931pfh.145.1516651557523; Mon, 22 Jan 2018 12:05:57 -0800 (PST) Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id n80sm2579299pfj.79.2018.01.22.12.05.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:05:56 -0800 (PST) From: Fred Baker Message-Id: <70EABBF2-8572-4D6B-8C92-E1F3E247D527@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D2F14560-CD78-4B68-B8D7-C484E94F9EC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 22 Jan 2018 12:05:53 -0800 In-Reply-To: Cc: Ole Troan , Sander Steffann , "v6ops@ietf.org WG" To: Lee Howard References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 20:06:05 -0000 --Apple-Mail=_D2F14560-CD78-4B68-B8D7-C484E94F9EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 22, 2018, at 11:54 AM, Lee Howard wrote: > On 1/22/18, 2:20 PM, "Ole Troan" wrote: >>>>> I think I might also argue that the market has more or less = followed >>>>> that advice. Your spreadsheet seems to suggest that. >>>>=20 >>>> The interesting thing is that 6rd, which is a way of appearing to = have >>>> an >>>> IPv6 network without actually having one, is not what one might = call >>>> "prevalent". It has in fact been used for *transition*, in places = like >>>> Free - which used to connect IPv6 customers using 6rd and (I >>>> understand) >>>> has recently announced native IPv6 deployment. The places I know = that >>>> have used it used it for a while and then have gone native. >>>>=20 >>>> Would you agree with that? >>>=20 >>> I would; that is my perception. MHO is that 6rd has had its day, and >>> while >>> I don=E2=80=99t think it needs to be deprecated, I haven=E2=80=99t = heard any scenarios >>> in >>> the past several years where it solves an actual problem. >>=20 >> Apart from giving millions of users IPv6 access? >=20 > Why would anyone want to do that? >=20 > That=E2=80=99s a bit of a snarky question, but it=E2=80=99s a real = one. Is there any > real-world problem for which 6rd is the best answer? I think the problem space I'm familiar with is stated in my previous = note in this thread (scroll up). Imagine that you are a network operator = (ISP or enterprise) and have some IPv4-dependent system (or set of = systems) that you haven't replaced yet (or can't replace) that you need = to jump over to create an IPv6 deployment. That might be as simple as - = what I understand to have been Free's business case until recently - you = have an IPv4 network and want to rapidly deploy IPv6. Or, the case I'm = told another company had, that its DSL infrastructure was IPv4-only and = 6rd allowed it to factor that out of the discussion until they could fix = it (now, I'm told, fixed). "IPv6 islands connected by IPv4 = infrastructure", which might be continents and peninsulas, who knows. Now, to my mind and I think yours, the best answer to "I want to deploy = IPv6" is "so do so". Where it becomes an issue is "but that costs money = for some reason". 6rd might be a temporary measure to provide the = service until the money was no longer an issue. > =E2=80=9CI can=E2=80=99t update my network to support IPv6, but there = are IPv6-only hosts > that my users need to be able to reach=E2=80=9D is the scenario 6rd = addresses. Is > that an actual case? The case =E2=80=9CMy ISP hasn=E2=80=99t updated = to support IPv6, but > there are IPv6-only hosts I need to reach=E2=80=9D is solved with a = tunnel broker. >=20 > I don=E2=80=99t deny that it is deployed at scale. I=E2=80=99m asking = whether there are > any new deployments, recent or contemplated, and what path on a = decision > tree would lead one to decide =E2=80=9C6rd.=E2=80=9D >=20 > Lee >=20 >=20 >=20 --Apple-Mail=_D2F14560-CD78-4B68-B8D7-C484E94F9EC0 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpmRCEACgkQEhdRnd2G P+DkTxAAujzqRi6Ey+dWsriK3G8rAa5qWahzqtdsKHAnV6JG2FQ/hoOHeTGFcpbg dMrigNWuCpacWIyjevl5sOSAntzCwYxmlSFPndptylv77rgoUGnbYeyaVzsRoKsn nuHmaO8gfm+qpCe7+SV052car1jZrr9A4/FcEcAc6XkaA0cw1Ro81wg4qjSpxJP+ rpipQnxPSLyhtmqX8ppxKtEDpsryUEMdUcwjE1pRbPe5XHGV67V2iIHtAm7ay6+s KhSqlzWI42IEWrMMd4l9eAhNCi4vkMZPW4V2wG9vDMQNnzuXiZUq4FFIc+iDyqZW Db2eb1FUyx+Vp2+w1gcWVO/9aSQaGZY+QfCXhA5fT3VUL/VBFs+AQkJhCVrU+SF6 aE/ebChLBe5XrllqXUmd2FIxXzLOzoMD5BE7qYbjh+kC8w7ia1lnpK0LjiLy25dy LZHWd9iOf/R29OhUid2ZYwn5WQhoNzOdWEEa5asSXSpszF+EVUwZYUw/Tz2bw+AZ zY7JEc79lXKoGHjqCQZd04Ee2g8+mFJHwkKk+cQQkWrkXcMl/CA1A0i+tLwcVcjx /oUiPbbHDw6STa1EJgJenyXUplbWAvH7bhpgX1riGwi4aST2O8SakAWShoLt2vS5 jIdhaq2GJFkAlh4wGG1hDSbL0Mc/eZnN9Srx+BuAHcMPe2x6+g8= =pH6I -----END PGP SIGNATURE----- --Apple-Mail=_D2F14560-CD78-4B68-B8D7-C484E94F9EC0-- From nobody Mon Jan 22 12:07:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1A212AF6E for ; Mon, 22 Jan 2018 12:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZUgWTGOf_Le for ; Mon, 22 Jan 2018 12:07:45 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDAE127136 for ; Mon, 22 Jan 2018 12:07:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 789474A; Mon, 22 Jan 2018 21:07:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1516651658; bh=qDTS4qxyzYO8Ba7Ve1p6jJVLBJ4MjCpdOnycEiUf4nA=; b=N 23+v7OsDOJaGW2exQ9s6a3z18joLwFu7LsxM7n4UIWzuk8MjgFMqPwz0XyhyLRH7 RsCh/9NqHNyjGG+naBA7SXm9wmNxjdsKKVoICUQ7orov8mQ8il1sD0xtMLkMjfWO Y76qAFDhrLfVkBmnkfJYySI9bTft6p6ifEVSUuq+s4= 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 fBfb0RPMkbb9; Mon, 22 Jan 2018 21:07:38 +0100 (CET) Received: from [IPv6:2a02:a213:a301:1000:11ea:361:90e3:7d1] (unknown [IPv6:2a02:a213:a301:1000:11ea:361:90e3:7d1]) (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 834F249; Mon, 22 Jan 2018 21:07:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Mon, 22 Jan 2018 21:07:35 +0100 Cc: Ole Troan , Fred Baker , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lee Howard X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 20:07:48 -0000 Hi, > That=E2=80=99s a bit of a snarky question, but it=E2=80=99s a real = one. Is there any > real-world problem for which 6rd is the best answer? The deployments that I worked on used 6rd because the L2 infrastructure = couldn't do first-hop security for IPv6. No DHCPv6-PD snooping, no = source guard etc. They refused to deploy IPv6 in a much less secure way = than they deployed IPv4. And of course the switches either couldn't be = software upgraded or would require newer supervisors to support the = features they needed. Part of that has solved itself over the years with = forklift upgrades, but not everywhere. So they couldn't do native IPv6, = but still wanted to provide IPv6 service to their users: hence 6rd. Cheers, Sander From nobody Mon Jan 22 12:23:18 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3494129BBF for ; Mon, 22 Jan 2018 12:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 HUWkLucVXVtP for ; Mon, 22 Jan 2018 12:23:15 -0800 (PST) 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 63732127136 for ; Mon, 22 Jan 2018 12:23:15 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id 136so7951058pgd.8 for ; Mon, 22 Jan 2018 12:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QmlukejxyZLDL6oMgmvFTB0NDtmgZjpSFxX+jzrkcbY=; b=ZoD8nw3Bmyw/X9CMH6jwd9lIf/h3WENnDDJRTwcJ3d/79s2gtVcOePsGyPW/1dnsFI Dh3RMv6PzEd9qvkTApnIzI0D/uNGm/HYhgRqZtu20d1qWVX/vA671fxdwf2NOogcAUmh ciDgslilH9+kWW3B38NwYXxt/39KXrG/E4YLVec1otrE4pBNQ5GrUTCVp89l0LHAF1JY XQPRvlZ6s8tww9gLzE6qDV12YPdUNvXgSz1yXOoNrb0aazb4DQQUTzVfR9Vhx3EG5boE PPN/yA59fRKH7YE9VX0bi0kkC7f9A7Rs8s5YgwkxsXqdmVaciUujYUYCyZVVL6MdDc7e aA3A== 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=QmlukejxyZLDL6oMgmvFTB0NDtmgZjpSFxX+jzrkcbY=; b=bM8b7GjcSjLDm/Tt8hFK910UhKBOIZS5jUyADiY87ehAgZG2fgOY4GVSitIn1xo8ii /0Vyot86ee+9fEOw/ZB6a+URqbdY28I9hIxScwroHJ49ElkBdSLPs3mOUvHJq9B5Ep5R sUxPYhrkvETG89g9h4YTuOcUALWXv7ERmnw+XwOfN4swA8UgGPubR8Zmoin5ksHnhzyP W6rlnZK6C0SP3swIxZj0Ge+rDSYoY0ddV4jL32BbJp8cksHZXyQ7xG1DoZQseAvVS1kT Imaarn/A4rq+VY/M5EKCSzPpOg3BS26CE/Zuz0zTy8Jnv1UQabeqvmLINEiho0uJHrPi lCcQ== X-Gm-Message-State: AKwxytfy834R6y+ygNjqgc3rzF7/nBlUqee+FnUOW9qeZuRflst3Xsav 6o4quUzMgAxGVR8mWVDWN3vBiBR5 X-Google-Smtp-Source: AH8x227aQTI7AQlDyG0vOTpxJpom7tNzlaCg+oMo8/Ed5P3FCqJawFRk5fptN8Fhsx05vspmZd/GgQ== X-Received: by 10.98.32.151 with SMTP id m23mr9097044pfj.182.1516652595021; Mon, 22 Jan 2018 12:23:15 -0800 (PST) Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id g74sm1749090pfd.73.2018.01.22.12.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:23:13 -0800 (PST) From: Fred Baker Message-Id: <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F2C0B2AF-F2F1-4F57-834B-BDFAA828DE30"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 22 Jan 2018 12:23:10 -0800 In-Reply-To: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> Cc: Sander Steffann , "v6ops@ietf.org WG" To: Ole Troan References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 20:23:17 -0000 --Apple-Mail=_F2C0B2AF-F2F1-4F57-834B-BDFAA828DE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: > What's the purpose of what you are trying to do? This started out as a question among the chairs, triggered in part by an = academic article that I can't share because it's not public yet. It = lists 26 different transition mechanisms and tries to make = recommendations, based in large part of recommendations we have made. = The question started out as "can we narrow that to one such mechanism? = Which ones are actually in use?" Now see the spreadsheet Lee shared, = which comes from different data. It sounds like Ole's data on 6rd needs to get reflected in Lee's = spreadsheet. After quite a bit of discussion, we think we had pretty much re-invented = RFC 6180. The discussion isn't over, but I suspect we're close. So Lee = asked for opinions from you guys. And BTW, I suspect that dslite is a little long in the tooth for the = same reason. The theory with both 6rd and dslite was/is that once there = is a native path from here to there, even if the dslite configuration is = still in the network it's unlikely to be used. That might be naive :-) The big question among the chairs is "what is the real case for = translation?" We see it in a variety of places, basically creating a way = for IPv6-only devices or networks to talk with IPv4-only devices or = networks, but wondering if there is a better way to proceed. My personal = take is "it is what it is, no worse than IPv4/IPv4 translation" - not = arguing for it, but considering it a fact of life until people become = motivated to replace it with native systems and connectivity. YMMV. --Apple-Mail=_F2C0B2AF-F2F1-4F57-834B-BDFAA828DE30 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpmSC4ACgkQEhdRnd2G P+CbqA/8C64MCoTwqfXX0ei732gWxpyJrgcY5qn4aJMEG2EBdxg7OGLt3TAIILA8 a2JVcs6I20xofCfsANtRljs1SyITMTKZqQpBNEvnI1aX/6ib7Jp0VxHIGWslH4G5 GIdJ67kwP8Oi4AZ7W5+GvCUUg6LRpoK5BK31T8sRwXj1tEKgFq51ebhF3wz3AZp4 O+9l4ReBl6PNhbxNr38eeBmoP4FNg3zu87UTCzAJuWAoScQbEaSNV2h4ifY56cdg 89nuVKFdcCtPGCN9yh++a2TWLpyTGZ3OLOyazubhfBq/K0leMcdwS51grs6ur0N6 Q3DL1CT3MVAGZpbHz9nR/sfaM6n+iOUzmsmTmFH4eQIZBnJp+AuUrDRz+YWco8Jh Q0k+M3HB4UNapgKDJ8fLtS7XeXu699sa0ssVJVq3yFoDY47nUPdR+tL9E5/HepLj uTxPSe+Rfs2Yq4gFaWVOJqPTqD/dgQPqurtTeYpPxD+YUUrXMlb+aJq9eotrdw16 wG1wrW8ptWePckkodCeOfvMeH2UmYoJrYiljvD6t7uKB1T4oGrCNP0f7HIsuclrH X75eXJA3KKkNm6zsO2WeAO70DFEXYxwHPTVBg/WkEBq2O/RZ+VxhjT7DXGOGJXwg /Ux7JDKkR6GRVRqnT5++G7bhmtdGHqTT7LuNeATfSODrmiSmEO4= =sa+B -----END PGP SIGNATURE----- --Apple-Mail=_F2C0B2AF-F2F1-4F57-834B-BDFAA828DE30-- From nobody Mon Jan 22 12:25:22 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3BD129966 for ; Mon, 22 Jan 2018 12:25:20 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65LxWHtfSoGr for ; Mon, 22 Jan 2018 12:25:18 -0800 (PST) Received: from atl4mhob09.registeredsite.com (atl4mhob09.registeredsite.com [209.17.115.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953D1126D73 for ; Mon, 22 Jan 2018 12:25:18 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob09.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0MKPFjt008025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jan 2018 15:25:16 -0500 Received: (qmail 21649 invoked by uid 0); 22 Jan 2018 20:25:15 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Jan 2018 20:25:15 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 22 Jan 2018 15:25:07 -0500 From: Lee Howard To: Fred Baker CC: Ole Troan , Sander Steffann , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] discussion of transition technologies References: <70EABBF2-8572-4D6B-8C92-E1F3E247D527@gmail.com> In-Reply-To: <70EABBF2-8572-4D6B-8C92-E1F3E247D527@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 20:25:20 -0000 On 1/22/18, 3:05 PM, "Fred Baker" wrote: > > >On Jan 22, 2018, at 11:54 AM, Lee Howard wrote: >> On 1/22/18, 2:20 PM, "Ole Troan" wrote: >>>>>> I think I might also argue that the market has more or less followed >>>>>> that advice. Your spreadsheet seems to suggest that. >>>>>=20 >>>>> The interesting thing is that 6rd, which is a way of appearing to >>>>>have >>>>> an >>>>> IPv6 network without actually having one, is not what one might call >>>>> "prevalent". It has in fact been used for *transition*, in places >>>>>like >>>>> Free - which used to connect IPv6 customers using 6rd and (I >>>>> understand) >>>>> has recently announced native IPv6 deployment. The places I know that >>>>> have used it used it for a while and then have gone native. >>>>>=20 >>>>> Would you agree with that? >>>>=20 >>>> I would; that is my perception. MHO is that 6rd has had its day, and >>>> while >>>> I don=E2=80=99t think it needs to be deprecated, I haven=E2=80=99t heard any scena= rios >>>> in >>>> the past several years where it solves an actual problem. >>>=20 >>> Apart from giving millions of users IPv6 access? >>=20 >> Why would anyone want to do that? >>=20 >> That=E2=80=99s a bit of a snarky question, but it=E2=80=99s a real one. Is there any >> real-world problem for which 6rd is the best answer? > >I think the problem space I'm familiar with is stated in my previous note >in this thread (scroll up). Imagine that you are a network operator (ISP >or enterprise) and have some IPv4-dependent system (or set of systems) >that you haven't replaced yet (or can't replace) that you need to jump >over to create an IPv6 deployment. That might be as simple as - what I >understand to have been Free's business case until recently - you have an >IPv4 network and want to rapidly deploy IPv6. Or, the case I'm told >another company had, that its DSL infrastructure was IPv4-only and 6rd >allowed it to factor that out of the discussion until they could fix it >(now, I'm told, fixed). "IPv6 islands connected by IPv4 infrastructure", >which might be continents and peninsulas, who knows. Yes, I=E2=80=99m familiar with those use cases. They had edge networks that couldn=E2=80=99t do IPv6. I haven=E2=80=99t seen provider edge equipment shipped in the last ten years that is IPv6-incapable. I don=E2=80=99t think whether they had business reasons for wanting IPv6. Sander=E2=80=99s example is similar, but was L2 switching gear that couldn=E2=80=99t do security inspections at L3, and he also says, =E2=80=9Cpart of that has solved itself over the years." > >Now, to my mind and I think yours, the best answer to "I want to deploy >IPv6" is "so do so". Where it becomes an issue is "but that costs money >for some reason". 6rd might be a temporary measure to provide the service >until the money was no longer an issue. I=E2=80=99m thinking like a business person: why do you *want* to deploy IPv6? Or as an engineer: I have twenty projects I could work on, what am I trading off to find that 6rd is the optimal choice? > >> =E2=80=9CI can=E2=80=99t update my network to support IPv6, but there are IPv6-only >>hosts >> that my users need to be able to reach=E2=80=9D is the scenario 6rd addresses. >>Is >> that an actual case? The case =E2=80=9CMy ISP hasn=E2=80=99t updated to support IPv6= , >>but >> there are IPv6-only hosts I need to reach=E2=80=9D is solved with a tunnel >>broker. >>=20 >> I don=E2=80=99t deny that it is deployed at scale. I=E2=80=99m asking whether there = are >> any new deployments, recent or contemplated, and what path on a decision >> tree would lead one to decide =E2=80=9C6rd.=E2=80=9D I=E2=80=99m not trying to deprecate 6rd; it is in active use, and it has been goo= d for the growth of the protocol, to prove that there was interest. What I=E2=80=99m struggling to believe is that there is an actual case now, where somebody was considering how to deploy IPv6, and I would advise them to use 6rd. Has anyone here encountered that in the last couple of years? If you had the conversation now, would you still advise 6rd? Lee From nobody Mon Jan 22 12:37:36 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D9127023 for ; Mon, 22 Jan 2018 12:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 mzgFvDQetwc0 for ; Mon, 22 Jan 2018 12:37:33 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357F5126D73 for ; Mon, 22 Jan 2018 12:37:33 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id y26so7970602pfi.10 for ; Mon, 22 Jan 2018 12:37:33 -0800 (PST) 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=9OeArAGerrvtPY4YkzVp47JyWnYP57zkpc/Mhv7fU+A=; b=P4dakyz2uZonh85rDWTNjyhKImMUDX3MYQ6CjkvS+fe44NGfLs64tHT0esZ1cZwYfq ZjYQZ75erPWEFlkozwxzl5RZOyLOBj827D7r0fDac9DuQqJW1ZsS8CE7MnbTuI/34VxZ bowfEjGbNHELQ08K9wF+/6495DSbWMjb+BcDstwcnTMk2cfTFdvb3Li4mm5BvqgS2qN8 a1s8s4kBgelmZvOWL33fvWXJ4Erp6PGzUmlgxM+HDksUxxIN/fGXfeqxShO/YST5/+MM XazOnVF22I2MwqQ5KrDQmj0kIR/SlHynmHg1n1GuGH0LEPl23ug5ON44k5W6jCNl8xXQ ZWaA== 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=9OeArAGerrvtPY4YkzVp47JyWnYP57zkpc/Mhv7fU+A=; b=WLdMwsoQ2y/2DD/pFP8t140AwyMDZgAF5NY17L8O6qAwofagvSK00MHy6dRh7WiaaT orJTGAwiaU8J8CKYpH1MMjkklOPw+NHG11sBhVrYt41j+HRMKYFkUvJ18nVlVWQjOdpP RiN2A1DiuFPyh+zChmN4Al3AuRkWWxDO6CAxCb9GroA5yuWCeHB52IwnBmN8LK6gy7ZK V/2w5F5fbi8WvSiStQse7zuvS9TJz+Q+3X1S8s7WktEflpm+aHDqPWbl7jnbsmBB5ccC ChV0N7cSsihHZtkCsZfmRL+gR5beH4gtefnIcukTqQPlPfLlkqIh/U42z0tkb9EGxxIG +3ag== X-Gm-Message-State: AKwxytfCnksejnEgrwlK/5FuqnrsRSVlhRQmn1zpWbrt5QLfHLnPITNR hw6iwT6Bq3B7Sz8rZNZuSbzFBg== X-Google-Smtp-Source: AH8x224+yoPctedA0XcJhQMA4Gr0N9YXufgGkhmNsviJYdzX1541WkysXxCoxzvJIorkK4rUt+6Xuw== X-Received: by 10.98.15.27 with SMTP id x27mr9124984pfi.197.1516653452301; Mon, 22 Jan 2018 12:37:32 -0800 (PST) Received: from [192.168.178.30] ([118.149.102.251]) by smtp.gmail.com with ESMTPSA id b9sm16233144pgq.35.2018.01.22.12.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:37:31 -0800 (PST) To: Fred Baker , Ole Troan Cc: "v6ops@ietf.org WG" References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 23 Jan 2018 09:37:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 20:37:35 -0000 After watching this debate, I'm asking myself why we want to anything other than a) watch the market deciding for itself, and b) formally deprecate anything we decide is broken. Brian On 23/01/2018 09:23, Fred Baker wrote: > > > On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: >> What's the purpose of what you are trying to do? > > This started out as a question among the chairs, triggered in part by an academic article that I can't share because it's not public yet. It lists 26 different transition mechanisms and tries to make recommendations, based in large part of recommendations we have made. The question started out as "can we narrow that to one such mechanism? Which ones are actually in use?" Now see the spreadsheet Lee shared, which comes from different data. > > It sounds like Ole's data on 6rd needs to get reflected in Lee's spreadsheet. > > After quite a bit of discussion, we think we had pretty much re-invented RFC 6180. The discussion isn't over, but I suspect we're close. So Lee asked for opinions from you guys. > > And BTW, I suspect that dslite is a little long in the tooth for the same reason. The theory with both 6rd and dslite was/is that once there is a native path from here to there, even if the dslite configuration is still in the network it's unlikely to be used. That might be naive :-) > > The big question among the chairs is "what is the real case for translation?" We see it in a variety of places, basically creating a way for IPv6-only devices or networks to talk with IPv4-only devices or networks, but wondering if there is a better way to proceed. My personal take is "it is what it is, no worse than IPv4/IPv4 translation" - not arguing for it, but considering it a fact of life until people become motivated to replace it with native systems and connectivity. YMMV. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 22 13:07:21 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EA712D7E4 for ; Mon, 22 Jan 2018 13:07:20 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwcRFnnEDhxx for ; Mon, 22 Jan 2018 13:07:18 -0800 (PST) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7741112AAB6 for ; Mon, 22 Jan 2018 13:07:18 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0ML7Fma007009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jan 2018 16:07:15 -0500 Received: (qmail 22941 invoked by uid 0); 22 Jan 2018 21:07:15 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Jan 2018 21:07:15 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 22 Jan 2018 16:07:09 -0500 From: Lee Howard To: Brian E Carpenter , Fred Baker , Ole Troan CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] discussion of transition technologies References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.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] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 21:07:20 -0000 On 1/22/18, 3:37 PM, "v6ops on behalf of Brian E Carpenter" wrote: >After watching this debate, I'm asking myself why we want to anything >other than >a) watch the market deciding for itself, and We are the market. :-) As Fred describes, a lot of market participants (myself included) are overwhelmed by the number of transition mechanisms, and I have heard from quite a few people (myself included) that I could not possibly investigate 26 different technologies well enough to understand the trade offs between them, and some therefore become paralyzed. RFC6180 "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment=E2=80=9D is fine as far as it goes, but it doesn=E2=80=99t consider all of them, and was published before 464xlat and MAP. I don=E2=80=99t know that we need to publish an update to RFC6180, but maybe we d= o. For my own use, I get asked a lot what transition technology people should use. I=E2=80=99d like to know that my answers are good. Lee=20 >b) formally deprecate anything we decide is broken. > > Brian >On 23/01/2018 09:23, Fred Baker wrote: >>=20 >>=20 >> On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: >>> What's the purpose of what you are trying to do? >>=20 >> This started out as a question among the chairs, triggered in part by >>an academic article that I can't share because it's not public yet. It >>lists 26 different transition mechanisms and tries to make >>recommendations, based in large part of recommendations we have made. >>The question started out as "can we narrow that to one such mechanism? >>Which ones are actually in use?" Now see the spreadsheet Lee shared, >>which comes from different data. >>=20 >> It sounds like Ole's data on 6rd needs to get reflected in Lee's >>spreadsheet. >>=20 >> After quite a bit of discussion, we think we had pretty much >>re-invented RFC 6180. The discussion isn't over, but I suspect we're >>close. So Lee asked for opinions from you guys. >>=20 >> And BTW, I suspect that dslite is a little long in the tooth for the >>same reason. The theory with both 6rd and dslite was/is that once there >>is a native path from here to there, even if the dslite configuration is >>still in the network it's unlikely to be used. That might be naive :-) >>=20 >> The big question among the chairs is "what is the real case for >>translation?" We see it in a variety of places, basically creating a way >>for IPv6-only devices or networks to talk with IPv4-only devices or >>networks, but wondering if there is a better way to proceed. My personal >>take is "it is what it is, no worse than IPv4/IPv4 translation" - not >>arguing for it, but considering it a fact of life until people become >>motivated to replace it with native systems and connectivity. YMMV. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 22 13:17:36 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2D12D7EF for ; Mon, 22 Jan 2018 13:17:35 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIdY6GxttKcT for ; Mon, 22 Jan 2018 13:17:33 -0800 (PST) Received: from atl4mhob08.registeredsite.com (atl4mhob08.registeredsite.com [209.17.115.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4B412D7EA for ; Mon, 22 Jan 2018 13:17:32 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob08.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0MLHUHk008638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jan 2018 16:17:30 -0500 Received: (qmail 6260 invoked by uid 0); 22 Jan 2018 21:17:30 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Jan 2018 21:17:30 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 22 Jan 2018 16:17:26 -0500 From: Lee Howard To: Fred Baker , Ole Troan CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] discussion of transition technologies References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> In-Reply-To: <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 21:17:35 -0000 On 1/22/18, 3:23 PM, "v6ops on behalf of Fred Baker" wrote: > > >On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: >> What's the purpose of what you are trying to do? > >This started out as a question among the chairs, triggered in part by an >academic article that I can't share because it's not public yet. It lists >26 different transition mechanisms and tries to make recommendations, >based in large part of recommendations we have made. The question started >out as "can we narrow that to one such mechanism? Which ones are actually >in use?" Now see the spreadsheet Lee shared, which comes from different >data. > >It sounds like Ole's data on 6rd needs to get reflected in Lee's >spreadsheet. I think it is; it lists five ISPs using 6rd, though I=E2=80=99ve heard rumors two of them have switched to native dual-stack. To me, that is exactly consistent with both Ole=E2=80=99s point (millions of people use 6rd; it=E2=80=99s what you do what your edge network can=E2=80=99t handle IP= v6 but you want to provide it) and my point (not seeing new deployments, old deployments are dwindling). > >After quite a bit of discussion, we think we had pretty much re-invented >RFC 6180. The discussion isn't over, but I suspect we're close. So Lee >asked for opinions from you guys. > >And BTW, I suspect that dslite is a little long in the tooth for the same >reason. The theory with both 6rd and dslite was/is that once there is a >native path from here to there, even if the dslite configuration is still >in the network it's unlikely to be used. That might be naive :-) Responding to both paragraphs: RFC6180 recommends DS-Lite in 4.3: The recommended tool for this model is Dual Stack Lite [DS-lite ]. I=E2=80=99m not sure that would still be our recommendation, and it sounds like you=E2=80=99re not, either. It has the advantage of broad residential gateway support, and the disadvantage of being stateful. The first advantage may decline over time, but hasn=E2=80=99t yet. > >The big question among the chairs is "what is the real case for >translation?" We see it in a variety of places, basically creating a way >for IPv6-only devices or networks to talk with IPv4-only devices or >networks, but wondering if there is a better way to proceed. My personal >take is "it is what it is, no worse than IPv4/IPv4 translation" - not >arguing for it, but considering it a fact of life until people become >motivated to replace it with native systems and connectivity. YMMV. Well, we kind of skipped the data center use cases, I think. 1. My data center is all IPv4, but I want IPv6-enabled hosts to reach it (reasons of performance, logging, cost, etc.). 2. My data center is all IPv6, but I want IPv4-only hosts to reach it (because 78% of the Internet is still IPv4-only). Lee From nobody Mon Jan 22 13:23:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF5312D7E8 for ; Mon, 22 Jan 2018 13:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Jk8R9TgE5Jbs for ; Mon, 22 Jan 2018 13:23:26 -0800 (PST) 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 8783912D7E2 for ; Mon, 22 Jan 2018 13:23:26 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id k68so8081103pga.3 for ; Mon, 22 Jan 2018 13:23:26 -0800 (PST) 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=be1rMf0SDSrlLOOsPOZap1wXNhN68xqzfwfHfUpyXfA=; b=R0hVWulahGJKUUb2P4xKPbzAVGNJWnROVALzVvAK+whdZovO9YxmBIMp7v3yq2QJLZ bSZUlxj9beWDYtupchCe1N29/kPClOOKj2Sj/dJ3ZzLjKEpE1NRCMRb03plSaotNbmz7 hTfPfJEoUOasJzAa4+kHSFuDtGIF3M5MtHFHrxyEwesGBfQXLRKI1qBwMRXXfIZVicf7 ZJEsDHZVP3KR8t4ND+DQiYVFLmDnJCifqtdemhfyKSiW+q/KV+/yRYP1DU8chCS7f+0w tV3/gIgHQR7SjgoAls2IENPkRyx2/4OgPEHlpvLLrtqajNUlibf/AR4zS+rVf47oZDKc cUQg== 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=be1rMf0SDSrlLOOsPOZap1wXNhN68xqzfwfHfUpyXfA=; b=Zq0koxUs+R6oBnNdsG1261fCcOxqK9a/i+/Jc+j3Az83gPZl7uMrp18MVOo/NPErCx vKZ63SFJ87CNxv+X7t4IL97IFDMXAxbWHSqg/OizZW/vEjcrL3l/ZHUQilJrMuLmvhd+ jt1u9nHcQ+mUOHIOg26KIMdmEeKAdF6xltOXGj6HlNf+Y77UVKX/ESdgG2RH/aYUh0E+ NjUazNG5ZdC8lES7pobTmWUM5r7y53vwUDavPcvyPX3Yf+gyjKGGuBL+vEQRh/85a3DR zMflJ5y9qJ4MpVDbkqoqe7PU7PXhHZptrIw+JPIu0vP3TyfgzuTzatVMhkOmZQ3vPZuI Jxug== X-Gm-Message-State: AKwxytdw/YkoTJHNGlTXhR5u7nl5x3mxlvoKpABjPgs14mrclSf5v+6j FStiTMgZrGs8m+Sewyn7tyOIxg== X-Google-Smtp-Source: AH8x225MJ50S0Q9zJG/1sVWx445cjh8fNSgWO1F5vwXpTaGaB9RBVCFMToGS0J518s02Wr4q2+1cxQ== X-Received: by 2002:a17:902:7716:: with SMTP id n22-v6mr4158262pll.388.1516656205737; Mon, 22 Jan 2018 13:23:25 -0800 (PST) Received: from [130.216.38.21] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.21]) by smtp.gmail.com with ESMTPSA id c29sm1785476pfd.172.2018.01.22.13.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 13:23:24 -0800 (PST) To: Lee Howard , Fred Baker , Ole Troan Cc: "v6ops@ietf.org WG" References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <876fa6df-bf73-13c5-8427-a9bc2c3100b3@gmail.com> Date: Tue, 23 Jan 2018 10:23:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 21:23:29 -0000 On 23/01/2018 10:07, Lee Howard wrote: >=20 >=20 > On 1/22/18, 3:37 PM, "v6ops on behalf of Brian E Carpenter" > wrote= : >=20 >> After watching this debate, I'm asking myself why we want to anything >> other than >> a) watch the market deciding for itself, and >=20 > We are the market. :-) >=20 > As Fred describes, a lot of market participants (myself included) are > overwhelmed by the number of transition mechanisms, and I have heard fr= om > quite a few people (myself included) that I could not possibly investig= ate > 26 different technologies well enough to understand the trade offs betw= een > them, and some therefore become paralyzed. RFC6180 "Guidelines for Usin= g > IPv6 Transition Mechanisms during IPv6 Deployment=E2=80=9D is fine as f= ar as it > goes, but it doesn=E2=80=99t consider all of them, and was published be= fore > 464xlat and MAP. >=20 > I don=E2=80=99t know that we need to publish an update to RFC6180, but = maybe we do. Has RFC6180 proved useful to people? If so, update it by all means. =20 > For my own use, I get asked a lot what transition technology people sho= uld > use. I=E2=80=99d like to know that my answers are good. Understood. A decision tree would be ideal. I'm just not sure that this is the ideal place to develop it. Brian >=20 > Lee=20 >=20 >=20 >=20 >> b) formally deprecate anything we decide is broken. >> >> Brian >> On 23/01/2018 09:23, Fred Baker wrote: >>> >>> >>> On Jan 22, 2018, at 11:17 AM, Ole Troan wrote:= >>>> What's the purpose of what you are trying to do? >>> >>> This started out as a question among the chairs, triggered in part by= >>> an academic article that I can't share because it's not public yet. I= t >>> lists 26 different transition mechanisms and tries to make >>> recommendations, based in large part of recommendations we have made.= >>> The question started out as "can we narrow that to one such mechanism= ? >>> Which ones are actually in use?" Now see the spreadsheet Lee shared, >>> which comes from different data. >>> >>> It sounds like Ole's data on 6rd needs to get reflected in Lee's >>> spreadsheet. >>> >>> After quite a bit of discussion, we think we had pretty much >>> re-invented RFC 6180. The discussion isn't over, but I suspect we're >>> close. So Lee asked for opinions from you guys. >>> >>> And BTW, I suspect that dslite is a little long in the tooth for the >>> same reason. The theory with both 6rd and dslite was/is that once the= re >>> is a native path from here to there, even if the dslite configuration= is >>> still in the network it's unlikely to be used. That might be naive :-= ) >>> >>> The big question among the chairs is "what is the real case for >>> translation?" We see it in a variety of places, basically creating a = way >>> for IPv6-only devices or networks to talk with IPv4-only devices or >>> networks, but wondering if there is a better way to proceed. My perso= nal >>> take is "it is what it is, no worse than IPv4/IPv4 translation" - not= >>> arguing for it, but considering it a fact of life until people become= >>> motivated to replace it with native systems and connectivity. YMMV. >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=20 From nobody Mon Jan 22 13:25:50 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0BE12D777 for ; Mon, 22 Jan 2018 13:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohXlHdssmj_g for ; Mon, 22 Jan 2018 13:25:39 -0800 (PST) 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 34D0312D7E3 for ; Mon, 22 Jan 2018 13:25:07 -0800 (PST) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 2CEEA2D5080; Mon, 22 Jan 2018 21:25:05 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2052C2017F371A; Mon, 22 Jan 2018 22:25:03 +0100 (CET) From: Ole Troan Message-Id: <9003B298-FA2C-416C-8F5C-C06414987244@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_81EC051F-7323-4D86-B613-691B85DB482C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 22 Jan 2018 22:25:02 +0100 In-Reply-To: To: "v6ops@ietf.org WG" References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 21:25:49 -0000 --Apple-Mail=_81EC051F-7323-4D86-B613-691B85DB482C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > After watching this debate, I'm asking myself why we want to anything > other than > a) watch the market deciding for itself, and > b) formally deprecate anything we decide is broken. Indeed, there was consensus in the IETF to let the market decide. (Said differently, there was no consensus on standardising fewer = mechanisms). Why would anyone think that has changed significantly enough that it = would matter? If anyone wants to reopen these discussions, may I recommend they = entertain themselves by reading through the few thousand messages over = the last 20 years on mailing lists like ngtrans, softwire, v6ops... It's not for the lack of trying, ngtrans shut down, coin-tosses, = deprecation etc. It isn't a choice among 26 of course. The market is deciding. And we are = not the market. The likelihood of us, as in the IETF, producing any better advice than = we've already done is quite unlikely. Ole >=20 > Brian > On 23/01/2018 09:23, Fred Baker wrote: >>=20 >>=20 >> On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: >>> What's the purpose of what you are trying to do? >>=20 >> This started out as a question among the chairs, triggered in part by = an academic article that I can't share because it's not public yet. It = lists 26 different transition mechanisms and tries to make = recommendations, based in large part of recommendations we have made. = The question started out as "can we narrow that to one such mechanism? = Which ones are actually in use?" Now see the spreadsheet Lee shared, = which comes from different data. >>=20 >> It sounds like Ole's data on 6rd needs to get reflected in Lee's = spreadsheet. >>=20 >> After quite a bit of discussion, we think we had pretty much = re-invented RFC 6180. The discussion isn't over, but I suspect we're = close. So Lee asked for opinions from you guys. >>=20 >> And BTW, I suspect that dslite is a little long in the tooth for the = same reason. The theory with both 6rd and dslite was/is that once there = is a native path from here to there, even if the dslite configuration is = still in the network it's unlikely to be used. That might be naive :-) >>=20 >> The big question among the chairs is "what is the real case for = translation?" We see it in a variety of places, basically creating a way = for IPv6-only devices or networks to talk with IPv4-only devices or = networks, but wondering if there is a better way to proceed. My personal = take is "it is what it is, no worse than IPv4/IPv4 translation" - not = arguing for it, but considering it a fact of life until people become = motivated to replace it with native systems and connectivity. YMMV. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 --Apple-Mail=_81EC051F-7323-4D86-B613-691B85DB482C 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 iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlpmVq4ACgkQvtpYqJhC 33bRMA/+Nu4JORlYgBN1t6uhdSMwdbTJSefkh0wC+9iTblsmf2/MkpWLJEXJBEnX Dz2lvb7Q0POvrQVVAjPKqgh14zPxdburwPXyU8UDFZR6pCgFtlJXR3dstrCfpIfm p8JP87q1yOJAkPx6BqGyyLl89GU9UUG2c7OvXjUo532G0KIrWRUli66GqZc8Vvbn j02AEl7l76ZOBsWF/WzWqZsc28rPAN63H7gwcEVgc8lgIswD1DqBvlKTguPhKjVj nc4XGhL1xAW7KGNhQ9ksCGrbT/K10OqzT2qHdaiRyczSh1bf4Xg8duCD8AHpuPpV 9CPDh07zazy1o9Ak/Dlcg7l6TEmpwVmmA5b5zueusMjzkD9Naa4Xo/q0HaVzeZJE g6W7icHwHS2uaLL45HFqMjfyybcvQGdEv+kCYKjtuYujj41V9ZajPSDF1M6qgyqR PwcHx6dinft/cplgYZwSlCCYjLdbAJKeSQcPfn9/7fS5Ett26sB3Hb1jKoKW0YFf /5i+tXJ33vpTefbvhdUQjfOyAFN/UDOUqyeEGTYe+bOc1BfOAhgIqawiHa5EPkXq wwfPp7bso4zABI4OwfmNs7xqcAkSTFlhL6TV217boZNsIcKqNKK1+R5pT4eGe+bS YXuGhZeyCn67dJguacv3or6tfQQsgi2sCmGOXQTnWkx502rBkTk= =DgGz -----END PGP SIGNATURE----- --Apple-Mail=_81EC051F-7323-4D86-B613-691B85DB482C-- From nobody Mon Jan 22 14:17:05 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD30124D6C for ; Mon, 22 Jan 2018 14:17:03 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONoGJX77r0Ne for ; Mon, 22 Jan 2018 14:17:00 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ADE127876 for ; Mon, 22 Jan 2018 14:17:00 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e125so5941734vkh.13 for ; Mon, 22 Jan 2018 14:17:00 -0800 (PST) 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=3xOtqkAGDSp7aS6C5LDnEpxsc4nFD9bWL66PUETC7Sg=; b=k/UiDQvUQk9IPrV9jNftoH9mMioVHh18ytE6Lpq1BZuCltbZTiTt9owCyIrlatnK2e adlq+uxLp+DmR/NXsfFfSmL4I4c5EeUiWGym8imdTCKMyiSiJipSAi3lfsvLTiKk2Isr hsu8mNVohZwphq7haM667f9s2r1fPh1mCOKfmqw8SrJwMkqb/eCJlP1KZ5/aIBzgxKQa P50pdw1MdkrhUEhcSesyB6S73YxdW9zq7MTcNL8ayYwt+nQP2DaceVVmkQDfL36sveXS 2b5bmEVRn6ya7hom5AI03kli6M213ytU8I8vZ9QFVzJFOyHHfWCliwSkcZIcAlSZM0NT Fo3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=3xOtqkAGDSp7aS6C5LDnEpxsc4nFD9bWL66PUETC7Sg=; b=C1wk1Q9WwEQ+Owwt8snMBrapxcd84XtuNuUuJRoWfePbjnLVcheStjllTrm28Zn73k SuTTf3h9/qsT9CRxM4ZZupcPoKisyRh67L6cz1qJu4Gy1wOxlTHQ/0h4Qx5a4M6x00d7 0eWacKfnp6iuB/t/pnzLdVOPUaP8mRIar2INRImYzYWBQ18hQuvsDNfnaM17xeEge+Hy Kc+VTLJh6CBmsccBOIYzPGf8aAjQq9FhpJtAainkllb86mSPAUphQRMRBqsAUDAd9vpV ZT23Szi5aRtb/fblFyiP+twbGB49qypgKle+T+VHMwhTxsHL04/jEFu+kxxjXBMorwZ0 WBHQ== X-Gm-Message-State: AKwxytfJa2Th9v0t6pJ5qFE9ka6B8qu8uzhI4zy+Y1zqrHmYR3Y8yTMX dFkeBgMjfHi7IiERK6X5kVPk9Nd2/igXBkUxf4U= X-Google-Smtp-Source: AH8x2243rYEEHORElFNaTtNKl+bkl/ZKukWKdaD+ZT7aTFpa0qYEOLp3rlnRpu0C5cOM8e74kRRXoA5rKGUXk0GyH9s= X-Received: by 10.31.189.76 with SMTP id n73mr284999vkf.3.1516659419315; Mon, 22 Jan 2018 14:16:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.246 with HTTP; Mon, 22 Jan 2018 14:16:58 -0800 (PST) Received: by 10.159.33.246 with HTTP; Mon, 22 Jan 2018 14:16:58 -0800 (PST) In-Reply-To: References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> From: Mark Smith Date: Tue, 23 Jan 2018 09:16:58 +1100 Message-ID: To: Brian E Carpenter Cc: Fred Baker , Ole Troan , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114dd9d4ef0356056364c9f8" Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 22:17:04 -0000 --001a114dd9d4ef0356056364c9f8 Content-Type: text/plain; charset="UTF-8" On 23 Jan. 2018 7:37 am, "Brian E Carpenter" wrote: After watching this debate, I'm asking myself why we want to anything other than a) watch the market deciding for itself, and I think with so much choice, the market has trouble making a choice. It becomes less risky to make no choice (meaning no IPv6 deployment at all) compared to the risks of making the wrong choice. https://en.m.wikipedia.org/wiki/Overchoice Regards, Mark. b) formally deprecate anything we decide is broken. Brian On 23/01/2018 09:23, Fred Baker wrote: > > > On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: >> What's the purpose of what you are trying to do? > > This started out as a question among the chairs, triggered in part by an academic article that I can't share because it's not public yet. It lists 26 different transition mechanisms and tries to make recommendations, based in large part of recommendations we have made. The question started out as "can we narrow that to one such mechanism? Which ones are actually in use?" Now see the spreadsheet Lee shared, which comes from different data. > > It sounds like Ole's data on 6rd needs to get reflected in Lee's spreadsheet. > > After quite a bit of discussion, we think we had pretty much re-invented RFC 6180. The discussion isn't over, but I suspect we're close. So Lee asked for opinions from you guys. > > And BTW, I suspect that dslite is a little long in the tooth for the same reason. The theory with both 6rd and dslite was/is that once there is a native path from here to there, even if the dslite configuration is still in the network it's unlikely to be used. That might be naive :-) > > The big question among the chairs is "what is the real case for translation?" We see it in a variety of places, basically creating a way for IPv6-only devices or networks to talk with IPv4-only devices or networks, but wondering if there is a better way to proceed. My personal take is "it is what it is, no worse than IPv4/IPv4 translation" - not arguing for it, but considering it a fact of life until people become motivated to replace it with native systems and connectivity. YMMV. > > > > _______________________________________________ > 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 --001a114dd9d4ef0356056364c9f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 23 Jan. 2018 7:37 am, "Brian E Carpenter" <brian.e.carpenter@gmail.com>= ; wrote:
    After watching th= is debate, I'm asking myself why we want to anything
    other than
    a) watch the market deciding for itself, and

    I think with so much choi= ce, the market has trouble making a choice. It becomes less risky to make n= o choice (meaning no IPv6 deployment at all) compared to the risks of makin= g the wrong choice.


    Regards,
    Mark.

    <= div dir=3D"auto">
    b) formally deprecate anything we decide is broken.

    =C2=A0 =C2=A0Brian
    On 23/01/2018 09:23, Fred Baker wrote: >
    >
    > On Jan 22, 2018, at 11:17 AM, Ole Troan <otroan@employees.org> wrote:
    >> What's the purpose of what you are trying to do?
    >
    > This started out as a question among the chairs, triggered in part by = an academic article that I can't share because it's not public yet.= It lists 26 different transition mechanisms and tries to make recommendati= ons, based in large part of recommendations we have made. The question star= ted out as "can we narrow that to one such mechanism? Which ones are a= ctually in use?" Now see the spreadsheet Lee shared, which comes from = different data.
    >
    > It sounds like Ole's data on 6rd needs to get reflected in Lee'= ;s spreadsheet.
    >
    > After quite a bit of discussion, we think we had pretty much re-invent= ed RFC 6180. The discussion isn't over, but I suspect we're close. = So Lee asked for opinions from you guys.
    >
    > And BTW, I suspect that dslite is a little long in the tooth for the s= ame reason. The theory with both 6rd and dslite was/is that once there is a= native path from here to there, even if the dslite configuration is still = in the network it's unlikely to be used. That might be naive :-)
    >
    > The big question among the chairs is "what is the real case for t= ranslation?" We see it in a variety of places, basically creating a wa= y for IPv6-only devices or networks to talk with IPv4-only devices or netwo= rks, but wondering if there is a better way to proceed. My personal take is= "it is what it is, no worse than IPv4/IPv4 translation" - not ar= guing for it, but considering it a fact of life until people become motivat= ed to replace it with native systems and connectivity. YMMV.
    >
    >
    >
    > ________________________________= _______________
    > 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

    --001a114dd9d4ef0356056364c9f8-- From nobody Mon Jan 22 14:24:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBED12D7EC for ; Mon, 22 Jan 2018 14:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VkL5HfNoxjf for ; Mon, 22 Jan 2018 14:24:25 -0800 (PST) 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 0061E124D6C for ; Mon, 22 Jan 2018 14:24:24 -0800 (PST) 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 B1B0458C5C5; Mon, 22 Jan 2018 23:24:20 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 986A3B0D816; Mon, 22 Jan 2018 23:24:20 +0100 (CET) Date: Mon, 22 Jan 2018 23:24:20 +0100 From: Toerless Eckert To: Ole Troan Cc: "v6ops@ietf.org WG" Message-ID: <20180122222420.GA6728@faui40p.informatik.uni-erlangen.de> References: <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com> <9003B298-FA2C-416C-8F5C-C06414987244@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9003B298-FA2C-416C-8F5C-C06414987244@employees.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jan 2018 22:24:28 -0000 RFC6180bis should be an ongoing effort with at most 2 yearly new-rfc drops to track the state of affairs/recommendations. Reading quickly through it, it for example does IMHO not well highlight distinguishing between network management itself and network services. As in: If you try to move towards IPv4 as a service and eliminating dual stack, better not forget your own network management infra/apps. Aka: maybe start bothering about moving your network management to IPv6 first like SPs have done it. Even if you're just an enterprise: With typical dev cycles in enterprise anetwork management pps, there is no harm for bitching to your vendors to support native IPv6 management. Then you will have on average still 2 years or more time to start doing any IPv6 support in your network (*sigh*). More generally, maybe we should start to be more descriptive to such strategies and more opinionated in rfc6180bis about what Lee called the "gold standard", aka: inculding more recommendations instead of what i read today as mostly neutral discussions of pro and cons. As in: IMHO we want to evolve the "gold standard". And it should not be dual-stack, but single-stack IPv6. And IPv4 as a service as long as you need that. Wrt. not being able to create better outcomes with additional work (Ole): Admittedly, i am not on top of all 26 transition mechanisms, but the way the IETF works, my impression is that they are driven by only a subset of the overall IPv6 community (mostly big ISPs and vendors representing them) and they where more than happy to create stopgaps for current problems than strategies for achieving a gold standard. And no blame to SPs for this. Thats the problem of commercial activities. But that should not represent the overall community. Not even experts in SPs that can manage to spend cycles beyond their immediate business problems. If i was looking at a strategy for the new gold standard, the last piece on the exit strategy from IPv4 would be the question which solution is best to provide IPv4 as a service WITHOUT BOTHERING THE NETWORK. Is in the list of 26 any evolved version of SOCKS ? Because that IMHO the type of solution i would be looking for. Aka: No reason to solve the problem any lower than in socket (shim) layer (Unfortunately, this also takes it out of the comfort realm of most network geeks). Cheers Toerless On Mon, Jan 22, 2018 at 10:25:02PM +0100, Ole Troan wrote: > > After watching this debate, I'm asking myself why we want to anything > > other than > > a) watch the market deciding for itself, and > > b) formally deprecate anything we decide is broken. > > Indeed, there was consensus in the IETF to let the market decide. > (Said differently, there was no consensus on standardising fewer mechanisms). > > Why would anyone think that has changed significantly enough that it would matter? > If anyone wants to reopen these discussions, may I recommend they entertain themselves by reading through the few thousand messages over the last 20 years on mailing lists like ngtrans, softwire, v6ops... > > It's not for the lack of trying, ngtrans shut down, coin-tosses, deprecation etc. > > It isn't a choice among 26 of course. The market is deciding. And we are not the market. > The likelihood of us, as in the IETF, producing any better advice than we've already done is quite unlikely. > > Ole > > > > > > > Brian > > On 23/01/2018 09:23, Fred Baker wrote: > >> > >> > >> On Jan 22, 2018, at 11:17 AM, Ole Troan wrote: > >>> What's the purpose of what you are trying to do? > >> > >> This started out as a question among the chairs, triggered in part by an academic article that I can't share because it's not public yet. It lists 26 different transition mechanisms and tries to make recommendations, based in large part of recommendations we have made. The question started out as "can we narrow that to one such mechanism? Which ones are actually in use?" Now see the spreadsheet Lee shared, which comes from different data. > >> > >> It sounds like Ole's data on 6rd needs to get reflected in Lee's spreadsheet. > >> > >> After quite a bit of discussion, we think we had pretty much re-invented RFC 6180. The discussion isn't over, but I suspect we're close. So Lee asked for opinions from you guys. > >> > >> And BTW, I suspect that dslite is a little long in the tooth for the same reason. The theory with both 6rd and dslite was/is that once there is a native path from here to there, even if the dslite configuration is still in the network it's unlikely to be used. That might be naive :-) > >> > >> The big question among the chairs is "what is the real case for translation?" We see it in a variety of places, basically creating a way for IPv6-only devices or networks to talk with IPv4-only devices or networks, but wondering if there is a better way to proceed. My personal take is "it is what it is, no worse than IPv4/IPv4 translation" - not arguing for it, but considering it a fact of life until people become motivated to replace it with native systems and connectivity. YMMV. > >> > >> > >> > >> _______________________________________________ > >> 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 Jan 23 01:14:11 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3C12DA07 for ; Tue, 23 Jan 2018 01:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 aVQSfiGVf1qA for ; Tue, 23 Jan 2018 01:14:04 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2CD12DA05 for ; Tue, 23 Jan 2018 01:13:48 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1DF79B0; Tue, 23 Jan 2018 10:13:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1516698825; bh=CpP8ZbsVrC2oMP9mfFH7ixsBhMKLyYcKgPTyEzVtVhY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pr5lr/E2Rv7oZzVfMJ46IJb3s5SpdQKX1/ZLuGpB0+45jSKhNlc+WGjYOY8lanHWa xDYeGfR1g6z6bkjIswZ8oMr2BLdM0ANwk8uUtrg1G3uKvFJKWqAIB9+LrC4Ikj4M2t bU+AzV5LZtSYPEbglrsQjP2ucsNPvCzY8GECq4xo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1C1F29F; Tue, 23 Jan 2018 10:13:45 +0100 (CET) Date: Tue, 23 Jan 2018 10:13:45 +0100 (CET) From: Mikael Abrahamsson To: Lee Howard cc: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1423558373-1516698825=:8884" Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jan 2018 09:14:09 -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-1423558373-1516698825=:8884 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 22 Jan 2018, Lee Howard wrote: > That’s a bit of a snarky question, but it’s a real one. Is there any > real-world problem for which 6rd is the best answer? > “I can’t update my network to support IPv6, but there are IPv6-only hosts > that my users need to be able to reach” is the scenario 6rd addresses. Is > that an actual case? The case “My ISP hasn’t updated to support IPv6, but > there are IPv6-only hosts I need to reach” is solved with a tunnel broker. > > I don’t deny that it is deployed at scale. I’m asking whether there are > any new deployments, recent or contemplated, and what path on a decision > tree would lead one to decide “6rd.” I know people who seriously are still considering this, because they're using old access tech which will never gain native IPv6 capability. So it's "6RD" or "no IPv6 at all for the lifetime of the platform". Like "we have this ethernet-over-DSL DSLAM from 2006 that seems to still work, aggregates a bunch of customers, everybody is in the same VLAN, and the vendor has EOLed this platform in 2012, we're seeing declining customer base but it's non-zero, and we need IPv6 SAVI functions to deploy IPv6 securely". Or "we buy bitstream access over ethernet to a bunch of customers, but the bitstream access provider is IPv4 only because ." I have talked to multiple people who have pretty compelling business reasons not to touch old access platforms, so it's 6RD or nothing. At least I haven't been able to come up with something better. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1423558373-1516698825=:8884-- From nobody Tue Jan 23 01:23:17 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAE4120725 for ; Tue, 23 Jan 2018 01:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 cbuy_9RPyTRq for ; Tue, 23 Jan 2018 01:23:15 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE8C12DA17 for ; Tue, 23 Jan 2018 01:23:14 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B3625AF; Tue, 23 Jan 2018 10:23:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1516699392; bh=PKsO8tRedxvGwrY/BVLTPGX599vRrBnfP2olDMCdnU0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=idhvd7oedDRKo1wnP3MQRcbaFyn4vV01D44GJvtMkKQzV35L3pac3IxRIITAnE2nO CZMI3LF4Ovz4xMtN+kRrPDPlqVaXAYuc0Oc3G6N6XsIcXpfo/0TNYXDVbNuusVoP3Y iHpgb4f3WpZGl5jPncCDDw67sxxAYyVvG6y4iRNA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C0A29F; Tue, 23 Jan 2018 10:23:12 +0100 (CET) Date: Tue, 23 Jan 2018 10:23:12 +0100 (CET) From: Mikael Abrahamsson To: Lee Howard cc: Fred Baker , "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: <70EABBF2-8572-4D6B-8C92-E1F3E247D527@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1767252296-1516699392=:8884" Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jan 2018 09:23:16 -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-1767252296-1516699392=:8884 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 22 Jan 2018, Lee Howard wrote: > Yes, I’m familiar with those use cases. They had edge networks that > couldn’t do IPv6. I haven’t seen provider edge equipment shipped in the > last ten years that is IPv6-incapable. I don’t think whether they had > business reasons for wanting IPv6. I know edge platforms that work like this: 1. "Shared VLAN between customers, SAVI security for IPv4, drop all ethertypes that are not ARP or IPv4". 2. "No SAVI." So if you chose option 1, to use this platform you have to move to a "one vlan per customer" type of deployment, for both IPv4 and IPv6, and use the upstream router to handle security. So this means changing the entire setup configuration, provisioning, fault finding tools etc. Good luck finding business reasons to do that. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1767252296-1516699392=:8884-- From nobody Tue Jan 23 09:23:21 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367B0127137 for ; Tue, 23 Jan 2018 09:23:20 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FnES5ueqOMuw for ; Tue, 23 Jan 2018 09:23:18 -0800 (PST) Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BAD12706D for ; Tue, 23 Jan 2018 09:23:18 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0NHNFDn103427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jan 2018 12:23:15 -0500 Received: (qmail 23569 invoked by uid 0); 23 Jan 2018 17:23:15 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 23 Jan 2018 17:23:14 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 23 Jan 2018 12:23:11 -0500 From: Lee Howard To: Mikael Abrahamsson CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] discussion of transition technologies References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jan 2018 17:23:20 -0000 On 1/23/18, 4:13 AM, "Mikael Abrahamsson" wrote: >On Mon, 22 Jan 2018, Lee Howard wrote: > >> That=E2=80=99s a bit of a snarky question, but it=E2=80=99s a real one. Is there any >> real-world problem for which 6rd is the best answer? >> =E2=80=9CI can=E2=80=99t update my network to support IPv6, but there are IPv6-only >>hosts >> that my users need to be able to reach=E2=80=9D is the scenario 6rd addresses. >>Is >> that an actual case? The case =E2=80=9CMy ISP hasn=E2=80=99t updated to support IPv6= , >>but >> there are IPv6-only hosts I need to reach=E2=80=9D is solved with a tunnel >>broker. >> >> I don=E2=80=99t deny that it is deployed at scale. I=E2=80=99m asking whether there = are >> any new deployments, recent or contemplated, and what path on a decision >> tree would lead one to decide =E2=80=9C6rd.=E2=80=9D > >I know people who seriously are still considering this, because they're >using old access tech which will never gain native IPv6 capability. So >it's "6RD" or "no IPv6 at all for the lifetime of the platform". > >Like "we have this ethernet-over-DSL DSLAM from 2006 that seems to still >work, aggregates a bunch of customers, everybody is in the same VLAN, and >the vendor has EOLed this platform in 2012, we're seeing declining >customer base but it's non-zero, and we need IPv6 SAVI functions to >deploy=20 >IPv6 securely". Or "we buy bitstream access over ethernet to a bunch of >customers, but the bitstream access provider is IPv4 only because >I just described earlier, and add >bitstream-provider-doesn't-see-business-need-to-deply-Ipv6>." > >I have talked to multiple people who have pretty compelling business >reasons not to touch old access platforms, so it's 6RD or nothing. At >least I haven't been able to come up with something better. That=E2=80=99s a great example, thank you. That=E2=80=99s also why I would describe 6rd as declining: its primary use is for bypassing ISP edge equipment that=E2=80=99s 12 years old and EOL. As time passes, the number of users behind equipment like that (where =E2=80=9C12=E2=80=9D continues incrementing) will continue to decline. If my network was gradually transitioning from old DSL or DOCSIS1.x, I might suggest enabling IPv6 on the newer edge boxes and not bothering with the old ones. Or even doing stateful NAT46 for the very few flows that needed to reach something on IPv6. But that=E2=80=99s just me, and I appreciate anyone who is trying to push IPv6 to those users on older technology. Lee > From nobody Wed Jan 24 05:30:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F88124217 for ; Wed, 24 Jan 2018 05:30:05 -0800 (PST) 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 Voemr_Yxn1nk for ; Wed, 24 Jan 2018 05:30:02 -0800 (PST) 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 15349124207 for ; Wed, 24 Jan 2018 05:30:01 -0800 (PST) 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 w0ODU0V3006355 for ; Wed, 24 Jan 2018 14:30:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0801C204FF5 for ; Wed, 24 Jan 2018 14:30:00 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F1FF3204F7B for ; Wed, 24 Jan 2018 14:29:59 +0100 (CET) Received: from [132.166.84.188] ([132.166.84.188]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0ODTxtL017317 for ; Wed, 24 Jan 2018 14:29:59 +0100 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <913e9068-83f4-3af6-7d0c-2b06ddb07fb0@gmail.com> Date: Wed, 24 Jan 2018 14:29:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jan 2018 13:30:05 -0000 Le 23/01/2018 à 18:23, Lee Howard a écrit : > > > On 1/23/18, 4:13 AM, "Mikael Abrahamsson" wrote: > >> On Mon, 22 Jan 2018, Lee Howard wrote: >> >>> That’s a bit of a snarky question, but it’s a real one. Is there any >>> real-world problem for which 6rd is the best answer? >>> “I can’t update my network to support IPv6, but there are IPv6-only >>> hosts >>> that my users need to be able to reach” is the scenario 6rd addresses. >>> Is >>> that an actual case? The case “My ISP hasn’t updated to support IPv6, >>> but >>> there are IPv6-only hosts I need to reach” is solved with a tunnel >>> broker. >>> >>> I don’t deny that it is deployed at scale. I’m asking whether there are >>> any new deployments, recent or contemplated, and what path on a decision >>> tree would lead one to decide “6rd.” >> >> I know people who seriously are still considering this, because they're >> using old access tech which will never gain native IPv6 capability. So >> it's "6RD" or "no IPv6 at all for the lifetime of the platform". >> >> Like "we have this ethernet-over-DSL DSLAM from 2006 that seems to still >> work, aggregates a bunch of customers, everybody is in the same VLAN, and >> the vendor has EOLed this platform in 2012, we're seeing declining >> customer base but it's non-zero, and we need IPv6 SAVI functions to >> deploy >> IPv6 securely". Or "we buy bitstream access over ethernet to a bunch of >> customers, but the bitstream access provider is IPv4 only because >> > I just described earlier, and add >> bitstream-provider-doesn't-see-business-need-to-deply-Ipv6>." >> >> I have talked to multiple people who have pretty compelling business >> reasons not to touch old access platforms, so it's 6RD or nothing. At >> least I haven't been able to come up with something better. > > That’s a great example, thank you. > > That’s also why I would describe 6rd as declining: its primary use is for > bypassing ISP edge equipment that’s 12 years old and EOL. As time passes, > the number of users behind equipment like that (where “12” continues > incrementing) will continue to decline. If my network was gradually > transitioning from old DSL or DOCSIS1.x, I might suggest enabling IPv6 on > the newer edge boxes and not bothering with the old ones. Or even doing > stateful NAT46 for the very few flows that needed to reach something on > IPv6. > > But that’s just me, and I appreciate anyone who is trying to push IPv6 to > those users on older technology. A similar description you make on 6rd can be made on GTP-U protocol transpoprting IPv6 user data on UDP/IPv4 cellular networks. Cellular operator does have answers about why they continue using IPv4 to transport IPv6 (instead of using IPv6 to transport IPv6.) For my part, I think the compute power goes so cheap that they can easily add layers upon layers and SDN them as they evolve their network, instead of designing on a clean slate. New protocol? Just beam up in a new overlaid world. For this to change, maybe the sysadmins will complain the management is too complex, or some security attacks will go without possibility to track the cause, or maybe a completely new operator wants to deploy a new network with software and hardware whose price is in the range of small investors. When that happes, they will be happy if an Internet Draft describing GTP on both IPv4 and IPv6 existed. Alex > > Lee > >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 24 08:57:16 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB63A126DCA for ; Wed, 24 Jan 2018 08:57:15 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-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=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f08jO5-Q8bxd for ; Wed, 24 Jan 2018 08:57:12 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E956C124235 for ; Wed, 24 Jan 2018 08:57:11 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 Jan 2018 16:57:12 +0000 Received: from smtpe1.intersmtp.com (10.187.98.10) by EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 24 Jan 2018 16:57:08 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (213.199.154.243) by smtpe1.intersmtp.com (62.239.224.234) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 Jan 2018 16:57:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a4nHe8HtSgOJwVzEY9WMFf597S/vbWEZQh3O6d2dN3A=; b=xGlsMCYnnlRxBHLM45eVR3edvVRzxkD28ntUGf5CQstl4ixvwDRsEEIIPH8CvzyT01vyhzqchJq3Y5N6X66yMQxz6g3GtNLxteRbqP7GVbzVcpaNIGbtpMqHejtPF0PZGtvRb6TdM1Et94e7umZT03JvEFwfKDN+ko9kgnPbXu0= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB0115.GBRP123.PROD.OUTLOOK.COM (10.167.24.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 16:57:06 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0428.024; Wed, 24 Jan 2018 16:57:06 +0000 From: To: , Thread-Topic: discussion of transition technologies Thread-Index: AQHTkWJf+dx5S2H5Hkq5X9wPAq1lEKODRPdw Date: Wed, 24 Jan 2018 16:57:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [77.97.239.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P123MB0115; 7:/4xKC8PQowas7TkLq1bkVkPVNokxI2SoCp85lWOOBj2bDbxG1TcgPBFzKSIrXIcBdZIR1b7KGQt5RjocPvmDcIGbkPxzBzCfhBTsUd/8hk8SZxCr+ubFNPHxK6czjd5ohhrqCCbRvHR5CsJonXSLRAr7PbW92N2NOxbdsZlI0jV2AuJ8sCgUA4pq2d9MMTesPA7Y1SdjYxQxdaMPy86xWsMWeTGtp5I01oIlirmAS+HvQISaLjx8GB26omY56QNK x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c75941ae-45ae-4136-41fd-08d5634b7ff9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:LO1P123MB0115; x-ms-traffictypediagnostic: LO1P123MB0115: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(211936372134217)(100405760836317)(21748063052155)(119230021023882); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:LO1P123MB0115; BCL:0; PCL:0; RULEID:; SRVR:LO1P123MB0115; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(346002)(376002)(39380400002)(189003)(199004)(790700001)(6306002)(33656002)(55016002)(2501003)(105586002)(77096007)(6436002)(102836004)(6246003)(229853002)(3480700004)(54896002)(8936002)(9686003)(410100003)(110136005)(316002)(81156014)(236005)(5660300001)(8676002)(966005)(68736007)(606006)(6506007)(53546011)(14454004)(53936002)(3660700001)(26005)(99286004)(7736002)(97736004)(59450400001)(106356001)(81166006)(478600001)(2900100001)(2950100002)(74316002)(76176011)(3846002)(7696005)(6116002)(3280700002)(2906002)(66066001)(86362001)(25786009)(15940465004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0115; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: D6Fl5VW5fmzya8Uik698OUiUV0XY91VmTQ1uufvrJ72/GH8ZgNivr+x/IcMWdqoVLG9oEZ5+9XB0CiRYYgHbbQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB0116C873308B5DA308EBC60AEAE20LO1P123MB0116GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c75941ae-45ae-4136-41fd-08d5634b7ff9 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 16:57:06.2438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0115 Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jan 2018 16:57:16 -0000 --_000_LO1P123MB0116C873308B5DA308EBC60AEAE20LO1P123MB0116GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGVlL0FsbCwNCldhcyB0YWxraW5nIHRvIGEgY291cGxlIG9mIHBlb3BsZSBhYm91dCB0aGUg c3ByZWFkc2hlZXQsIGFuZCB3ZSBkb27igJl0IHRoaW5rIHRoZSBlbnRyeSBmb3IgVmVyaXpvbiBX aXJlbGVzcyBpcyBjb3JyZWN0IGkuZS4gSSBkb27igJl0IHRoaW5rIERTLUxpdGUgaXMgdXNlZCBm b3IgbW9iaWxlLiBJcyB0aGlzIGEgdHlwby9lcnJvcj8gT3IgY2FuIHNvbWVvbmUgZXhwYW5kIG9u IHRoaXMgdXNhZ2U/DQpUaGFua3MsDQpOaWNrDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZSBIb3dhcmQNClNlbnQ6IDE5IEphbnVh cnkgMjAxOCAyMDoxNg0KVG86IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBbdjZvcHNdIGRpc2N1 c3Npb24gb2YgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMNCg0KDQpUaGUgV0cgQ2hhaXJzIHdlcmUg ZGlzY3Vzc2luZyB0aGUgdmFyaW91cyB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcyBhdCBzb21lIGxl bmd0aCB0b2RheS4NCkkgbWVudGlvbmVkIGEgcHJldmlvdXMgY29udmVyc2F0aW9uIGluIGFub3Ro ZXIgZm9ydW0gdGhhdCBsZWQgdG8gdGhpcyBsaXN0IG9mIG5ldHdvcmtzIGFuZCB0aGVpciBtZWNo YW5pc21zOg0KaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vc3ByZWFkc2hlZXRzL2QvMWtzT29XT2FS ZFJ5alpuakxTaWtIZjRPNUwxT1VUTk9PXzdOSzl2Y1ZBcGMvZWRpdCNnaWQ9MA0KKENvcnJlY3Rp b25zIGFuZCBhZGRpdGlvbnMgZW5jb3VyYWdlZCwgZXNwZWNpYWxseSB3aXRoIGxpbmtzKQ0KDQpP dXIgaW1wcmVzc2lvbiB3YXMgdGhhdCBvZiB0aGUgMjYrIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBk ZWZpbmVkLCBvbmx5IGEgZmV3IGhhdmUgYW55IG1vZGVybiByZWxldmFuY2UgKGVkaXRvcmlhbCBj b21tZW50cyBhcmUgbWluZSwgbm90IGNvbnNlbnN1cyBwb3NpdGlvbnMpOg0KNnJkLiAgIEl0IG1h eSBiZSB0aGF0IGl0cyBsaWdodCBpcyB3YW5pbmcsIHdpdGggZWFybHkgZGVwbG95bWVudHMgbW92 aW5nIHRvIG5hdGl2ZSBJUHY2LCBhbmQgbm8gbmV3IGRlcGxveW1lbnRzLg0KRFMtTGl0ZS4gICBX aWRlbHkgZGVwbG95ZWQsIGV4aXN0aW5nIHN1cHBvcnQgYW1vbmcgaG9tZSBnYXRld2F5IG1hbnVm YWN0dXJlcnMuDQpOQVQ2NC80NjR4bGF0LiAgIEltcGxpZXMgTkFUNjQsIFNJSVQsIHdoaWNoIG1h eSBiZSB1c2VkIGVsc2V3aGVyZS4gSGFuZHNldCBDTEFUcy4gTm8gaG9tZSBnYXRld2F5IENMQVQg eWV0Lg0KTUFQLVQuICAgQW5ub3VuY2VkIHRyaWFscyBhbmQgbG90cyBvZiBidXp6LCBidXQgbm8g bGFyZ2Utc2NhbGUgZGVwbG95bWVudHMsIG5vIGhvbWUgZ2F0ZXdheSBzdXBwb3J0IHlldC4NCk1B UC1FLiAgIFNvbWUgYnV6eiwgbm8gYW5ub3VuY2VkIHRyaWFscyBvciBkZXBsb3ltZW50cywgbm8g aG9tZSBnYXRld2F5IHN1cHBvcnQgeWV0Lg0KTmF0aXZlIGR1YWwtc3RhY2suICAgU3RpbGwgdGhl IGdvbGQgc3RhbmRhcmQsIGJ1dCBkb2VzbuKAmXQgc29sdmUgSVB2NCBhZGRyZXNzIHNob3J0YWdl Lg0KDQooTm90ZSB0aGF0IOKAnHlldOKAnSBtYXkgY2hhbmdlIGF0IGFueSB0aW1lKS4NCkFzIGEg bWF0dGVyIG9mIGRpc2N1c3Npb24sIGRvIHlvdSBhZ3JlZT8NClRvIGd1aWRlIG91ciB3b3JrLCBp cyB0aGVyZSB3b3JrIHdlIHNob3VsZCBkbyB0byBkb2N1bWVudCBvciBkZXByZWNhdGUgYW55IG9m IHRoZXNlPw0KDQpUaGFua3MsDQoNCkxlZQ0KDQo= --_000_LO1P123MB0116C873308B5DA308EBC60AEAE20LO1P123MB0116GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIExlZS9BbGwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5XYXMgdGFsa2luZyB0byBhIGNvdXBsZSBvZiBwZW9wbGUgYWJvdXQgdGhl IHNwcmVhZHNoZWV0LCBhbmQgd2UgZG9u4oCZdCB0aGluayB0aGUgZW50cnkgZm9yIFZlcml6b24g V2lyZWxlc3MgaXMgY29ycmVjdCBpLmUuIEkgZG9u4oCZdCB0aGluayBEUy1MaXRlIGlzIHVzZWQg Zm9yIG1vYmlsZS4gSXMgdGhpcyBhIHR5cG8vZXJyb3I/IE9yIGNhbiBzb21lb25lDQogZXhwYW5k IG9uIHRoaXMgdXNhZ2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5OaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TGVlIEhvd2FyZDxicj4NCjxiPlNlbnQ6PC9i PiAxOSBKYW51YXJ5IDIwMTggMjA6MTY8YnI+DQo8Yj5Ubzo8L2I+IHY2b3BzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFt2Nm9wc10gZGlzY3Vzc2lvbiBvZiB0cmFuc2l0aW9uIHRlY2hu b2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoZSBXRyBDaGFpcnMg d2VyZSBkaXNjdXNzaW5nIHRoZSB2YXJpb3VzIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIGF0IHNv bWUgbGVuZ3RoIHRvZGF5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj5JIG1lbnRpb25lZCBhIHByZXZpb3VzIGNvbnZlcnNhdGlvbiBpbiBhbm90aGVyIGZvcnVt IHRoYXQgbGVkIHRvIHRoaXMgbGlzdCBvZiBuZXR3b3JrcyBhbmQgdGhlaXIgbWVjaGFuaXNtczo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0 cHM6Ly9kb2NzLmdvb2dsZS5jb20vc3ByZWFkc2hlZXRzL2QvMWtzT29XT2FSZFJ5alpuakxTaWtI ZjRPNUwxT1VUTk9PXzdOSzl2Y1ZBcGMvZWRpdCNnaWQ9MCI+aHR0cHM6Ly9kb2NzLmdvb2dsZS5j b20vc3ByZWFkc2hlZXRzL2QvMWtzT29XT2FSZFJ5alpuakxTaWtIZjRPNUwxT1VUTk9PXzdOSzl2 Y1ZBcGMvZWRpdCNnaWQ9MDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjpibGFjayI+KENvcnJlY3Rpb25zIGFuZCBhZGRpdGlvbnMgZW5jb3VyYWdlZCwgZXNwZWNpYWxs eSB3aXRoIGxpbmtzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+T3Vy IGltcHJlc3Npb24gd2FzIHRoYXQgb2YgdGhlIDI2JiM0MzsgdHJhbnNpdGlvbiBtZWNoYW5pc21z IGRlZmluZWQsIG9ubHkgYSBmZXcgaGF2ZSBhbnkgbW9kZXJuIHJlbGV2YW5jZSAoZWRpdG9yaWFs IGNvbW1lbnRzIGFyZSBtaW5lLCBub3QgY29uc2Vuc3VzIHBvc2l0aW9ucyk6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjZyZC4gJm5ic3A7IEl0IG1heSBiZSB0 aGF0IGl0cyBsaWdodCBpcyB3YW5pbmcsIHdpdGggZWFybHkgZGVwbG95bWVudHMgbW92aW5nIHRv IG5hdGl2ZSBJUHY2LCBhbmQgbm8gbmV3IGRlcGxveW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5EUy1MaXRlLiAmbmJzcDsgV2lkZWx5IGRlcGxveWVk LCBleGlzdGluZyBzdXBwb3J0IGFtb25nIGhvbWUgZ2F0ZXdheSBtYW51ZmFjdHVyZXJzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5OQVQ2NC80NjR4bGF0LiAm bmJzcDsgSW1wbGllcyBOQVQ2NCwgU0lJVCwgd2hpY2ggbWF5IGJlIHVzZWQgZWxzZXdoZXJlLiBI YW5kc2V0IENMQVRzLiBObyBob21lIGdhdGV3YXkgQ0xBVCB5ZXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPk1BUC1ULiAmbmJzcDsgQW5ub3VuY2VkIHRyaWFs cyBhbmQgbG90cyBvZiBidXp6LCBidXQgbm8gbGFyZ2Utc2NhbGUgZGVwbG95bWVudHMsIG5vIGhv bWUgZ2F0ZXdheSBzdXBwb3J0IHlldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+TUFQLUUuICZuYnNwOyBTb21lIGJ1enosIG5vIGFubm91bmNlZCB0cmlhbHMg b3IgZGVwbG95bWVudHMsIG5vIGhvbWUgZ2F0ZXdheSBzdXBwb3J0IHlldC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+TmF0aXZlIGR1YWwtc3RhY2suICZuYnNw OyBTdGlsbCB0aGUgZ29sZCBzdGFuZGFyZCwgYnV0IGRvZXNu4oCZdCBzb2x2ZSBJUHY0IGFkZHJl c3Mgc2hvcnRhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4oTm90 ZSB0aGF0IOKAnHlldOKAnSBtYXkgY2hhbmdlIGF0IGFueSB0aW1lKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+QXMgYSBtYXR0ZXIgb2YgZGlzY3Vzc2lvbiwg ZG8geW91IGFncmVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij5UbyBndWlkZSBvdXIgd29yaywgaXMgdGhlcmUgd29yayB3ZSBzaG91bGQgZG8gdG8gZG9jdW1l bnQgb3IgZGVwcmVjYXRlIGFueSBvZiB0aGVzZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2siPkxlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_LO1P123MB0116C873308B5DA308EBC60AEAE20LO1P123MB0116GBRP_-- From nobody Wed Jan 24 11:55:03 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBDC12700F for ; Wed, 24 Jan 2018 11:55:01 -0800 (PST) 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 qG384Bkydtqd for ; Wed, 24 Jan 2018 11:54:59 -0800 (PST) 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 3549D12751F for ; Wed, 24 Jan 2018 11:54:59 -0800 (PST) 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 w0OJsvwC043899; Wed, 24 Jan 2018 20:54:57 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 17B9820539B; Wed, 24 Jan 2018 20:54:57 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01017201A89; Wed, 24 Jan 2018 20:54:57 +0100 (CET) Received: from [132.166.84.225] ([132.166.84.225]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0OJsuJh017727; Wed, 24 Jan 2018 20:54:56 +0100 To: v6ops@ietf.org References: <913e9068-83f4-3af6-7d0c-2b06ddb07fb0@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 24 Jan 2018 20:54:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <913e9068-83f4-3af6-7d0c-2b06ddb07fb0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jan 2018 19:55:01 -0000 Le 24/01/2018 à 14:29, Alexandre Petrescu a écrit : [...] I said: > Cellular operator does have answers about why they continue using IPv4 > to transport IPv6 (instead of using IPv6 to transport IPv6.) FYI, over in the 5gangip email list at IETF I am told to stop making such statements, and proposed counter-examples that I have no means to verify other than asking for packet dumps. Until then I still believe it is worth writing an Internet Draft about GTP on IPv4 and on IPv6. Such thing does not exist and I dont like that. Alex From nobody Thu Jan 25 02:12:58 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C112E885 for ; Thu, 25 Jan 2018 02:12:57 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 S2sVaKLPEcRK for ; Thu, 25 Jan 2018 02:12:55 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4850212DA00 for ; Thu, 25 Jan 2018 02:12:54 -0800 (PST) Received: from 10.236.51.100 (EHLO PE16MR05.tp.gk.corp.tepenet) ([10.236.51.100]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id IJD48581; Thu, 25 Jan 2018 11:12:38 +0100 (CET) From: Kossut Tomasz - Hurt To: Fred Baker , Sander Steffann CC: "v6ops@ietf.org WG" , Lee Howard Thread-Topic: [v6ops] discussion of transition technologies Thread-Index: AQHTkvJwWs6HagCVoEOsivDIcsJh86OESKbg Date: Thu, 25 Jan 2018 10:12:30 +0000 Message-ID: <398258f23e8e4263835ee59f65eec744@orange.com> References: In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.38] x-tm-as-product-ver: SMEX-12.0.0.1727-8.200.1013-23618.006 x-tm-as-result: No--23.826600-0.000000-31 x-tm-as-matchedid: 150567-701625-704425-700685-303277-710442-106580-700512-7 07163-700401-139006-701960-106660-710970-137717-139010-700075-707800-704749 -139705-702791-704351-862762-703835-702126-706722-106230-701005-709584-7107 39-702358-702131-704171-841660-700104-702020-121651-701837-707760-704980-70 0693-704301-701618-188198-105630-702920-121101-711432-701923-700245-708196- 863828-709364-701914-700040-711371-700752-703378-707595-702271-117213-18709 9-705753-706561-701236-705388-705441-700107-148004-148133-20025-20043-42000 -42003 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2018.1.25.90318:17:8.707, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MSGID_32HEX, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, CTE_BASE64, __MIME_VERSION, WEBMAIL_X_IP_HDR, __KNOWN_FREEWEB_URI3[https://docs.google.com/ [docs.google.com] [docs.google.com]], URI_ENDS_IN_PHP, __ANY_URI, __HTTPS_URI, __URI_WITH_PATH, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, ECARD_KNOWN_DOMAINS, __STOCK_PHRASE_7, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __MULTIPLE_URI_TEXT, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODY_SIZE_5000_5999, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, __FRAUD_WEBMAIL, WEBMAIL_SOURCE, IN_REP_TO, [TRUNCATED] X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0208.5A69AD97.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0208.5A69AD97.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8290ce925b4797692eff4a25c92e42e1 Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jan 2018 10:12:57 -0000 Pj4gTkFUNjQvNDY0eGxhdC4gICBJbXBsaWVzIE5BVDY0LCBTSUlULCB3aGljaCBtYXkgYmUgdXNl ZCBlbHNld2hlcmUuIEhhbmRzZXQgQ0xBVHMuIE5vIGhvbWUgZ2F0ZXdheSBDTEFUIHlldC4NCiJN b2JpbGUiIEhvbWUgR1cgd2l0aCBDTEFUIGV4aXN0cy4gVENML0FsY2F0ZWwvSHVhd2VpL1pURSwg IGltcGxlbWVudGF0aW9ucyBkb2VzIG5vdCByZXF1aXJlIEROUzY0LiBJUHY2IENMQVQgc29mdHdh cmUgdmFyaWFudCBpcyB1cG9uIG9wZXJhdG9yIHJlcXVlc3QuIA0KQ2hlZXJzLA0KVEsNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRnJlZCBCYWtlciBbbWFpbHRvOmZyZWRi YWtlci5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMjEsIDIwMTggODoy OCBQTQ0KVG86IFNhbmRlciBTdGVmZmFubg0KQ2M6IHY2b3BzQGlldGYub3JnIFdHOyBMZWUgSG93 YXJkDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkaXNjdXNzaW9uIG9mIHRyYW5zaXRpb24gdGVjaG5v bG9naWVzDQoNClJlc3RhdGVkLiBDbG9zZT8NCg0KPiBPbiBKYW4gMTksIDIwMTgsIGF0IDQ6MjIg UE0sIEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBB dCBsZWFzdCBwYXJ0IG9mIHRoaXMgY29tbWVudGFyeSB3b3VuZCB1cCBpbiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjE4MA0KPiAgICAgR3VpZGVsaW5lcyBmb3IgVXNpbmcgSVB2NiBU cmFuc2l0aW9uIE1lY2hhbmlzbXMgZHVyaW5nIElQdjYNCj4gICAgIERlcGxveW1lbnQuIEouIEFy a2tvLCBGLiBCYWtlci4gTWF5IDIwMTEuIChGb3JtYXQ6IFRYVD00OTY3OSBieXRlcykNCj4gICAg IChTdGF0dXM6IElORk9STUFUSU9OQUwpIChET0k6IDEwLjE3NDg3L1JGQzYxODApDQo+IA0KPiBJ IHRoaW5rIEphcmkncyB2aWV3IGluIHRoYXQgd2FzIHRoYXQgd2UgbmVlZGVkIHRvIHJlaW4gaW4g dGhlIHBsZXRob3JhIG9mIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzLCBhbmQgImlmIG9uZSBoYXMg dG8gdHJhbnNsYXRlLCBjYW4gd2UgcGxlYXNlIGRvIHNvIGFib3ZlIHRoZSBJUCBsYXllcj8iIEkg YWRkZWQgU0lJVC9OQVQ2NCwgYmVjYXVzZSBJIHRoaW5rIHRoZXJlIGlzIG1hcmtldCByZWxldmFu Y2UgaW5jbHVkaW5nIHNldmVyYWwgZGVwbG95bWVudHMgb2YgdmFyaW91cyBraW5kczsgYW55IG1l bnRpb24gb2YgTUFQLVQgb3IgNDY0WExBVCBpcyBTSUlUL05BVDY0LiBCdXQgdGhlIGJhc2ljIHJl Y29tbWVuZGF0aW9uIG9mIFJGQyA2MTgwIHdhczoNCj4gIC0gZmlyc3QgY2hvaWNlLCBkZXBsb3kg bmF0aXZlIElQdjYgLSBmb3Igc2NlbmFyaW9zIGluIHdoaWNoIElQdjYgaXNsYW5kcyBhcmUgY29u bmVjdGVkIGFjcm9zcyBJUHY0IHNwYWNlLCB1c2UgZHNsaXRlIChhIHR1bm5lbGluZyBkZXNpZ24p Lg0KPiAgLSBmb3Igc2NlbmFyaW9zIGluIHdoaWNoIElQdjQgaXNsYW5kcyBhcmUgY29ubmVjdGVk IGFjcm9zcyBJUHY2IHNwYWNlLCB1c2UgZHNsaXRlIChhIHR1bm5lbGluZyBkZXNpZ24pLg0KICAt IGZvciBzY2VuYXJpb3MgaW4gd2hpY2ggSVB2NiBpc2xhbmRzIGFyZSBjb25uZWN0ZWQgYWNyb3Nz IElQdjQgc3BhY2UsIHVzZSA2cmQgKGEgdHVubmVsaW5nIGRlc2lnbikuDQo+ICAtIGZvciBzY2Vu YXJpb3MgaW4gd2hpY2ggSVB2NiBzeXN0ZW1zIGhhdmUgdG8gdGFsayB3aXRoIElQdjQgc3lzdGVt cywgdHJhbnNsYXRlLiBQbGVhc2UgY29uc2lkZXIgZG9pbmcgc28gYWJvdmUgdGhlIElQIGxheWVy Lg0KPiANCj4gSSB3b3VsZCBhcmd1ZSB0aGF0IDQ2NFhMQVQsIE1BUC1FLCBhbmQgTUFQLVQgYXJl ICJzZXJ2aWNlcyBpbiB3aGljaCBhbiBJU1AgbWlnaHQgdXNlIFNJSVQvTkFUNjQgaW4gaXRzIG5l dHdvcmsiLCBhbmQgYXJlIHRoZXJlZm9yZSBub3QgZnVuZGFtZW50YWwgdHJhbnNpdGlvbiB0ZWNo bm9sb2dpZXMgYXMgbXVjaCBhcyBJU1Agc2VydmljZXMgYnVpbHQgdXNpbmcgdGhlbS4NCj4gDQo+ IEkgdGhpbmsgSSBtaWdodCBhbHNvIGFyZ3VlIHRoYXQgdGhlIG1hcmtldCBoYXMgbW9yZSBvciBs ZXNzIGZvbGxvd2VkIHRoYXQgYWR2aWNlLiBZb3VyIHNwcmVhZHNoZWV0IHNlZW1zIHRvIHN1Z2dl c3QgdGhhdC4NCg0KVGhlIGludGVyZXN0aW5nIHRoaW5nIGlzIHRoYXQgNnJkLCB3aGljaCBpcyBh IHdheSBvZiBhcHBlYXJpbmcgdG8gaGF2ZSBhbiBJUHY2IG5ldHdvcmsgd2l0aG91dCBhY3R1YWxs eSBoYXZpbmcgb25lLCBpcyBub3Qgd2hhdCBvbmUgbWlnaHQgY2FsbCAicHJldmFsZW50Ii4gSXQg aGFzIGluIGZhY3QgYmVlbiB1c2VkIGZvciAqdHJhbnNpdGlvbiosIGluIHBsYWNlcyBsaWtlIEZy ZWUgLSB3aGljaCB1c2VkIHRvIGNvbm5lY3QgSVB2NiBjdXN0b21lcnMgdXNpbmcgNnJkIGFuZCAo SSB1bmRlcnN0YW5kKSBoYXMgcmVjZW50bHkgYW5ub3VuY2VkIG5hdGl2ZSBJUHY2IGRlcGxveW1l bnQuIFRoZSBwbGFjZXMgSSBrbm93IHRoYXQgaGF2ZSB1c2VkIGl0IHVzZWQgaXQgZm9yIGEgd2hp bGUgYW5kIHRoZW4gaGF2ZSBnb25lIG5hdGl2ZS4NCg0KV291bGQgeW91IGFncmVlIHdpdGggdGhh dD8NCg0KU2lkZSBjb21tZW50OiBJIHdyb3RlIHRoZSBhYm92ZSBhbmQgdGhlbiByZWFkIGl0IGJh Y2suIFRoZSBjb21tb24gbWVhbmluZyBvZiB0aGUgcGhyYXNlICJnbyBuYXRpdmUiIGlzIG5vdCB3 aGF0IEkgbWVhbnQgKGl0J3MgZGVyb2dhdG9yeSksIGJ1dCBodW1vcm91cyBpbiBjb250ZXh0LiBo dHRwczovL3d3dy51cmJhbmRpY3Rpb25hcnkuY29tL2RlZmluZS5waHA/dGVybT1nbyUyMG5hdGl2 ZQ0KDQo+PiBPbiBKYW4gMTksIDIwMTgsIGF0IDEyOjE1IFBNLCBMZWUgSG93YXJkIDxMZWVAYXNn YXJkLm9yZz4gd3JvdGU6DQo+PiANCj4+IA0KPj4gVGhlIFdHIENoYWlycyB3ZXJlIGRpc2N1c3Np bmcgdGhlIHZhcmlvdXMgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgYXQgc29tZSBsZW5ndGggdG9k YXkuDQo+PiBJIG1lbnRpb25lZCBhIHByZXZpb3VzIGNvbnZlcnNhdGlvbiBpbiBhbm90aGVyIGZv cnVtIHRoYXQgbGVkIHRvIHRoaXMgbGlzdCBvZiBuZXR3b3JrcyBhbmQgdGhlaXIgbWVjaGFuaXNt czoNCj4+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL3NwcmVhZHNoZWV0cy9kLzFrc09vV09hUmRS eWpabmpMU2lrSGY0TzVMMU9VVA0KPj4gTk9PXzdOSzl2Y1ZBcGMvZWRpdCNnaWQ9MCAoQ29ycmVj dGlvbnMgYW5kIGFkZGl0aW9ucyBlbmNvdXJhZ2VkLCANCj4+IGVzcGVjaWFsbHkgd2l0aCBsaW5r cykNCj4+IA0KPj4gT3VyIGltcHJlc3Npb24gd2FzIHRoYXQgb2YgdGhlIDI2KyB0cmFuc2l0aW9u IG1lY2hhbmlzbXMgZGVmaW5lZCwgb25seSBhIGZldyBoYXZlIGFueSBtb2Rlcm4gcmVsZXZhbmNl IChlZGl0b3JpYWwgY29tbWVudHMgYXJlIG1pbmUsIG5vdCBjb25zZW5zdXMgcG9zaXRpb25zKToN Cj4+IDZyZC4gICBJdCBtYXkgYmUgdGhhdCBpdHMgbGlnaHQgaXMgd2FuaW5nLCB3aXRoIGVhcmx5 IGRlcGxveW1lbnRzIG1vdmluZyB0byBuYXRpdmUgSVB2NiwgYW5kIG5vIG5ldyBkZXBsb3ltZW50 cy4NCj4+IERTLUxpdGUuICAgV2lkZWx5IGRlcGxveWVkLCBleGlzdGluZyBzdXBwb3J0IGFtb25n IGhvbWUgZ2F0ZXdheSBtYW51ZmFjdHVyZXJzLg0KPj4gTkFUNjQvNDY0eGxhdC4gICBJbXBsaWVz IE5BVDY0LCBTSUlULCB3aGljaCBtYXkgYmUgdXNlZCBlbHNld2hlcmUuIEhhbmRzZXQgQ0xBVHMu IE5vIGhvbWUgZ2F0ZXdheSBDTEFUIHlldC4NCj4+IE1BUC1ULiAgIEFubm91bmNlZCB0cmlhbHMg YW5kIGxvdHMgb2YgYnV6eiwgYnV0IG5vIGxhcmdlLXNjYWxlIGRlcGxveW1lbnRzLCBubyBob21l IGdhdGV3YXkgc3VwcG9ydCB5ZXQuDQo+PiBNQVAtRS4gICBTb21lIGJ1enosIG5vIGFubm91bmNl ZCB0cmlhbHMgb3IgZGVwbG95bWVudHMsIG5vIGhvbWUgZ2F0ZXdheSBzdXBwb3J0IHlldC4NCj4+ IE5hdGl2ZSBkdWFsLXN0YWNrLiAgIFN0aWxsIHRoZSBnb2xkIHN0YW5kYXJkLCBidXQgZG9lc27i gJl0IHNvbHZlIElQdjQgYWRkcmVzcyBzaG9ydGFnZS4NCj4+IA0KPj4gKE5vdGUgdGhhdCDigJx5 ZXTigJ0gbWF5IGNoYW5nZSBhdCBhbnkgdGltZSkuDQo+PiBBcyBhIG1hdHRlciBvZiBkaXNjdXNz aW9uLCBkbyB5b3UgYWdyZWU/DQo+PiBUbyBndWlkZSBvdXIgd29yaywgaXMgdGhlcmUgd29yayB3 ZSBzaG91bGQgZG8gdG8gZG9jdW1lbnQgb3IgZGVwcmVjYXRlIGFueSBvZiB0aGVzZT8NCj4+IA0K Pj4gVGhhbmtzLA0KPj4gDQo+PiBMZWUNCg0K From nobody Sat Jan 27 14:40:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4F7126BFD for ; Sat, 27 Jan 2018 14:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, 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 EQWsaatYGLwC for ; Sat, 27 Jan 2018 14:40:38 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582F21201FA for ; Sat, 27 Jan 2018 14:40:38 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id m197so2399389vka.3 for ; Sat, 27 Jan 2018 14:40:38 -0800 (PST) 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=y3J3TQg+aaSk9wJgk0o+7BYqhtdD2B7yPWzv7IySla0=; b=YkaD6oyfikL7wUrldz/a2xia/g0Sh1btMcSBM2agevmZeADqyYBQifMTKxPQfjZwyn EzPBTVi5MnkqaaevT7lJmOYpLfwRL8UdAXvAGrMnY18eIegVP9ChDSRxcfd5YjVBUhCO 8so/1PK9NSm13tsYI9+2OUwARYO1NbtT9tKhfvRn+iNlCER8z3QCPCVC0VUdeZTDCLYv H1RWWWYfKjywWYjr4WgMuAe0rkeF0pIYx3cMOXRqZoHpCfoPaK/41WN5TmfTsl10DZ0G shUGV+Wz5lD/fQ0kdTGPBGto4Crnscx9QsnxVZ+FT9vEOLLiBFVNf5rLfHA5IYNcDmue pwaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=y3J3TQg+aaSk9wJgk0o+7BYqhtdD2B7yPWzv7IySla0=; b=NZtSez4RXX3uGFcvEExE5A9B48RwIIrjEBjv6oHSIxotYm4Pes0WHi+GWly9VmHbwi VX+1v4yk9xBdVr8ciaTsJIe6RlCNyws3g9jNVw3/LryxYE4N9mcghzcbFiM4z/62Sqh0 c+JuU92vhC+1FCRIvt0l89FC5oIu2naTNS2gitOFyCkpRSoExckd80NS6k3SvNvXOIXv SM89IsUyUuP0JcknVwgU6J/lc/kia18fJgLapviBhvOj+NEnHmT4iNfQnrWuJBbKvmIH iEYZW2q5QLkN/NFdxUz78BUVwLmiFOXkzMZAE+Ecg8qWinL4z5NHgp1YNNL58A1tMUBa k3eA== X-Gm-Message-State: AKwxytfz+3z+9oxL8TLEaZSgjAP7h3CcuD6F7Le5mEJ/Rp8c3IsWkrYJ aGFrj5PNzugIPNjLBkeW3ewuP6ovyiDpWy4TN7g= X-Google-Smtp-Source: AH8x224pB73OK5wdLIhher9Yey9N4BhKkW0AGj5v/pFFjYPVqPpjfUYnzssPOodDlUA5GHCi6uDxLhZ7rPFerxeKR5Q= X-Received: by 10.31.189.76 with SMTP id n73mr14480008vkf.3.1517092837124; Sat, 27 Jan 2018 14:40:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.246 with HTTP; Sat, 27 Jan 2018 14:40:36 -0800 (PST) Received: by 10.159.33.246 with HTTP; Sat, 27 Jan 2018 14:40:36 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Sun, 28 Jan 2018 09:40:36 +1100 Message-ID: To: v6ops list Content-Type: multipart/alternative; boundary="001a114dd9d4a5f0570563c9b317" Archived-At: Subject: [v6ops] LCA2018 - "IPv6 and Containers: Why We Can't Have Nice Things (And How We Can)" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Jan 2018 22:40:40 -0000 --001a114dd9d4a5f0570563c9b317 Content-Type: text/plain; charset="UTF-8" Worth a watch. Summary: IPv6 good for containers Cloud provider and container orchestration implementations of IPv6 not good https://youtu.be/eF50OxZ5u4o --001a114dd9d4a5f0570563c9b317 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Worth a watch.

    Summary:

    IPv6 good fo= r containers
    Cloud provider and container orchestrat= ion implementations of IPv6 not good



    --001a114dd9d4a5f0570563c9b317-- From nobody Mon Jan 29 16:13:07 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F44E131473 for ; Mon, 29 Jan 2018 16:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-rE017Hh9sO for ; Mon, 29 Jan 2018 16:13:03 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.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 7CAA6131470 for ; Mon, 29 Jan 2018 16:13:02 -0800 (PST) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id w0U0D0a3029426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jan 2018 18:13:00 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U0CsJQ061086; Mon, 29 Jan 2018 18:12:55 -0600 Received: from lxdnp32k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U0CsJo061080 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 29 Jan 2018 18:12:54 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U0CsxG018380; Mon, 29 Jan 2018 17:12:54 -0700 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U0Css2018376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jan 2018 17:12:54 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.77]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Mon, 29 Jan 2018 18:12:54 -0600 From: "Woodworth, John R" To: "'v6ops@ietf.org'" CC: "Ballew, Dean" , "'Dave Lawrence'" , "'shash raghu'" , "Woodworth, John R" Thread-Topic: I-D Action: draft-woodworth-bulk-rr-07.txt Thread-Index: AQHTYRvan/iKFaAXSU2coiu3/nPrHqOLylQQ Date: Tue, 30 Jan 2018 00:12:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.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, 30 Jan 2018 00:13:06 -0000 R3JlZXRpbmdzIFdHIE1lbWJlcnMsDQoNCkJlbG93IGlzIHRoZSBsYXRlc3QgcmVsZWFzZSBvZiBv dXIgZHJhZnQuICBJdCB3YXMgcG9zdGVkIGEgZmV3IG1vbnRocyBiYWNrIGJ1dA0Kd2UgZXhwZWN0 IHRvIGNvbXBsZXRlIGEgbmV3IHZlcnNpb24gdmVyeSBzb29uIGluY29ycG9yYXRpbmcgc29tZSB2 YWx1YWJsZQ0KZmVlZGJhY2sgd2XigJl2ZSByZWNlaXZlZC4NCg0KV2UgaGF2ZSBiZWVuIHByaW1h cmlseSB3b3JraW5nIHdpdGggdGhlIEROU09QIFdHIGJ1dCBzaW5jZSBvdXIgZHJhZnQgaGFzIGdy ZWF0DQpwb3RlbnRpYWwgaW4gdGhlIElQdjYgbmFtZXNwYWNlIChmb3J3YXJkIGFuZCByZXZlcnNl KSB3ZXJlIGhvcGluZyB0byBnZXQNCmZlZWRiYWNrIGFuZCBpbnNpZ2h0IHNvbWV3aGF0IHVuaXF1 ZSB0byB0aGlzIGF1ZGllbmNlLg0KDQpXZSBhcmUgb3BlbiB0byBhbnkgcXVlc3Rpb25zLyBjb21t ZW50cyBhbmQgd291bGQgYmUgZ3JhdGVmdWwgZm9yIGV4YW1wbGVzIG9mDQphbnkgcmVhbC13b3Js ZCBpc3N1ZXMgd2hlcmUgcGF0dGVybi1iYXNlZCBETlMgcmVjb3JkcyB3b3VsZCBlaXRoZXIgc29s dmUNCm9yIGdyZWF0bHkgbWluaW1pemUgdGhlIHByb2JsZW0uDQoNCkZvciBleGFtcGxlIC0gb24g dGhlIElQdjQgc2lkZSB3ZSBoYXZlIHNlZW4gc2V2ZXJhbCB6b25lLWZpbGVzLCBoZWF2eSBpbg0K JEdFTkVSQVRFJ3MsIGZhaWwgdG8gQVhGUiBkdWUgdG8gbGFyZ2UgKD4xMTBNQikgZXhwYW5kZWQg ZmlsZSBzaXplcyBldmVuIHRob3VnaA0KdGhlIG9yaWdpbmFsIHdhcyBjb21mb3J0YWJseSB1bmRl ciAxME1CLiAgT3VyIGRyYWZ0IHdvdWxkIHBvdGVudGlhbGx5IG1ha2UgdGhlDQpmaWxlIGV2ZW4g c21hbGxlciBhbmQgYWJsZSB0byBBWEZSIHdpdGhvdXQgaW5jcmVhc2luZyBpdHMgc2l6ZSBvdmVy LXRoZS13aXJlLg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgdGltZSBhbmQgYW55IGFzc2lzdGFuY2Ug eW91IGFyZSBhYmxlIHRvIG9mZmVyLg0KDQoNClJlZ2FyZHMsDQpKb2huDQoNCi0tLS0tLS0tIE9y aWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K U3ViamVjdDogW0ROU09QXSBJLUQgQWN0aW9uOiBkcmFmdC13b29kd29ydGgtYnVsay1yci0wNy50 eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBEb21haW4gTmFtZSBTeXN0ZW0gT3BlcmF0aW9ucyBXRyBvZiB0aGUgSUVURi4NCg0K ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBCVUxLIEROUyBSZXNvdXJjZSBSZWNvcmRzDQogICAg ICAgIEF1dGhvcnMgICAgICAgICA6IEpvaG4gV29vZHdvcnRoDQogICAgICAgICAgICAgICAgICAg ICAgICAgIERlYW4gQmFsbGV3DQogICAgICAgICAgICAgICAgICAgICAgICAgIFNoYXNod2F0aCBC aW5kaW5nYW5hdmVsaSBSYWdoYXZhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBEYXZpZCBD IExhd3JlbmNlDQpGaWxlbmFtZSAgICAgICAgOiBkcmFmdC13b29kd29ydGgtYnVsay1yci0wNy50 eHQNClBhZ2VzICAgICAgICAgICA6IDE2DQpEYXRlICAgICAgICAgICAgOiAyMDE3LTEwLTMwDQoN CkFic3RyYWN0Og0KICAgVGhlIEJVTEsgRE5TIHJlc291cmNlIHJlY29yZCB0eXBlIGRlZmluZXMg YSBtZXRob2Qgb2YgcGF0dGVybi1iYXNlZA0KICAgY3JlYXRpb24gb2YgRE5TIHJlc291cmNlIHJl Y29yZHMgYmFzZWQgb24gbnVtZXJpYyBzdWJzdHJpbmdzIG9mIHF1ZXJ5DQogICBuYW1lcy4gIFRo ZSBpbnRlbnQgb2YgQlVMSyBpcyB0byBzaW1wbGlmeSBnZW5lcmljIGFzc2lnbm1lbnRzIGluIGEN CiAgIG1lbW9yeS1lZmZpY2llbnQgd2F5IHRoYXQgY2FuIGJlIGVhc2lseSBzaGFyZWQgYmV0d2Vl biB0aGUgcHJpbWFyeQ0KICAgYW5kIHNlY29uZGFyeSBuYW1lc2VydmVycyBmb3IgYSB6b25lLg0K DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd29vZHdvcnRoLWJ1bGstcnIv DQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13b29kd29ydGgtYnVsay1yci0wNw0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13b29kd29ydGgtYnVsay1yci0w Nw0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd29vZHdvcnRoLWJ1bGstcnIt MDcNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRE5TT1AgbWFpbGluZyBsaXN0DQpETlNPUEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNvcA0KLS0gVEhFU0UgQVJFIFRI RSBEUk9JRFMgVE8gV0hPTSBJIFJFRkVSOg0KDQpUaGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHBy b3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNvbW11bmljYXRp b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGll cyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg0K From nobody Mon Jan 29 16:28:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777FC131470 for ; Mon, 29 Jan 2018 16:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 WDztIwK8I5gg for ; Mon, 29 Jan 2018 16:28:38 -0800 (PST) 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 A977813148F for ; Mon, 29 Jan 2018 16:28:38 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id u1so5802995pgr.0 for ; Mon, 29 Jan 2018 16:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Wy3hBDXbAmicA0a9qEb80kMxfhNjAEaY7DE4ygMGJAU=; b=a/JJqjAc7JBiBjku7Pz5hyL5EU12T7ivoeRH79JnmRrtKwhQKufE+vcHOXrqfwk7Ni rMqCYyCXjSwPbrpxpCJsvd47P4YjwRBvdgw1HhywAGN+jvCaHfwZYxpcx5jKjAribPDE hIY0jtIUyRZI8DeckZgo09C//T/QG1R01egqqE5R56dDqlpcqes7+iZ4eyRhYRKoZxoz +aGHMQWEHiLigXB/95NbtuqDruZ0xsjwpeHrIeKX+Lpdnxbh5Sic+WCLzKOrVVPIWh9O YSgVx7llJTYu3060uK7ewBytZMyRP3w5dOQav8NR2m4mgnMfW5cgdSxpVzpXwBHdWiT7 XzRw== 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=Wy3hBDXbAmicA0a9qEb80kMxfhNjAEaY7DE4ygMGJAU=; b=l9wivQ9YErZYJapv6FcjU1QzIzRqOfynOQQFumoHLqi0FAhDgZxMvrOW/T7dyr/je2 yx7edCBwrM0basJdzqRsM588K/PtwFuCwahTRe4COWIIEvgx44ad76ki52R9tcfTl80M CwNx3DdWK6fY84hg17m+8lSZx9SOzyvU+0G3+zt64Q3FLtn2k52SCFBLVq8SN7mw1WiI s4ITUyQI7nPXMb6Cbxb2NOmNUtIhZf64BtLqd/wbGFbPrOzfl8LOrZZPwVYEQLN2yywf WSImwjQoFJOI6Hji/pWfW1yso2whLZ7DnMDztlQaX2GeyYZMsqWK07O1hHMsz0Aq3W8X VLTg== X-Gm-Message-State: AKwxytfZ7mG9kTgaQIVHXp67MI7VAcxn2c17idkrl2Bl987O1MMIdTgG iU402OvDsh7PLkgf3kttP4E= X-Google-Smtp-Source: AH8x226cq/Fy3PDxbaT7mRXwLAa7DwX0RbO5guSu43MQI4m/yz5RU5NsU28y2TzVKg7/ulNk0emE2g== X-Received: by 10.98.160.25 with SMTP id r25mr28599744pfe.218.1517272118087; Mon, 29 Jan 2018 16:28:38 -0800 (PST) Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id d205sm32649867pfd.165.2018.01.29.16.28.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 16:28:37 -0800 (PST) From: Fred Baker Message-Id: <7CF9877D-80DA-4AFF-B6F7-3315BCA08899@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_43AECB5B-F238-4B73-B67B-49C72D5D7B47"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.9\)) Date: Mon, 29 Jan 2018 16:28:35 -0800 In-Reply-To: Cc: "v6ops@ietf.org" , Dave Lawrence , shash raghu , "Ballew, Dean" To: "Woodworth, John R" References: X-Mailer: Apple Mail (2.3445.6.9) Archived-At: Subject: Re: [v6ops] I-D Action: draft-woodworth-bulk-rr-07.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, 30 Jan 2018 00:28:40 -0000 --Apple-Mail=_43AECB5B-F238-4B73-B67B-49C72D5D7B47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Are you hoping to get the discussion on dnsop, or to happen here and be = forwarded or observed? > On Jan 29, 2018, at 4:12 PM, Woodworth, John R = wrote: >=20 > Greetings WG Members, >=20 > Below is the latest release of our draft. It was posted a few months = back but > we expect to complete a new version very soon incorporating some = valuable > feedback we=E2=80=99ve received. >=20 > We have been primarily working with the DNSOP WG but since our draft = has great > potential in the IPv6 namespace (forward and reverse) were hoping to = get > feedback and insight somewhat unique to this audience. >=20 > We are open to any questions/ comments and would be grateful for = examples of > any real-world issues where pattern-based DNS records would either = solve > or greatly minimize the problem. >=20 > For example - on the IPv4 side we have seen several zone-files, heavy = in > $GENERATE's, fail to AXFR due to large (>110MB) expanded file sizes = even though > the original was comfortably under 10MB. Our draft would potentially = make the > file even smaller and able to AXFR without increasing its size = over-the-wire. >=20 > Thank you for your time and any assistance you are able to offer. >=20 >=20 > Regards, > John >=20 > -------- Original message -------- > From: internet-drafts@ietf.org > Subject: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations WG of = the IETF. >=20 > Title : BULK DNS Resource Records > Authors : John Woodworth > Dean Ballew > Shashwath Bindinganaveli Raghavan > David C Lawrence > Filename : draft-woodworth-bulk-rr-07.txt > Pages : 16 > Date : 2017-10-30 >=20 > Abstract: > The BULK DNS resource record type defines a method of pattern-based > creation of DNS resource records based on numeric substrings of = query > names. The intent of BULK is to simplify generic assignments in a > memory-efficient way that can be easily shared between the primary > and secondary nameservers for a zone. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-woodworth-bulk-rr-07 > https://datatracker.ietf.org/doc/html/draft-woodworth-bulk-rr-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-woodworth-bulk-rr-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- THESE ARE THE DROIDS TO WHOM I REFER: >=20 > This communication is the property of CenturyLink and may contain = confidential or privileged information. Unauthorized use of this = communication is strictly prohibited and may be unlawful. If you have = received this communication in error, please immediately notify the = sender by reply e-mail and destroy all copies of the communication and = any attachments. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_43AECB5B-F238-4B73-B67B-49C72D5D7B47 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpvvDMACgkQEhdRnd2G P+DLqw/+MMWlGUNNRr90Avy1Y5vsFfAsDOcEO1iQsLJzSEkNbIPE5t6lwRI+zJcX shlN+92FG3ufCwAoPdA9fvO9iUSOKqdT6wexMr3Z9IXgpRpMthFelH4+AcqVlK5b P604DEAznvz32VzxpkKxdEbUi2f7+Z99MlEDGnVAPN9A7zbCZDJ//lUzv152VEuU YDuWG/krzwYWE/eOO9ZI1L6vmJWw3MAxIcBUAvcIdmTZobZQEsT9/34TreigMWDg +RPbgqgqXk/7ZpjxCvzTYcWAW7Nzd6qsaPEIrPIpWezyq6zD76oMkpBuWK3NhGMQ AXDsercXkbonyf57d1ro1FHeAruGZv4yy16aa85cwzFq0HzVJQljoAO9gOLZuYYy Nz6Or/7sC1oqNPVrrV38HqFecTqwNW3DAtsACqtVcFKbW7e0PUmysn1CWkLg5bw7 kNWkKTJpyemuw3wY0eiuxDoOHwwcqSdA1Ew6/q5zhEwoNtWF7+o3bsnYDUiHtKB6 RDsVPQrYpF4TaQs/VmUQBxy3bsWG3jXQOzhyp8PKKVi9dmr/rbvuhRnjZMgd4+rt eCM0x9y6IQE9AoMXybrl2u2Fm57PuVHqZL1erQy6lQyi6d/Rhxr+v7YkJUQ+Am67 7Pej6KWS9qKrnOcPfRPhUNmZHLeN0Qe4N2rBuKJBp4PZS81j8oY= =mGLV -----END PGP SIGNATURE----- --Apple-Mail=_43AECB5B-F238-4B73-B67B-49C72D5D7B47-- From nobody Tue Jan 30 00:03:33 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D89131AD3 for ; Tue, 30 Jan 2018 00:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH09RROjqzsL for ; Tue, 30 Jan 2018 00:03:30 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.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 5BAF0131A3E for ; Tue, 30 Jan 2018 00:00:58 -0800 (PST) Received: from lxdnp04n.corp.intranet (emailout.qintra.com [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id w0U80u9l065415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jan 2018 02:00:56 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U80oox026587; Tue, 30 Jan 2018 01:00:51 -0700 Received: from lxdnp31k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U80oog026492 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Tue, 30 Jan 2018 01:00:50 -0700 Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U80oGd031577; Tue, 30 Jan 2018 01:00:50 -0700 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w0U80oeh031568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jan 2018 01:00:50 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.77]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Tue, 30 Jan 2018 02:00:49 -0600 From: "Woodworth, John R" To: "'Fred Baker'" CC: "v6ops@ietf.org" , Dave Lawrence , "shash raghu" , "Ballew, Dean" , "Woodworth, John R" Thread-Topic: [v6ops] I-D Action: draft-woodworth-bulk-rr-07.txt Thread-Index: AQHTYRvan/iKFaAXSU2coiu3/nPrHqOLylQQgACakICAABaXgA== Date: Tue, 30 Jan 2018 08:00:50 +0000 Message-ID: References: <7CF9877D-80DA-4AFF-B6F7-3315BCA08899@gmail.com> In-Reply-To: <7CF9877D-80DA-4AFF-B6F7-3315BCA08899@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-woodworth-bulk-rr-07.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, 30 Jan 2018 08:03:32 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEZyZWQgQmFrZXIgW21haWx0bzpm cmVkYmFrZXIuaWV0ZkBnbWFpbC5jb21dDQo+DQo+DQo+IEFyZSB5b3UgaG9waW5nIHRvIGdldCB0 aGUgZGlzY3Vzc2lvbiBvbiBkbnNvcCwgb3IgdG8gaGFwcGVuIGhlcmUNCj4gYW5kIGJlIGZvcndh cmRlZCBvciBvYnNlcnZlZD8NCj4NCg0KSGkgRnJlZCwNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRi YWNrIQ0KDQpXZSd2ZSBiZWVuIGNvbW11bmljYXRpbmcgd2l0aCBkbnNvcCBidXQgd2FudGVkIHRv IG1ha2Ugc3VyZSB3ZQ0KaW5jbHVkZWQgYWxsIHRoZSByaWdodCB2b2ljZXMgKGR1ZSBkaWxpZ2Vu Y2UpLg0KDQpJIHdhcyB0aGlua2luZyB3ZSB3b3VsZCBkaXNjdXNzIGl0IGhlcmUgYnV0IHVuZGVy c3RhbmQgdGhlcmUNCmlzIGEgZmFpciBiaXQgb2Ygb3ZlcmxhcCBzbyBhbSBmaW5lIHdpdGggd2hh dGV2ZXIgaGFwcGVucw0Kb3JnYW5pY2FsbHkuDQoNCg0KVGhhbmtzLA0KSm9obg0KDQo+DQotLSBU SEVTRSBBUkUgVEhFIERST0lEUyBUTyBXSE9NIEkgUkVGRVI6DQpUaGlzIGNvbW11bmljYXRpb24g aXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNv bW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kg YWxsIGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg0K From nobody Tue Jan 30 09:58:22 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC61F12751F for ; Tue, 30 Jan 2018 09:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 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, 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 hHEvXNR55k8A for ; Tue, 30 Jan 2018 09:58:19 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928F912F281 for ; Tue, 30 Jan 2018 09:57:53 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id 141so2885911wme.3 for ; Tue, 30 Jan 2018 09:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=1MXwMYrAB17Ro46kuHbwehpTjGHVtxns3xHO/2LSd7Q=; b=mSmEVRqS2bQbqR/c525qvdRlhrbHPlHv2NxLVHlAChAmxbr6v94s/XlZTxm4CKPgFY +wCJ3O/UEEUcycTmuSYWG82Ozpk8S+T7FHMEThHFr2mj4a6F/JhgOZ3ng0dNuE5fnJkR RMfp8P13mhD4+TkBgL4m+GC0rMCgr6BPL5KcahtJg2Cdj0F4WVzBc994Druy883twZNV tcmTaZX8G8gGGV0LNDOd9tvIFADuulWvpzVJQC9xo3MR+wr2VXW9KIEmMH2rS4IpXomj LteOlCEI93emj2Oqp93mEivEB9B/4jraFysbU21KomBywVSmkJUVV10Dw/fOj8zF2ihz gdEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=1MXwMYrAB17Ro46kuHbwehpTjGHVtxns3xHO/2LSd7Q=; b=LzWbxUvXivVSvg1lDyr+hQfsbydBUmmkatXOQrO65vVa0w6U9qhUUHOIoHg0sDfV02 /TWyRa3L6cQgt1wXXH/9oHwFDv02OCCDUs+Kl4M6VRmDAUP/MMtTHuxpTaBLBmCcorbF 7n1/ZioeYRVU0XI1qHnrf/Qh0Vx1WMOTKi+XYkplI1t5PuddzaqH/jKFGVLyxMl3y9t/ uzrtMWBXm9HIPn5SAhQf725pDw7xkD9rehYM+Kb+q2EKnoNL0xFl4Mw4Mhb7Mrye8q+m SJYI9q424yqLmG1NMDfoBKO0DxORCCvuHtjmvqeX1H4ZVewjYgFq6CuJw1ViTfGrRw1C 9p6Q== X-Gm-Message-State: AKwxytfF7DEg0se8lIn5Nv+g4feqlQkV8PJFwXMDWSZDziOlIjE7K8rx LEcO6zGzt1UseKSAg+g5MBDo47nKzadvfDHHujY= X-Google-Smtp-Source: AH8x22761edXsf7DT0NJEQPYWYDkadST/W4rpXtz2z3HqbK+Z/sL19swNsL9HEThMLi26imw0mPPwmPv8AW7cyZtVPw= X-Received: by 10.28.128.82 with SMTP id b79mr20810428wmd.113.1517335071965; Tue, 30 Jan 2018 09:57:51 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.133.183 with HTTP; Tue, 30 Jan 2018 09:57:51 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 30 Jan 2018 09:57:51 -0800 X-Google-Sender-Auth: yCcXKuBYQxtkpz8pTi9d-no2EPI Message-ID: To: "Woodworth, John R" Cc: "v6ops@ietf.org" , Dave Lawrence , shash raghu , "Ballew, Dean" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.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, 30 Jan 2018 17:58:22 -0000 At Tue, 30 Jan 2018 00:12:53 +0000, "Woodworth, John R" wrote: > Below is the latest release of our draft. It was posted a few months bac= k but > we expect to complete a new version very soon incorporating some valuable > feedback we=E2=80=99ve received. > > We have been primarily working with the DNSOP WG but since our draft has = great > potential in the IPv6 namespace (forward and reverse) were hoping to get > feedback and insight somewhat unique to this audience. > > We are open to any questions/ comments and would be grateful for examples= of > any real-world issues where pattern-based DNS records would either solve > or greatly minimize the problem. I suspect the draft is mostly about DNS specific details that many of the v6ops participants don't bother to care:-) So I guess this email thread at dnsop provides nice higher-level background: https://www.ietf.org/mail-archive/web/dnsop/current/msg20488.html My interpretation of the thread is that the dnsop WG was generally not fully convinced about the need for a new trick to provide individual (different) IPv6 reverse DNS records (i.e. PTR) for a large IPv6 address space, given that the complexity of the proposal and the impact on implementations would be quite significant. If v6ops can help the discussion, I guess it would be opinions on the need for such bulk PTRs for IPv6 addresses from large-scale IPv6 operators. (I'm not that kind of person so I can't provide it, unfortunately). -- JINMEI, Tatuya From nobody Wed Jan 31 10:14:08 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F23131895 for ; Wed, 31 Jan 2018 10:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNgudqMUb096 for ; Wed, 31 Jan 2018 10:14:00 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.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 EE75C12EB77 for ; Wed, 31 Jan 2018 10:13:43 -0800 (PST) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id w0VIDfB0045213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 31 Jan 2018 12:13:41 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VIDaBM025511; Wed, 31 Jan 2018 11:13:36 -0700 Received: from lxomp07u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VIDZUn025472 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 31 Jan 2018 11:13:35 -0700 Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VIDZBe043865; Wed, 31 Jan 2018 12:13:35 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VIDZbn043861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jan 2018 12:13:35 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.77]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Wed, 31 Jan 2018 12:13:35 -0600 From: "Woodworth, John R" To: "'jinmei@wide.ad.jp'" CC: "v6ops@ietf.org" , Dave Lawrence , "shash raghu" , "Ballew, Dean" , "Woodworth, John R" Thread-Topic: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.txt Thread-Index: AQHTYRvan/iKFaAXSU2coiu3/nPrHqOLylQQgAG/uoCAASib8A== Date: Wed, 31 Jan 2018 18:13:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.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, 31 Jan 2018 18:14:07 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqaW5tZWkudGF0dXlhQGdtYWls LmNvbSBbbWFpbHRvOmppbm1laS50YXR1eWFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgPz8/Pw0K Pg0KPiBJIHN1c3BlY3QgdGhlIGRyYWZ0IGlzIG1vc3RseSBhYm91dCBETlMgc3BlY2lmaWMgZGV0 YWlscyB0aGF0IG1hbnkgb2YNCj4gdGhlIHY2b3BzIHBhcnRpY2lwYW50cyBkb24ndCBib3RoZXIg dG8gY2FyZTotKSBTbyBJIGd1ZXNzIHRoaXMgZW1haWwNCj4gdGhyZWFkIGF0IGRuc29wIHByb3Zp ZGVzIG5pY2UgaGlnaGVyLWxldmVsIGJhY2tncm91bmQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvZG5zb3AvY3VycmVudC9tc2cyMDQ4OC5odG1sDQo+DQo+IE15IGlu dGVycHJldGF0aW9uIG9mIHRoZSB0aHJlYWQgaXMgdGhhdCB0aGUgZG5zb3AgV0cgd2FzIGdlbmVy YWxseQ0KPiBub3QgZnVsbHkgY29udmluY2VkIGFib3V0IHRoZSBuZWVkIGZvciBhIG5ldyB0cmlj ayB0byBwcm92aWRlIGluZGl2aWR1YWwNCj4gKGRpZmZlcmVudCkgSVB2NiByZXZlcnNlIEROUyBy ZWNvcmRzIChpLmUuIFBUUikgZm9yIGEgbGFyZ2UgSVB2Ng0KPiBhZGRyZXNzIHNwYWNlLCBnaXZl biB0aGF0IHRoZSBjb21wbGV4aXR5IG9mIHRoZSBwcm9wb3NhbCBhbmQgdGhlDQo+IGltcGFjdCBv biBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgcXVpdGUgc2lnbmlmaWNhbnQuICBJZiB2Nm9wcyBj YW4NCj4gaGVscCB0aGUgZGlzY3Vzc2lvbiwgSSBndWVzcyBpdCB3b3VsZCBiZSBvcGluaW9ucyBv biB0aGUgbmVlZCBmb3INCj4gc3VjaCBidWxrIFBUUnMgZm9yIElQdjYgYWRkcmVzc2VzIGZyb20g bGFyZ2Utc2NhbGUgSVB2NiBvcGVyYXRvcnMuDQo+IChJJ20gbm90IHRoYXQga2luZCBvZiBwZXJz b24gc28gSSBjYW4ndCBwcm92aWRlIGl0LCB1bmZvcnR1bmF0ZWx5KS4NCj4NCj4gLS0NCj4gSklO TUVJLCBUYXR1eWENCj4NCg0KSGkgSmlubWVpLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVu dHMuDQoNCkl0IHNlZW1zIHRoZXJlIGFyZSBhIG51bWJlciBvZiBtZW1iZXJzIHRoYXQgZmVlbCBp dCdzIHBlcmZlY3RseQ0KcmVhc29uYWJsZSB0byBpZ25vcmUgSVB2NiBQVFIncyBhbHRvZ2V0aGVy Lg0KDQpVbmZvcnR1bmF0ZWx5LCBJIGFtIG5vdCBpbiBhIHBvc2l0aW9uIHRvIGRvIHNvIGJlY2F1 c2UgYXMgYQ0KcHJvdmlkZXIgd2UgYXJlIGV4cGVjdGVkIHRvIHByb3ZpZGUgb3VyIGN1c3RvbWVy cyB3aXRoIHF1YWxpdHkNCnNlcnZpY2UgYW5kIGhvbm9yIHJlYXNvbmFibGUgcmVxdWVzdHMuDQoN ClNpbmNlIGEgbnVtYmVyIG9mIGNvbW1lcmNpYWwgdmVuZG9ycyAqYWxyZWFkeSogb2ZmZXIgdGhp cyBmZWF0dXJlDQp0byB0aGVpciBjdXN0b21lcnMgSSBkbyBub3QgYmVsaWV2ZSBpdCB0byBiZSBh biB1bnJlYXNvbmFibGUgcmVxdWVzdC4NCg0KUmF0aGVyIHRoYW4gaGFjayB0b2dldGhlciBhbm90 aGVyIHN1Y2ggc2VydmljZSwgSSBmZWVsIGl0IGJldHRlcg0Kc2VydmVzIG91ciBjdXN0b21lcnMg YW5kIHRoZSBjb21tdW5pdHkgYXMgYSB3aG9sZSB0byBwcm92aWRlDQoiY29tcGF0aWJpbGl0eSIg d2l0aCB0aGlzIGZlYXR1cmUgYW5kIG5vdCBqdXN0IGFkZCB0byB0aGUgbnVtYmVyDQpvZiBwcm9w cmlldGFyeSBzb2x1dGlvbnMgY3VycmVudGx5ICp1bmFibGUqIHRvIHBsYXkgbmljZSB3aXRoDQpv bmUgYW5vdGhlciBhcyB3ZSBoYXZlIHRvZGF5Lg0KDQpXaGlsZSB3b3JraW5nIHRocm91Z2ggdGhl IGNvbmNlcHQsIHdoaWNoIHdhcyBJUHY0IG1vdGl2YXRlZCwgaW4gb3JkZXINCnRvIGhlbHAgaW4g dGhlIGRheS10by1kYXkgcmVhbC13b3JsZCBwcm9ibGVtIG9mIG1hbmFnaW5nIHRob3VzYW5kcw0K b2YgJEdFTkVSQVRFJ3MuICAiV2hvIGNvdWxkIHBvc3NpYmx5IGJlIGFnYWluc3QgdHJhbnNmZXJh YmxlDQokR0VORVJBVEUncz8iLCB3ZSB0aG91Z2h0LiAgIiRHRU5FUkFURSdzIHVuYWJsZSB0byBz dGVwIG9uIG90aGVyDQpyZWNvcmRzLCB0aGlzIHdpbGwgc3VyZWx5IGJlIGNlbGVicmF0ZWQhIiwg d2Ugc2FpZCBhbmQgY2hvc2UNCnRvIHNoYXJlLg0KDQpOb3cgaGVyZSB3ZSBhcmUsIGRlY2lkZWRs eSBodW5nIHVwIG9uIHRoZSAiaWNpbmciIChJUHY2KQ0Kb2YgYWxsIHRoaW5ncyA6KSAuDQoNCg0K SW4gYW55IGNhc2UsIHRoYW5rIHlvdSBhZ2FpbiBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGNvbW1l bnQsDQppdCBpcyBncmVhdGx5IGFwcHJlY2lhdGVkLg0KDQoNCi9Kb2huDQotLSBUSEVTRSBBUkUg VEhFIERST0lEUyBUTyBXSE9NIEkgUkVGRVI6DQpUaGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHBy b3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNvbW11bmljYXRp b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGll cyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg0K From nobody Wed Jan 31 10:57:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D812EBF0 for ; Wed, 31 Jan 2018 10:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 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, 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 ZM96AS43ZNzD for ; Wed, 31 Jan 2018 10:57:38 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A1912D84E for ; Wed, 31 Jan 2018 10:57:37 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id 143so1085921wma.5 for ; Wed, 31 Jan 2018 10:57:37 -0800 (PST) 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=dVdBqq5QRmW7D6x2nXpO5ubMicXkrwlo2in0rJbdexM=; b=GmJKaj3WL2lyGBmApLTBb2ZW6p3g+oMVXgYJMIbftEmojHKSfmdA4QY4yO9E/MozF5 k88uk+9E7pi27K7Z5Xec23/wQ7jX5xglplTrqzu9oagyHVAqb76t8Df25hHJ/rsEWbZO 1iVn2d+4OZIo900lelbo9U0rmB/rat9i7ZnqblJk8++yoNJdJnGBJsYeCHi4idvkWcQh 0A7aSjaqEBZpRAraEglo7YcCdDZiElQZWqOmRjmEJjiT5crDWPS79v86wtO3aAeWT8/v ++kbCkv95wPDKtyU5bQ1ZCFuJppohHlVpiRRfGoNmFcTxLLEJ3BIvwRrMaYxfc0WcTbR fS/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:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dVdBqq5QRmW7D6x2nXpO5ubMicXkrwlo2in0rJbdexM=; b=VUeSl4HwY1h57ccpIEXC5qeGntrGt1VzO9zwTvSwkNGaUehSG8XSdrcWlTKBidBNkH pH42uKK3MWLZJ2hYJSZtG5ULjZYmGxEHSZp6lG66LVrJohbHsInfGj4KQGcxJTIEUx19 9bTHSTc/oY+v3PPPq9+1mKz2TN/ku2QmYlL1129qDIZ4koL0Y3KIh4vEI+ZNtNIFkimf 4Ufqxyx/85vjJJp9oc3OptZz2dtq37OMg27GihE/NPuLl1Lm3WmUqpWJJhCGs9/qo9qf 651Vls3x/1T+bPCLvPwbgIM2REbUtaCyIQMQhau84Mw2Hk3VtRqJehasrXnpnArsX6JZ NmzA== X-Gm-Message-State: AKwxytcfrydpW8u3BWXFUu5Y1DTCEwITyDfNqN7LIQctQ6Ne70NUNYr8 /L6b0Rxnv7TsFvFb3ustP7UFwMOy08rLgGuWQX8= X-Google-Smtp-Source: AH8x226WNgJgATUpqpZFbj0/R6bEN7Q37rm3ltjq5X9Q88HO3z2ylZIhnQmI7nttUyceMI6Fbow3p9V5nP8uW7yDKBM= X-Received: by 10.28.53.130 with SMTP id c124mr22083974wma.110.1517425056349; Wed, 31 Jan 2018 10:57:36 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.133.189 with HTTP; Wed, 31 Jan 2018 10:57:35 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 31 Jan 2018 10:57:35 -0800 X-Google-Sender-Auth: eTPJ0ZMWQopZqiKw6NGVdeeFTtI Message-ID: To: "Woodworth, John R" Cc: "v6ops@ietf.org" , "Ballew, Dean" , shash raghu , Dave Lawrence Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.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, 31 Jan 2018 18:57:40 -0000 At Wed, 31 Jan 2018 18:13:34 +0000, "Woodworth, John R" wrote: > It seems there are a number of members that feel it's perfectly > reasonable to ignore IPv6 PTR's altogether. I thought it was more subtle. In my understanding it was about the need for a standard DNS protocol extension to provide different PTRs for a large set (say, /64) of different IPv6 addresses. And my understanding is that the dnsop people didn't see a strong need for it, especially if it requires a substantial protocol enhancement. This message in the dnsop thread I referred to shows that: https://www.ietf.org/mail-archive/web/dnsop/current/msg20507.html In my previous comment I tried to point out that if v6ops people have some opinion on this point (either positive or negative) that would be good feedback to the dnsop discussion. -- JINMEI, Tatuya From nobody Wed Jan 31 11:50:19 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432AB12F4CC for ; Wed, 31 Jan 2018 11:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgaF2fTgNJp1 for ; Wed, 31 Jan 2018 11:50:15 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.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 A95A312F4C4 for ; Wed, 31 Jan 2018 11:50:15 -0800 (PST) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id w0VJoDaH029211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 31 Jan 2018 13:50:13 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VJo8Dn015881; Wed, 31 Jan 2018 13:50:08 -0600 Received: from lxdnp31k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VJo7Tm015865 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 31 Jan 2018 13:50:08 -0600 Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VJo7nl059169; Wed, 31 Jan 2018 12:50:07 -0700 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w0VJo64v059094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jan 2018 12:50:07 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.77]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Wed, 31 Jan 2018 13:50:07 -0600 From: "Woodworth, John R" To: "'jinmei@wide.ad.jp'" CC: "v6ops@ietf.org" , "Ballew, Dean" , shash raghu , "Dave Lawrence" , "Woodworth, John R" Thread-Topic: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.txt Thread-Index: AQHTYRvan/iKFaAXSU2coiu3/nPrHqOLylQQgAG/uoCAASib8IAAemqA//+oZ9A= Date: Wed, 31 Jan 2018 19:50:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] FW: I-D Action: draft-woodworth-bulk-rr-07.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, 31 Jan 2018 19:50:17 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqaW5tZWkudGF0dXlhQGdtYWls LmNvbSBbbWFpbHRvOmppbm1laS50YXR1eWFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgPz8/Pw0K Pg0KPiBBdCBXZWQsIDMxIEphbiAyMDE4IDE4OjEzOjM0ICswMDAwLA0KPiAiV29vZHdvcnRoLCBK b2huIFIiIDxKb2huLldvb2R3b3J0aEBDZW50dXJ5TGluay5jb20+IHdyb3RlOg0KPg0KPiA+IEl0 IHNlZW1zIHRoZXJlIGFyZSBhIG51bWJlciBvZiBtZW1iZXJzIHRoYXQgZmVlbCBpdCdzIHBlcmZl Y3RseQ0KPiA+IHJlYXNvbmFibGUgdG8gaWdub3JlIElQdjYgUFRSJ3MgYWx0b2dldGhlci4NCj4N Cj4gSSB0aG91Z2h0IGl0IHdhcyBtb3JlIHN1YnRsZS4gIEluIG15IHVuZGVyc3RhbmRpbmcgaXQg d2FzIGFib3V0IHRoZSBuZWVkIGZvcg0KPiBhIHN0YW5kYXJkIEROUyBwcm90b2NvbCBleHRlbnNp b24gdG8gcHJvdmlkZSBkaWZmZXJlbnQgUFRScyBmb3IgYSBsYXJnZSBzZXQNCj4gKHNheSwgLzY0 KSBvZiBkaWZmZXJlbnQgSVB2NiBhZGRyZXNzZXMuICBBbmQgbXkgdW5kZXJzdGFuZGluZyBpcyB0 aGF0IHRoZQ0KPiBkbnNvcCBwZW9wbGUgZGlkbid0IHNlZSBhIHN0cm9uZyBuZWVkIGZvciBpdCwg ZXNwZWNpYWxseSBpZiBpdCByZXF1aXJlcyBhDQo+IHN1YnN0YW50aWFsIHByb3RvY29sIGVuaGFu Y2VtZW50Lg0KPiBUaGlzIG1lc3NhZ2UgaW4gdGhlIGRuc29wIHRocmVhZCBJIHJlZmVycmVkIHRv IHNob3dzIHRoYXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5z b3AvY3VycmVudC9tc2cyMDUwNy5odG1sDQo+DQo+IEluIG15IHByZXZpb3VzIGNvbW1lbnQgSSB0 cmllZCB0byBwb2ludCBvdXQgdGhhdCBpZiB2Nm9wcyBwZW9wbGUgaGF2ZSBzb21lDQo+IG9waW5p b24gb24gdGhpcyBwb2ludCAoZWl0aGVyIHBvc2l0aXZlIG9yIG5lZ2F0aXZlKSB0aGF0IHdvdWxk IGJlIGdvb2QNCj4gZmVlZGJhY2sgdG8gdGhlIGRuc29wIGRpc2N1c3Npb24uDQo+DQo+IC0tDQo+ IEpJTk1FSSwgVGF0dXlhDQo+DQpUaGFua3MgYWdhaW4hICBJIGFncmVlLCB0aGlzIGlzIGV4YWN0 bHkgd2hhdCBJIHdhcyBob3BpbmcgZm9yICh2Nm9wcyBmZWVkYmFjaykuDQoNCi9Kb2huDQotLSBU SEVTRSBBUkUgVEhFIERST0lEUyBUTyBXSE9NIEkgUkVGRVI6DQpUaGlzIGNvbW11bmljYXRpb24g aXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNv bW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kg YWxsIGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg0K